Source www.searchdatacenter.comRobert Crawford, Contributor
10.07.2009
This year marks the 40th anniversary of CICS. It has certainly come a long way from the original free system for line terminals and Assembler programs targeted for smaller shops. To pile onto -- er, honor -- this occasion, I offer my totally subjective list, in no particular order, of the basic, structural infrastructure that positions CICS for the future.
CICSPlex System Manager (CPSM)
CICSPlex System Manager (CPSM) is a mixed blessing. On one hand, it is an excellent tool for monitoring and changing resources across huge CICS region farms. Despite a few quirks, CPSM's dynamic transaction routing (DTR) runs with little fuss and works very well. Lastly, CPSM is the backbone of the Web User Interface (WUI) and CICS Explorer, two very nice management tools.
Unfortunately, CPSM is also a complicated black box with a confusing application programming interface (API) that often fails to work the same way twice. And, for one further gripe, CPSM real-time analysis (RTA) will never be very useful until all the alert information comes out as one console message instead of two.
Command-level interface
Sure, it's a little awkward and kind of jarring to see in the middle of some programming languages, but it freed IBM to work behind the scenes without worrying about someone diddling with system internals. I don't think there's any way to tell which features we take for granted that wouldn't be available today if IBM had to work around user code. For customers, this means that programs older than some recently hired college graduates can continue to run without recompiling.
More Task Control Blocks
CICS's single-task structure had two weaknesses. First, CICS can never run more work than one CPU can process. Second, any kind of operating system wait would freeze the whole region.
IBM created multiple tasks in the CICS address space and took the idea a step further, grouping Task Control Blocks (TCBs) into "modes" dedicated to handling a particular workload. Then they perfected the code necessary to painlessly (except for longer instruction path length) move a running transaction between task modes. This is where transactions using the open API will run. New modes may be on their way as IBM finds more things for CICS to do.
Resource management interface and task-related user exits
The resource management interface (RMI) grew out of the concept of CICS as a unit of work coordinator. Through RMI, other systems that require data integrity, such as databases (DB2 and IMS) or messaging (MQ) can participate in syncpoint/rollback processing. When the next big database management system (DBMS) comes out (DB3 or DL/2), CICS will be in position to support it once the RMI interface is available.
CICS run-rime libraries for higher-level languages
Support for higher-level languages like COBOL or PL/1 wouldn't have meant much if it had created too many programming restrictions or destroyed CICS's cooperative multitasking environment. Instead, someone at IBM got the bright idea of providing a CICS run-time library for the higher-level languages that would enable them to slide easily into the CICS environment. These CICS run-time routines took care of operating system-type requests (e.g., program management) as well as created separate copies of working storage so even COBOL programs could run in parallel.)
Of course, a few restrictions on what a CICS program can do remain, but those will drop off as CICS extends its multiple task control block (TCB) structure and the open API. The pain of maintaining separate run-time libraries is largely ameliorated with the advent of Language Environment (LE).
Multi-region operation
Multi-region operation (MRO) was a huge step forward. Instead of dealing with multiple single-use regions, systems programmers could connect them together into flexible and resilient CICSPlexes with an efficient, private protocol built on top of cross-memory services and cross-coupling facility.
Many concepts bloomed from this simple idea of allowing regions to talk to each other.
- Remote resource definitions, which allow a transaction in Baltimore to use a file in Vancouver without a single change to an application program. This reached its ultimate in usefulness with the distributed program link, which enabled CICS to implement a transport-agnostic client server structure and served as the entry point for CICS Transaction Gateway.
- Users could now design topologies to run transactions in parallel to avoid reaching the processing limit of CICS's quasi-reentrant TCB and get around virtual storage constraints.
- My personal favorite concept is dynamic workload routing. Specific transactions are no longer tied to specific regions. Instead, routing software can make a choice -- again, transparent to the application -- based on its own criteria, thus avoiding bottlenecks and slow or crippled systems. I couldn't imagine running the applications we have today without it.
I don't know what will be next, but its flexibility and structure well positions CICS to handle whatever the market decides next.
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.
No comments:
Post a Comment