Celebrating 40 Successful Years
IMS version 10 supports synchronous and asynchronous callout
Forty years ago, the first “IMS READY” message was displayed and the IBM IMS* was open for business. Today, IMS continues to be IBM’s high-performance application and data server for the IBM System z* platform. IMS version 10 continues to support new technological innovations by enabling IMS applications to call out to not only communication devices and application programs managed by IMS, but also to external applications and Web services through open standards. This evolution of functionality can be leveraged to build an on-demand business environment.
IMS’s service oriented architecture (SOA) describes how different application programs can call out to each other as they participate in business processes. Version 10 provides SOA-enabling functions for IMS application programs to integrate with other products and platforms across the Internet.
Synchronous Versus Asynchronous Callout
IMS has evolved to support both asynchronous and synchronous callout to external subsystems–to outside of the IMS runtime environment, and to the Internet. A call-out request is considered asynchronous if the requesting IMS application program doesn’t expect a response, or if the response message is expected to return as a different transaction. In this instance, the application program terminates and doesn’t hold up the IMS-dependent region. If a response is expected to return in the same transaction during the same unit of work, the call-out request is called a synchronous call-out request.
The IMS alternate program control block (alternate PCB) concept introduced by the IMS transaction manager (IMS TM) for asynchronous call-out support enables access to communication devices and application programs managed by IMS in a logical fashion. This concept provides transparency for the IMS application program and security for end-user messages. The IMS application program doesn’t have to know the characteristics of the communication device or the network protocol when sending data.
IMS-Managed ALTPCB Callout
A two-tiered IMS-managed request is one where the IMS application program A (PGMA) uses the IMS DL/I ISRT call to the ALTPCB. This call invokes IMS application program B (PGMB). PGMB can be in the same IMS system or can be routed to access PGMB in another IMS system. However, each IMS program is an independent unit of work. In this scenario, since the response message to the end-user client is from PGMB, the client doesn’t know two IMS application programs were used to process the request. This technique is used to provide an IMS-managed flow of work.
Cooperative Call-out Processing
IMS TM supports cooperative application processing using the IBM Systems Network Architecture Logical Unit 6.2 (SNA LU 6.2) Advanced Program-to-Program Communications (APPC) protocol and the open standards Common Programming Interface for Communication (CPI-C). IMS preserves the existing application program interface to the ALTPCB via LU 6.2 descriptors. The descriptor associates the ALTPCB with an APPC application program to provide APPC asynchronous call-out support. The IMS application program can also use the CPI-C interface for synchronous call-out processing.
Figure 1 is an example of a two-tiered APPC protocol using asynchronous and synchronous call-out processing. For an asynchronous call-out request, the IMS application program does an ISRT call to the ALTPCB, to send data to an application program defined in the IMS managed LU6.2 descriptor. The APPC/IMS function allocates a conversation to the partner program (for example, TP-A), sends the data and de-allocates the conversation.
Again, each of these programs is an independent unit of work. IMS PGMA isn’t able to process any results from the partner program running outside IMS in the same IMS unit of work (program TP-A or program B TP-B in Figure 1). In this scenario, since the response message to the end-user client is from PGMA, the client can’t obtain the results from both application programs, even though the results are in the same unit of work.
For a synchronous call-out request, the IMS application program can use the open standard CPI-C interface to establish connectivity to an application program and then exchange data. Both application programs can participate in the same unit of work. In this scenario, since the response message to the end-user client is from PGMA, the client doesn’t know two application programs were used to process the request. The client can obtain the results from both application programs in the same unit of work.
Synchronous Callout Through ESAF
The IMS External Subsystem Attach Facility (ESAF) enables IMS application programs access to resources managed by other subsystems. ESAF provides for synchronization of external subsystem data resources with IMS data resources. For synchronization processing, the IMS syncpoint manager is the coordinator and is responsible for directing commit or abort actions on behalf of the IMS application programs. External subsystems are participants in the process, and commit or abort data updates by IMS applications according to directions given by the IMS syncpoint manager. IMS ESAF provides the capability for synchronous callout via WebSphere* MQ and DB2* stored procedures.
Search our new 2013 Buyer's Guide.
Administrator | New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.
Trends | IMS version 10 supports synchronous and asynchronous callout
Trends | Improvements to IBM make it a first-rate data-management solution.