Why modernization is hard – Series 5
Background
It is common to find COBOL or other legacy language application programs calling System modules viz. Standard z/OS Language Environment modules for Date functions, DB2 DSNALI/RLI modules for connection establishment, DSNTIAR utility to get formatted DB2 exception trace, IDCAMS for file allocation, IKJEFT for ISPF functions, Standard abend modules to trigger abnormal termination of process as part of exception handling, and other such utilities.
System Modules
The following are the common categories of system modules that legacy programs call:
1. z/OS Language Environment calls such as
- CEEDAYS, CEEDATE that convert between standard date format and Lilian format date for easy date-based arithmetic
- CEELOCT to get current local time
- CEEGMT to get current Greenwich Mean Time (GMT) in Lilian format
- CEEGMTO to get difference between the local system time and Greenwich Mean Time (GMT)
- CEE3DLY, CEEDYLM to suspend processing for a duration in seconds or milliseconds
- CEEDYWK to return day of week from a Lilian format date
- CEE3ABD, ILBOABN0 to request termination of process with an abend code
- LE storage related modules
When calculating the date and time, it is important to keep in mind that COBOL dates are based on Gregorian calendar starting January 1st 1601, while Java references the date January 1, 1970, 00:00:00 GMT. I have seen many systems fail to produce correct results because of date calculations.
2. DB2 Service modules
- DSNALI/DSNRLI calls to handle DB2 Connections
- DSNTIAR that helps programs obtain a formatted form of the SQLCA and a text message that is based on the SQLCODE field of the SQLCA
3. Obtaining MVS Control blocks
- Assembler program calls to retrieve Job name, job Id, find dataset attributes and finds out if a program is running in batch or CICS environment etc.
- Sometimes, the COBOL programs directly establish pointers to map MVS Control blocks and resolve runtime job related attributes
4. It is not uncommon to find COBOL programs calling System programs for handling dataset, calling REXX and other MVS Services
- IDCAMS calls
- ISPLINK calls to invoice ISPF services
- Passing SORT Control cards via JCL SORTCNTL DD to COBOL SORT statements
- Calling Assembler programs to utilize various System services.
- WAIT, POST, ENQ, DEQ etc
- Dynamic allocation/deallocation of datasets
If your modernization toolkit cannot handle these system utilities, then the manual refactoring work to identify and plug the required missing code to support these calls in legacy application programs will be significantly challenging.
Conclusion
CloudFrame identifies and handles standard system modules that are a part of the call chain of application legacy programs. This provides total transparency when it comes to handling such system modules and facilitates a transparent migration experience, so you don’t lose a critical business function in the process.
Related Post
The Role of Db2 DBAs in Promoting zIIP Usage
As most z/OS practitioners know, zIIP processors can provide significant benefits in…
Java and the zIIP: The 5 Major Benefits
In this series of blog posts on the zIIP, we have looked…
FS Firm envisions a COBOL-less future by collaborating with CloudFrame…
FS Firm envisions a COBOL-less future by collaborating with CloudFrame and EPAMDownload…
Recent Comments