IMS v11 scalability and usability
IMS version 11 is one of the best examples of scaling up by growing horizontally. However, some parts of the system, such as virtual storage, can't grow. The latest version of IMS provides virtual storage relief by moving things above the 4G bar.
IMS 11 provides local system queue area (LSQA) relief by moving "CDE-like" blocks into 64-bit storage, namely the CDEs, or content dictionary entries, that IMS uses to keep track of programs and storage blocks within control address spaces. Reducing LSQA usage may prevent a bounce of IMS and possible Initial Program Load of the entire LPAR.
A couple of other important blocks go into 64-bit storage as well. Perhaps the biggest bang comes from Fast Path (FP) buffers. Large systems with many dependent regions have a lot of FP buffers that tend to use large chunks of the extended common service area (ECSA), whose utilization must be carefully managed.
IMS 11 moves buffers for most types of FP databases above the bar, where it allocates and manages them as needed based on database block size. The automated control also benefits database administrators (DBAs) who will now be able to choose block sizes based on performance rather than what fits into the ECSA buffer pools. The amount of available buffer storage is limited only by the dependent region definition and the number of dependent regions. You may enable 64-bit FP buffers through the FPBP64M parameter in the
Note that FPBP64M's only parameter specifies the amount of storage in megabytes to be used for data entry databases, or DEDBs.
Parts of IMS' Access Control Block Library (ACBLIB) go above the bar as well. At application schedule time, IMS moves non-resident Program Specification Blocks and Database Management Blocks into 31-bit and 64-bit storage. Then, with each subsequent schedule, IMS copies the blocks from above the bar to 31-bit storage, thus saving I/O against the ACBLIB library. The ACBIN64 parameter in the
IMS 11 also implements dynamic allocation of ACBLIB. An installation can use this feature merely by removing the ACBLIBA and ACBLIBB DD cards from the control region and then creating macro for dynamic allocation (MDA) members in the DFSMDA library for the two datasets. Then, if an installation needs to re-organize an ACB library, they can ask IMS to switch to the alternate dataset and rebuild the freed ACBLIB as needed.
Introducing database quiesce
Many 24/7 shops have trouble finding time to generate safe database recovery points. For this problem, IMS 11 introduces database quiesce.
An operator can invoke a quiesce through IMS commands. During the quiesce, read-only calls may access the impacted databases while update requests are held until the quiesce is released. Batch jobs will fail database authorization during a quiesce. There are two options for specifying when the quiesce will be released. One option releases the quiesce as soon as it creates the recovery point. The second type waits for an explicit release command.
This feature is enabled easily enough by upgrading the Database Recovery Control RECON dataset. Another parameter, DBQUIESCETO, controls how many seconds IMS must wait before timing out a quiesce request. Database quiesce requires the common service layer for those who haven't implemented yet.
Although it is kinder and gentler than stopping databases, you wouldn't want to quiesce any databases at 10:00 on Monday. The documentation also didn't say anything about DB2 updates in mixed applications.
Synchronous callout isn't unique to IMS 11, as IBM introduced it in version 10 through the service stream. For IMS version 11, the pertinent APARs are PK81543 for Open Transaction Manager Access (OTMA) and PK81544 for IMS Connect. As the name implies, synchronous callout allows IMS applications to call services in other subsystems and wait for the reply.
Synchronous callout introduces the new command code ICAL. When an application issues an ICAL through an Application Interface Block (AIB), it specifies the input and output areas, an eight-byte OTMA descriptor name along with a timeout value. On the way out, IMS generates a correlation token that OTMA passes to the called service. The called service must supply the token with its reply so IMS can complete the circle. The input and output areas don't go through IMS' message queue and therefore don't need an LLZZ type header. This also means the messages may be longer than 32 KB.
IMS touts synchronous callout in support of service-oriented architecture Web services, although there are some restrictions on what IMS supports. I think this development might be even more significant than that. On the foundation of synchronous callout, IMS applications may be able to synchronously call any manner of services within an architected interface, which is a strong position to be in for the next big thing (NBT).
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at firstname.lastname@example.org.
This was first published in January 2010