What’s new in CICS CM V5.4
IBM CICS Transaction Server for z/OS (CICS TS) has evolved to become the world’s most powerful mixed language application server. In support of CICS TS, CICS Configuration Manager (CICS CM) provides a single point of management of CICS resource definitions and artifacts across multiple repositories with full audit control and back out capabilities.
CICS CM enables you to:
- Manage IBMÂ® CICSÂ® Transaction Server for z/OSÂ® (CICS TS) resource definitions across your enterprise from a single point of
- Manipulate definitions seamlessly across CSDs, IBM CICSPlexÂ® System Manager (SM) data repositories and z/OS File System (zFS)
- Distribute CICS resources across multiple sites using integrated export and import function
- Simplify user access with a powerful plug-in for IBM CICS ExplorerÂ®
- Create, edit, rename, compare, copy, move, and remove definitions either individually or in groups
- Promote multiple definitions using packages, migration schemes and transformation rules to transform definitions automatically, to
match the target environment
- Use the audit trail to generate reports and back out changes to any previous version of the definitions
- Compare CSDs and report definitions missing or having different values for all or user selectable attributes
- Assess CICS COLD START impact using updated CICS definitions when compared with the CICS region’s current runtime resources
CICS CM, in conjunction with the other tools in the CICS Tools portfolio, helps to improve operational efficiency and service agility. Development, systems and operational teams can adopt a collaborative, DevOps approach when building and deploying CICS applications and infrastructure. With CICS TS V5.4 and CICS Tools, it is quicker and easier to build, deploy, and manage powerful mixed language applications.
CICS CM V5.4 delivers the following new set of capabilities:
- zFS file management
- PKG packaging security
- DFHCSDUP audit collection
- Write commands to DFHCSDUP-format export files
- Inhibit server connection input on the CICS CM ISPF main menu
- Improved SSL connect messages
- Comply with DASD Extended Address Volumes
- Support for CICS Transaction Server V5.4
zFS file management
Some CICS resource definitions have related zFS files, for example AtomService config files and WebService WSDL files. In addition, recent releases of CICS TS have make increasing use of zFS for storing application and system artifacts. Products such as IBMÂ® z/OSÂ® Connect Enterprise Edition store configuration artifacts in zFS. Life cycle management and full audit control of these artifacts is a problem that all z/OS Systems and Application programmers face.
CICS CM V5.4 provides the ability to define zFS files and directories as Configurations and manage these easily from a single point of control. This example shows a single zFS file. Alternatively, you could set the RelativePath field to a directory (implicitly including all subordinate files and sub-directories), or to a relative path like /lev2/lev3/thirdlevdown.wsdl. If you have set backups to on for the target configuration, when you copy or migrate a backup is automatically taken (more on this later)
Use the CICS CM DEF command to define these CICS configurations. Note: You can also Copy and Migrate ZFSFILEs to an Export-import CICS configurations.
If zFS files are backed up, you can use a Recover or Backout command to make the zFS files revert to their previous state. Backup method NONE means no backups will be taken Backup count 9 is reasonable. This would give you the ability to recover the last 9 changes to each ZFSFILE resource definition.
You then define a zFS file or directory using option 2 CICS Resources. In CICS CM, a ZFSFILE resource definition can refer to either a single zFS file or a directory including all the files, sub-directories, and files within those directories. For brevity, this blog will generally refer to single files only.
- Define a zFS file or directory using option 2 CICS Resources.
- Select the zFS directory CICS configuration.
- On the Command line, enter DEF.
RelativePath field identifies the zFS file or directory. Data 1-4 can hold any text you like. By convention, enter the details of the associated CICS resource definition: name, type, group, and attribute. The important field is RelativePath. If the ZFSFILE refers to a directory, enter the directory name, e.g. newfolder. Note: You cannot set RelativePath to a zFS file of type FIFO, symbolic link, or external link.
Once the ZFSFILE definition is completed, line actions are available for these resources. These are the line actions available for ZFSFILE definitions. Copy and package allow you to transport the zFS file
Copy provides a quick way to test zFS functionality in CICS CM. When you copy a ZFSFILE, the zFS object (file or directory plus subordinate objects) is copied to the target location. The Prompt states *Copied if the ZFSFILE did not previously exist in the target configuration, or *Replaced if it already existed there. You can copy to a zFS CICS Configurations or to an Export-Import file CICS configuration
Using option 2 CICS Resources from the ISPF Main Menu, you can package a ZFSFILE
Change packages can hold both ZFSFILE resources and CICS resources. When a change package that contains a ZFSFILE is migrated, the associated zFS file is transported in accordance with the migration scheme.
As shown in this migration scheme, you could migrate CICS resource definitions (DEVT to TEST) and zFS files (ZDEVT to ZTEST) at the same time.
CICS CM keeps an audit trail of all changes to these zFS artifacts. ZFSFILE resource definitions are stored in the repository (that is, the CCVDDD file). Before and after images of changes are stored in the journal. You can report on ZFSFILE changes via ISPF menu option 4.3.
The audit record also identifies whether the zFS file or directory was updated, created, deleted, or whether there was no change to the zFS file. You can Recover and Backout changes to ZFSFILEs, which can cause the associated zFS file to be deleted, updated, or created.
The graphic below shows a side by side comparison of the history or audit records for zFS file WSDL01.
PKG – packaging security
To control access to Packaging of zFS resources, you can use RACF or another SAF-enabled external security manager (ESM) to control who can do what with ZFSFILEs (API commands and CICS resource keys). The security profile examples below assume that Security key prefix for server API commands is set to CCVAPI. In example 2, ZFSFILE represents (has a RelativePath field set to) a file in the zFS.
When you migrate or copy a zFS file or directory, the CICS region user ID becomes the owner of the file The Unix file permissions applied to the zFS object in the target location are the permissions that the file had in the source location. There are zFS file processing exits (pre- and post-) and samples CCVXZEC (pre) and CCVXZTC (post). In the pre-processing exit, you can change file permissions, preserve or set ACLs, or, in some circumstances, change ownership or group ownership of the zFS file. You can also cause zFS manipulation to be rejected for a particular ZFSFILE or configuration. In the post-processing exit, you can manipulate the zFS file after CICS CM processing is complete, or log information messages about changes in the zFS
The new enhancement to Packaging security enables you to ensure a user can package resources only when the resources are in specific groups or CICS configurations. You can use the new PKG security call to allow or disallow users from packaging resource definitions or commands. This makes it easier to stop people accidentally distributing an old or incorrect version of a resource.
The examples below are based on the assumption that Security Key prefix is set to CCVAPI. See sample library (SCCVSAMP) member CCVXSAF2 for more details, including list of object types. PKG security is also described in the CICS CM V5.4 Userâ€™s Guide, topic Checking authority to package resources or commands.
DFHCSDUP audit collection
In some CICS customer sites, DFHCSDUP is used to make emergency changes to CICS resources or DFHCSDUP is used to make resource definition changes in remote environments where CICS CM is not available. These changes are not tracked by CICS CM, so there is nowhere where you can see an audit record of both the CICS CM and the DFHCSDUP changes.
Using the new capability in CICS CM V5.4, you use supplied samples to implement a wrapper program around DFHCSDUP to capture the DFHCSDUP audit trail. You can then view changes from both sources using CICS CM audit reports and views. You do not need to change any existing JCL jobs which run DFHCSDUP.
You can use samples CCVXDUP1-9 in SCCVSAMP to set up DFHCSDUP audit collection. CICS CM uses a wrapper so that any existing JCL which calls DFHCSDUP does not have to change. DFHCSDUP effectively becomes an alias for CCVCSDUP.
This graphic shows the 3 scenarios in which CICS CM can collect DFHCSDUP audit records:
- You can use EXCI to save the audit records directly to the CICS CM server
- CICS CM can save the audit records to a file, and load those records into the CICS CM server when it restarts, or when the CCVJ transaction runs. This is suitable when both DFHCSDUP and the CICS CM server can access the same file storage system
- When DFHCSDUP and CICS CM do not have shared DASD, CICS CM can save the audit records to a file, you can use a script to transfer the audit records by FTP to the CICS CM server and then trigger the CCVJ transaction to load the audit records into the CICS CM server. The samples can help
A DYNAMIC mode is available which uses EXCI when it is available, and uses FILE otherwise
Support for new resource definitions in CICS TS V5.4
CICS CM supports the new MQMONITOR definition. You can use this new resource to configure an MQMONITOR, which can be a trigger monitor, an MQ bridge monitor, or a user-written monitor.
For further details on CICS CM V5.4, please see Announcement 217-333.
If you want to reach out to me, please find me at the following channels: