IBM started shipping CICSPlex System Manager (CPSM) for free when they re-branded CICS/ESA as CICS/Transaction Server (CICS/TS). Reportedly co-developed with BMC, CPSM is kind of a mixed bag of system management, automation and workload management. It's not exactly easy to implement or manage, but it does provide lots of advantages for those who want to exploit them. This column will deal with some CPSM basics.
Defining CICSPlex regions
One of CPSM's aims is to present a single-system image for complicated CICS environments. Conceptually, you can have a CICSPlex without CPSM in a homogenous data-sharing workload spread over various LPARs and regions. CPSM goes a step further to formalize the idea of a CICSPlex. In a CPSM CICSPlex, a CICS region is referred to as Managed Address Space (MAS). You can define one large CICSPlex encompassing all the regions in a Sysplex, or multiple CICSPlexes using subsets of them. However, an MAS may belong to only one CPSM CICSPlex.
MAS can be local or remote. A local MAS runs on the mainframe while a remote MAS runs on Windows or OS/2 and are managed via APPC.
In addition to MAS, CPSM uses these beasts:
- Coordinating Address Space (CAS), which is not part of the CICSPlex. But it provides support for the TSO end user interface (EUI) and can be bounced independently of any other CPSM address spaces. Note that the TSO EUI goes away with CICS/TS 3.2, but we don't know yet what this means for CAS.
- Environment Service System Services (ESSS) is a relatively simple task that initializes after an IPL. Its job is to own CPSM's data spaces so they will be available even when an MAS or CMAS goes down. ESSS also provides some interfaces with Netview for automation purposes.
- CPSM Web Interface (WUI)
- CICSPlex SM Address Space (CMAS)
Connecting to CPSM
The CMAS and WUI are distinguished by function and how they connect to CPSM. A CPSM connection is controlled through the CPSMCONN system initialization table (SIT) parameter as follows:
- CPSMCONN=LMAS for an MAS
- CPSMCONN=WUI for a WUI
- CPSMCONN=CMAS for a CMAS
According to the documentation, you can still start the CPSM interface through PLTPI programs, but IBM prefers you use the CPSMCONN parameter.
In general, after starting the interface the CPSM code reads configuration parameters from the EYUPARM DD card. The CMASes and WUIs are still CICS regions; you can log onto them to do whatever snooping you wish to do. It also means you may monitor them as you would any other region.
A WUI region provides a Web interface to CPSM. It maintains a VSAM file containing Web view and menu definitions called the Web repository (EYUWREP). CPSM's WUI comes with some serviceable Web pages and allows you to develop some of your own, which makes the WUI an ideal place for building custom views into your CICS environment. Examples would be a Web-based CICS health dashboard or something Operations could use to open or close files.
Of the CPSM menagerie, the CMASes are the most complicated. A CMAS manages and monitors the environment and the managed address spaces. There should be one CMAS for each LPAR on which CICS executes. Each CMAS maintains its own data repository (EYUDREP), which is another VSAM file containing CPSM configuration and object definitions. Each CMAS connects to its partners through dynamically created LU6.2 connections. CMAS shares changes to the environments through these links. Each CMAS writes status messages to file EYULOG, which is CPSM's equivalent to CSSL.
One special CMAS should be designated as the control point (CP). The CP is so called because it is the coordinator of CPSM definition changes and its responsibility is to ensure each CMAS is up to date. Therefore, any CPSM definition changes should be done through the CP CMAS. If the CP goes down the other CMAS can operate, but you shouldn't make any changes to CPSM. You should choose your CP carefully, as the procedure moving it to another CMAS is long and gruesome.
CPSM security is thorough and at times frustrating. Authorizing the CPSM transactions is the easy part. Otherwise, CPSM carefully controls access to "objects" through RACF FACILITY rules somewhat akin to CICS command level security. An example of a CPSM object is a file. READ access controls who can look at files from CPSM. Similarly, UPDATE access to the CPSM FILE object controls who can change the file's status. With this type of control a shop can use one set of CPSM WUI Web pages, allowing application programs "look but don't touch" access to production while supporting full access in development.
This has been a brief overview of CPSM. I hope to build on it in the coming months. As this was brief, I would still recommend reading the manuals or attending a class to get more details before trying to roll out your own CPSM CICSPlex. It's a wonderful tool, but it can be kind of cranky, and some bad decisions in the design phase can haunt you for a long time.
ABOUT THE AUTHOR: Robert Crawford has been a CICS systems programmer off and on for 24 years. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
