Skip to content

Installation Considerations

This chapter describes issues you must consider before installing ChangeMan ZMF.

Note

The information in this chapter is provided to help you plan for your installation. Do not execute any installation or configuration tasks until you get to Unloading the Software and Installing ChangeMan ZMF Components.

System Considerations

This section describes system issues that you must consider before you start the ChangeMan ZMF installation process.

z/OS Subsystem

While each SERNET instance is identified by a "subsystem ID," SERNET is not a formal z/OS subsystem like JES or Db2®; do not define SERNET in the subsystem name table in SYS1.PARMLIB(IEFSSNxx). If you define it in the subsystem name table, SERNET may abend with an S0C4 when it tries to update the subsystem communication vector table with the identifying address space (ASID).

Updating the System Linkage Index

Each SERNET instance uses a system linkage index (a z/OS resource). The system linkage index is not released when a SERNET started task is shut down. However, the next time the same subsystem ID (a SERNET instance identifier) is initialized, it uses the same system linkage index.

The NSYSLX parameter in IEASYSxx defines the number of linkage indexes (in addition to those in the system function table) to be reserved as system linkages. The default number is 55. If your environment has a number of subsystems defined that use system linkage indexes (for example, Db2 and IMS V5), you might need to increase the value of NSYSLX if you define multiple SERNET instances on the same LPAR.

Non-Swappable

The SERNET address space must be available at all times for asynchronous requests coming from client desktops and from other z/OS address spaces. Each SERNET instance makes itself non-swappable by internally issuing the following:

SYSEVENT TRANSWAP

TRANSWAP is IBM’s preferred method of making an address space non-swappable for long periods of time.

Reusable Address Space Identifiers (ASID)

SERNET, ChangeMan ZMF, and all selectable options for ChangeMan ZMF except the Enterprise Release Option (ERO) and the ChangeMan ZMF Db2 Option are compatible with reusable ASIDs. Ensure that reusable ASIDs are enabled on your z/OS system.

For information about ERO and reusable ASIDs, see the ChangeMan ZMF ERO Getting Started Guide.

We recommend that you do not add load libraries for our mainframe products to the LINKLIST. Instead, include a STEPLIB statement in the JCL for each SERNET instance, and include a JOBLIB or STEPLIB statement in the JCL for each batch job submitted by the product.

STEPLIB and JOBLIB are preferred because:

  • If you license more than one product and you do not keep the products at compatible release levels, common load modules in a LINKLIST library might interfere with the proper function of some of these products.

  • You should segregate delivered (vendor) versions of load modules in libraries separate from customized programs such as exits. It is easier to maintain the proper concatenation of custom and delivered load libraries if they are in STEPLIB or JOBLIB statements in started procedures and batch JCL.

VSAM Performance

ChangeMan ZMF uses VSAM files to store information about application components and change packages. The ChangeMan ZMF package master, component master, long name component master, activity log, and recovery files are active KSDS VSAM files. This section provides information about enhancing VSAM and ChangeMan ZMF performance.

Defining VSAM file characteristics

Model JCL to define VSAM KSDS files for ChangeMan ZMF includes DEFINE CLUSTER parameter settings that are intended to optimize performance. It is recommended that you use the delivered settings for CISZ, FREESPACE, and SHAREOPTIONS.

AMP Parameters

Model JCL for ChangeMan ZMF files in a SERNET started procedure is delivered with AMP parameters to optimize VSAM performance. It is recommended that you use the delivered AMP subparameter values for STRNO, BUFND, and BUFNI. These subparameters can be adjusted when you have performance data that suggests different settings.

As delivered, ChangeMan ZMF obtains all VSAM buffers and control blocks above the line (RMODE31=ALL). No GSR or LSR buffer pools are used.

VSAM I/O Optimization of ZMF Master Files

Customers have the option of using BLSR (Batch Local Shared Resources), SMB (System Managed Buffers), or no buffering on their started task JCL. There are sample JCL cards which can be commented in/out to pick the desired method.

SMB only applies to extended VSAM datasets; it has no effect otherwise.

The SMB parameter SMBVSP can be tweaked to improve performance; ACCBIAS and SMBDFR should not be changed. For more information on tuning SMB, see the IBM manual z/OS DFSMS Using Datasets.

BLSR is a subsystem of MVS that improves performance by allowing programs that use VSAM non-shared resources (NSR) to use VSAM local shared resources (LSR) without changing application source code or link-editing application load modules.

BLSR can be used with ChangeMan ZMF Version 5 and above. The required JCL changes are included as comments in the model JCL for a ChangeMan ZMF instance.

See the MVS Programming Batch Local Shared Resources Subsystem Guide for complete information on the application of BLSR in your environment. It is recommended that one of the supported VSAM I/O optimization methods be enabled as it has shown to dramatically improve VSAM I/O performance with the ZMF instance.

