How to Code a Synchronous Program Switch in IMS 13
IMS 13, announced in October 2012, introduces a feature called synchronous program switch, which can help you modernize your IMS application infrastructure and reduce unnecessary network traffic.
This feature enables synchronous communication between IMS application programs running in separate IMS Database/Transaction Manager (DB/TM) or IMS TM dependent regions.
The new method relies on simpler programming logic than the asynchronous programming switch method that IMS has had for many years. Clients can use synchronous program switch to simplify their application programs and to easily leverage the services of existing IMS application programs.
The synchronous program switch approach uses the existing IMS Call (ICAL) of the IMS Data Language/I (DL/I) interface, which has been enhanced to support the new feature. It enables further modernization of application infrastructures in IMS DB/TM and IMS TM environments by enabling IMS to synchronously broker multiple IMS transactions in a business process that’s initiated by a single client transaction, as seen in Figure 1.
Two examples—one in PL/I and one in REXX—can be reviewed in Program Sample 1 and Program Sample 2, respectively. Each performs a synchronous program switch.
The sample PL/I program makes a synchronous call to an IMS transaction named PART, which returns data about part AN960C10, a part in the sample Parts database provided with the IMS product. The code shown in Program Sample 1 performs the following actions:
- It issues a Get Unique (GU) Data Language/I (DL/I) call to the I/O program communi-cation block (PCB) to obtain the initial input message that triggers the synchronous pro-gram switch.
- It issues the ICAL DL/I call to make the synchronous program switch after setting re-quired values in the application interface block (AIB) (AIB_SUB_FUNCTION, AIB_RESOURCE_NAME1, AIB_IOAREA_LENGTH,AIB_IOAREA_USED).
- It sends back the first 80 bytes of the data that’s returned by synchronous program switch as the response to the initial input message.
If the initial response to a DLI/ICAL call is so long that IMS truncates the return data, the complete response message can be retrieve by issuing the ICAL call again with RECEIVE specified as the AIB sub-function.
Before this PL/I program can be run, the application program and the transaction must be defined to IMS with the IMS CREATE command or by adding the IMS APPLCTN and TRANSACT stage-1 system definition macros to the IMS system:
TRANSACT CODE=ICALPL1,PRTY=(7,10,2),INQUIRY=NO,MODE=SNGL, X MSGTYPE=(SNGLSEG,RESPONSE),EDIT=ULC
The sample REXX program does much the same thing as the PL/I program, except that instead of calling a transaction that queries a database, it makes a synchronous call to a COBOL program that executes an INQY call and returns data about the IMS system. This is illustrated in Program Sample 2.
To have the REXX program run the PART transaction like the PL/I program does, simply change the value of ptptran in the REXX code from AMSC from sync prog to prog to PART AN960C10. The REXX program is designed to run under the IVPREXX transaction, which is also provided by IMS with the IVP and shown in Figure 2.
Get More from IMS 13
By modeling your efforts after these examples, you can:
- Simplify the flows and reduce the network traffic between IMS and the clients that re-quire the services of multiple IMS application programs
- Modernize the design of IMS application programs that communicate with each other
- More easily leverage the functionality of existing application programs within IMS 13
The synchronous program switch functionality is just another example of how IBM continues to improve IMS and adapt it to the demands of the modern business world. As you modernize the mission-critical application infrastructure that IMS supports, be sure to explore all of the new features of IMS that support application modernization, and see how the value of IMS to the future of your business should not be underestimated.