Converting DMS/CICS/VS

(Approaches for DMS 5740-XC5 Removal)

By

Don Fowler, MCE, Inc. February 2005

 

DMS/CICS/VS V1.5 Ends Support

IBM announcement letter 904-151 (August 3, 2004) announced end of support for Development Management System CICS/VS-OS 1.5 (5740-XC5) as of September 30,2005.

 

There is no replacement product available.

 

DMS still works under CICS TS 2.2 and 2.3 with DMS user exits using the old OS/VS COBOL. 

 

The LE runtime must be used in CICS TS 3.1 and so it looks like CICS TS 2.3 will be the last release where you can run your DMS 1.5 COBOL exits code with OS/VS COBOL. CICS TS V3.1 to be available March 25, 2005, no longer supports nor provides any OS/VS COBOL Runtime. OS/VS COBOL programs (i.e., DMS User Exits) which had runtime support in CICS Transaction Server for z/OS, Version 2, cannot run under CICS TS for z/OS, Version 3. OS/VS COBOL programs must be upgraded to Language Environment® conforming COBOL, and recompiled against a level of COBOL compiler supported by CICS. A new abend code ALIK indicates an attempt to use an OS/VS COBOL program.

 

Enterprise COBOL for z/OS and OS/390® Version 3 is the IBM recommended compiler. CICS TS allows and supports VS COBOL II, COBOL/370, COBOL For OS/390 and VM, and COBOL For MVS and VM but only when compiled with the COBOL3 option (LE Runtime.)   

 

What To Do About DMS Applications

Several CICS Clients have already placed help wanted ads for project people to convert DMS panels and user exits to BMS Maps and standard CICS COMMAREA-based applications. 

 

The DMS to BMS conversion alternative may well be a much more expensive and lengthier then expected project which, at the end, would leave you with a standard 3270 “Green Screen” application.

 

In order for an organization to best decide the appropriate course of action for their elderly DMS applications, the decision makers and project planners must be aware of the significant differences between a DMS architected application and a corresponding BMS application. 

 

The Son of DMS/CICS Was CSP/AD and CSP/AE

DMS came as a single package containing both the development layer and the application runtime execution services. DMS was specific to CICS Application Development.  Cross System Product (CSP) was the next generation (1988) of structured design and service routine reuse. CSP came in two portions. CSP/AD was the application development component and used DMS-like panel definitions and the concept of a panel cycle. CSP/AE was the runtime environment. CSP could run as a pseudo-conversational CICS transaction or as an IMS conversational or non-conversational  (depending on use of the scratchpad area) and also as a MVS batch job. It also provided BMS functionality for VSE, MVS, and VM platforms. 

CSP was somewhat more robust in that developers could layout an entire business process and through the CSP PERFORM statement create an entire process flow of business application.  A good description of CSP/AD and the development process employed with it is in The IBM Systems Journal, Volume 29, Number 2, 1990 Cross System Product Application Development Generator: Application Design paper by M. Eugene Dewell.

 

By the mid-1990’s CSP was considered dead and most users migrated their CSP to Visual Generator. The VisualAge Generator Server V1.2 is still available and fully supported at current z/OS release as of the time of this paper. CSP MSL files can be exported in external or extended external formats to various tools such as SDF or VisualAge Generator.                      

Move It To BMS

It may sound easy and seemingly logical that a DMS application should convert to a BMS application. Don’t fall into this trap without understanding what needs to be done to make this happen! 

 

So What Is the Difference Between DMS and BMS?

There are significant architectural differences between a DMS application and an equivalent function BMS application.

First and foremost is that of who is driving the application navigation. In DMS the displayed screen is defined as a ‘Panel’. This Panel contains all of the field descriptions and attributes one would define with BMS but at this point the similarity ends. When we use the term 'panel' in this article we mean the associated DMS Panel Descriptions, File Field Descriptions, Calc/Edit statements, and any Data Transfer statements.  These items can either be either DMS batch statements or DMS Interactive Application Generator statements.      

 

The Panel also contains the basic screen navigation (DMS supervisor functions) in that the next screen to display is defined on the Panel based on what key is pressed or how a user exit overrides the Panel’s defined navigation. In BMS the screen navigation is determined programmatically at the application level. 

 

The Panel can also contain programmatic representations for field calculations and edits. Known as Panel Calc/Edits, these built in DMS functions perform the majority of field content validation, range checking, edit mask handling, and arithmetic operations such as add screen field 1 to screen field 2 giving screen field 3. In BMS these built in functions do not exist and thus one must write the editing and calculations into the user application.

 