VSAM Linear Data Sets

ChangeMan ZMF stores some data in VSAM Linear Data Sets (LDS). An LDS contains data but no control information. IDCAMS is used to define a linear data set. An LDS has only a data component. An LDS is just a physical sequential VSAM data set comprised of 4 KB physical records.

When a ChangeMan ZMF program opens an LDS, the entire file is read into a data space. The data is accessed by the program as a byte-addressable string in virtual storage. When a program updates the data space, the LDS is updated asynchronously by data-in-virtual services.

To a ChangeMan ZMF program, an LDS looks like a table in virtual storage that requires no physical I/O for processing. ChangeMan ZMF employs VSAM LDS files to improve the performance of files that are accessed non-sequentially in an unpredictable pattern. Only programs running under the SERNET/ ChangeMan ZMF started tasks are allowed to dynamically update VSAM LDS files.

In ChangeMan ZMF 8.1, there are two sets of data that are stored in VSAM LDS files:

  • An impact analysis LDS contains multiple tables, such as baseline unique number (BUN) data, component identification data, and component relationship data. Impact analysis data is updated as component relationships are added, updated, and deleted, and as library types, applications, and baseline libraries are added and deleted.

  • Relationships between XML schemas and DSECTS used for fixed-format control blocks and copybooks are stored in the XMLSPACE LDS. These relationships are static between updates to ChangeMan ZMF software.

LDS Space Utilization

The ChangeMan ZMF impact analysis LDS is defined with extents. The physical space is logically formatted as it is filled with data. You can determine the space utilization of the impact analysis LDS by running an IDCAMS LISTCAT.

The contents of the XMLSPACE LDS do not change between software releases. Space utilization is managed by with changes to the delivered JCL that creates and populates the LDS.

Using Db2 to replace the impact analysis LDS

If you want, you can use Db2 to host the baseline I/A table. See Using Db2 to replace the impact analysis LDS for more details.

SERNET and ChangeMan ZMF JCL

Expect to run at least two instances of ChangeMan ZMF:

  • A production ChangeMan ZMF instance that manages application components in production libraries.

  • A test ChangeMan ZMF instance that the ChangeMan ZMF Administrator uses to test upgrades and modifications before they are installed into the libraries running the production ChangeMan ZMF.

Each instance of ChangeMan ZMF runs as an application under a separate SERNET instance. Before building SERNET and ChangeMan ZMF JCL, consider the issues described in the following subsections.

Subsystem ID

Each instance of SERNET is identified by a unique one-character subsystem ID. Valid values for a subsystem ID are:

  • Blank (space)

  • Numeric 0-9

  • Alphabetic A-Z

  • Special characters @, #, and $.

Note

Although a null (blank) subsystem ID is valid, it is strongly recommended that you avoid using a null subsystem ID.

A subsystem ID is assigned through SERNET keyword option SUBSYS=subsysID, which is input to program SERVER.

SERNET Started Task Names

As stated previously, you will have at least two ChangeMan ZMF instances: a test instance and a production instance. You may also have multiple ChangeMan ZMF instances running on other LPARs to manage production libraries.

Each ChangeMan ZMF instance runs under a separate SERNET started task. Each SERNET started task must be assigned a unique identity in z/OS for console commands, automated data center management tools, and SMF. There are three ways to establish a unique z/OS identity for a SERNET started task:

  • Member name - Build a separate procedure (member) for each started task. Use only the member name in the START command.

    S SERPROC1

    The SERNET started task jobname and identifier is SERPROC1.

  • Identifier - Append an identifier to the procedure member name in the START command.

    S SERPROC.SERTASK2,ID=2

    The SERNET started task jobname is SERPROC and the identifier is SERTASK2.

  • Jobname - Use the JOBNAME parameter in the START command.

    S SERPROC,JOBNAME=SERTASK3,ID=3

    The SERNET started task jobname and identifier are both SERTASK3.

If you use a common procedure for several SERNET instances, then you must use an identifier or a JOBNAME parameter in the START command.

Note

When you assign a started task identity that is different from the started procedure member name, IBM recommends that you use the JOBNAME parameter because it provides an identity that is available to the most z/OS services.

Parameters for SERNET and ChangeMan ZMF

SERNET behavior, and the behavior of applications like ChangeMan ZMF that run under SERNET are controlled by keyword options input to program SERVER.

Passing Parameters to SERNET

Keyword options may be passed to SERNET in two ways:

  • In the EXEC statement for program SERVER, as subparameters in the PARM= parameter.

    Example 1:

    //SERVER  PROC ID=1,OPT='XCH=1234'
