MAINFRAME > Administrator > IMS

What's New in IMS Transaction Manager via the Service Process

Several enhancements recently made to IMS Transaction Manager through the service process for IMS versions 12, 13 or 14 warrant some attention. These enhancements improve traceability in an IMSplex environment, strengthen the IMS Connect communication protocol, reduce the risk of system outages due to message flood condition, lower the processing cost for expired transactions and support new special password characters in IBM RACF. This article provides a look into these enhancements and how to benefit from them.

Auto-signon for Time-Controlled Operations Terminal

The time-controlled operations terminal (TCO) allows you to initiate time-driven procedures for any IMS operation. It relieves operators from routine tasks that need to be performed at a specif-ic time or interval. However, when multiple IMS’s are running in an IMSplex, unless a user ID is specified for the TCO terminal, there’s no way to find out who submits a transaction or a com-mand in the IMSplex.

An IMS TCO enhancement provided in IMS V12 APAR PI37412 and IMS V13 APAR PI45427 introduces two new startup parameters in the DFSDCxxx member in the IMS PROCLIB data set to enable auto-signon for the TCO terminal for this purpose. The new parameters are TCOUSID= and SIGNTCO=.

Both TCOUSID= and SIGNTCO= let you specify a user ID that IMS will use if the TCO termi-nal did not sign on for transaction and command authority checking. The two parameters differ in that, when TCOUSID= is specified with a user ID, the TCO Logical Terminal (LTERM) won’t be signed on, and the user ID will not be included in any IMS log record. On the other hand, when the SIGNTCO= parameter is specified with a user ID, the TCO LTERM will be signed on with the user ID, and the ID will be included in all IMS log records. Table 1 provides a comparison of the two.

When both TCOUSID= and SIGNTCO= are specified in the DFSDCxxx PROCLIB member, the latter specification overrides the former one. In Table 2, consider the two scenarios where TCOUSID= is set to user1 and SIGNTCO= is set to user2.

If neither TCOUSID= nor SIGNTCO= is specified, and if no IMS/SIGN command is issued, the control region user ID will be used for authorization checking for the TCO terminal.

This enhancement is already in IMS V14 general availability base code.

Strengthened IMS Connect Message Retrieval Protocol for ACK Timeout

IMS Connect client applications can retrieve IMS asynchronous output or synchronous callout request messages by issuing a RESUME TPIPE call. When retrieving multiple messages from the IMS tpipe queue by using the auto or no-auto control option of the RESUME TPIPE call (with the field IRM_F5 set to either IRM_F5_AUTO or IRM_F5_NOAUTO in IMS Request Message prefix), the client application gets one message at a time. When a message is received, an acknowledgement (ACK) is sent to IMS to confirm the receipt of the IMS output message (see Figure 1). However, if some network issue occurs at this time and IMS waits longer than the ACK timeout value, IMS would cancel the RESUME TPIPE call and put the output message on the IMS timeout queue. If this is a synchronous callout message, it would be discarded and the synchronous callout call would be rejected. Because the RESUME TPIPE call is canceled by IMS but IMS Connect is not informed, the client application can wait for a long time before the issue is identified.

An IMS Connect enhancement provided in IMS V13 APAR PI49599 and an OTMA enhance-ment provided in IMS V13 APAR PI31424 work together to improve the ACK timeout condition for RESUME TPIPE calls. When IMS cancels a RESUME TPIPE call because of an ACK timeout, IMS issues a DFS4830I message to the system console about deleting a RESUME TPIPE call and informs IMS Connect by sending a protocol message. As soon as IMS Connect receives a delayed ACK from the client application, it sends a request status message with an error return code to inform the client and terminates the client socket. With this enhancement, the client application is informed of the ACK timeout condition and no longer needs to wait.

This enhancement is already in IMS V14 general availability base code.

Enhanced OTMA Flood Control with Higher Limit

To avoid system outages due to message flood conditions, Open Transaction Manager Access (OT-MA) monitors the number of input messages that are waiting to be processed in the IMS system. When the number of input messages from an individual OTMA client reaches its defined limit, OTMA suppresses new input messages from that client. The default limit for each OTMA client is 5000 and the maximum has been 9999 for each client. When the number of messages in the IMS system reaches 80 percent of the limit defined for a client, OTMA will start sending out warning messages to the system console and the client. However, for environments with high transaction rates, reaching 100 percent of the flood limit from the 80 percent level might not take long, leaving operators or administrators very little time to react. Having a bigger flood limit would allow more time for recovery.

An IMS OTMA enhancement provided in IMS V12 APAR PI45214 and IMS V13 APAR PI45657 increases the maximum flood limit for a client from 9999 to 65000. You can issue an IMS command /START TMEMBER INPUT to set the maximum value:

/START TMEMBER client-name INPUT new-limit

Or you can update INPT=new-limit in the OTMA client descriptor to specify a higher flood limit for a client. If the OTMA system client DFSOTMA isn’t used to set a global flood limit in the OTMA client descriptor and the client flood limit specified is higher than the default global flood limit, the global flood limit is set to the highest client flood limit specified.

This enhancement is already in IMS V14 general availability base code.

Overhead Elimination for Transaction Expiration Processing

To reduce processing costs, specify an expiration time for a transaction so that IMS doesn’t pro-cess transactions that its clients no longer use. When an IMS application program issues a Get Unique (GU) call to retrieve an OTMA transaction from the input queue, if IMS detects that the transaction has expired, IMS will take a pseudo abend 0243 to discard the input transaction. In the process of generating a pseudo abend 0243, IMS uses additional CPU cycles to create a symptom dump, to abend the message region, and to issue a DFS554A message.

An IMS enhancement provided in IMS V12 APAR PI48820, IMS V13 APAR PI51833 and IMS V14 APAR PI51834 allows you to simply discard an expired OTMA transaction without any pseudo abend to save CPU cycles. This eliminates the overhead of processing the expired trans-actions, especially useful for environments with high transaction rates. If you want a pseudo abend 0243 for each expired OTMA transaction at GU time, you can specify TODUMP=YES in the OTMA client descriptor in the DFSYDTx member of the IMS.PROCLIB data set. You can also request a pseudo abend 0243 for individually expired transaction by setting the TMAM-DUMP flag in the OTMA state data prefix of the input messages.

Support of New Special Password Characters

RACF has introduced 14 special characters (.<+|&!*-%_>?:=) that can be used in the RACF passwords. IMS current treats those special characters as invalid for RACF passwords.

To support passwords that contain these special characters from RACF, IMS provides an en-hancement through IMS APAR PI48111 and IMS Connect APAR PI48112 for IMS V14, and IMS APAR PI54037 and IMS Connect APAR PI54038 for IMS V13. To enable this function, z/OS APAR OA43999 must be installed and RACF special character support has to be turned on by using the SETROPTS command.

Enhancements Provide Flexibility

Enhancements delivered via the recent service process for the IMS Transaction Manager provide added traceability for IMSplexes, strengthen the IMS Connect RESUME TPIPE protocol for problem scenarios, reduce the chance of system outages due to message flood conditions, lower the processing cost associated with expired transactions and support new special password char-acters from RACF. Installing maintenance on a regular, ongoing basis to keep your service level current is always a best practice. The enhancements described in this article could increase sys-tem stability and might help save you some headaches.

Richard Schneider is an IMS Transaction Manager expert with IBM. He can be reached at

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