DMS Defined

Let’s first define what DMS is and what DMS is not.

DMS is an application creator. It creates CICS applications using existing executables (i.e., built-in functions) provided by DMS itself. These built-in functions reside in DMS supplied load modules prefixed with “DMX” and defined in the CICS RDO.

DMS is not an application source code generator. It generates no new lines of source code or executable objects. Not one line of new code is built by DMS.

DMS utilizes user defined descriptions of what screens look like, what data is displayed on the screen, and what built-in functions of DMS will be executed for any specific user action requested from the screen. These descriptions are kept in 80-character length files known as DMS panels and DMS File Descriptions.

Keep in mind that DMS was popular in the days of the IBM punch card. All panel and file descriptions could be coded on these punch cards. Some current DMS users still utilize the DMS coding forms that, when completed, were given to unit record operators who punched the card deck from the coding form entries. Today, they simply created 80-character files using TSO from these forms.

DMS brought out a feature known as Interactive Application Generator (IAG). This feature provided a project level storing approach for the DMS panels and file descriptions. And it provided a screen development and editing capability. Of the six DMS clients I have already spoken with about conversion issues, not one utilizes the IAG feature. The IAG was a separately priced feature of DMS that allowed the application development functions to be split apart and separately licensed from the run-time functions. The IAG came along about the time that CSP was overtaking DMS as the application development tool. So some users opted to go to CSP while others opted to stabilize on their existing DMS product. The IAG feature was an add-on to make DMS and CSP more equivalent and make it easier to move between the two products.

The reason we find so many user exits in existing DMS applications are that the DMS built-in functions provided many standard routines but not all that were required to create robust applications. The main places user exits were required was for additional security layering, handling of complex business rules, working with more than four files or unsupported file types, and handling complex IMS (DL/I) navigation and segment handling.

DMS/CICS File Support

DMS supports both standard and non-standard file types. Non-standard file types are unique file organizations and accesses that are provided by and unique to DMS. The user specifies on the file description the file name and what type of file access is being described by specifying a one or two character alpha designation (K, I, B, S, U, and KG, IG, BG, and UG.) DL/I databases are identified differently but are also supported.

Most of the applications reviewed in the last six months are either “K” style - VSAM KSDS, or DLI.

On the panel description the user will specify the file name and if the file is opened for input, output or both.

Standard File Types Supported

DMS supports three standard file organizations and access methods. While ‘standard’ implies widely used access methods, one or more may be considered archaic and not applied much in modern IT systems.

DMS - VSAM KSDS

DMS supports VSAM KSDS. DMS knows this file by the CICS file name defined in the RDO. This is a pure native VSAM KSDS and standard VSAM Alternate Index support and it can be use the CICS MRO and ISC features to remotely access a file. The file is identified as a “K” designation on the DMS file header card.

DMS - ISAM Files

DMS supports ISAM. This is identified as an “I” designation. ISAM as an access method was discontinued many years ago and was replaced by the ISAM Interface Program. Today one puts the ISAM data into VSAM form, runs under the ISAM Compatibility Interface that allows the application’s ISAM APIs to remain unchanged. Be aware that IBM has made the following statement regarding ISAM as of V1.7 of z/OS:

“Support for ISAM data sets will be withdrawn. When this support is withdrawn, you will no longer be able to process ISAM data sets other than to delete them. The ISAM Compatibility Interface will remain available to help you migrate applications to VSAM without application changes.”

DMS - Sequential Files

DMS supports sequential datasets as CICS Transient Data destinations. This is identified as an “S” designation. The Transient Data destinations can be read or written but not both via DMS. This is typically used to write records online and subsequently process offline. One application is using this as input to batch job DMXUPDTE to update ISAM, VSAM or DMS Indexed Files.

Non-Standard File Types Supported

DMS has several unique file access mechanisms that are not available anywhere else. These existing mechanisms, if used currently, will add some complexity to any attempted conversion project to properly replace these with some standard supported file data accessing approach.

DMS - INDEXED FILE

DMS supports INDEXED FILE organizations. This is identified as a “B” designation. This is a mechanism that uses paired BDAM files to provide quick access to data via an index in the first BDAM file to the relative record data in the other BDAM file (Reference File). These paired files are built by DMS provided batch utility jobs (DMXDMXBI, DMXUPDTE, and DMXPURGE).

DMS - USER DEFINED FILE

DMS supports the application of User defined file organizations. These are identified as a “U” designation on the DMS File Header card. A User Program does ALL file I/O. The User Program gets control via CICS LINK when DMS File Services is invoked and is related to a ‘U” File Header Card.DMS passes I/O work area, I/O request type, Cycle Point indicator, file name, file key from panel, housekeeping flags to the User Program. The online application may have batch programs to initialize, load, and maintain the files that are run on a nightly basis.

DMS - GROUP FILE