//SERVER  EXEC PGM=SERVER,                *Started Task
//             REGION=0M,                 *Maximum Region
//             DYNAMNBR=200,              *High allocations
//             PARM='SUBSYS=&ID,&OPT'     *Execution Parms

    Example 2:

    Override the SERVER parameters in Example 1 by setting symbolic parameters in the START command.

    S SERPROC,ID=2,XCH=2345

  • In a data set read by program SERVER at a DD statement referred to by the keyword option DDNAME=ddname coded as a PARM= subparameter.

    Example:

    //SERVER  PROC
//SERVER  EXEC PGM=SERVER,                 *Started Task
//             REGION=0M,                  *Maximum Region
//             DYNAMNBR=200,               *High allocations
//             PARM='DDNAME=ANYNAME'       *Execution Parms
. . .
//ANYNAME  DD  DSN=SERCOMC.PARMS(SERPARM)

    PDS member SERPARM contains:

Keyword Options For ChangeMan ZMF

There are many SERNET keyword options. Options listed in this section are required or are commonly used with ChangeMan ZMF.

See Appendix D, "Sernet Keyword Options" for detailed descriptions of the options listed here.

To find other SERNET keyword options that can be used with ChangeMan ZMF, look for CMN or ZMF in the “Application(s)” row of the description tables in Appendix D.

Required Options

These options must be specified for a SERNET instance running ChangeMan ZMF.

Option Description
SUBSYS SUBSYS
CMN=port or ZMF=port or CMN or ZMF apl

Common Options

You may code these options for a SERNET instance running ChangeMan ZMF depending on the functions you use.

Option Description
DDNAME DDNAME
SDNOTIFY SDNOTIFY
TIMEOUT TIMEOUT
STAX STAX

Special Case Options

These options are used only in special situations.

Option Description
TCPIP TCPIP
XML XML
LIB LIB

...

SER#PARM DD Statement

Each SERNET started task can optionally create a reference table of application TCP/IP addresses and port numbers for the application. Alternatively the DD may be omitted from the started task JCL and manually edited. This will allow the use of VIPA rather than real IP addresses. This reference table is stored in a PDS member named #SERx, where x is the subsystem ID of the SERNET started task.

The information in a #SERx member is used to communicate with a ChangeMan ZMF instance using TCP/IP rather than cross memory services from the following:

  • ChangeMan ZMF ISPF client

  • ZMF programs in batch jobs

  • ZMF File tailoring started procedures

The library containing a #SERx member usually has a DSN low level node of TCPIPORT and is referenced by:

JCL CLIST
//SER#PARM DD DSN=... ALLOC DD (SER#PARM) DSN(...

This example shows the format of member #SER7 in a SER#PARM library:

********************************* Top of Data ***********************
****** This is member "#SER7" created 2018 19th apr 20:33:06 ******
* The purpose of this member is to track the relationship
* between this SerNet subsystem, applications, and associated
* TCP/IP address or DNS name & port number.
* The member is created/updated by SERVER/SERXMSIP as needed.
* It may be manually (careful) edited but this is not recommended.
* <== asterisk in column one denotes comment.
* SMF-ID (SMFI) uniquely identifies the LPAR. Multiple APPs possible.
* SMFI S APP TCPIPROC PORT# ADDR
  Q001 7 XCH          06122 Q001
  Q001 7 CMN          06121 Q001
******************************** Bottom of Data *********************

SERNET creates a #SERx member (if the SER#PARM DD is allocated) from the location of the started task (SMFID, DNS name) and from SERNET keyword parameters (SUBSYS=x, apl=port).

Note

Prior to ChangeMan ZMF 7.1.3, #SERx members were generated with dotted decimal IP addressees. Starting with ZMF 7.1.3, they are generated with DNS names of 16 characters or less. The maximum length of a DNS name will be extended in future ZMF versions.

The SER#PARM DD statement is no longer required in the JCL for the started task that runs ChangeMan ZMF.

If there is a TCP/IP address space on the LPAR where SERNET runs, SERNET will automatically create a #SERx member in the SER#PARM file (if it is allocated). If there is no TCP/IP address space on the same image, you must manually create a member in this file and manually code a dummy table entry. Instructions for manually creating this member are provided in Chapter 5, "Installing ChangeMan ZMF Components".

Caution

A library containing #SERx members can be shared by multiple SERNET started tasks as long as those started tasks have unique subsystem IDs. However, do not use a SER#PARM library for any other purpose, such as passing SERNET keyword parameters to a started task. SERNET opens this library for output, which can interfere with other uses of the file.

SERLIC DD Statement

The SER10TY License Manager gives you a choice of storing licenses for the mainframe products in CSA or in a PDS.

If you store licenses in a PDS, that library must be named in DD statement SERLIC included in:

  • Started procedures that run ChangeMan ZMF

  • CLISTs you use to connect to ChangeMan ZMF instances

See the SER10TY 4.3 User Guide for information about applying licenses.

SYSMDUMP DD Statement

