MAINFRAME > Administrator > IMS

Using IMS 14 Transaction Manager

The challenge to meet the ever-changing business needs and the growing demand for broader service availability through mobile and cloud have fueled the increase of transactions and data volumes and the need for greater operation agility and easier application deployment. IMS 14, released in October, provides various enhancements in IMS Transaction Manager (TM) to sup-port these requirements.

For growing transaction and data volumes, the optional advanced program-to-program communication (APPC)/IMS flood control enhancement improves IMS availability by enabling flood control for APPC conversations. For IMS callout applications, a single IMS Open Transaction Manager Access (OTMA) tpipe can now support multiple active RESUME TPIPE requests, which improves failover protection and increases callout request processing throughput and efficiency. For greater operation agility, Multiple Systems Coupling (MSC) enablement is simplified, MSC resources can now be dynamically defined, OTMA descriptors storage can be dynamically allocated, and connection-only security for OTMA can now be enforced without enabling transaction and command security. For easier application deployment, IMS now supports two-phase commit processing for cascaded global z/OS Resource Recovery Services (RRS) transactions from the IMS TM resource adapter.

Other TM enhancements include extended connectivity and availability for Inter-System Communication (ISC) VTAM sessions, improved monitoring of Common Queue Server (CQS) usage, and automatic refresh of OTMA cached Accessor Environment Elements (ACEEs) when RACF definition changes.

APPC Flood Control

Many IMS customers run transaction messages from APPC clients. To process each APPC request for the transaction, IMS allocates 31-bit storage to create an IMS Task (ITASK) structure and to build a set of control blocks, such as Transaction Instant Block. When there are a large number of APPC requests in a short period of time, these requests could eat up significant IMS private storage in the 31-bit area. IMS could then run out of storage and crash.

In IMS 14, the APPC flood control function for IMS transactions helps prevent IMS abends due to 31-bit storage exhaustion. APPC flood control is enabled by default, helping to move APPC requests that are waiting to be processed by IMS into 64-bit storage after the number of requests reaches a certain threshold. You can modify or disable APPC/IMS flood control by specifying the APPCMAXC=(X,Y) parameter in the DFSDCxxx member in the IMS PRO-CLIB data set. X specifies the maximum active APPC requests before IMS moves requests into the 64-bit area. Y specifies the maximum number of queued APPC requests in the 64-bit area before IMS rejects new APPC requests. The valid range of X is 20 to 30,000 with a default value of 5000. A value of 0 for X disables the APPC/IMS flood control. The valid range of Y is 0 to 9,999,999 with a default value of 1,000,000. When Y is 0, IMS doesn’t use 64-bit storage to queue the APPC requests. The MAXC= output field of the /DISPLAY ACTIVE command dis-plays the maximum limit of the active APPC requests before IMS moves requests into the 64-bit area.

IMS TM Resource Adapter Across z/OS Images

The IMS TM resource adapter can be used to submit global transactions to IMS via IMS Connect. Prior to IMS 14, both IMS and IMS Connect had to be on the same z/OS image for the IMS TM resource adapter to submit a global transaction. This restriction means if IMS fails, there is no way to route the global transaction to another IMS in a different z/OS image.

In IMS 14, IMS Connect and IMS TM are enhanced to support global transactions received from the IMS TM resource adapter via a TCP/IP connection when IMS Connect and IMS TM are located on different z/OS images. This new function can be enabled in IMS Connect by specifying CASCADE=Y in either the IMS Connect system definition or data store definitions. Alternatively, you can issue IMS Connect type-2 CREATE and UPDATE commands with CASCADE=ON for IMS Connect system and data store definitions. The IMS Connect command VIEWDS, VIEWHWS, QUERY DATASTORE, or QUERY MEMBER can be used to query the current CASCADE setting.

Extended Connectivity and Availability for ISC VTAM Sessions

If IMS uses an ISC link to send a message to another subsystem, e.g., CICS, and an error occurs when processing the message, an error recovery procedure (ERP) message will be sent to IMS. IMS will close the ISC VTAM session, keep the original message on the queue, and pass the ERP message as a DFS2073I message to the master terminal operator (MTO).

In IMS 14, when the new parameter ERPKPSES=Y is specified on the DFSDCxxx PROCLIB member, IMS keeps the ISC VTAM session open when the sense code X'0846xxxx' ERP messages is received from another subsystem. IMS dequeues the original message, and the accompanying ERP message is passed either to the MTO or the original inputting terminal depending on the bracket protocols specified on the link.

Shared Queues Overflow Protection

The IMS shared queues structure can overflow if the messages arrival rate is faster than the messages processing rate. The shared queues full condition can impact system availability.

In IMS 14, usage feedback information is passed to the queue space notification user exit, DFSQSSP0 that indicates how much of the message queue structure is used for both the primary structure and the overflow structure. You can use this information to monitor shared message queues and provide overflow protection. The QSPCF3FB flag in the input parameter list of DFSQSSP0 user exit indicates if the feedback information is returned. The QSPCFBKP field in the input parameter list points to the feedback information, and the QSPCFBKL field contains the length of feedback information.

Dynamic Storage for OTMA Descriptors

Before IMS 14, OTMA obtains a fixed amount of storage for the descriptors, with a maximum of 255 member descriptors and 510 destination descriptors at IMS startup in Extended Common Service Area (ECSA). This storage is consumed even if you’re not using the OTMA descriptors.

In IMS 14, IMS allocates the ECSA storage for OTMA descriptors dynamically when the descriptors are defined. Additionally the limit on the number of member descriptors increases from 255 to 4,095, and the limit on the number of destination descriptors increases from 510 to 4,095. The MDESCMAX parameter of the DFSOTMA member descriptor in the DFSYDTx PROCLIB member can be specified to set the new limit for member descriptors. The DDESCMAX parameter of DFSOTMA can be specified to set the new limit for destination descriptors. This DFSOTMA member descriptor with the new parameter(s) must be in the first 255 member descriptor entries.

For tools accessing OTMA descriptors, the descriptor entries for member descriptors and destination descriptors are now chained by pointers rather than contiguous in storage. Descriptor mapping are defined in source copy DFSYDES.

Automatic Refresh of OTMA Cached ACEE

Before IMS 14, OTMA caches the ACEE for input user ID when OTMA security is enabled. This cached ACEE is used for the subsequent transaction authorization for the user ID for better performance. However, when there is a change to the RACF security credentials for the user ID, you must issue the IMS command, /SECURE OTMA REFRESH, to refresh the cached ACEE for the user ID.

In IMS 14, OTMA automatically listens for changes to the RACF security credentials and refreshes the impacted ACEEs. Issuing /SECURE OTMA REFRESH command is no longer needed.

Connection-only Security for OTMA

OTMA provides two types of security: connection (OTMA client bid security) and trans-action/command authorization. Prior to IMS 14, both types were either enabled or disabled together.

In IMS 14, you can enable connection security without enabling the transaction and command security by issuing the IMS type-1 command /SECURE OTMA JOIN or specifying J on the OTMASE startup parameter.

Jack Yuan is a senior software engineer for IMS development. He can be contacted at

Yee-Rong Lai is a key information developer for the IMS SOA solution suite at the IBM Silicon Valley lab.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Bringing IMS and SOA Together With IMS Connect

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

Celebrating 40 Successful Years

IMS version 10 supports synchronous and asynchronous callout

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters