Writer instructions
Page title	For most spaces, this page must be titled Space announcements. For spaces with localized content, this page must be titled Space announcements l10n.
Purpose	Provide an announcement banner on every page of your space.
Location	Move this page outside of your home branch.
Guidelines	Space-announcements-banners

Server JCL

Server jobs can be one of the following:

Batch server jobs—These jobs are automatically initiated by the BMC AMI Utilities master job.
Started task server jobs—These jobs are run from members of your data center's specified PROCLIB. They do not require the use of initiators.

Batch server jobs

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:

//SVRJOBCD DD DISP=SHR,DSN=yourlibrary(member1)

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)

Important

References to RX11* members refer to members created during installation or configuration of BMC AMI Utilities. These members contain parameters and other information, which are used every time you run BMC AMI Utilities.

Tip

BMC recommends that you use the BMC AMI Utilities SVR specification in the configuration to locate the server model JCL. Using this method, you can make global changes at the system level without changing any product JCL. You should override only the product parameters in jobs to specify an alternate member.

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).

Important

The NGTCNTL library contains two sample started task procedures:

Member NGTSERVD for disk servers (+SVRPROCD)
Member NGTSERVT for tape servers (+SVRPROCT)

You may use these samples as they are, or copy and customize them to your needs.

Literals

The master 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).

Important

Generated literal, including all '&', '.', '(' and ')' characters, must not exceed eight characters, and all literals (or symbolics) must end with a delimiter. The delimiter can be a ',', '.', '('. ')', '&', ''', or a space.

Generated literals must not exceed eight characters and can include any of the following characters:

Character	Character name
&	Ampersand
.	Period
( or )	Parenthesis (opening or closing)

You must end all literals (or symbolics) must end with one of the following delimiters:

Character	Character name
&	Ampersand
.	Period
,	Comma
'	Single quote mark
( or )	Parenthesis (opening or closing)
	Space

The period character (.) is special and is replaced as part of the symbolic in accordance with normal MVS standards.

The job name and step name produced are limited to eight characters by MVS. If the master job name is MSTRJOB1 and you are starting DASD server, you should code &MJ(4)&JT&NN.P. This would produce a name of MSTRD01P which meets the MVS standards and is eight characters long.

The following table describes the literal options:

Literal	Description
&MJ	Master job name
&MJ(n)	First n characters of the master job name
&MU	User ID of the master job
&MU(n)	First n characters of the user ID of the master job
&MJC	The master 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 master 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 master 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.

Tip

BMC recommends that job name masks include a &NNN to guarantee unique server job names. If you have used up most of the allowed eight characters, you can substitute &NN or &A.

The XSVRJCL-automated-server-JCL-automation-control-point can provide additional functionality in the definition of literals.

The following figure shows a sample JCL skeleton. JCL statements are described in detail by reference to line numbers in JCL descriptions.

//DSERV&NN EXEC PGM=NGTSERVR,PARM='&SVRPARM'
//*
//*****************************************************************
//*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. Warning If this statement is not correctly coded, server processing fails. Review this statement carefully to ensure that it is correctly coded.
6	STEPLIB DD	STEPLIB DSNs are provided to match those specified in the master 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¹	(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¹	(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¹	(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. Important If you omit this DD statement, there is no RUNSTATS report on any statement (including SYSPRINT and SUMMARY).
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 (PTF BQU1353 applied) This DD is always automatically allocated.}

Server JCL

Batch server jobs

Started task server jobs

Literals

On this page