The preferred means of gathering diagnostic information for a program interrupt in a SERNET started task is through a data set allocated to a SYSMDUMP DD statement. The data set should have these attributes:

//SYSMDUMP  DD DISP=(MOD,CATLG,CATLG),             * SYSMDUMP
//             DSN=somnode.SERCOMC.SYSMDUMP(+1),
//             UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE),
//             DCB=(DSORG=PS,RECFM=FBS,LRECL=4160,BLKSIZE=4160)

It is recommends that you define a GDG index for the SYSMDUMP data set to prevent diagnostic information in the data set from being overwritten when the SERNET instance is restarted after an abend.

SYSTCPD DD Statement

If you use TCP/IP to communicate with ChangeMan ZMF and there are multiple TCP/IP started tasks running on the same LPAR, you may need to code DD name SYSTCPD in the SERNET started task JCL. See topic “Considerations for Multiple Instances of TCP/IP” in the IBM publication z/OS Communications Server IP Configuration Guide.

SERALOG DD Statement

A new JCL member ACTLOG of the SERCOMC.CNTL distribution library is shipped with ZMF 8.2 Patch 2. Run this job to delete and define a Sernet Activity Log, which is new in ZMF 8.2 Patch 2. This Activity Log data set is then referenced in the following DD statement in the SERVER member of the SERCOMC.CNTL distribution library:

//SERALOG DD DISP=SHR,DSN=somnode.ACTLOG

Note

Each instance of the started task requires its own SERALOG DD statement; attempts to share a single data set between multiple started tasks will produce unpredictable results.

If the DD statement is missing, the started task will abend with code U4000.

This data set is required for all ChangeMan ZMF instances for release 8.2 Patch 2 and greater.

Started Procedures for File Tailoring

A SERNET started task running ChangeMan ZMF initiates started procedures to perform ISPF file tailoring to create JCL for the following functions:

  • Package installation

  • Stage

  • Promotion

  • Other batch activities

These procedures run like started tasks in their own address space. They are not regular batch jobs and they do not require an initiator. They run only as long as it takes to perform file tailoring for the ChangeMan ZMF function that started them, and then they terminate. Multiple copies of these procedures may be started, and multiple started tasks may execute at the same time.

The default name for these started procedures is CMNxADSP, where x is the subsystem ID of the of the SERNET started task where ChangeMan runs. However, up to four separate file tailoring started procedure names may be specified in ChangeMan ZMF administration, one for each of the four file tailoring functions listed above.

Instructions for creating and implementing the default file tailoring started procedure CMNxADSP are provided in subsequent topics and chapters in this manual. As your requirements become clear later in your implementation of ChangeMan ZMF, you can clone procedure CMNxADSP to create additional started procedures, repeating the installation steps executed for CMNxADSP, and then enter the name of the new procedures in ChangeMan ZMF administration.

Security Considerations

ChangeMan ZMF maintains the integrity of production components by managing production libraries and all libraries that contain components in any stage of development.

ChangeMan ZMF answers the questions, “What is production?” by including all development and test environments within the controls traditionally applied only to production execution libraries and source libraries. These controls include:

  • Physical access to development and production libraries.

  • Access to the automated change management functions that change development and production libraries.

Exclusive Access to Libraries

To exercise such broad control, ChangeMan ZMF must have:

  • Exclusive update access to baseline (production) libraries

  • Exclusive update access to libraries in controlled test (promotion) environments

  • Exclusive create, update, and scratch access to ChangeMan ZMF staging libraries that are dynamically allocated for each change package

  • Read access to all system libraries involved in the development process.

All of this data set access is granted to the SERNET started task where ChangeMan ZMF runs. ChangeMan ZMF performs on-line functions using this security access, and it submits batch jobs that inherit the security access of the started task, even when the jobs run with the user’s TSO ID as the job name.

Access to ChangeMan ZMF Functions

Once exclusive update access to production and development libraries has been granted to ChangeMan ZMF, the components in these libraries are protected by limiting access to the ChangeMan ZMF functions that can change these libraries.

These restrictions are defined in your security system.

  • You define a new resource class for ChangeMan ZMF.

  • You define security entities under that resource class that represent ChangeMan ZMF functions.

  • You define security entities that represent applications in ChangeMan ZMF.

  • You grant access for each security entity to individual TSO IDs or to groups.

When someone attempts to use a ChangeMan ZMF function, ChangeMan ZMF queries the security system with the name of the security entity for that function and the TSO ID of the user.

  • If your security system determines that the TSO ID has sufficient access to the security entity, ChangeMan ZMF permits the user to execute the function.

  • If the TSO ID does not have sufficient access, ChangeMan prohibits execution of the function.

Administrator and Change Manager Security Entities

Five security entities have fixed format names and control administrator and change manager functions. These security entities are always required for a ChangeMan ZMF implementation.

Note

Some ChangeMan ZMF selectable options require additional security entities. If you license a selectable option, see the Getting Started Guide for that option.

