DMS Conversions;

DMS Conversions;
Observed Errors & Omissions

By Don Fowler July 2005

Several CICS/DMS conversion projects are now underway. Some common errors and omissions have occurred (or are occurring.) The projects we have seen are all taking the tact of converting to a Command-level BMS application set. As we have stated in prior papers, we don’t believe that this conversion approach is the best use of the conversion dollars and staff time. However, since so many are taking this approach, we are providing some general observations and suggestions using this approach.

The projects all tend to have similar objectives defined. These objectives are:

(a) The application data presentation should look the same to the end-user,

(b) The application should have the same screen navigation as the old system,

(d) Minimize any changes that would require user retraining.

Each Error and Omission discussed below impact one or more of the above objectives. If you are dealing with only one application being converted by a single conversion team, these impacts are minor. But when dealing with multiple applications, with multiple conversion teams working concurrently, these impacts can cause major immediate rework and significant future maintenance and enhancement costs.

The first major omission is the failure of the application owners to take into account the internal DMS error processing and to define conversion objectives for these internal processes.

In the existing projects, when error detection and error message generation were discussed and described in the project documents, they were in terms of the data fields validation and editing errors that are defined on the DMS panels and the perceived views of how these error types are handled by DMS. No thought has been given to converting the internal DMS handling of common file I/O errors, and program abnormal condition handling. Let’s take a look at the internal processes that DMS uses and how we might define these to a conversion team.

File related errors occur in all applications. Simple errors might be no record found or out of space conditions. More complex logical errors might be caused by erroneous file restores where indexes are out of synchronization with base data clusters or similar situations.

Let's focus our attention on any common error that causes a non-zero return code on a VSAM file I/O operation. When DMS detects a file error condition, it first checks to see if the DMS system field #DMSERR is defined on the current panel for display. If #DMSERR is defined, DMS writes its predefined error message to that error line (one line - 79 characters long). These predefined error messages have a standard DMS identifier, message number, descriptive text, and defined operator actions for response. When #DMSERR is defined on a panel, then that panel must contain the associated operator response Function Identifier and Supervisor Function sequences needed to perform the various operator actions for the various messages that can occur.

If #DMSERR is not defined on the panel for display, DMS creates a default screen with the error message identifier, number and text. The predefined operator actions are displayed below the error message text on this default screen (see figure 1).

Figure 1 – The effect of #DMSERR Field

Using Figure 1, if #DMSERR exists, DMS uses that field on Panel ‘A’ and performs the FI-SF sequences defined on the panel, or it may transfer to the next panel (B) and utilize that panels FI-SF sequences. If #DMSERR does not exist, then DMS presents its predefined Error Message Panel as indicated by the dotted lines in Figure 1. This panel may return to Panel ‘A’ or proceed to Panel ‘B’ based on operator response.

The conversion standards should include a table showing what common errors must be standardized to replace the existing DMS internal processing. A decision should be made between the user and the conversion project as to if such errors must maintain the existing internal DMS error message standards. Any change to this would require some retraining or user documentation revisions to show what the new error standards will be.

If such a conversion standard is not put in place, each conversion team may select a different approach for replacement of such error messages or even not put any mechanism. At best one would expect that future maintenance and enhancement costs would rise since each converted application would have different standards. Remember, we are not talking about data field level edit and validation error message generation, we are talking about basic file and Handle Condition types of errors.

The major error we see being introduced into the project is one of taking the easy way out for replacement of the existing DMS file browse function. In VSAM files the conversion architect is favoring the use of VSAM API with use of the forward and backward read functions. This is an adequate implementation and only requires minimal program logic to deal with first and last record conditions. The simplest technique is to simply read forward or back from the existing record location as required. This will cause excessive I/O and should be balanced against additional programming logic needed to in-storage store the read records within the current browse.

However, either of the above approaches would lead to completely missing the boat on the current user’s usage of PAGE FORWARD - BACK functions provided by DMS.

We were asked if the VSAM APIs (read forward and backward) were OK to use for browsing. Our answer, as the question was presented, was “no”. The question is not if the VSAM API is ok for browsing, but how to honor paging commands in conjunction with the browsed files.

Currently DMS starts a file browse and stores browsed records information and data in temporary storage or in-core. Page commands can then be used to go forward and backward through the latest browsed records.

By maintaining the first and last keys of the existing browse operation, you will then know how far forward or back to honor the Page commands selected by the user. You might option to use the VSAM API and simply read forward and backward to these given keys or you may option to store the browsed records and programmatically page forward and back through them.

Without some fact finding on how the user is applying browsing and paging no conversion standard can be developed. Once we know how the user is applying the existing DMS commands, we can make a standard on browsing and paging.

An additional omission to the standards is dealing with called subroutines from a DMS user exit program. Many of these calls are to DMXCM to alter DMS communication fields. This can be replaced by simple data moves or attribute byte alterations. A decision table can be built to show the conversion team what to do.

We really think the conversion team should consider using a COMMAREA-based “shell program” as the base implementation for a command-level BMS approach. In Figure 2, we show a possible implementation of a shell program.

It will:

· Always first one started

· Handles security access

· Handles old DMS supplied functions

Ø Error messages,

Ø Built-in functions,

Ø Page storage

Ø Enqueing mechanism, if necessary (consider for ‘threadsafing’ the application)

Ø Other housekeeping done by DMS TI and SM modules.

Figure 2 – Shell Implementation

These are some of the more common issues we have seen with the currently in process conversion projects. For clarifications or questions on this paper, contact me at y2kdon@msn.com.