Skip to main content

IMS Transaction Manager Advancements for 2020

IMS Transaction Manager performs online transaction processing and enables enterprises to handle a high volume of requests in a secure, reliable and scalable manner.

IMS in red against computer code

IMS has been one the stalwarts of modern enterprises for decades. Organizations spanning multiple industries including finance, travel and insurance depend on IMS to handle their mission-critical applications and workflows.

One core component of the IMS product portfolio is the IMS Transaction Manager (IMS TM). IMS TM performs online transaction processing and is fundamental in enabling enterprises to handle a high volume of requests in a secure, reliable and scalable manner.

Despite the disruption to the world during 2020, our team has persevered to deliver several enhancements for IMS TM across the areas of scalability, serviceability and security. IMS TM has been a critical piece of infrastructure for modern applications for decades and we are dedicated to ensuring the continued success of our clients in the future.

APPC Transaction Expiration Enhancement

With the IMS transaction expiration function, an input transaction can be discarded at Get Unique (GU) time when the transaction is expired based on the EXPRTIME value specified via the TRANSACT system definition macro, the CREATE TRAN type-2 command, or the UPDATE TRAN SET(EXPRTIME) type-2 command. The expiration time is determined by the difference of the transaction arrival time and the store clock (STCK) value at GU time. The difference is compared with the EXPRTIME value of the scheduler message block (SMB). If the difference is equal to or greater than the EXPRTIME value, the input transaction is discarded. However, this function does not support transactions entered via Advanced Program to Program Communication (APPC) protocol. 

The APPC Transaction Expiration Enhancement, provided in IMS version 15 APAR PH20290, introduces a transaction expiration support for asynchronous APPC transactions. The EXPRTIME for APPC synchronous transactions is not supported as a restriction.   

Static Terminal Output Security Enhancement

VTAM terminals (nodes) can be defined to IMS in System Definition using the TERMINAL and NAME macros. The TERMINAL macro defines the physical terminal (NODE), while the NAME macro associates a logical terminal (LTERM) to the physical terminal. Terminals defined in System Definition are referred to as static terminals.
For static terminals, IMS queues transaction output to the LTERM assigned to the NODE. Any user with valid authorized access to the static terminal can access the queued output. As documented, IMS does not automatically provide output security for static terminals, so the output generated by a transaction initiated by one user signed on to a VTAM terminal could be read later by another user signed on to the same VTAM terminal. To prevent this, the installation typically codes the Physical Terminal Output Edit exit (DFSCTTO0 or equivalent) to discard messages when the User ID of the current user does not match the User ID associated with the message.
The Static Terminal Output Security Enhancement, provided in IMS version 15 APAR PH24997, provides an alternative to having to code a user exit for the purpose of discarding messages. The new STATICOUTSEC keyword is added to the DFSDCxxx PROCLIB member. When specified, IMS will automatically discard transaction reply messages for static terminals (except for ISC and MSC terminals) when the current user does not match the user that initiated the transaction. When IMS discards a message due to the specification, the Physical Terminal Output Edit exit is no longer called. In addition, this new option will cause IMS to exit all active and held IMS conversations when a user signs off from a static terminal. Finally, this new option can either be applied to all static terminals or to those static terminals that require user sign on.

OTMA Lightweight TPIPE Enhancement

IMS allocates over 9K of extended private storage to create an OTMA TPIPE. However, some storage allocated for TPIPEs is not used when a TPIPE is created for ALTPCB output processing, for output reroute, or for shared-queues backend processing. When a TPIPE flood limit is specified by a customer via the MAXTP parameter, the TPIPE limit in a shared-queues environment can be hit quicker than expected.
The OTMA Lightweight TPIPE Enhancement provided in IMS version 15 APAR PH17832 removes the allocation of TPIPE-related storage that is not being used and prevents IMS from quickly reaching the TPIPE flood limit. The new LITETP= parameter in DFSOTMA descriptor in the DFSYDTx PROCLIB member is introduced to activate the lightweight TPIPE function. LITETP=NO is the default so that the function is activated only when it is needed by our clients. Once LITETP=YES is specified, a DFS7411I message is displayed during IMS initialization to indicate that this function is enabled. For customers with TPIPE flood limit specified, IMS introduces the concept of “weighting factor” (WGF) which is the percentage of the lightweight TPIPE storage size compared to the regular full TPIPE storage size. This percentage is usually 28%. With the WGF, the total TPIPE count is adjusted by considering the number of lightweight TPIPEs, weighting factor, and the number of regular TPIPEs. This adjusted TPIPE count, displayed via DFS7412I or DFS7413I message, is significantly less than the TPIPE count in the shared-queues backend IMS and will prevent IMS from reaching the TPIPE flood limit as quickly as before. Additionally, the enhanced /DISPLAY OTMA command will display the number of lightweight TPIPEs and the weighting factor at any given moment.

Enhanced OTMA Output Security for IMS-to-IMS TCP/IP Communications

An IMS alternate PCB (ALTPCB) output message can be sent to a remote IMS from a local IMS using the IMS-to-IMS TCP/IP communication function with the remote destination defined in the local IMS via OTMA destination descriptor and IMS Connect. Once the message is delivered to a remote IMS, it will be processed as an input transaction based on the OTMA security level defined in the remote IMS. All the OTMA security levels, except the PROFILE security, are supported in the remote IMS.

This enhancement, provided in IMS version 15 APAR PH20667/PH13450, supports the PROFILE security for the remote IMS. The security flag needed by the PROFILE security will be set by the local IMS and sent to the remote IMS. This security flag can be created or updated by using new RMTSEC parameter of CREATE OTMADESC or UPDATE OTMADESC command if the original message in the local IMS is not from an OTMA client.

Enhanced Workload Manager (WLM) Usage for OTMA Input Transactions  

For every OTMA input transaction, IMS will invoke WLM to classify a unit-of-work by passing the input TPIPE name. In the case of IMS Connect, the TCP/IP port number, which is treated as input TPIPE name for Commit Mode 1 transaction, will be passed to WLM. For Commit Mode 0 transaction, the IMS Connect client name treated as input TPIPE name will be passed to WLM for service classification.
This enhancement, provided in IMS version 15 APAR PH20420, also allows for clients to classify the unit-of-work based on an assigned logical unit (LU) name. OTMA will pass this LU name, which is specified in the LTERM override field of OTMA input prefix, to WLM instead of passing the input TPIPE name. If DFSOTMA descriptor in the DFSYDTx PROCLIB member has WLMLTRM=YES, then an assigned LU name will be passed to WLM. The default is WLMLTRM=NO, which means the OTMA input TPIPE name will be passed to WLM for service classification.

Serviceability Enhancement for IMS Callout Using DL/I ICAL Calls

The DL/I ICAL call allows an application program that runs in the IMS TM environment to send a synchronous request for data or services to a non-IMS application program or service that runs in a z/OS or distributed environment via IMS Connect.  
This serviceability enhancement, provided in IMS version 15 APAR PH24788/PH30319, includes IMS region ID and IMS program name in the prefix of an ICAL callout message so that the origin of a callout message can be easily identified for serviceability.

Stay on top of all things tech!
View upcoming & on-demand webinars →