Security Entity ChangeMan ZMF Function
CMNGBADM or CMNxGBAD Configure/change global administration
CMNLCADM or CMNxLCAD Configure/change application administration
CMNREVRT or CMNxREVR Revert packages to DEV status after the approval process has started
CMNBKOUT or CMNxBKOU Back out packages in BAS or INS status
CMNMON or CMNxMON Monitor failed package installs or packages in the ChangeMan ZMF scheduler
CMNMONI or CMNxMONI Display, change, hold, or release jobs with the Monitor Installation Scheduler.
CMNMONP or CMNxMONP Suspend, push back, or push up a package's promotion date with the Monitor Promotion Scheduler function.

The x imbedded in the security entity name represents the one-character subsystem ID of the SERNET started task where ChangeMan runs. A security entity with an embedded subsystem ID controls authority only for the ChangeMan ZMF instance with that subsystem ID.

Note

If the CMNMONI/CMNxMONI or CMNMONP/CMNxMONP security entities are defined, users must have UPDATE rights to them to open the CMN Monitor Installation Scheduler or CMN Monitor Promotion Scheduler functions, respectively. If these profiles are not defined, all users have access to these functions.

Caution

If you are running Security Server software that issues a RACROUTE RC=8 for a profile not found condition (e.g. CA-ACF2, CA-TSS), and RACF environments that have overridden the default return code for a 'profile not found' condition from 4 to 8, you must define the subsystem profile names for all subsystems. If you do not, the response will be incorrectly interpreted as users being denied access to the function and they will not be allowed to access it.

Default Security Entities

Normally, ChangeMan ZMF searches for the subsystem-specific entity with the embedded subsystem ID, and if that entity is not found, the search looks for the entity without the subsystem ID.

For example, the search for the global administrator entity for ChangeMan ZMF running under subsystem ID 3 is:

  1. CMN3GBAD, and if not found, then...

  2. CMNGBADM

Implicitly, the security entities without the embedded subsystem ID become the default set that are used when you have not defined subsystem-specific entities.

Caution

If you use a null (blank) subsystem ID, the security entities for that ChangeMan ZMF instance become the default entities for all other instances. That is one reason why it is strongly recommended that you avoid using a null subsystem ID.

Mandatory System-Specific Security Entities

If your security administrator uses one of the following parameters in your security system, and the ChangeMan ZMF subsystem-specific security entity is not found, there is no search for the default entity, and authorization is denied.

Security System Parameter
RACF PROTECTALL
CA ACF2 MODE(ABORT)
CA Top Secret MODE(FAIL)

If one of these parameters is used, you must create a set of system-specific security entities with embedded subsystem ID for each ChangeMan ZMF instance.

Security Entities and Required Authority

This table lists the security entities that control execution of ChangeMan ZMF functions, and it shows the level of security access that is required to execute each function.

Note

Some ChangeMan ZMF selectable options require additional security entities. If you license a selectable option, see the Getting Started Guide for that option.

The first five rows in the table describe five security entities with fixed format names. To grant authority to execute other functions, you define your own security entity name in your security system, and then associate that entity name with a ChangeMan ZMF function by making an entry in ChangeMan ZMF administration.

ChangeMan ZMF Function Primary Authorization Additional Authorization
Configure/change global administration UPDATE access to entity CMNGBADM or CMNxGBAD None
Browse global administration READ access to entity CMNGBADM or CMNxGBAD None
Configure/change application administration UPDATE access to entity CMNLCADM or CMNxLCAD READ access to the application entity you define
Browse application administration READ access to entity CMNLCADM or CMNxLCAD READ access to the application entity you browse
Revert packages to DEV status after the approval process has started UPDATE access to entity CMNREVRT or CMNxREVR READ access to the application entity you define
Back out packages in BAS or INS status UPDATE access to entity CMNBKOUT or CMNxBKOU READ access to the application entity you define
Monitor failed package installs or packages in the Change Man ZMF scheduler UPDATE access to entity CMNMON or CMNxMON READ access to the application entity you define
Query packages, browse components in baseline and promotion READ access to the application entity you define None
Create packages, work with package components UPDATE access to the application entity you define None
Promote/demote packages to a site/level UPDATE access to the promotion entity you define for the site/level READ access to the application entity you define
Approve/reject packages UPDATE access to an approval entity you define READ access to the application entity you define
Selectively unfreeze/ refreeze components in frozen package UPDATE access to the next approval entity UPDATE access to the application entity you define
Monitor Installation Scheduler UPDATE access to entity CMNMONI or CMNxMONI None
Monitor Promotion Scheduler UPDATE access to entity CMNMONP None

When you define a ChangeMan ZMF security entity in your security system, you define it with no universal access. When you grant a TSO ID or group access to the security entity, you give them READ or UPDATE authority.

