IBM announced the next version of Information Management System (IMS), its workhorse transaction processing and...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
database management tool, in October 2012. This version, like the others before it, promises to maintain the stature of IMS as a valuable part of IBM's software portfolio. What follows are some of the more interesting points.
Version 13 introduces database versioning, which allows database administrators to assign identifiers to different structures of the same database. When it is done properly, existing programs can continue to refer to the old structure while new code takes advantage of any changes.
- A change in segment length
- A new field at the end of a segment
- Redefining an old field and adding space to the end of a segment
To support versioning, the DBD and PSB macros will have a DBVER parameter. In addition, the DATABASE section of the DFSDFxxx system definition member specifies when versioning is active and the default version number, although the PSBGEN macro can override the system default. Programs wishing to use a nondefault version of a database must first issue the INIT DL/1 call. Lastly, versioning requires all the affected databases to be in an active IMS catalog.
At this point, the IMS V13 documentation doesn't supply information about the format or length of a database version ID. With the proper implementation, this could be a major boon for enterprises that want to change database structures without having to retrofit older programs. It may also reduce the number of planned database reorganization outages.
IMS V13 has a new asynchronous callout feature that allows programmers to write to MQ messages using the IMS's normal terminal interface -- ALT IOPCB. If it is truly transparent to the application, this new feature might enable administrators to redirect output to MQ without changing the underlying program.
Of course, the MQ interface information must exist somewhere. To accomplish this, IMS V13 adds MQSERIES destination descriptors in Open Transaction Manager Access (OTMA). Among other things, the MQSERIES descriptor lists the queue manager, as well as the request and reply to queue.
More exciting are the changes to synchronous callout. Synchronous callout allows an IMS transaction to use the ICAL function code to invoke another IMS transaction within the same unit of work. The originating transaction will wait until it receives a return message or a time-out value expires. The time-out value can be a system default or included in the ICAL call. It also implies that both transactions must end normally for IMS to commit in-flight resources.
To use synchronous callout, the systems programmer creates a TYPE=IMSTRAN M OTMA descriptor, to which the application must refer when it issues the ICAL. The descriptor itself has several parameters, one of which defines whether the originating transaction needs to know if the target task ended without sending a return message. If the parameter is set to YES, then IMS will issue return and reason codes to the calling application instead of a time-out.
The target transaction can be in the same IMS, an IMS in the same shared queue group or a control region connected through the Multi-Systems Coupling (MSC) link. This capability is available to all types of dependent regions.
There are a few restrictions with the new functionality. IMS doesn't call a couple of message routing and control exits for these synchronous conversations. This function is also unavailable through DBCTL and the target transaction has read-only access to main storage databases. IMS also imposes a 32 KB message segment length limit.
Synchronous callout seems to be the beginnings of something like transaction routing for CICS, with the idea that one IMS transaction can invoke another in the same Sysplex or, with TCP/IP MSC links, across a continent. There are still a lot of details to study and implications to work out that won't be entirely clear until IBM provides the full V13 documentation. However, this could be a very powerful way to move IMS into a more distributed model.
Other interesting IMS 13 enhancements include:
- IMS Universal Drivers. V13 introduces universal drivers for Java applications wishing to access IMS databases. Following the industry standard, there is a type 2 adapter for local access and a type 4 for remote.
- More PSTs. IBM increased the number of program specification table (PST) entries to 4,095. This goes along with IBM's general strategy to nudge users towards vertical integration that works better with the later generations of mainframe processors.
- IMS service oriented architecture protocol (SOAP) Gateway. Applications can create a unique tracking ID that will allow monitors and systems programmers to keep track of workloads as they flow through the system. This could be very helpful in debugging situations or when enterprises want to do their own internal tracking and routing.
There are also some discontinued functions:
- V12 was the last to support the SECURITY system generation macro. Now these parameters must be specified in system parameters.
- V13 will be the last version to support the IMS Connect SSL feature.
About the author
Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support, he has also worked with VSAM, DB2, IMS and other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career is as an operations architect responsible for establishing mainframe strategy and direction for a large insurance company. He works in south Texas, where he lives with his family.