Before reading this section, you should be familiar with the concept of COPE Libsets. Refer to the “Understanding Libset Concepts” section in the BMC-COPE-Administration-Guide.

Most of the tasks have an ISPF based application that implement them. To give an idea of the magnitude of each of the tasks, they are detailed in following Task to generate a COPE System with an estimate (for comparison purposes only) of the time it takes to perform them.

Task 5.1 Define Stage 1 Processing Technique

In DB/TM and DCCTL systems, if a COPE system uses identical definitions of DATABASE, APPLCTN and TRANSACT Stage 1 macros in different Lsys’s, set the XCMNSTG1 ZDEFAULT variable to YES.

This setting allows COPE to store only 1 copy of the Stage 1 definition, and uses enhanced processing techniques to generate COPE Stage 1 definitions and SS information. The definition must be set before any Stage 1 source is imported.

Task 5.2 Define Libset Configuration (Option 1.1)

Prerequisites:

Before commencing the Libset definition process, the XDSNFORM ZDEFAULT/ZDEFCICS parameter should be defined to define the high-level qualifiers for all of the datasets in each LIBSET.

Each logical IMS system (or Lsys) is associated with a Libset definition. Libsets can be concatenated with one or more other Libsets. Thus programs, PSBs, DBDs, or MFS members stored in a Libset can be shared between several Lsys's if the Libsets that the Lsys's are associated with, do not contain duplicate members.

Select option 1.1 Define Logical Systems from the COPE ISPF Main Menu to access the Libset definition facilities.

Careful analysis of Libset requirements should be performed before any Libset definition is attempted. Changing Libset relationships or adding or deleting Libsets requires a re-population of Libsets that have sibling relationships changed or which have been added, and a complete regeneration of all DBDs, PSBs and MFS members. 

The following Logical System Definition panel shows several interrelated Logical Systems being defined:

Logical System Definition Panel 

The display indicates that Logical Systems DBT2, DBT3, and DBT4 are junior siblings to DBT1. DBT4 has no siblings.

Application load libraries may be defined for each Logical System by entering an L as a row command. This is not a requirement during initial definition since Option 1.5 can allow definition at any time.

On exit from the definition panel, the administrator will have to define one of the Logical Systems as the Master Logical System. This is the system that contains all the Stage 1 macro definitions. This Master Logical system is the same one that will contain the network definition. The remaining Logical Systems save only the APPLCTN, DATABASE and TRANSACT definitions for that system.

When the Master Logical System has been defined, panels will be displayed that allow entry of Volume Serial Names for datasets that make up the LIBSET for the Logical System. The names of the datasets are controlled by the XDSNFORM definition in the ZDEFAULT (EVARS) environment PROCS definition. XDSNFORM allows definition of the high order part of the dataset name. The last qualifier is standard and set to names such as PSBSRCLB or DBDSRCLB.

Task 5.3 Generate Batch JCL Procedure (Option 1.2)

Select option 1.2 Generate Batch JCL Procedure to generate a procedure with the same name as the COPE Physical System to the dataset specified on the JCLLIB statement in the job card.

Task 5.4 Define Batch JOB Card (Option 1.3)

Select Option 1.3 Define Batch JOB Card. This will bring you into ISPF Edit for member DEFLTJOB in the xcope1.CTLCD distribution library to produce a valid job statement. One of the JCL statements must be a JCLLIB statement referencing the installation base JCL dataset. This must contain 4 JCL statements, for example:

The current TSO user ID will be substituted wherever you put an ampersand (&) in this member (usually in the job name and on the NOTIFY= parameter). The external interface will use this job statement when it submits other jobs to import and generate DBDs, PSBs and MFS members.

Task 5.5 Define Message Region Lsys Steplibs (Option 1.5 - DB/TM and DCCTL only)

Selecting Option 1.5 displays the following:

Message Region Dataset definition 

Every Logical System may have multiple 'STEPLIB' definitions defined for it. These are dynamically allocated whenever a transaction is executed in a message region.

If the DD name is TASKLIB the datasets may be thought of as Message Region STEPLIB datasets. If the DD name is not TASKLIB, COPE assigns the dataset to a file of that name whenever it is opened in the Message Region. This facility can be useful for supporting architectures that use data files in message regions and access them from online transactions.

Besides STEPLIB load library concatenations, you might have other library concatenations, VSAM files, or sequential files which you want to vary across Lsys's. You specify these in the same MDS table.

Insert, delete or change the TASKLIB DD rows, for Steplib concatenations. Note that the "concatenation number" specifies the order of the DSNs in each concatenation. "TASKLIB" refers to the internal mechanism used by COPE to make the libraries behave exactly like a Steplib. You should put libraries that are common to all Lsys's in the message region JCL on the COPESTEP DD, not in the MDS table.

Insert, delete or change other DDname rows, for non-Steplib datasets.

Press <PF3>, and you will see the following menu as shown in the following figure.

Dependent STEPLIB on Class and PCB

If you press PF3 you will be put into EDIT on generated JCL which you should submit (SUB) to recreate the COPEXRF4 load module with the TASKLIB definitions in them. Check the submitted job runs correctly with ondition code of  0 or 4

When you press ENTER you will see the following screen.

STEPLIB Selection Criteria Menu

This facility allows a different TASKLIB to be specified for message regions that have a specific scheduling class (for a MPP region) or PSB name (For an IFP region). These Tasklibs are different from the 'default' Tasklibs specified in the previous dialog.

• Option 1 specifies either the job class or the IFP region PSB name to scan for if Tasklib specifications different from the default are required.
• Option 2 specifies the Tasklib datasets for each selection.

If you select Option 1, the following panel is displayed as shown below

STEPLIB Class Set Definition

This allows specification of selections. Each selection has a name or ID shown in the second column

In the example Selection 01 is applied to message regions that have scheduling classes 77. Selection 03 applies to an IFP region that has PSB DFSIVP4 specified in the JCL MPP regions may have up to 4 classes specified. Only one of them need be specified in the selection.