Functional entities

ZMF performs a security entity check for the following functions that are accessed through the ISPF interface and XML services:

Function Subsystem Profile Name Generic Profile Name
Create CMNxCREA CMNCREAT
Checkout CMNxCKOU CMNCKOUT
Stage CMNxSTGE CMNSTGER
Scratch CMNx$UTI CMN$UTIL
Rename CMNx$UTI CMN$UTIL
Recompile CMNxRCOM CMNRCOMP
Rebind CMNxRBIN CMNRBIND
Freeze CMNxFREZ CMNFREZE
Promote CMNxPROM CMNPROMO
Approve CMNxAPPR CMNAPPRV
where x = ZMF subsystem ID
The security entity is the name of the ISPF
function program (for example, Create = CMNCREAT).

If the security entity is defined, the user must have Update access to the security entity to access the function.

If the security entity is defined and the user does not have update access, the function returns an error message indicating that the user ID is not authorized to perform the function.

When checking for the existence of these profiles, ZMF checks for access in the following order:

  1. ZMF checks for the existence of the subsystem profile and, if defined, the user's access to it.

  2. If the subsystem profile is not found, ZMF checks for the existence of the generic profile. If this profile exists, ZMF checks the user's access level and allows or denies access to the function based on the response.

  3. If neither the subsystem nor generic profiles exist, users are granted access to the function.

Caution

  • If you are running Security Server software that issues a RACROUTE RC=8 for a profile not found condition (e.g. CA-ACF2, CA-TSS), and RACF environments that have overridden the default return code for a 'profile not found' condition from 4 to 8, you must define the subsystem profile names for all subsystems. If you do not, the response will be incorrectly interpreted as users being denied access to the functions and they will not be allowed to access them.

  • Similarly, when running any Security Server product, you should also take care when generic profiles exist in the ZMF Security Class (as defined in global admin option A.G.1 - ChangeMan ZMF security resource). For example, if a generic profile named CMN* is defined with a universal access level of NONE within this class, only users who are explicitly granted UPDATE access to this profile are allowed to access any of the functions listed above.

SAF and Your Security System

You define security rules and authorizations for ChangeMan ZMF users in your security system. ChangeMan ZMF is compatible with IBM Security Server RACF, CA ACF2, and CA Top Secret.

SAF is an acronym for System Authorization Facility, an interface defined by z/OS that enables programs to use system authorization services to protect access to resources such as data sets and system commands. SAF provides a common interface for IBM Security Server RACF, CA ACF2, and CA Top Secret where you define the security rules for an LPAR.

Security for File Tailoring Started Procedures

Special security definitions are required for file tailoring started procedure CMNxADSP and any clones you may create and specify in ChangeMan ZMF administration.

These definitions are detailed in Chapter 6, "Configuring Security".

Access to TCP/IP Functions

Access to TCP/IP Services in z/OS Communications Server requires a z/OS UNIX security context, referred to as an OMVS segment, for the user ID associated with a SERNET instance.

See the section “Requirement for an OMVS Segment” in the IBM publication z/OS Communications Server: IP Configuration Guide.

Additionally, RACF PassTickets are a requirement for mainframe clients (not ChangeMan ZDD or ChangeMan ZMF for Eclipse) connecting via TCP/IP. Instructions for generating RACF PassTickets are detailed in Chapter 6, “Configuring Security”.

Data Set Considerations

ChangeMan ZMF uses several data set types that impose unique requirements on your DASD management tools and/or your data set security rules.

Temporary List Data Sets

ChangeMan ZMF stage jobs write SYSOUT data sets to z/OS temporary files named &&LIST*. At the end of the job, utility program SERPRINT reads these temporary files, combines them into a single file, writes the file in compressed format to a package staging library member, and then writes this same information to SYSOUT at DD name PRINT2 in eye-readable format.

Program SERPRINT cannot find &&LIST* files that are written to virtual I/O (VIO) files because these files exist only in paging storage.

In ChangeMan ZMF administration, you can specify an esoteric device group or generic device type that applies only to &&LIST* data sets. Consult with your storage administrator or system programmer to identify an esoteric device group or generic type that is ineligible for VIO and would be appropriate for &&LIST* data sets.

Utility Data Sets

ChangeMan ZMF uses “temporary” cataloged utility data sets when performing functions such as:

  • Expanding compressed listings for the Browse Listing function

  • ISPF file tailoring to create job JCL from ChangeMan ZMF skeletons

  • Opening package components for edit (You edit the component in a utility data set rather than in the staging library member.)

ChangeMan ZMF utility data sets are created by:

  • SERNET started tasks running ChangeMan ZMF

  • File tailoring started procedures initiated by ChangeMan ZMF

  • ChangeMan ZMF users (automatically) as they connect to ChangeMan ZMF through the ISPF interface

