IBM’s CICS TS 4.2 is the latest release of the venerable transaction processor and should be generally available...
by June 24. Until then, IBM is providing an open beta, giving customers the opportunity to kick the tires until July 31. Here are some of the features you can expect:
IBM expanded event processing with a new and better editor. It also added an HTTP event handler that can publish events without modification, similar to what happens with MQ events. For data integrity, a new option will abend the transaction if the event emission fails.
More interestingly, 4.2 extends event emission to a subset of system state changes. Included in this new release are event points for file status changes, along with disconnection or reconnection of the DB2 interface. The most useful points are perhaps those where a shop can ask CICS to emit events when the number of active tasks crosses a threshold percentage for max task (MXT) or a transaction class (TCLASS). Some users may want to exploit task threshold events to replace inaccurate or expensive sampling techniques. Hopefully, these new system event types are a glimpse into a future where CICS adds more system state change events, allowing customers to create better automation for dashboards and monitors.
IBM touts many performance improvements for 4.2 centered on new developments in thread-safeness. Getting more work on the open Task Control Blocks (TCBs) also improves an individual region’s throughput and avoids horizontal sprawl.
CICS added a couple dozen existing application programming interface (API) and systems programming interface (SPI) commands to the thread-safe list. Several new SPI commands made the list as well.
In addition, the mirror program DFHMIRS is now thread-safe for function shipping requests over IP connections (IPIC). A new program attribute, CONCURRENCY REQUIRED, forces CICS to move a transaction to an open TCB when invoking the program. If the program does something that’s not thread-safe, CICS will move the task back to an open TCB before returning control to the program.
The DBCTL interface is now thread-safe, which reduces transaction CPU because CICS doesn’t have to bounce a task between open and quasi-reentrant (QR) tasks for each IMS database call. We can only hope that CICS will soon take ownership of the DBCTL interface to provide the same ease of control we have for DB2 and MQ.
CICS TS 4.2 moves two big virtual storage consumers, the internal trace table and temporary storage, above the 4 GB bar. Moving the trace table into 64-bit storage enables shops to capture more trace and dump trace information. Temporary storage above the bar encourages the use of better performing main temporary storage and may decrease the requirement for additional parallel regions.
This support does not come for free. Trace overhead, already significant, will probably get a little larger considering the addressing mode switches necessary to get things above the bar. Systems programmers should also be careful about the amount of storage they want to use relative to the 64-bit memory limit (MEMLIMIT) set by the system when CICS initializes. Shops should consult the virtual storage section of IBM’s CICS TS 4.2 performance guide for information about what goes into 64-bit storage and how it plays into MEMLIMIT.
CICS TS 4.2 supports IBM’s 64-bit, 6.0.1 JVM, which makes it easier to accommodate storage-hungry Java applications. More significantly, 4.2 marks a shift of CICS being a grown up JVM server like WebSphere. CICS maintains support for old-style pooled JVMs, but the 4.2 announcement letter’s statement of direction tells us it may be dropped in the future.
In a JVM server, you can run more than one Java application inside of a JVM. There is also the ability to run multi-threaded Java applications in the same JVM and CICS task. The server concept seems to allow Java to be Java without so many tweaks for the mainframe.
There are a series of qualifications that the Java code must meet to run in the Java server. For example, the code must comply with the Open Source Gateway initiative (OSGi). OSGi is a many splendored thing, designed to improve and automate the management, deployment and execution of Java applications through the use of bundles.
Besides the big hitters mentioned above, there are some other improvements included in this new release:
- The number of Local Shared Resource buffer pools increases from 8 to 255 -- another opportunity to either segregate file buffer pools or consolidate regions and reduce sprawl.
- New types of function shipping are available over IPIC connections.
- Recovery support for MQ to parallel how CICS resynchronizes with DB2 and IMS after a failure.
- More control for how many times a DB2 thread may be reused. This feature will come in handy for shops where online traffic sometimes gets in the way of online database re-orgs.
- Support for password phrases in case you want to memorize a 100 byte string to get onto CICS.
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.