If you want to SAVE the specifications before they are completed enter SAVE in the command field. If you want to leave the specification so that you can return at a later time, enter CAN to CANCEL the specification process. Use of the CAN command will lose all specifications entered after the previous SAVE command.

Press PF3 and selection Option 2 on the selection panel will display the following figure

STEPLIB Set Dataset Definition

For every selection id specified in the previous dialog you have to specify Tasklibs FOR EVERY LOGICAL SYSTEM. If there are more than one dataset, a concatenation number must be specified in the rightmost column.

Pressing PF3 twice will put you into edit on generated JCL that contains the specifications for all Tasklib members. The JCL should be (SUB)mitted and the return codes checked.

Go to IMS, clear the screen, and type COPE REFRESH. This causes all message regions to refresh their MDS allocations on
the next transaction through each region.

Task 5.6 Define Lsys Identifying Tokens (Relink-edit IMS Modules) (Option 1.6)

Whenever an IMS based batch JOB is executed, the Logical System it is to be executed in must be identified. This identification is achieved in one of three ways (shown in the order of preference):

1. Put Lsys identifying token in the second positional JOB card parameter.
2. Put an Lsys identifying token in place of the IMSID in the PARM field of the DFSRRC00 program.

3. Add a COPEBSYS DD statement where the Lsys Identifying token is a temporary dataset name. For example:

   //COPEBSYS DD UNIT=SYSDA,SPACE=(TRK,1),DSN=&&Lsys-token

The tokens that identify a Logical System are defined with Option 1.6. This ISPF based application puts the Lsys identifying tokens into a load module named COPEPSYS and link-edits it into the IMS RESLIB. It also transfers some COPE modules into the IMS RESLIB and relink-edits DFSRRC00 and other utility modules into various datasets.

Before 1.6 option is executed, the COPETOOL PROCS member must be reviewed and updated to specify what utility modules are present in an installation. Enter EVARS;EDIT COPETOOL on the COPE primary ISPF menu to access the COPETOOL PROCS member. An example of the result is shown in the following figure:

COPETOOL Content 

The load module datasets present for various utilities in an installation are identified and an alternate dataset is specified for each. The COPE Option 1.6 application generates Link-edit statements that relink-edit the utility load modules and puts them in the alternate datasets. The alternate datasets are specified in the JCL whenever the utility is executed in a COPE environment.

1. Select COPE ISPF Option 1.6 to display the Generate Lsys Token Control Module menu.
2. Enter G in the command field.
3. Read the message in the PROCESSING MESSAGE DISPLAY.
4. Press Enter to continue to display in the following panel:

Specify COPE Systems 

If an IMS RESLIB is shared between multiple COPE systems, the ZDEFAULT/ZDEFCICS (EVARS) dataset and member name of all the systems must be specified. The dataset name and member name can be found on the primary COPE ISPF panel.

1. Press the END key (PF3).
2. Read the message in the PROCESSING MESSAGE DISPLAY.
3. Press Enter to continue to display in the following panel:

Lsys Identifying Token Specification 

Different tokens may be specified for the JOB Card and the PARM field IMSID. Generally identical tokens are specified. The IMSID token may be 8 characters even though the field is limited to 4 characters in normal usage.

When definition is completed, enter END (PF3). Check the resulting generated job, submitted after the SYSLMOD statements of the generated job, to ensure the target datasets are correct.

Task 5.7 Define Excluded Databases/Applications and Transactions (Option 1.7)

System orientated transactions and databases may be excluded from COPE. COPE does not change the names of the DBDs or PSBs that they reference.

Option 1.7 allows definition of the Stage 1 statements that define the excluded objects.

The following panel shows a typical edit session for a system. Many of the items are defined automatically by COPE for its own usage.

Define Excluded Databases and Applications

PSBs or DBDs that are defined as being excluded may be imported into the COPE Master Logical System. (The name of the Master Logical system is displayed on the initial COPE ISPF panel.)

This option should be used for AOI programs, or other programs, that perform functions also be excluded (automatically) from COPE control.

To exclude system PSBs:

1. Select option XPSB on the B;4.2 command line and press Enter. The dataset name and IMS system fields at the bottom of the screen are not relevant for the XPSB option. A list of all PSBs from all Stage 1's that were parsed will be presented.
2. Place S characters next to the PSBs in the list that are to be excluded. Use the FIND command (F xxx) to position in the list, if the list is very long. Use find with PREV (F xxx PREV) to position backwards.
3. If this is the second or successive time that you have entered the XPSB function, some of the PSBs displayed may have an S next to them indicating that they have been excluded before. If a previously excluded PSB is to be included, blank out the S.
4. Press END (PF3) to save the excluded list.

Task 5.8 Define the Common Stage 1 and Dynamic Allocation Specification (Option 1.8)

A decision must be made as to whether some or all Logical Systems have identical Stage 1 definitions. If the XCMNSTG1 COPE variable parameter is set to YES (N/A for DBCTL) all Logical Systems share the same Stage 1 definition. If it is not set to YES, access COPE ISPF Option 1.8 to define the set of Logical Systems that are common. In a DBCTL environment, you must use COPE ISPF Option 1.8 to define Common Stage 1.