ChangeMan ZMF deletes the utility data set when the function is completed.

The same data set name format is used for all ChangeMan ZMF utility data sets. The DSN format for ChangeMan ZMF utility data sets is defined in exit program CMNEXINS. Comments in the source code for CMNEXINS describe the default DSN format.

Utility Data Set Security

When you first install ChangeMan ZMF, you must:

  • Choose a data set naming convention for ChangeMan ZMF utility data sets.

  • Code that DSN format in exit program CMNEXINS.

  • Define rules in your security system that grant ALTER/CREATE access to:

    • SERNET started tasks running ChangeMan ZMF

    • File tailoring started procedures initiated by ChangeMan ZMF

    • Users who access ChangeMan ZMF though the ISPF interface

  • Define a zFS folder in global administration parameters part 7, where temporary zFS files are created. The SERNET started tasks running ChangeMan ZMF, File Tailoring started procedures initiated by ChangeMan ZMF, and users who access ChangeMan ZMF must have rights to create files in this folder.

In some data centers, there is an existing high-level qualifier like TEST that has universal ALTER/CREATE security access.

If you do not have such a high-level qualifier already defined, work with your DASD manager and security administrator to set up a high-level qualifier that ChangeMan ZMF can use for utility data sets.

Tip

Comments in the source for exit program CMNEXINS describe several examples that can help you choose a high-level qualifier.

DASD Management for Utility Data Sets

ChangeMan ZMF deletes utility data sets when users exit the function that created the data set. When a ChangeMan ZMF function or session does not end normally, utility data sets are not deleted. For example, if your TSO session times out when you are editing a package component, the utility data set allocated for your edit session is not deleted.

You can create an ACS routine for DFHSMS to delete old utility data sets based on the naming convention code in exit program CMNEXINS. However, you should not let DFHSMS delete utility data sets while they can still be used to recover edit changes from an interrupted edit-in-stage session.

For example, if your TSO session times out while you are editing a ChangeMan ZMF package component on a Friday afternoon, you can recover your edit changes after the weekend if the utility data set you were editing is still cataloged. (See topics “Automatic Edit Recovery” and “Manual Edit Recovery” in the ChangeMan ZMF User’s Guide.)

Staging Library Model Data Set Name

Your global administrator defines a Staging Library Model Data Set Name in Global Administration Parameters. This model is used to create data set names when ChangeMan ZMF allocates these data sets for a change package:

  • Package staging libraries

  • Dot X libraries for package installation job JCL

  • PACKAGE data set for package installation processing at ZMF production instances

  • Dot B data set for package blackout processing in a ZMF DP/P environment

  • Dot R data set for package revert processing in a ZMF DP/P environment

The Staging Library Model Data Set Name must include:

  • A three- or four-character node for application mnemonic

  • A seven-character node for the package number preceded by #

  • A node to distinguish development staging libraries from production staging libraries that are used to install a package at a remote site

The longest library name that is constructed using the minimal staging library model data set name is:

...aaaa.\#nnnnnn.e.X.ssssssss

where:

  • aaaa is the 3-4 character application mnemonic

  • nnnnnn is the six digit package number

  • e indicates whether the data set is a development or production staging library

  • X is a literal that denotes a library containing package installation JCL

  • ssssssss is a 1-8 byte site name

ChangeMan ZMF allocates these data sets under the authority of the user ID for the SERNET started task that runs ChangeMan ZMF. ChangeMan ZMF automatically reallocates these data sets if they run out of extents or directory space, and the data sets are deleted by a housekeeping job submitted by the started task.

You can add a high level qualifier and other nodes to the Staging Library Model Data Set Name as long as the longest name does not exceed the 44 character maximum. Define a Staging Model Data Set Name that allows you to satisfy these security access requirements and DASD management requirements:

  • The SERNET started task must have exclusive ALTER/CREATE, UPDATE, and DELETE access to data sets created with the Staging Model Data Set Name.

  • DFHSM can migrate these data sets to a secondary storage format or media. SERNET will issue an HRECALL command when it needs a data set that has been migrated, or it will issue an HDELETE if it wants to delete a migrated data set.

  • Data sets created with the Staging Model Data Set Name should not be compressed unless the development and production instances of ChangeMan ZMF are down and no ChangeMan ZMF installation or promotion jobs are running.

Batch Job Name Considerations

ChangeMan ZMF submits batch jobs to perform functions like component stage (build), package promote, and package install. These jobs may manipulate components in libraries under ChangeMan ZMF control and update ChangeMan ZMF master files.

For these batch jobs submitted by ChangeMan ZMF:

  • The job owner is the user ID of the SERNET started task where ChangeMan ZMF runs.

  • The job runs with the security authority of the started task user ID.

Job names and other JOB statement information depend on whose behalf the job is run.

User Job Names

ChangeMan ZMF submits batch jobs on behalf of ChangeMan ZMF users who work with packages and components.