The Panel might also contain simple file I/O operations commands (such as get a record, put a record, or update a record.)

BMS does not have this type of built in function. So in BMS all of the I/O statements and associated error handling will have to be coded within the application code. Also the File Descriptions containing the file field names and location within the file record are required DMS elements that will need migration to BMS application working storage areas. Some field names will change out of necessity for input/output mapping.       

 

DMS was seriously lacking in robust built in functions, so many of the user’s business rules and process handling had to be done within a COBOL or PLI procedural code user exit. DMS allowed user exits at many points within a screen-handling event. One could take an exit prior to or after a screen operation, prior to or after a DMS I/O event, or at just about any point within the DMS panel cycle. So not only does that user exit code now have to be placed into a new CICS application procedural code, but it must be placed at exactly the right logical point within the new procedural code.           

 

Is it the Dog Wagging the Tail, or the Tail Wagging The Dog?

In simplest terms, in BMS the application issues a Write to the Terminal with the associated output map definition. The application then issues a Read from the Terminal with an associated input map definition. The application will determine if the programmatic edit checks are passed and, if not, issue an appropriate output map definition and write to the terminal.

 

In DMS this type of screen manipulation is handled by the DMS built in functions. These built in functions are programmatic assembler routines contained in a set of common service modules provided by DMS. 

 

Take a normal CICS BMS transaction. The CICS application code is initiated by entering a 4-character transaction id. CICS determines what program is associated with that transid and initiated the application. The application, in turn, issues a BMS screen write operation and waits for input. When input is received, the application must determine what input was received, perform field editing and validation, and perform the associated business function rules, file I/O required, and necessary calculations. Then maybe put out a BMS screen with the final massaged data. The application may put out that final BMS screen and then set a CICS Return with a new TRANID set. So the next time the user enters anything at the terminal, the new transaction is initiated.

        

What happens in DMS? The generic DMS structure is there is only one DMS transid, DMSS.  The user might enter something like DMSS01. DMSS causes CICS to start the DMS program DMXTI (Transaction Initiate). DMSTI would then look at characters 5 and 6 to see what transaction indicators are there. Finding a ‘01’, DMS will start the Panel cycle for Panel 01 (DMX0001.) Panel 01 was originally the sample applications. Panel 02 might be a menu of DMS applications. Or it might be a single application entry point. In either case the panel is loaded and control is passed to DMXSM (system manager) for panel cycling.  You could make the initial entry to an application any 4-character ID as long as it pointed to program DMXTI. Later versions of DMS did allow for internally changing the transid. This removed a problem where all statistics were collected against the transid 'DMSS.'     

 

Another implementation used in the ‘old days’ to get around having all statistics logged against the single DMSS transaction were to have multiple 4-character transids pointing to DMXTI as the initiated application. Then in a TI exit, see what transid was entered and start and appropriate BMS panel cycle. Just prior to panel cycle is where normally security checking is performed.

 

Another point is that in DMS supervisor functions one could do panel overlays or panel links. In BMS these might be defined easiest and in most simplistic terms viewed as BMS program transfer controls and program links. In some cases, the BMS application program may take the place of a whole series of linked or overlaid DMS panels. In other cases, there will be a one-to-one correspondence between the original DMS panel and an equivalent BMS program.      

 

DMS Panel Cycle

We have spoken of panel cycles several times. DMS was built to operate against a panel’s definitions, screen navigation, calc/edits, file I/O, and user exits in a specified order. Thus when the specified order was completed, the panel could be said to have completed its cycle. A panel cycle has specific cycle points (i.e. post-read, pre-write, pre-display, post-display, calc/edit cycle points as examples).  These cycle points were commonly known as CP1, CP2…CP6 etc.  

 

User exits can be taken at various points within the panel cycle. These exits allowed the user to insert programmatic logic to accomplish functions beyond the capabilities built into DMS service modules. In some cases, exits were written by the user to get around DMS ‘working as designed’ limitations. The built in I/O functions and some calc/edit functions were notoriously weak or contained code defects that impacted the user’s ability to utilize the function the way the user needed. The user got around the weakness or defect by invoking a high-level language user exit at the appropriate point within the panel cycle.     

 

The calc/edit functions never provided a robust enough internal logic to allow the user to completely code most complex business rules and processes within the available panel functions. Thus, additional exits were used to contain the programmatic logic required for the specific business application.

 

