Server JCL
JCL for server jobs is stored in a PDS (partitioned data set). At installation, they are placed in the NGTCNTL PDS with the automation members. These members could be put in an existing PDS, such as a PARMLIB PDS. When moving server jobs, specify where the jobs are in the NGTSVR DD of the configuration job and rerun it. Some users require different server jobname cards for each data sharing group to specify system affinity. You can create additional job card members, if required. To specify which job card to use, override the +SVRJCLJOB parameter in the JCL.
The following figure shows the server model JCL members on the right and how the configuration job finds them. You can override all or part of this setup in individual product jobs.
Configuration setup (CNFGdbid)
You can override the PDS used for server members by specifying a BMC AMI Utilities SVR DD statement in individual jobs. Alternatively, you can override only the member used for a job by specifying one of the +SVRJCL parameters in the product job UTLPARMS DD.
You can also override the use of these server members completely by specifying a DD statement in the BMC AMI Utilities job with the member name specified in each of the three +SVRJCL… parameters in the Configuration setup (CNFGdbid) figure. These DDs would reference a PDS data set name (DSN) specifying a member needed for use. When you specify the following line in a product job, the jobcard in member1 is used:
In summary, processing reads the name specified in +SVRJCLJOB, +SVRJCLDISK, or +SVRJCLTAPE and takes the following steps:
- Verifies whether it is a DDNAME in the job. If it is, processing uses the library (member) specified to that DD.
- Looks for BMC AMI Utilities SVR in the job to determine the location of the member
- Looks for the member in the BMC AMI Utilities SVR specified in the configuration member (RX11ssid)
- Looks for the specific member (RX110GBL)
Started task server jobs
If you use started task servers, the JOB statement, tape, and disk JCL mentioned previously in this topic are not used. Instead, a PROCLIB member is added and referenced by the UTLPARMS +SVRPROCD(member) and +SVRPROCT(member) parameters. When you request multiple servers, they are automatically generated as started tasks with unique step names.The USERID associated with BMC AMI Utilities that will create the started task servers must have the following RACF permissions:
- MCS.MCSOPER.* must have READ access.
- MVS.START.STC.CDBSRV*.* must have UPDATE access (CDBSRV* is the name that you gave the started tasks).
Literals
The primary product job submits several server jobs from the skeleton JCL. The skeleton JCL requires variables to use in the job names and step names, so that there is no contention with duplicates. BMC AMI Utilities have provided literals to use in these names.
You must use at least one of these literals in the server job name. Otherwise, you might inadvertently submit two different jobs with the same name (causing them to run serially rather than in parallel).
The following table describes the literal options:
Literal | Description |
|---|---|
&MJ | Primary job name |
&MJ(n) | First n characters of the primary job name |
&MU | User ID of the primary job |
&MU(n) | First n characters of the user ID of the primary job |
&MJC | The primary job class, a single letter from A to Z or a single number from 0 to 9 |
&JT | The job type—either a D (for disk) or a T (for tape) |
&SPEC | Unique character string inserted each time a server is submitted from a job. The proper use of this literal is to specify a single letter from A to Z, followed by &SPEC (for example, A&SPEC, B&SPEC, C&SPEC, … Z&SPEC). |
&N | Random number 0-9 is inserted and incremented each time a server is submitted from a job. If you have specified fewer than nine servers, this literal provides unique names. |
&NN | Random number 0-99 is inserted and incremented each time a server is submitted from a job. If you have specified fewer than 99 servers, this literal provides unique names. |
&NNN | Random number 000-999 is inserted and incremented each time a server is submitted from a job. If you have specified fewer than 999 servers, this literal provides unique names. |
&A | Letter starting at A and incrementing to Z inserted each time a server is submitted from a job. |
The following table is an examples of literal usage:
Literal | Description |
|---|---|
&MJ(2)&N | Unique name starting with the first two characters of the primary job name and followed by a single random number from 0 to 9. |
&MU(3)&N | Unique name starting with the first three characters of the primary job's user ID and followed by a single random number from 0 to 9. |
A&SPEC | A unique name starting with A is used. |
SERV&NNN | The name SERV001 through SERV999 is used. |
NGTSTP&A | The name NGTSTPA through NGTSTPZ is used. |
The following figure shows a sample JCL skeleton. JCL statements are described in detail by reference to line numbers in JCL descriptions.
//*
//*****************************************************************
//*REQUIRED DD CARDS
//*****************************************************************
//STEPLIB DD DSN=NGT.UTILITY,DISP=SHR
//SYSPRINT DD SYSOUT=*
//*
//*****************************************************************
//*EVERYTHING BELOW IS OPTIONAL
//*****************************************************************
//*
//*REPORT CONTROLS
//*
//SYSERROR DD SYSOUT=*
//SUMMARY DD SYSOUT=*
//RUNSTATS DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
The following table describes the JCL DD statements:
Line no. | Name | Description |
|---|---|---|
1 | EXEC statement | On this statement, the step name must contain the literal &NN. You must code the values for PGM= and PARM= MUST exactly as you see them in this example. |
6 | STEPLIB DD | STEPLIB DSNs are provided to match those specified in the primary job. |
7 | SYSPRINT DD | (Required) You must code a SYSPRINT statement to capture product output. From SYSPRINT, the product output is transferred to the CDBPRINT DD data set. The SYSPRINT data set is cleared and released following each BMC AMI Utility step. The SYSPRINT data set provides a valuable diagnostic tool in the event of errors. However, some BMC AMI Utilities employ parallel processing, which can result in overlapping outputs in SYSPRINT. The SUMMARY DD statement contains a more readable analysis of the product execution. |
15 | SYSERROR DD 1 | (Optional) Use SYSERROR for BMC AMI Utilities server processing error messages. If you do not specify this DD statement, error messages appear only in SYSPRINT. However, if SYSERROR is specified, error messages appear in SYSERROR and SYSPRINT. |
16 | SUMMARY DD 1 | (Optional) SUMMARY statement to capture product output SUMMARY contains a more organized analysis of the product execution than SYSPRINT. SUMMARY includes reports printed at the conclusion of a product run and does not reflect output overlapped from parallel processing. If you specify this DD statement, summary reports are not printed to SYSPRINT. Instead, they are printed to SUMMARY as each product statement completes. If this DD statement is omitted, the summary reports are printed to SYSPRINT. |
17 | RUNSTATS DD 1 | (Optional) RUNSTATS report RUNSTATS contains a report showing RUNSTATS values, and messages affirming update of the Db2 catalog with these values. This report is printed for any product that also updates catalog RUNSTATS values, such as REORG and LOAD. |
18 | SYSTSPRT DD | (Optional) SYSTSPRT data set Any messages sent to TSO are also sent to SYSTSPRT. This may include output from automation control points. REXX Displays from automation are only sent back to the job if you have requested the Journal level output. If you have accepted Journal level output, these displays are sent to CDBPRINT unless this SYSTSPRT DD is included. If this SYSTSPRT DD is included, these displays are sent to SYSTSPRT. |
1 This DD is always automatically allocated.