For example, when a user stages a like-source component, ChangeMan ZMF builds stage job JCL from ISPF skeletons and submits a job to compile and link edit the component, update the component status and component history, and put newly generated components into package staging libraries.

The user enters JOB Statement Information, including a job name, on an ISPF panel in the online process that initiates batch processing.

You can validate or change the JOB statement information entered by users for jobs submitted by ChangeMan ZMF on their behalf by customizing exit program CMNEX008.

Install Job Names

ChangeMan ZMF submits a series of batch jobs to install and baseline ripple a package. Even if you use an external job scheduler like CA 7® Workload Automation or CA Scheduler® Job Management to submit the first install job for a change package, ChangeMan ZMF submits all following install jobs for the package.

ChangeMan ZMF builds JCL for install jobs from ISPF skeletons. JOB statement information for these jobs, except for job name, is taken from an ISPF panel in Application Administration. The job name is constructed as follows:

For an application with a four-character application mnemonic, the install job name is:

//aaaattnn

where:

  • aaaa = application name

  • tt = transaction code

  • nn = last 2 characters of package number

For an application with a three-character application mnemonic, the install job name is:

//aaattnnn

where:

  • aaa = application name

  • tt = transaction code

  • nnn = last 3 characters of package number

You can validate or change the job name for install jobs submitted by ChangeMan ZMF by customizing exit program CMNEX008.

Viewing Job SYSOUT

ChangeMan ZMF users will want to view the sysout from jobs submitted on their behalf by ChangeMan ZMF, and they need authority to purge such job output. Developers, project managers, change control staff, and operations staff may need to view sysout from ChangeMan ZMF install jobs.

You may have to make adjustments to the following to provide the necessary access to sysout from jobs submitted by ChangeMan ZMF:

  • Job access rules in your sysout management tool

  • Job access rules in your security system

  • JES rules for access to job output

  • Job name overrides in ChangeMan ZMF exit program CMNEX008

Staging Versions

The staging versions facility can save an unlimited number of versions of a package component that a developer might create in a staging library between the time the component is first added to the package and the time the package is baselined.

Staging versions are stored as full copies in a compressed format in a VSAM file. Each version may be labeled with an optional 35-character description.

Some features of staging versions are available if the staging versions facility is installed by defining three VSAM files and by including the HPSPLIB and HPSIN DD statements in the SERNET started procedure.

All features of staging versions are available for package components in a library type if the staging version facility is installed, and if the application administrator enables staging versions for the library type.

All staging versions processing is bypassed if the HPSPLIB and HPSIN DD statements are deleted from the SERNET started procedure.

Issues to consider when deciding whether to install the staging versions facility:

  • If the staging versions facility is installed, ChangeMan ZMF reads one of the staging version VSAM files whenever a user performs a function that replaces a member in a staging library. This VSAM read might have an adverse effect on ChangeMan ZMF response time.

  • If the staging versions facility is installed and enabled for a library type, ChangeMan ZMF writes to the staging version VSAM files whenever a user saves a staging version. This VSAM write might have an adverse effect on ChangeMan ZMF response time.

For a full description of the Staging Versions facility, see topic “Staging Versions” in Chapter 3 "Pre-Implementation Decisions" in the ChangeMan ZMF Administrator Guide.

Customizing ChangeMan ZMF Components

ChangeMan ZMF is designed to be flexible so that it can serve customers with different change management processes and different data center standards. Within the constraints of best practices for change management, you can adapt ChangeMan ZMF to your environment using:

  • Configuration in Global and Application Administration

  • Modifications to ISPF skeletons that are file tailored into JCL for batch processes

  • Code in exit programs that are provided with Changeman ZMF

Even if you do not need to customize ChangeMan ZMF components to fit your change management practices, you must modify some components to fit your local data set naming conventions.

When you modify ChangeMan ZMF components, preserve the original components that were delivered. Never edit components in the libraries you unloaded from the ZMF installer, and never link edit load modules into the delivered libraries.

Allocate a separate set of custom libraries for ChangeMan ZMF components that you change. Copy the component you want to modify from the delivered library into your custom library, then make you changes in the custom library.

"Step 1: Allocate CUSTOM Libraries" contains a sample list of delivered and custom libraries.

When you modify a delivered component, keep the name of the custom component the same as the delivered component so that you can use a file compare tool or code merge tool to help you reapply your modifications for a ChangeMan ZMF upgrade.

When you create an new custom component for ChangeMan ZMF, use an abbreviation or acronym for your company or organization in the first three characters of the component name to differentiate your component from components delivered with ChangeMan ZMF.

Console Log Messages

SERNET and ChangeMan ZMF write certain messages to the console log (WTO) to make them available to your automated operations tools. You can configure your automated operations tools to recognize the messages and issue notifications or execute remedial tasks.