The author worked on several large development projects where DMS became a simple screen handler and all editing, validation, file I/O, and calculations were done by user exits. This was especially true when DMS was used with Database Managers like IMS. The navigation and place holding through IMS segments was abysmal with DMS.

 

All calc/edit and supervisor functions could be ‘chained’ into a series of steps that would occur at the indicated point in the panel cycle.  All such chaining will have to be programmatically picked up and replicated in the new application logic.  

 

There are other features of DMS panels and the Interactive Application Generator (IAG) feature that not discussed here that may be covered in a future article. The only portion of the IAG that we will discuss is the IAG concepts for application structure.

 

Interactive Application Generator (IAG) Terms

In IAG terms, a MAP is the terminal display format. Do not confuse this with a BMS map. In DMS construct, a  map is the DMS panel definitions for static and variable data and panel locations of DMS or I/O supplied fields and attributes.   

 

A FRAME is the I/O processing and panel to panel sequencing associated with a map. The FRAME contains the DMS supervisor function coding, calculation statements, and user exit programs.  It will also contain the DL/I segment calls is IMS is being used.

 

A PROCESS is a list of frames which make up a leg of an application. Consider a "process" as a sub-application or a related grouping of FRAMES and panels that make up a specific operation (function or service) for an application. A "process" might be the frames and maps used for an "inquiry a membership record" application function.   

 

An APPLICATION is a list of one or more PROCESSES which make up all functions used by the application.

 

A VALIDATION section that contains the edit statements and tables used for editing, and editing user exits.  

 

These conceptual constructs may be used to determine the in the parsing techniques (manual or automated) for the IAG ASL, if used. This subject will be expanded in a future paper or as part of a DMS Conversion Seminar (fee service.)        

DMS Enque Mechanism

DMS also provided its own internal enque technique to avoid deadly embrace situations (deadlock detection). This is where one user (the primary) requests Record A for update and then later also requests Record B for update.  Another user (the secondary) requests Record B for update before the first user and then requests Record A for update. We now have a deadlock condition. Neither application can continue because each is enqued on the others’ resources. DMS added logic to detect this and take action. This normally involved sending an error message to the secondary user that a deadlock was detected and they should abort their transaction. At this point, the standard CICS rollback for the secondary user’s resources was performed when the user aborted the application.              

  

DMS Transaction Management  

DMS evolved in the days when short duration pseudo-conversational transactions were a must. The virtual storage sizes were only 16meg and I/O on what one would consider very slow disk drives by today’s standards would cause long I/O wait times and queue backups. This caused response time issues at the user workstation.

 

DMS was architected to deliver the short duration transaction by a combination of approaches. First, the DMS transaction’s resources were released as quickly as possible within the panel cycle. Any DMS state information required was written to CICS temporary storage. Some developers actually used protected dark fields in the workstation screen to keep state information needed by the user’s application. A user could create a DMS environment that ran all tasks as long duration conversational style transactions by specifying specific system parameters at DMS installation.  

 

In some ways DMS was a forerunner of today’s object oriented programming. That is to say, that DMS provided common service routines for most general calculations, edits, I/O, and data presentation (screens). These common routines, or services in today’s jargon, were early examples of code reuse, and specific services being provided by specific suppliers. One can more easily identify DMS with the Object-world of today then a corresponding BMS application. A BMS application certainly is less structured for reuse and has most, if not all, functions performed in-line to the application rather then through common service routines.

 

DMS Error Handling

DMS provided the error handling for it’s built in functions. Thus if a file I/O error occurred, error routines were there to deal with it.  Using DMS error messages count as a rough indicator we can say that there can e as many as 100 error routines that will have to be picked up from the DMS action modules (DMXxx) and added to your new BMS application in order to make the user view of the new BMS application totally transparent.         

 

Let’s Move It To BMS

What tasks would have to be accomplished to migrate a DMS application to an equivalent BMS transaction with minimal perceived changes to the end users?

 

Now that you know a little about the architectures of DMS and BMS, you stand a better chance of addressing the above question. Remember, the term "panel" in this paper means the associated panel descriptions, file field descriptions, Calc/edit statements, and file transfer statements. If you were using the DMS Interactive Application Generator replace the term "panel" with "Application Specification Library (ASL)".  Some of the tasks that will need to be done are:

1.      Parse the DMS panels (or ASL) to;

a)      Locate and save off the screen/field definitions

b)      Locate and save off the calc/edit statements

c)      Locate and save off the File I/O statements

d)    Locate and save off the File Field Descriptions

e)      Locate and save off the user exits and panel cycle point information

