The Background

IBM announced the withdrawal from marketing of Development Management System (DMS/CICS/VS-OS, 5740-XC5 and DMS/CICS/VS-DOS, 5846-XC4) effective April 2003. This would indicate that, if IBM follows past practices, the above products should be withdrawn from service and support around mid-2005.

CSP was a follow-on product containing similar panel structures as DMS. For the remainder of this document, any mention of DMS implies CSP also.

So you now have a couple of years to migrate or convert the DMS applications you have in house to some more modern and supported environment. In order to determine a migration path, one must first look at some fairly typical DMS characteristics.

This product was extremely popular in the very late 1970s and early 1980s as a way of quickly prototyping and then building a CICS application. The author of this article used to use the VM version of DMS to prototype an application, gain user acceptance, and then build the application under CICS. Some people may still know this product as Display Management System.

DMS has some general characteristics that almost all current users share.

DMS was designed so that DMS panels defined the online presentation and data representation to the user.

The panels also defined and described the current process to perform and initiated most business function logic within exits defined from the panel.

Through use of pre-defined panel descriptions, navigation between panels was accomplished when either the current defined process ended or the user selected a specific Program Function (PF) Key.

These panels also provided access to I/O handlers for generalized add, update, delete, and view of VSAM flat files as well as hierarchical database (IMS-DLI) structures.

Other observations about DMS that are important are:

Over 80% of the DMS systems have 90% of the business logic in one or more high-level language panel exits.

Most uses of DMS are as a panel manager. Not used for extensive I/O or direct business logic. All of the heavy duty I/O was relegated to exits.

There is no COMMAREA used in standard DMS panel systems.

 

Drawing Some Equivalents In Today’s Object Environment

The DMS structure was way ahead of its time in some respects. The structure recognized that business logic was self-contained and separate from presentation. This was more because the product was lacking a great deal of functionality that could only be done by a high-level language in an exit.

The data presentation was handled within a layer separated from the business logic.

Simple I/O was handled separately from business logic.

One can look at the overall execution environment of DMS and immediately see many of these correlations and correspondences to today’s objects (methods and data).

Earlier Migrations From DMS Can Help Today

As users began mobbing away from developing new applications with DMS and in some cases moving existing applications to native CICS and BMS, several user tools were independently developed to assist in the conversion and migration. The first was to convert the DMS panels and its Field Definition Records to BMS. Then create a COMMAREA description based on the developed BMS. Once this was done final movement to a COMMAREA-based 3270 BMS application was pretty much a snap.

Back in 1989, a home-brewed, rudimentary tool was developed by Paul Henken, a systems professional in Tucson. This tool, known as DMS2BMS, took existing DMS panel definitions and translated them to BMS statements. DMS2BMS processes the DMS/CMS panel file field by field (top to bottom, left to right). Additional data is

obtained for each field from the Field Definition Record, located below the panel layout. DFHMDF macro names are constructed from the row and column position of the attribute byte. It is assumed that the programmer will change these to meaningful

names or that the Symbolic Map will be redefined with COBOL variable names.

The objective of DMS2BMS is to reduce clerical effort not to eliminate the CICS programmer. The BMS Assembler program will still need to be reviewed and completed for the mapset name, map name, macro names (if map is not redefined), and BMS

parameters not provided by DMS/CMS such as FSET, PICIN, PICOUT, etc.

This was a REXX-based tool but the general concept and content can be moved into many other interpretive languages that exist today. You can find the original source by clicking here or by going to http://www.xephon.com/arcframe/c043a06.

In 1990, the BMS to COMMAREA portion was addresses by a second tool also created by Paul Henken.

BMS2DCA processes the BMS map, macro by macro, creating corresponding COBOL variables in the shadow screen. In addition a one-byte status switch is created for each variable in order to assist in controlling input edit processing.

The generated DFHCOMMAREA will still need to be reviewed and completed for any necessary data fields that are not related to the screen. Also 'output-only' fields, such as fields used to display messages, should be removed unless the data is to be used for editing input fields.

This was a REXX-based tool but the general concept and content can be moved into many other interpretive languages that exist today. You can find the original source by clicking here or by going to http://www.xephon.com/arcframe/c059a04.

With an in-house version of the two tools mentioned above, a current CICS user can create the necessary BMS and COMMAREA required.

Then manually build an I/O "object" to handle the DMS panel defined I/O. Some modern day tools can assist here. COMPUWARE’s File-AID/MVS has added the XMLGEN utility feature that allows an application programmer to create an XML document from the merged contents of a data record and a copybook layout. We assume that the IBM File Manager product will also have this utility very soon. The programmer can now encapsulate the old I/O content into an XML aware object (new Enterprise COBOL For z/OS or say a JAVA object) to perform the equivalent I/O.

Finally create and modify the existing DMS exits as new objects. It would be best to use XML aware compilers for this. So if your exit is COBOL or PLI, use the IBM Enterprise COBOL or PLI level compilers with their new XML parsing support.

What To Do With the Objects

Now the user can choose several approaches to final conversion.

First the user can decide to utilize the 3270 bridging that has existed since CICS TS 1.3. In this case the new BMS maps would be re-translated through the Bridge supplied components to create HTML files. Then the user would create one driver application in an object-oriented language that the bridge can be associated with and execute the various objects via the bridge and under CICS Business Transaction Services (BTS).

Or the user may determine that the best long-term approach would be execution of the required objects via a SOAP Server approach. This would require imbedding SOAP headers for the CICS driver module into XML generated versions of the BMS Maps. Again Business Transaction Services (BTS) would serve as the glue to pull the transaction objects together into a valid process flow.

San Francisco-based Forecross was an early pioneer in XML exploitation in the CICS environment. They have a full set of tools to convert CICS CSP (DMS) or VSAM applications to full XML exploiters. View their website at:

http://www.forecross.com/index.htm .

Don Estes has written a plethora of papers about XML and its robust future that can be found at: http://www.forecross.com/white-papers/index.htm . Pay particular attention to Estes’ "XML As Glue" and "XML: The Future of Data" articles found at the above website.

Summary

There is no "magic bullet" for migrating away from DMS panel structures. But there are old and new tools and environments that can make the migration much less painful. In most cases, with a properly trained individual a single DMS application would be able to be converted, and system tested within a one-week to two-week period. Almost all of the labor will be to draw proper correlation and relationships between the inputs and outputs of each tool mentioned above and then creation of the necessary objects to replace I/O functions provided by DMS. Most sites would require one to two days of DMS and current objects aware party to develop the correspondences and correlations for the technical laborer to follow.

Use your browser Back Button to return to previous page.