Thisdocumentdescribes the use of multiple copies of Com-plete at an installation.
This document covers the following topics:
More than one copy of Com-plete can run on the same system at one time. Running multiple copies of Com-plete simultaneously allows:
Separation of data and functions by department or agency;
Isolation within large application systems;
Isolation of Com-plete batch support;
Greater data integrity and privacy;
Easy conversion from one release or version of Com-plete to another.
Each copy of Com-plete must have its own SD dataset and spool dataset, thus enabling each copy of Com-plete to function independently. For example, a test version of Com-plete with a new feature or fix can be started without affecting production work on other Com-plete systems, or an entirely new release or version of Com-plete can run concurrently with an older production release, greatly facilitating the conversion.
Because nearly all the modules can be shared among multiple copies of Com-plete, a full installation of Com-plete is not necessary for each copy. Only those files and modules containing information unique to each Com-plete system must be duplicated.
The Com-plete system files such as the SD dataset contain information that is unique to each copy of Com-plete, and, therefore, cannot be shared. One set of the following Com-plete files must be allocated, initialized, and loaded for each Com-plete system.
| File | Description |
|---|---|
| COMPLETE.SPOOL | Disk-resident queue for messages and printout spooling data. |
| COMPLETE.SD | Online text editing and SD storage data set. |
For more information on initializing and loading these files, see the Com-plete Installation documentation and the sections dealing with the TUMSUTIL, and TUSDUTIL utilities in this documentation.
The Com-plete load libraries can be shared among all Com-plete systems. When compressing these data sets, however, it is necessary to stop all Com-plete systems that use the load libraries. All other Com-plete files can be shared by multiple Com-plete systems.
For information on sharing the system data containers COMSYSn, see The System Data Infrastructure.
The following sysparms require special attention when running multiple copies of Com-plete:
- ACCESS-ID
This parameter must be unique amongst all users of the same Adabas router SVC number within the same machine, and if NET-WORK is active in the machine and ACCESS-LOCAL is not set to YES, then it must be unique within the network itself.
- INSTALLATION
This parameter must be unique on the system, so that it can tell users which Com-plete they are using. However, no check is made that this is in fact unique within the machine.
- PATCHAR
This parameter must be unique, as it identifies the Com-plete uniquely within the machine. If more than one Com-plete is started with the same patch character, the second is terminated with a message to the effect that the patch character is already in use.
- SMFRECORDS
It is no longer necessary to have a seperate SMF record number for each different record type, as the records are now identified within the prefix as to what they were written for, for example, LOGON, LOGOFF and which Com-plete they have come from. Refer to Com-plete Accounting Facility for more information.
- VTAMAPPL
This parameter must be unique because VTAM fails any attempt for a second OPEN to the same ACB name.
- VTAMSIMLQ and VTAMSIMLREL
To maintain a flexible system, these sysparms must both be set to YES to ensure that any particular Com-plete for which printers are specified releases them on request from another VTAM application (for example, another Com-plete).
Parallel Sysplex technology provides a number of advantages, the most important of which are high system availability and workload balancing. This version of Com-plete can be installed as a cluster of two or more instances running on different systems in a Parallel Sysplex and known to VTAM as a generic resource . Users log on to the generic resource name, and the sessions are distributed by VTAM equally among the Com-pletes sharing this generic resource name.
From the installation point of view, in contrast to a single-system installation, the following requirements must be met for a Parallel Sysplex installation:
VSAM Record Level Sharing (RLS) must be used for the Com-plete system datasets and SD files so they can be shared between multiple Com-plete instances.
A VTAM Generic Resource name must be defined and specified by means of the VTAMGENERIC sysparm for all peer Com-pletes in the cluster. Users log on to this generic name instead of the unique VTAM APPL-ID of a single Com-plete. See section VTAM in Software Interfaces for more details.
The following datasets must be shared between all peer instances of Com-plete:
all load libraries in the STEPLIB and COMPLIB chains,
the SYSMAP map library (if any is used),
the two System Data Containers (COMSYSn),
dynamic SD files. See Com-plete Files and Associated User Files for details and the Com-plete Installation documentation for conversion issues.
Of the following datasets, a unique copy is required for each of the instances of Com-plete:
the spool dataset (COMSPL),
the COMSD dataset, but it must be used for online dumps only (see Com-plete Files and Associated User Files for details about dynamic SD files),
the CAPTURn datasets (if any are used).
When sharing the COMSYS data containers, Com-plete must access them using VSAM RLS (record level sharing). In order for this to work, LOG(NONE) must be specified for each of the COMSYS VSAM clusters. Depending on the rules in effect on your system, other parameters like STORAGECLASS may also require different values.
In your Com-plete JCL procedure, add the parameter RLS=NRI to each of the four COMSYSn DD statements.
Though some of the required datasets cannot be shared, a single JCL procedure can still be used for all Com-plete instances in a cluster. These datasets should be named in a way so that, e.g., the &SYSTEM or &SYSCLONE system variables can be used to refer to different datasets on different systems in the sysplex.
Example:
If the value of &SYSCLONE is 'SA' on system A and 'SB' on SYSTEM B in the sysplex, and your spool datasets are named COM.SA.SPOOL and COM.SB.SPOOL, then the COMSPL DD statement in your Com-plete startup procedure could look like this:
COMSPL DD DISP=SHR,DSN=COM.&SYSCLONE..SPOOL
The advantages of using a single JCL procedure are maximum consistency and minimum maintenance effort.
With a few exceptions (see below), all sysparms will have the same values for all Com-plete instances in the cluster. Therefore, to keep maintenance effort low, it is a good idea to define the common sysparms in a shared sysparm member and only the system-dependent sysparms in separate members for each instance. All these sysparm members can reside in one shared PDS. In the shared JCL procedure, this could look like in the following example:
SYSPARM DD DISP=SHR,DSN=COM.CONTROL(PARM_ALL)
DD DISP=SHR,DSN=COM.CONTROL(PARM_&SYSCLONE)
Members in COM.CONTROL: PARM_ALL:
PARM_SA
PARM_SB
INSTALLATION (not necessarily)
PATCHAR (not necessarily)
VTAMAPPL (required by VTAM to be different)