2.      Using the screen/field definitions from item 1 create BMS maps and map sets as needed.

3.   Using the File Fields Descriptions generate the File I/O record descriptions for the BMS application.

4.      Using the user exit information from item 1 move the user exits to a procedural flow in a single or multiple module(s) using standard CICS Command level APIs and COMMAREA structure. Most referenced field names will change.

5.      Replace DMS panel interactions in user exits with corresponding BMS read/write commands.

6.      Using the calc/edit information from item 1 write corresponding source code for insertion in new modules built in items 4 and 5 above.

7.      Add necessary error handling routines for calc/edit errors. 

8.      Using the File I/O information from item 1, write source code to perform equivalent functions and add with necessary error handling routines to new modules built in item 7.

9.      Create a front-end (shell) module to simulate DMS task initiation and transfer control to new application module(s). 

10.  Change any required documentation and train the user on any DMS error handling not brought forward to the new application. Or explain the differences between the old and new applications to the user community.  

 

This is the minimum series of tasks that must be accomplished. Before any of the above conversion tasks are done, the DMS application should be flow charted to show each panel (by name) and the panel to panel interaction (panel overlays or panel links). This is best shown in a hierarchy format. After building this chart, annotate each panel with the supervisor functions used, I/O used, and exit names used with that panel. In some cases you will find panels that are 'phantom' in nature. They don't display anything and are there only to provide exit points or a chain of specific functions between an input and output panel. This 'phantom'  panel does not need BMS conversion. Only the functions or exit invoked need to be handled.        

 

There is a large amount of new application coding required that replaces the DMS functions and its provided error handling. Using a standard industry number, roughly 80% to 120% of the new BMS CICS application will be new code consisting of basic map commands and error handling, calculations, field validation and editing and error handling, file I/O commands and error handling routines, and standard CICS housekeeping routines. And the new application logic will probably conform more to the old DMS cycle points then to a well-formed structured program.   

 

We have done a great deal of research for any tooling that can take DMS to BMS with some level of automation and have found none currently being marketed. There were several packages available back in Y2K remediation days, but upon investigation, the authors of the tools have retired and to quote one author ”I have no interest in getting back in the conversion game.”  This would indicate that the entire project is a manual process with little or no automation. There is one example DMS to BMS map converter from 1989 that is available on the web at: http://www.xephon.com/archive/c043a06. This is just an example of a parsing tool with some caveats.  The tool is in written in REXX and was originally used to move DMS/CMS panels to BMS maps. It should, with a little tweaking, parse out the needed DMS/CICS panel screen definitions. You might adapt it to parse the other items as well. There is also a BMS to DFHCOMMAREA migration aid by the same author at the same website.

 

You will also need fairly standard comprehensive test criteria and test plan to ensure the new application is functioning properly and interacting with the users in a transparent manner (the users get the same error returns and take the same actions as before).

 

You will need a great deal of skill in BMS and creating standard CICS applications plus a working knowledge of the DMS built in functions and the panel cycle in order to recreate the application that masks the users from the change to BMS.

 

And at the end of this whole expensive and laborious project, you still have a 3270 ‘green screen’ application! 

 

Another Approach - Modernizing the DMS Application

There is another conversion approach that does offer some limited tooling and automation with a much better end-product.

Denmark-based Xact offers a tool to take DMS panel definitions to VisualAge Generator for JAVA v4.5. In essence you move the DMS panels into a fully functional EJB environment.

 

This will take advantage of CICS TS V2.2 and above enhancements in the area of JAVA support. Using this approach one can much more quickly rewrite the application into a fully webified application that can immediately play in the Service Oriented Architecture (SOA) implemented by your enterprise. The user should be thrilled to have a modernized application and you can accomplish this conversion with much less money, time and people.

 

It’s In The Details

There are many tasks required to accomplish either of the above conversion approaches. We have only touched a few of the more major tasks. Suffice to say, we see the DMS to BMS conversion as a costly and lengthy project with little upside for the organization in the long run. You would end up with a ‘green screen’ application. As long as you adhered to the recommended COMMAREA-based programming standards, you could put the application under the CICS 3270 bridge to gain at least browser and interchange capability to web components. Optionally you could take the green screen application to full participation in SOA using the CICS TS V3.1 supplied SOA assistant tooling.        

 

For a detailed DMS conversion seminar, in-depth planning session with customized project plans, and general DMS conversion support services, contact either your Star Group IBM Business Partner or MCE, Inc directly.                

 

 

Project Estimation