DMS supports an indexed file organization that sits on top of any existing VSAM, INDEXED, USER DEFINED, or ISAM file access method. These are identified as a KG, BG, UG, or IG designation on the DMS File Header card.

This adds another level of index above that provided by the normal file access method. By splitting the physical file into up to 6 physical sub-files that are addressed via six-letter file name known to CICS and suffixed 01-06.

Each sub-file contains only those records whose keys fall into the sub-files defined range. The highest-level index is an In-Storage Index.

CICS defines the single physical file and logical splitting of the file is done by DMS internally.

">This structure’s conversion requirements should best be worked out based on how the business user is applying the group file to their day-to-day business process. The highest-level index is an In-Storage Index. CICS defines the single physical file and logical splitting of the file is done by DMS internally.

This structure’s conversion requirements should best be worked out based on how the business user is applying the group file to their day-to-day business process.

DMS Required File Descriptions For All File Types

As with any other application, all of the data records and their data fields must be defined so that DMS can process the data to and from the screen. This is done via the DMS File Descriptions containing the included fields by name, the field length, and the field data characteristics. Other entries are to handle identification of key fields and to provide ways to reposition within the record description and redefine fields. These File Descriptions are critical to the modernization project.

See our first paper on DMS modernization for more information on this.

DLI & DMS

DMS supports access to IMS or DLI language databases via the use of two internal modules (DMXFS and DMXDLI).

DMS uses standard DLI API under the covers of the action modules. The significant differences between DMS and other DLI applications is that DMS has to handle requests for any number of DMS applications all accessing the DBMS database. The DBMS thinks it is communicating with a single application via the standard PSB scheduling mechanism. This means that DMS must handle aspects of data integrity, internal enqueing, data access threading, and know about all segment types that any DMS application may use.

The PSB name is specified on each DMS panel that will display or reference a DLI DBMS. The panel may also contain the DMS DBD name for the database being referenced. The user may also code which PCB (by numeric position) in the named PSB to use. The panel must contain either the PCB number, or the DMS DBD name but not both. Up to four unique databases may be coded on a panel description.

DMS provides several macros to create the DMS/DBD that is only used by DMS and not to be confused with the standard DBD generated for and used by the DBMS. DMS uses this unique control block in the same way it does the file description forms. All segments and fields to be used by DMS must be coded on the DMS/DBD. If a specific parent child relationship is not used by the DMS application, the segment and fields for that relationship do not need to be coded. The DLI DBD must contain the names of the sequenced or non-key fields that will be used to access specific segments within the database. A segment card has to be coded for any segment intended to be added, updated, deleted, or searched.

The DMS/DBD must be assembled prior to generating any panel descriptions that will reference the database described by the DMS/DBD.

Depending on which DMS enqueing method is globally selected for the DMS environment, certain techniques were applied to DBD and PSB coding. Using the Program Isolation (PI) method, DMS enqueues for updates on the segment occurrence (RBA). DMS might be set up to use the Segment Intent method. This method enqueues on the segment type. DMS suggested that if method two is used, one would use an optional PSB defined on the panel to read for inquiry and then when ready, read for update and immediately do the update if the segment data has not changed between the first and second read.

Suffice to say that with DMS modernization, the best approach is probably to use the second method to reduce the amount of time any segment is held for update.

DMS provides a search facility (S type Supervisor Function) that works in place of a normally qualified SSA. The user keys on a search string with some number of qualified character positions and some as ‘*’. Using this function DMS would pass DL/I a key with hex zeroes replacing the ‘*’ positions and a relational operator of ‘=>’.

DMS provides a segment repeat command ($RPT) to allow segments found from a search or get next operation to be displayed on a panel. The $RPT command will contain a number indicating how many occurrences of the found segment will be displayed. This repeat can span multiple physical screens known as windows.

Keep in mind that all SSA strings are built internally by the DMS action modules. The various DMS database navigation and display functions are converted to corresponding SSA when needed. Since DMS handled all of this, some complex database structures or multiple segment displays were beyond the built-in DMS functions. Thus in many cases, most if not all of the DLI access was written into user supplied user exits as standard SSA API. The most that DMS provided was the initial PSB scheduling. Any DBMS I/O done in the exit was really up to the user to synchronize and ensure adherence to the global in place DMS segment enqueing & data integrity methods.

The rules for segment card coding are impacted by the data integrity mode (SI or PI). Get a copy of DMS/CICS/VS Program Reference Manual, SH20-2209-08, and review Chapter 10, ‘Data and Application Integrity’, for a complete discussion of the rules. This will explain the various nuisances of the DMS panel coding you will see for DL/I files. Once these nuisances are clear, one can easily translate the DMS panel commands to a template of SSA statements required.

Summary

We are attempting to provide the reader with enough information to begin formulating plans for a DMS modernization project. We are not attempting to provide every facet or nuisance of the DMS migration issues one will face. For that, we provide on site consulting services and modernization project augmentation services.