Remote DL/1, born of IBM's 1980s mainframe programming technology, comes in handy today for distributing IMS database...
requests in CICS.
In the 1980s, IBM implemented CICS' Information Management System interface as local DL/1 on the mainframe, meaning that all IMS database I/Os and modules ran inside of CICS. IBM later replaced the local data language option with the more robust database control (DBCTL) interface, but left behind something called remote DL/1.
Remote DL/1 is a type of CICS function shipping that allows mainframe programs to schedule Program Specification Blocks (PSB) on a local CICS for a database available via DBCTL on another region. Shipping the request across Multi-Region Operation (MRO) links is mostly transparent to the program. The database I/O is synchronous, and CICS ensures the distributed unit of work's integrity.
I'll refer to IMS database requests as "DL/1," but the discussion applies to Application Interface Block, or AIB, calls as well.
Setting up remote DL/1
Setting up remote DL/1 involves an artifact from the local DL/1 days called the PSB directory (PDIR). Defined using the DFHDLPSB macro, the PDIR lists PSBs to be scheduled remotely. Each PDIR entry has the following attributes:
PSB: The PSB name
MXSSASZ : The maximum segment search argument (SSA) length used by the PSB. You can easily get the correct value from the SSASIZE specified on the PSBGEN macro that created the PSB.
SYSIDNT: The 4-byte system ID of the remote CICS that actually executes the DL/1 request.
RMTNAME: The PSB name the remote CICS should use. By default, the remote name is the same as the value of the PSB parameter.
CICS can mix remote DL/1 and DBCTL. When a program schedules a PSB, CICS first checks the PDIR to see if the request should be function shipped. If the PSB isn't in the PDIR, or the SYSIDNT of the PSB names the local system, CICS sends the request through DBCTL. Otherwise, CICS bundles up the schedule and ships it to the remote system.
After creating the PDIR, the systems programmer must define MRO links between the remote and local systems. This is usually pretty easy, but be sure that the local CICS has enough send sessions to allow DL/1 calls to get to the remote system with minimal queuing. Otherwise, slow response time and possible deadlock timeouts will occur.
Remote DL/1 in action
Function shipping begins when a transaction schedules or allocates a remote PSB. CICS bundles up the request and sends it to the remote region, where the remote CICS starts a mirror transaction -- in this example, CSM5 -- to complete the schedule on behalf of the first task and send the results back to the originating system.
As the application executes, the local CICS intercepts IMS calls and sends them to the mirror transaction. As before, CSM5 performs the request and returns the results. The mirror transaction will continue to exist until the originating transaction ends or takes a SYNCPOINT (commit). At that time, the mirror transaction tells IMS to commit the database resources, and ends. If, at any point, the originating transaction abends or issues a ROLLBACK command, the CSM5 transaction tells IMS to back out, pending database changes.
Implications and uses for remote DL/1
Use remote DL/1 because MRO links can span Sysplexes and long distances. If an application in New York needs to update information in a database in Tokyo, function shipping is an alternative to duplicating the database.
You also may want to isolate the IMS to a subset of logical partitions in the same Sysplex. Remote DL/1 gives these installations the capability to run IMS where they need it but still provide CICS applications access to the databases from the other systems in the Sysplex.
Response times can slow because of remote DL/1, as IMS database calls that normally execute in microseconds with DBCTL are elongated into milliseconds due to network latency and overhead. Remote DL/1 works best for applications that make relatively few IMS database requests and can tolerate the increase in response time.
Despite CICS' efforts, not all DL/1 requests work the same remotely. For example, information returned in an inquiry may be formatted differently from the originating data. There are also some error conditions, such as trying to use a Program Control Block that's not part of the currently scheduled PSB, that return an IMS error when running through DBCTL but produce an abend with remote PSBs.
CICS usually manages distributed units of work (UOW) well. However, if any CICS or IMS involved in the distributed UOW fails, the restart negotiation for in-doubt UOWs could get ticklish due to the number of participants.
About the author:
Robert Crawford spent 29 years as a systems programmer, covering CICS technical support, Virtual Storage Access Method, IBM DB2, IBM IMS and other mainframe products. He programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. Crawford is currently an operations architect based in south Texas, establishing mainframe strategy for a large insurance company.