Task 5.9 Grant PACKADM on Collection (DCCTL, DCCTL (YED), and optional for DB/TM

1. Copy Member IMDB2COL from the xcope1.JCL library to the xcope2.JCL library.
2. Modify member IMDB2COL according to the comments in the job as appropriate in the xcope2.JCL library.
3. Submit modified member IMDB2COL. Expected return code is 0.

Task 5.10 Specify Packages for All Logical Systems (DCCTL only)

Using Option 4.PACK (Specify Packages for all Logical Systems), specify the set of collections required to execute applications in any Logical System. This process requires a clear understanding of how COPE and the Db2 database system and applications interact and will be described in detail here.

Overview of IMS and Db2 Systems Distributed Data

The database managers in a distributed relational database communicate and cooperate with each other in a way that allows a Db2 application program to use SQL to access data at any of the interconnected computer systems.

IMS Transaction Manager (IMS TM) can access multiple Db2 local subsystems. Each local subsystem may have 1 or more remote subsystems connected to it.

COPE manages the connection between application programs executing in a Logical System and allows retrieval of data from any of the interconnected local and remote Db2 systems. No modifications of the application program need be made and no linkedit of interface modules containing the Db2 literal that allows connection to a local subsystem is required.

The package specification dialogue extracts plans from existing RTT members and Stage 1 source specifications that relate to a COPE Logical System and generates a load module containing information that allows COPE to connect an application with the set of data that it requires based on the Logical System the application is executing in.

COPE is constructed to first scan for a PSB in a Logical System and, if found, define a CURRENT PACKLIST command using specific information associated with the PSB, or, if not found, a default set of packages is used in the SET CURRENT PACKLIST command.

Convert Existing Definitions to Reside in a Logical COPE System

Option 4.PACK displays the following panel:

Option 4.PACK 

Option 1 allows collection of information relating to a Logical System (see Option 1 Define Conversion Information).

Option 2 generates the information into a form that is accessible by a COPE system using foreground execution (see Define and Load Database and Transaction Definitions (DB/TM and DCCTL only)).

Option 2B generates the information into a form that is accessible by a COPE system using background execution. The background job submits another job for compiling the required load module (see Option 2B, Background Generate COPE Package Path Table).

Option 3 resets all collected information and should not be used unless all previously collected package information is required to be destroyed.

Option J allows specification of a JOB card.

Option 1 Define Conversion Information

The following panel is displayed when Option 1 is selected.

Define Conversion Information 

There are 4 types of information that must be specified. The information for Options 1-3 is mandatory. The information for Option 4 (PSB collections) is optional.

Some default data is supplied the first time the option is selected. This data must be edited to match the Installation’s requirements.

Define BIND PLAN Parms (Option 1)

COPE constructs a Master Plan called COPEDLIT. This plan contains all the packages for all the Logical Systems. Parameters for binding the plan are contained in this section and may be modified.

Define BIND PLAN Parms 

Each plan Option field is 255 bytes in length. Editing of any field is possible by specifying UW (Unformatted Window) or FW (Formatted Window) in the row command field and positioning the cursor on the field that is to be edited.

Define Logical Systems (Option 2)

The sub dialogue is initialized with default data as shown in the following panel:

Define Logical Systems

If more than 1 locally connected IMS system is used, a different LITERAL and Db2 Location name must be used to identify the local systems. The Local Name can be obtained from the SYSIBM.LOCATIONS table in the Db2 catalog. If a remote subsystem is to be connected, the LITERAL of the local system must be specified and the Db2 name of the remote system together with a R indicator must be specified.

Define Default Lsys Collections (Option 3)

This option defines the Default Set of collections for each Logical System. These collections will be used if no match on the scheduled PSB is found, The PSB Collections are defined in Option 4.

The first time this option is entered, initial incomplete definitions exist for each logical system.

Define Default Lsys Collections

All the collections for all applications executing in a Logical system must be entered in multiple rows. The Location Name may be left blank, since it will be filled in automatically when the END (PF3) is pressed.

Define Specific PSB Collections (Option 4)

The operation of the dialog is identical to that specified above in the Define Default Lsys Collections section. Specifying collections by PSB is optional and is used only if COLLECTIONS relating to an application are not included in the default package set specified in Option 3.

Information may be extracted from RTT and STAGE1 source members by entering IMP in the command field. The following display appears.

Extract Collections for a Logical System

Information is extracted from the Db2 catalog and saved in the COPE package information table by foreground or background execution processes.

Option 2, Foreground Generate COPE Package Path Table

Selecting this option causes a check to be made of the completeness of the specified package information and a generation of a load module called COPEDCXX that contains the specified package information. In addition, the master plan COPEDLIT is generated containing the collections for all logical systems. A check is made for the user exit COPESXUX existing in the xcope2.LOAD dataset and if absent a copy and rename of the COPEDCXL module is made. This module may be modified by installations and is the generalized exit for many COPE processes.

Option 2B, Background Generate COPE Package Path Table

This option performs the same processes as Option 2 above but submits a job to do the processing in background.

Task 5.11 Bind COPE DB2 Plans (Option 1.9) (Optional – DB/TM and DCCTL only)

Execute COPE Option 1.9 (Bind COPE DB2 Plans) and submit the generated job to re-bind the new DBRM modules.

Task 5.12 Recreate COPEXREF Modules (Option 1.10)

Execute COPE option 1.10 (Generate Environment Member after Changes to ZDEFAULT) and submit the generated job to upgrade the COPEXRF5 module.

Task 5.13 Import Stage 1 Source (Option 2.1)

Prerequisite Step

Option 2 Menu 

The entire Stage 1 source must be imported into the Master Logical System. The name of the Master Lsys can be found on the COPE primary ISPF menu. It has been defined as part of the Lsys setup (Option 1.1).

1. Select Option 1 (Import Entire Stage 1 Source to COPE Dictionary) to import Stage 1 from a PDS.
2. Make any updates as desired and press PF3.
3. Follow the instructions on the screens provided.
4. Submit the generated job. The expected return code is 0.

Task 5.14 Import DBD/PSB/MFS Copy Members (Options 2.3C/4C/5C)

Some installations use COPY members as part of their DBD, PSB or MFS definitions. These members may be imported with Options 2./3C/4C/5C respectively. The copy members should be imported before the definitions are imported.

The sibling arrangement is maintained for COPY members. A junior sibling will concatenate its COPYLIB in front of the senior sibling COPYLIB. COPY members that are identical between Logical Systems need not be imported to all of them if they exist in the Senior Logical System.

Task 5.15 Import and Generate DBDs

When an import of a DBD is made to a COPE Logical System, the source is copied to the COPE source dataset from an external dataset and the source is then regenerated for the Logical System and all Junior Logical Systems that are related to it. Thus, if a Logical System has 10 junior siblings, eleven DBDs will be generated if a DBD is imported into the Senior Lsys.

If a Junior Sibling contains a duplicate member, a Load module will not be generated for that system.

Imports for DBDs may be performed with Option 2.3. The input dataset may be a source or load type dataset. The advantage of using a DBDLIB LOAD dataset as the input is that the definitions match a running system. The disadvantage is that comments are not present.

1. Using option 2.DBD import, point to the installation DBDBSOURC or DBDLIB dataset.
2. Select all DBDs to be imported by placing an S next to them. Enter the following on the command line: S*.

All DBDs must be imported into all Logical Systems before PSBs are imported. If a DBD is not present when a PSB is generated, COPE will generate a Dummy PSB to allow other Logical Systems to execute using the shared Message Region PSB definition.

Task 5.16 Import PSBs (Option 2.4)

When an import of a PSB is made to a COPE Logical System, the source is copied to the COPE source dataset from an external dataset and the source is then regenerated for the Logical System and all Junior Logical Systems that are related to it. Thus, if a Logical System has 10 junior siblings, the PSB generated will contain PCBs for all 11 Lsys.

Imports for PSBs may be performed with Option 2.4. The input dataset may be a source or load type dataset. The advantage of using PSBLIB LOAD datasets as the input is that the definitions match a running system. The disadvantage is that comments are not present. Options are allowed in the import operation for generating the PSBs and doing an ACBGEN. NO should be specified for each option during this initial COPE setup. If YES is specified, there will be no damage to the system, but there will be a much greater CPU usage.

1. Using option 2.PSB import, point to the installation PSBSOURC or PSBLIB dataset.
2. Specify Online PSBGEN option NO and ACB generation NO.
3. Select all PSBs to be imported by placing an S next to them. Enter the following on the command line: S*.

1. Using option 2.PSB, import the following members from the installation PSBSOURC dataset into the master Logical System PSBSRCLB.
   
   • COPEBMP
   • COPEDCCL
   • COPEDCCT
2. Specify PSBGEN=YES and ACBGEN=NO.
   
   

Compile all PSBs using Option 3.5.

1. Enter G A* in the command field.
2. Press Enter.
3. Press END (PF3).
4. Specify NO for ACB generation and press Enter.
5. Enter SUB to submit the job that generates all members beginning with A.
6. Repeat using G B* followed by G C*, etc., until all members are compiled.
   The command G * may be entered but the resulting job would generate many jobs and may time out. SUB setting the generate jobs minimizes problems.

Task 5.18 Import Dynalloc (DFSMDA) Definitions (Option 2.2 – DB/TM, DBCTL, and DCCTL with XDCTTL=YED only)

Use Option 2.2 to import Dynalloc (DFSMDA) macros.

The import dataset may be a Load library with compiled DFSMDA members in it or a library with the DFSMDA source. The system will generate source from them and copy the source into the Logical System definition.

Do the following to import Dynalloc (DFSMDA) macros:

1. Use COPE ISPF option 2.2 pointing to DFSMDA source or load library and the desired Logical System.
2. Make updates as desired and press PF3.
3. Submit and run job created. The expected return code is 0.
4. Use COPE ISPF option 3.3 pointing to the desired logical system. Change dataset names as appropriate, and press PF3 twice.
5. Place an S next to the databases for which you want to create dynamic allocation member(s). Use command S *.
6. Press PF3 twice.
7. Submit and run the created job. The expected return code is 0.

Typically each Logical System (Lsys) will have a separate set of DFSMDA macros. You can repeat steps 1 through 7 above for each Lsys. An alternative method once you've completed steps 1 through 7 above for the first Lsys is:

1. Use COPE ISPF option 3.3 specifying the desired Logical system.
2. Copy the previous dynamic allocation member from the DYNALLOC dataset (the name of the dataset shown at the top of the screen).
3. Update the dataset names as appropriate, and save it by pressing PF3 twice.
4. Place an S next to the databases for which you want to create dynamic allocation member(s). Use command S *.
5. Press PF3 twice.
6. Submit and run the created job. The expected return code is 0. These jobs must be created and run one at a time.

If you have an IMS/TM system and Option 1.8 specifies ‘Shared Dyno’, all shared systems will be updated whenever a Dynalloc specification is added or deleted. The updates will have dummy names which will have to be modified using COPE ISPF Option 3;3.

Task 5.19 Generate Stage 1 (Option 4.1)

Option 4.1 generates a job that when submitted creates a COPE Stage 1 definition and outputs it as a STAGE1 member in the IMSGEN dataset. A compilation is then made and the output saved as a member named STAGE2 in the IMSGEN dataset. (This dataset is accessible any time using Option 4.11). If DRD is active, Type 2 commands will be generated to update the executing system and no Stage 2 is required to be compiled. This will cause multiple jobs to be submitted.  Expected return codes are 0 or 4 in a DB/TM or DBCTL environment. In a DCCTL environment RC=24 is expected in the LOAD step (loading DB2 tables). 

Task 5.20 Edit Stage 1 (Option 4.1E – Optional)

If the Stage 1 generation is successful, the Stage 2 member is automatically generated. If, however, changes are required to correct problems, the STAGE1 member may be edited and compiled by using Option 4.1E (or 4.S1E).

Task 5.21 Compile Stage 2 (Option 4.2)

This step is not required if DRD is active.

The Generated Stage2 member may be edited and submitted for compile with Option 4.2.

Task 5.22 Online Change

This step is not required if DRD is active for the second and subsequent generations and the COPE SPOC feature installed.

Copy the MODBLKS dataset to MODBLKSA and MODBLKSB datasets.

Task 5.23 Generate Dynalloc (DFSMDA) Definitions (Option 4.3 – DB/TM, DBCTL, and DCCTL with XDCCTL=YED only)

Task 5.24 Import Message Format Services (MFS) – Option 3.6 (Optional; DB/TM and DCCTL only)

The treatment of MFS (Message Format Services) is a little different from that of the PSBs and DBDs. The COPE system can access the IMS system Format Libraries. Whenever a change is made to a format definition or a new format introduced, it has to be imported into the Logical System that uses it. If a format is not imported into a Logical System, COPE will use the non-COPE version of the format.

Task 5.25 Initialize the RECONS – Option 2.6 (Optional)

COPE provides the ability to delete and define the RECON datasets, and then initialize them.

The following are the steps to accomplish this.

Task 5.25.1 Option 2.6

1. Go to Option 2.6 Create and Generate Recon Database Definitions,4. which will bring up the Generate DBRC INIT.DBD/DBDS/GROUP statements screen as shown in the following: 
   Generate DBRC INIT.DBD/DBDS/GROUP Statements - Backup 
   

2. Select Option B to create a job that will back up the RECONS. 

   If you are creating a new set of RECONS, skip this step and continue with Task 5.25.2.

3. Press Enter.
4. Submit the job that was created.
   The following table lists the expected return codes.

Task 5.25.2 Build DBRC Job

1. Type G in the command line.
2. Type a * in the Lsys field as shown in Generate DBRC INIT.DBD/DBDS/GROUP Statements - Generate.
3. Press Enter. This will create a job which after completion will build another job that will build the RECONS.

Generate DBRC INIT.DBD/DBDS/GROUP Statements - Generate

Task 5.25.3 Submit Build DBRC Job

1. Submit the job that was generated.
   Expected return code is 0.
2. When this job completes successfully, proceed to Task 5.25.4.

Task 5.25.4 Edit Generated Statements

1. Select option E.
2. Press Enter as shown in the following figure.
3. Review the generated statements.

Generate DBRC INIT.DBD/DBDS/GROUP Statements - Edit 

Task 5.25.5 Submit Job to Recreate and Initialize RECONS

Submit the job that was created which will delete the RECONS, define the RECONS and initialize the RECONS. Expected return code is 0.

Task 5.26 Perform ACB Generation (Option 4.5)

Select Option 4.5 to display the COPE ACBGEN panel. 

ACBGEN Menu 

Task 5.26.1 ACBGEN ALL

A new installation requires an ACBGEN ALL, which can take a considerable amount of time.

The COPE application supports this type of generation, but it also supplies a quicker method that generates up to 9 jobs that can run simultaneously. An additional job is generated that is placed on the hold queue that, when released, combines the partial ACBGENs into the target ACBLIBs. The expedited method may be invoked by specifying PAR in the command field.

You may get the following message to which Press Enter:

*No COPEMFSX module found in IM.IF2T.PGMLIB - a dummy module will be *
*generated to satisfy online requirements *                                                              
Submit  and run the  jobs created
Return code of 4 is expected in the job that merges

Task 5.26.2 ACBGEN FIX

The FIX option should be run after the ACBGEN is complete. This generates additional PSBs for use by the Xpediter product. It also generates 'dummy' ACBs and STUBX modules for missing ACBs. These allow transactions to execute and give warning messages.

Task 5.27 Define and Load Database and Transaction Definitions (DB/TM and DCCTL only)

Task 5.27.1 Option 4.9

1. Use Option 4.9 (Recreate COPE Transaction and Database Start/Stop Definitions) to create a job which will load the Start/Stop definitions.
2. Submit the job that is created. The expected return code is 0.
   This job extracts from internal COPE definitions and automatically creates groups of related databases and Batch message switch transactions.

Task 5.27.2 Option 5.7

1. Use option 5.7 (Gen-Sub COPE Database Initialization Job) to create a job to update the Start/Stop Definitions.
2. Submit the resulting JOB.

Task 5.27.3 Option 3.7

1. Use option 7 (Update COPE Start/Stop Definitions and Submit Load JOB) to create a job to update the Start/Stop Definitions.
2. Press END (PF3),
3. Submit the resulting Return code of 4 is expected

The generated JOB will generate a ZDLD member in the IMSGEN dataset (accessible with Option 4.11). In a new installation, the steps that update the COPE database will fail (If they are DL1) since the database has not been  initialized.

Task 5.28 Consistency Check System Definitions (Option B;3;11)

An IMS system may consist of thousands of interrelated definitions. If there are errors, they can only be discovered when a transaction or application is executed. Finding and fixing the incorrect definitions is time consuming and requires the experience of a DBA or Systems Programmer.

COPE supplies an application that checks 15 different relationships and reports on any detected inconsistencies.

1. Select Option B;3;11 to access the CHECK application as shown in the following figure:
   Check application 
   
   
   
2. Select Option 2 to generate the report.
3. When the Report Job is completed, select Option 1 to view the results.

The following is an example of the result panel:

Overall Consistency Check Report 

The figure shows the detected relationships. To view the specifics of a Logical System report:

1. Type JUMP in the command field.
2. Position the cursor on the intersection of the Logical System row and the report column.
3. Press Enter.

A typical report is shown in the following panel:

Individual Consistency Check Report 

JUMPE may be entered instead of JUMP. If the alternate ISPF screen is displayed in Edit member select mode and you place the cursor on the top-left character of a column, S <member-name> commands will be issued for all names in the column. This mode automates the tedious job of selecting multiple non-contiguous members.

Task 5.29 HALDB Setup (DB/TM and DBCTL only – Optional)

The HALDB import utility is provided with COPE to ease the migration for HALDB databases. The following is the process for using this utility.

1. Access the COPE Prime Menu.
2. Select Option 3.4H
3. Press Enter.

The COPE HALDB definition utility 3.4H panel is displayed.

High Availability Large Data Base Partition

A prerequisite to using this application is that all HALDBDs must be imported into COPE before the partitions can be defined and stored in the RECON.

The I option allows definitions to be imported into COPE and unique C-numbers assigned to the partition definitions.

The DEF option allows access to the IBM partition definition utility, however if the databases are defined in an IMS system outside of COPE.

The I option allows multiple HALDBs to be defined at a time. The DEF option processes one HALDB at a time. For an initial setup of COPE the I option is recommended.

The HALDB Definition Import (I) Option

1. Enter I in the command line.
2. Press Enter.

The Import menu displays.

HALDB Selection Partition Definition Import 

The non-COPE Recons in which the HALDB definitions reside must be defined together with the DBD library of the system they belong to.

The partition definitions have a dataset name defined. Since the definitions are copied into multiple logical systems, a dataset rename mask must be specified before the import operation is started so that the definitions in each Logical System (Lsys) have unique names.

Specify Dataset Rename Mask

The Rename Mask allows a High-Level Qualifier (HLQ) to be inserted at the beginning of the dataset name and allows the Lsys name to be inserted at a specific location within the dataset name.

The HLQ can either be inserted at the front of the existing dataset name or can replace the first token in the dataset name. If the HLQ is surrounded with brackets, it replaces the first token.

LSYS (with or without brackets) must either follow the HLQ or, if there is no HLQ, it must be the first item in the Rename Mask specification. The position that the LSYS name is inserted is determined by the number of asterisks (*) that follow LSYS. The position is determined by counting tokens from the right of the dataset name. If there are two *s, the right two tokens in the dataset name are left unchanged. The COPE Lsys name is inserted before them. If (LSYS) is specified, the next token from the right is replaced, else the LSYS name is inserted and the remaining dataset tokens are unchanged.

HALDB Rename Import Mask

The HALDB Rename Import Mask consists of two parts: the Left Part and the Right Part. The Right part is required; the Left part is optional

The Right Part

The word LSYS must be defined with any number of .* following it.

The .* indicate the number of tokens in the dataset name, starting from the right, that have to be skipped before the LSYS name is inserted or replaced the token in the position.

If the mask is LSYS.*.*.* for Lsys DBT1 and the dataset name is MA.MF.MW01.INKEY.BLOG, the result will be:

If the mask is (LSYS).*.*.*, the result will be:

The Left Part

Any 1- to 8-character string may be defined with or without enclosing parens ( ). If there are parens, the character string they enclose will replace the left-most token of the dataset name.

If the dataset name is MA.MF.MW01.INKEY.BLOG and the Mask is FLOPPY, the result will be:

If the mask is (FLOPPY), the result will be:

An aid to determine the effectiveness of the Dataset Rename Mask exists.

1. Enter DEMO on the High Availability Large Data Base Partition Import menu, to display the Dataset Change Demonstration window.
   Dataset Change Demonstration
   
2. Enter the Lsys and the dataset name that exists in the external HALDB Recon together with a Dataset Rename Mask. For example, enter A.B.C in the Dataset name field and press Enter. The following panel shows the result of the rename operation specified by the mask. 
   Dataset Change Demonstration
   
   

The Database Selection Display

1. Return to the HALDB Selection Partition Definition Import screen.
2. Place the Lsys name (or an *) and the database name (or an *) on the Import Menu and a G in the command field

3. Press Enter to display a list of HALDBs. 

   Database Selection Display 

   
   

The EXTN DB NAME is initially set to the COPE DBD name but may be changed if the HALDB definition belongs to a differently named database in the external system. (This is rarely the case).

All databases may be selected by entering S * in the command field or (alternatively) an S may be entered in the row command field or S dbname entered in the panel command field to select individual databases.

Job Submission Considerations

When you have selected a set of databases and pressed PF3 (END), COPE generates a job that should be submitted to import the definitions. The top of the generated JCL contains information about non-existent databases in the external system. This should be noted, and the required definitions imported or specified at a later date.

Task 5.30 MSC (DB/TM and DCCTL – Optional)

In MSC, if you want the user to have control over the Lsys they run in, then define Lsys names to be unique across all Psys's. Doing so will turn off the Transmitted Lsys" mechanism, simply because the Transmitted Lsys will never be defined in the destination Psys.

If you want the user never to have control over the Lsys used in a remote Psys, then define the same set of Lsys names in each Psys, and the Transmitted Lsys will be used.

If you want some other degree of user control over the Lsys, either control the combinations of Lsys's the user can logon to (as a security control), or code a COPESXUX exit to set the Lsys name that you require under whatever circumstances that you require. Please contact BMC Customer Solutions for further information in the latter case.

Remote Logon Support

Follow these steps to support COPE MSC Remote Logons:

Task 5.30.1 Definitions

In ISPF 5.5 add COPExxxx transaction codes under the COPEUTP1 APPLCTN macro. For example, if you have two physical systems ("Psys's") to be known to your users as IMSM and IMSP, and if the System Id for IMSM is 61, and the System Id for IMSP is 51, the option 1;7 (Define Excluded (Not Modified by COPE) Databases and Transactions) definition in system IMSM would be:

System C should follow this pattern: COPEA SYSID=(1,3) and COPEB SYSID=(2,3), and COPEC without SYSID=.

Don't remove the COPE transaction, or put a SYSID= on it. It is needed to run locally in each system, even though there is a COPExxxx that also runs locally.

Choose a 1-4 character suffix for the COPExxxx's in each system that will be as useful as possible for your users. This suffix is what your users will see as the name of the Psys, on their logon screen (on the =RMT=> line).

Take care to ensure that the routing makes COPExxxx run in Psys xxxx, no matter which system COPExxxx is initiated from, without the possibility of loops.

Task 5.30.2 IMS Security

Set up your RACF definitions for all COPExxxx transaction codes, including the COPE transaction code, in all systems:

All of these issue /DIS commands occasionally. The non-MSC issue /STA, /STO, /DBR and /ASS.

Task 5.30.3 IMSGEN

Run option 4.1. If the SPOC feature is present, the definitions will be added via the IMS Type 2 commands. If the SPOC feature is not present, use Option 4.2 (or 4.S2) (Edit (and submit) a Stage 2 member) and when the submitted job has completed do a /MOD PREPARE MODBLKS and /MOD COMMIT. The other useful commands are /DIS MODIFY ALL and /MOD ABORT.

Task 5.30.4 REFRESH or SYNC

From a cleared screen enter COPE REFRESH, or from the COPE screen enter REFRESH. SYNC is automatically done by COPE at cold, warm or emergency start. Either of these commands issue /DIS TRAN to find out the names of the remote Psys's, and store them on USTDLMGR.

Task 5.30.5 Verify

On system A, enter B.Lsys, where Lsys is the name of a Lsys in system B. This remote logon command is from Psys.Lsys, and can be entered from a cleared screen followed by entering a transaction COPE B.B3, or from the COPE screen. For example:

Task 5.30.6 Customize COPEO

Edit the COPEO (O is for Online) member of the MENUS library to add often-used combinations of remote logons as commands or options. This member is the same format as an ISPF panel, with commands being defined in the &ZSEL list. For example, if an installation has 2 systems named IMSM and IMSP with 25 Logical Systems defined in each, the following COPEO menu could be used:

The IMSM definition as follows:

The IMSP COPEO definition would be as follows:

The =RMT=> must be present on some line in column 2, to give the user their current status. The Psys.Lsys values are listed on this line, across the screen, and going to the next lines if necessary and "squeezing down" the rest of the panel definition in that case. Nothing is lost, unless it simply won't fit, then you might lose your =PFK=> lines off the bottom.

Note that in system A, A.A1 is an acceptable form of the local logon. The regular form is just A1. The TRACEL example in each option definition is one way to ensure all your users have their traces on, if you feel this is desirable. You can define, redefine, and nest any command definitions in this way, with &Pn parameter substitution, if desired.

Task 5.30.7 Check for MSNAME Conflicts

If you are combining existing IMS systems, and MSNAMEs are hard-coded in CHNG calls inside programs, you might have a problem where a program in one Lsys attaches an essentially different routing meaning to an MSNAME, to some program in another Lsys. If this conflict cannot be corrected by changing and recompiling programs, you should consider using the B.4.2.TR Destination Translate facility. This is a table, giving Destination (Transaction code, Lterm or MSNASME) within Lsys, and the new Destination name that COPE is to translate all CHNG calls to (for all programs in that Lsys).

Task 5.30.8 Implement Security

Where restrictions are appropriate, consider one of these three methods:

1. Code IFUSER <user list> on command re-definitions in COPEO. You then should protect MENUS for update. This s a way to implement non bypassable security, because COPE honors your definitions and redefinitions under all circumstances (that is, from cleared screen, etc.). but it only gives you the ability to exclude a set of users from doing remote logons by Psys (not by Psys.Lsys).
2. Code an AUTH call in the COPE security exit, COPESXSX, described under Install MSG Region Security Exit COPESXSX in the BMC-COPE-Administration-Guide.
3. Use IMS AGN type security, etc., in the normal way.

For methods one and two above, the information you need is what commands run where:

LOGON

This is local logon (for example, type COPE A1 from a cleared screen or A1 from the COPE screen). Internally (to the IFUSER and to the SXSX exit) this will always appear as LOGON A1.

LOGONRS

Remote logon Send. When the user enters B.B3, the internal command on the local system is LOGONRS B B3 (no dot).

LOGONRR

Remote Receive. When system B receives the remote logon request, the internal command is LOGONRR B3 ORIGTRAN COPEA.

LOGONRC

Remote Confirm. When system A receives the confirmation tran back from B, the internal command is LOGONRC B B3.

An example of using the IFUSER command is:

In the above, only users whose Lterm or Signon-id match the list (with * wild on the end only) can perform remote logon receives on this Psys. The &PP0 says to "substitute all parameters beginning with the 0th", which is the command name (LOGONRR).

In this case, you should also protect local logons:

LOGON,'IFUSER SEC* MTO DBA*;&PP0'

This SXSX exit has more capabilities because it can examine all the parameters (then you would probably look for LOGONRS.

MSC Support Limitations

1. Lterm names should be unique throughout the network, or two same-named Lterms should not be used simultaneously, because logon in each Psys is by Lterm name, and there would be a usage conflict (Sign on ids, if you use /SIGN).
2. Programs cannot choose which Lsys to run in a remote system; the user chooses that at logon time.
3. The option 5.5 definitions and COPEO panel have to be set up in each system, with SYSID's that do not cause endless loops.
4. No simulation of mslinks between Lsys's within one Psys is provided at this stage.
5. The COPEO panel is the only place to define logon options currently (there is no sub-selection panel facility).
6. ROUTING=YES is not currently supported unless you use /SIGN (because the lterm name in the IOPCB, which COPE uses to identify the user, is not there, if ROUTING=YES).

MSC Supported Features

1. Lsys names do not need to be unique across the network.
2. Remote transactions can run directly from terminals without an intervening local MPP switch.
3. /SIGN ON is supported. The signon id is always used instead of the Lterm name, if present.
4. /MSASSIGN commands make no difference to the Lsys selected. They would, of course, affect the routing of transactions to Psys's, but this routing is independent of COPE considerations.
5. The setup of msnames and mslinks in the stage 1 does not affect the Lsys selection mechanism. From the application point of view, these names have to be set up so that transactions will be routed to the correct remote Psys.
6. Conversational transactions are supported fully. There is no change to the SPA or message sent across the link.
7. The Abend Summary feature of COPE is supported. This screen is returned on an Express Alternate PCB, via a CHNG to the originating system's transaction code. This transaction code is set in the local USTDLMGR at the time that the remote user logged on. The user displays the Abend Summary screen using the ABS command (same as for non-MSC users).

MFS Synchronization with MSC

If a transaction executes in one Physical system and inserts a transaction with a Modname that is displayed in another physical system, there must be a version of the MFS with the same name in both systems. Since COPE changes the MFS names whenever any MFS is imported into a Lsys, there has to be a mechanism to make the names the same between the various physical systems that are interconnected. The process of making the names the same is called MFS Synchronization. The application is accessed via option B;4.12. This option displays the following panel:

MFS Synchronization Menu 

The application obtains the knowledge of the physical systems from the token identification application for batch jobs in option 1.7;G. Identifiers must be defined for all in all physical systems before the MSC Synchronization application is used.

When option 'S' is selected, the following menu is displayed:

Synchronization Lsys Select Menu 

Enter an S next to the Logical Systems you wish to synchronize. When END (PFKey3) is pressed, a member selection list from the first selected system is shown. Members should then be selected and the END (PFKey3) entered. COPE will make the MID and MOD names the same for those systems.

On exit from the application a COPEMFSX job for each synchronized system will be generated.

Task 5.31 Define Scheme for Generating Plan Names and Rebind DBRMs (DB/TM only)

In a non-COPE IMS system, the plan name used, when an application program is scheduled, is either the same name as the PSB or an alternate name supplied by a RTT table.

Since COPE uses a single PSB to support multiple Logical System (environments) a different mechanism must be used.

COPE uses an Assembler exit named COPESXUX to generate a plan name on the first SQL call from an application program. The exit has access to the 'real' (unmodified by COPE) PSB name and the Logical System name that the application program is executing in. With these tokens it can generate a unique plan name for the application. The simplest approach is to generate a plan that is the same name as the Logical System. All DBRMs for all applications in the Logical System may be bound to one or more collections that are referenced in the PLAN.

If the COPESXUX exit is not used, COPE substitutes a C-number COPE name that is different for each Logical System. This C-number name can be found in Option 4;D;5.

In addition, the COPESXUX exit may associate different Db2 sub-systems with different Logical Systems. This is a supported facility for IMS but application programs must then be link edited with different Db2 language interface module containing unique SSID tokens that relate to a specific Db2 subsystem. If the COPESXUX module is used, all versions of application programs may contain the default language interface module and the exit will substitute different SSIDs automatically.

Once the PLAN name protocol is defined, appropriate Db2 collections must be populated, and the defined plans created.

Many customers define a single plan containing all DBRM definitions for the Logical system applications. This plan simplifies the coding of the COPESXUX exit and the Db2 trace record retrieval.

Task 5.32 Fast Path DEDB Multiple Area Datasets (MADS) (DB/TM, DBCTL, and DCCTL with XDCCTL=YED only - Optional)

The DEDB database has this DBD defined:

The Dynalloc allocation statements are as follows:

The statements provide the link between the information in the DBD and the Dynalloc as follows:

In this example, two area datasets have been defined for the two areas defined in the DBD.

Task 5.32.1 Import Fast Path Dynamic Allocation

If the Fast Path dynamic allocation member(s) were not imported in Task 5.18 import them now.

Task 5.32.2 Edit DBRC Area Dataset Definitions Option B.4.2.E.A

The A option on the parse panel allows entry of information from existing DBRC statements. The statements can be intermixed with JCL or other DBRC statements on input. Only the INIT.ADS and CHANGE.ADS information will be extracted. If you do not use AREA statements, you can omit using option A, because the DD name on the area defaults to the area name.

Task 5.32.3 Generate Dynamic Allocation Members

Use option 3.Dyn and generate the dynamic allocation members for Fast Path DEDBs for each Lsys.

Task 5.33 Load User Databases

COPE supports all standard IMS utilities to load databases. The COPE Lsys being loaded is specified in the JCL by adding a COPEBSYS DD statement to the utility step. An example that specifies logical system IEC1 is:

Task 5.34 Develop Scheme for MQ (DB/TM and DCCTL only) and Create COPE Exit (Optional)

MQ uses a Trigger BMP to insert transactions into a COPE system. If there is a separate MQ system for each Logical System, there is a separate trigger BMP for each. The Trigger BMP has different COPEBSYS DD statements to identify the Logical System being used. The Logical System name extracted from the COPEBSYS DD statement is attached to all inserted transactions from the trigger BMP and used when the transaction is executed.

Task 5.35 Evaluate COPE Exits

COPE provides multiple user exits such as COPEXSUX, COPESXSX and COPEBMPX, that can be used to customize the behavior of COPE. These should be evaluated and coded as appropriate.

Task 5.36 Bring up IMS and Check It Out

Review the following considerations:

1. If you encounter COPEMFSX missing messages, perform option 4.7 (4.MFS).
2. If you run Fast Path Expedited Message Handling (IFP regions), you must convert the JCL for those regions by importing it into a Libset using option T, and then regenerating it. For instructions on how to do this, refer to "Convert External Names to COPE Internal Names (Option B.4;9)” in the BMC-COPE-Administration-Guide. This conversion is required because COPE changes the PSB name to an internal C-number.
3. Make sure that the supplied PSBs, DBD ,and MFS formats are generated, as described in tasks xxxxx above. Entering COPE with a required following blank space from a cleared screen after you are connected to the physical IMS system will bring up the main COPE screen, which lists the Lsys's that are available. Connect or logon to an Lsys by typing in its name. After clearing the screen, from this point on, operation is the same as in a non-COPE system.
4. View the online tutorial (by pressing PF1 HELP) from the COPE screen), and then press Enter, the same way as in an ISPF tutorial.
5. You can exercise Start/Stop Database/Transaction, which is accessed by typing SS from the COPE screen. These facilities are described in the BMC COPE Programmer’s Guide.
6. Now test user applications. The Lsys identifying tokens are in the JCL and Batch jobs executed.