2. Planning for Installation and Use of CA MICS › 2.3 Installation Planning and Parameter Specification › 2.3.3 CA MICS JCL Planning and Parameters › 2.3.3.3 JCLGEN Parameters for Special Requirements › 2.3.3.3.6 OS Step Names
2.3.3.3.6 OS Step Names
Jobs generated with JCLGEN have descriptive job step names.
In the CA MICS installation jobs, the job step names can be
changed without impact on CA MICS operation. This is NOT true
of the CA MICS operational jobs (i.e., DAILY, INCRccc,
WEEKLY, MONTHLY, YEARLY, BACKUP, BACKUPM, RESTORE, RSTATUS,
and SCHEDULE). During the operational jobs, the current job
step name is compared with the step which is acceptable to
run, based on the status of the database checkpoint file.
CA MICS operational job step names have a strict naming
convention. Having operational jobs that adhere to this
convention allows the CA MICS Product Support representatives
to accurately and quickly isolate operational problems. This
helps us provide you with more timely problem resolution
should operational job problems occur. Changing the job step
names of CA MICS operational jobs always interrupts this
initial problem isolation, and usually lengthens problem
resolution times.
You may not be able to take full advantage of features
provided by CA MICS if you modify the CA MICS operational job
step names. CA MICS automatic job submission facilities in
the batch SCHEDULE job and in the online Operational Status
and Tracking facility create processes that include a series
of CA MICS operational jobs. For example, a weekly process
would consist of a DAILY, WEEKLY, and BACKUP in a single job
stream. Job step names must be unique among all of the
operational jobs in order to use the automatic submission
facilities.
Changing operational job step names is a process that
involves more user modifications than any other tailoring
operation in CA MICS. A facility is provided to allow the
override of CA MICS operational job step names used in
checkpoint analysis. The step names must be manually
modified in all of the affected PROTOLIB members, and
overridden names must be mapped to standard names. This
mapping may change as new products are added to the database.
Because of the maintenance burden this will add, and because
modifying operational job step names usually lengthens
support interactions, WE HIGHLY RECOMMEND THAT BEFORE THE
EFFORT OF CHANGING JOB STEP NAMES IS BEGUN, YOU ATTEMPT TO
GET A WAIVER OF THE INSTALLATION JOB STEP NAME STANDARD.
If you find that you must change operational job step names,
follow these steps (which are explained in more detail in the
text that follows):
MODIFYING PROTOLIB MEMBERS:
o Determine if you will be scheduling CA MICS through a
vendor scheduling package or using a CA MICS provided
facility.
o Identify the minimum number of job step names that
must be changed.
o Identify the location of each job step name in
members of sharedprefix.MICS.PROTOLIB.
o Prepare the PROTOLIB modifications.
TRANSLATING STEP NAMES:
o Prepare the PROC FORMAT statements that comprise the
$USTEP format. This format is called by operational
job checkpoint processing to translate the actual
(modified) job and step name of an operational job
into the CA MICS standard job and step name.
o Prepare the _USRSTEP macro that performs the opposite
translation; given a CA MICS standard operational job
step name, return the actual (modified) job step name
in which restart processing should occur.
INSTALLING:
o Install the modifications, format, and macro.
o Keep complete written records of all modifications,
and have them available for each call to the CA MICS
Product Support group.
Here is a detailed description of the operational job step
name modification strategy.
MODIFYING PROTOLIB MEMBERS:
1. Determine if you will be scheduling CA MICS through a
vendor scheduling package or using a CA MICS provided
facility.
If you plan to use one of the CA MICS scheduling
facilities, all operational job step names MUST be
unique. If you use the same job step name, for example
STEP1, in multiple CA MICS jobs, then you can NOT use the
CA MICS batch SCHEDULE job or the Operational Status and
Tracking SCHEDULE, DAILY, WEEKLY, MONTHLY, or YEARLY
commands.
2. Identify the minimum number of job step names that must
be changed.
The CA MICS operational jobs and their step names are
listed in Chapter 4. Thoroughly examine that chapter for
an understanding of the structure and job step naming
conventions used by CA MICS.
From the list of possible job step names, select the
fewest number of names that must be changed. Fewer name
changes mean fewer modifications and less effort.
3. Identify the location of each job step name in members of
sharedprefix.MICS.PROTOLIB.
The PROTOLIB members that cause each operational job to
be generated are named for the job: DAILY, WEEKLY,
MONTHLY, YEARLY, BACKUP, BACKUPM, RESTORE, RSTATUS, and
SCHEDULE. Note: The INCRccc operational jobs are
generated from the cccINCR protolib members.
The operational update jobs (DAILY, INCRccc, WEEKLY,
MONTHLY, and YEARLY) include other PROTOLIB members to
complete their generation. The names of these members
vary according to the job step which the members
prototype.
For the DAILY, WEEKLY, MONTHLY, and YEARLY job steps that
update CA MICS databases, the members have names of the
form ttcccsss, where
tt = DY for the DAILY job
WK for the WEEKLY job
MN for the MONTHLY job
YR for the YEARLY job
ccc = the product identifier, and
sss = the product update step number
The INCRccc jobs are in the cccINCR members and have step
names of INCRnnn.
The product identifiers (ccc) and update step numbers
(nnn) for each CA MICS data integration product can be
found in sharedprefix.MICS.GENLIB(COMPTDEF).
An example of such a member is the CA MICS Batch and
Operations (SMF) Analyzer. Its operational update step
prototypes can be found in PROTOLIB members DYSMF030,
SMFINCR, WKSMF030, MNSMF030, and YRSMF030.
In addition, the DAILY, WEEKLY, and MONTHLY jobs have
separate report step prototype members in PROTOLIB.
These members are called:
DYRPT400
WKRPT400
MNRPT400
Finally, the DAILY, WEEKLY, MONTHLY, and YEARLY jobs have
separate user step prototype members in PROTOLIB. These
members are called:
DYUSR500
WKUSR500
MNUSR500
YRUSR500
4. Prepare the PROTOLIB modifications.
If you need to change step names, to conform to a
standard, you would typically build modifications for all
the members identified above.
As an example, we will examine a single modification.
The first step of the DAILY job is called DAYALL. Its
prototype is in sharedprefix.MICS.PROTOLIB(DAILY). For
this example, lets say that the DAYALL step is located on
a line with sequence number 00041000. The contents of
that line are:
col 1 col 80
| |
//DAYALL EXEC &MICSNDB,SYSPARM=&SYSPARM 00041000
To change the name of the step from DAYALL to STPDY000,
build an IEBUPDTE input stream that replaces the line
with the desired contents:
col 1 col 80
| |
./ CHANGE NAME=DAILY
//STPDY000 EXEC &MICSNDB,SYSPARM=&SYSPARM 00041000
Repeat this procedure for each step and member modified.
Be sure to add user maintenance block comments to each
member, and save the update in the modification staging
library sharedprefix.MICS.LOCALMOD.CNTL.
TRANSLATING STEP NAMES:
5. Prepare the $USTEP FORMAT.
The $USTEP format is generated by every JCLGEN run in a
unit database. The source for this format is contained
in prefix.MICS.USER.SOURCE(USTEP) for every unit
database.
For every unit database, enter the step translation
information in prefix.MICS.USER.SOURCE(USTEP).
The distributed USTEP member contains:
PROC FORMAT LIBRARY=TMUOLIB.MICSFMTS PRINT;
VALUE $USTEP (MIN=16 MAX=16 DEFAULT=16)
/* */
/* INSERT STEP MAPPING DEFINITIONS HERE. */
/* FORM OF DEFINITIONS IS: */
/* 'NEW_JOB_NAME_STEP_NAME'='OLD_JOB_NAME_STEP_NAME' */
/* */
/* EXAMPLE: */
/* IF JOB "DAILY" STEP "DAY020" HAD BEEN RENAMED TO */
/* IF JOB "YLIAD" STEP "Q64A31" THE DEFINITION IS: */
/* 'YLIAD Q64A31 '='DAILY DAY020 ' */
/* */
/* IT IS VERY IMPORTANT THAT THE JOB AND STEP NAME */
/* BE SPECIFIED EXACTLY AS SHOWN. THE JOB MUST BE */
/* THE FIRST EIGHT POSITIONS AND THE STEP MUST START */
/* IN POSITION NINE. */
/* */
/* NEW_JOB NEW_STEP OLD_JOB OLD_STEP */
/* '1234567812345678'='1234567812345678' */
/* */
/* */
/* THE FOLLOWING ENTRY REPRESENTS AN ILLEGAL */
/* COMBINATION OF JOB AND STEP NAME. IT IS */
/* INCLUDED TO ENSURE THAT THIS FORMAT, AS */
/* GENERATED, WILL NOT BE EMPTY. ADD ANY SITE */
/* DEPENDENT ENTRIES AFTER THIS DUMMY ENTRY. */
/* */
'+ ' = '+ '
; RUN;
The translations must be added to this member. Since the
CA MICS automatic job submission facilities generate a
composite job stream of multiple CA MICS operational
jobs, you must provide a mapping of all possible
combinations of job and step names. The resulting SAS
code in prefix.MICS.USER.SOURCE(USTEP), with comments
removed, will look like this:
PROC FORMAT LIBRARY=TMUOLIB.MICSFMTS PRINT;
VALUE $USTEP (MIN=16 MAX=16 DEFAULT=16)
'SYSOPDY STPDY000' = 'DAILY DAYALL '
'SYSOPDY STPDY001' = 'DAILY DAYSMF '
'SYSOPDY STPDY002' = 'DAILY DAY010 '
'SYSOPIU STPIU010' = 'INCRTSO INCR010 '
'SYSOPDY STPDY003' = 'DAILY DAY020 '
'SYSOPIU STPIU020' = 'INCRRMF INCR020 '
'SYSOPDY STPWK001' = 'WEEKLY WEEK010 '
'SYSOPDY STPWK002' = 'WEEKLY WEEK020 '
'SYSOPDY STPMN001' = 'MONTHLY MONTH010'
'SYSOPDY STPMN002' = 'MONTHLY MONTH020'
'SYSOPDY STPYR001' = 'YEARLY YEAR010 '
'SYSOPDT STPYR002' = 'YEARLY YEAR020 '
. . . = . . .
'SYSOPWK STPWK001' = 'WEEKLY WEEK010 '
'SYSOPWK STPWK002' = 'WEEKLY WEEK020 '
. . . = . . .
'SYSOPMN STPMN001' = 'MONTHLY MONTH010'
'SYSOPMN STPMN002' = 'MONTHLY MONTH020'
. . . = . . .
'SYSOPYR STPYR001' = 'YEARLY YEAR010 '
'SYSOPYR STPYR002' = 'YEARLY YEAR020 '
... etc ...
'+ ' = '+ '
; RUN;
Note that each DAILY job step name is mapped with the
DAILY, WEEKLY, MONTHLY, and YEARLY job name. WEEKLY,
MONTHLY, and YEARLY job step names must also be mapped
with the DAILY job name.
If you have duplicate job step names in the CA MICS
operational jobs, you will not be able to code the
multiple job name mapping. For example, if the first
step in the DAILY job is MICS001 and this is also the
name of the first step in the WEEKLY job, you cannot
correctly map the MICS001 step to DAYALL when the DAILY
operational job is part of a composite job stream of
DAILY, WEEKLY, and BACKUP (the WEEKLY process). For this
reason, you will not be able to use the CA MICS SCHEDULE
job or the Operational Status and Tracking SCHEDULE,
DAILY, WEEKLY, MONTHLY, or YEARLY commands.
6. Prepare the _USRSTEP macro.
Remember that the function of the $USTEP macro was to
translate an actual job/step name into the equivalent
CA MICS standard job and step name. The _USRSTEP macro
has the opposite function: to find the name of the step
in a failed operational job, which should be specified in
a RESTART JCL control parameter. The step name found must
be put into a data element called RESTEP.
The macro could use any of several methods to reassign
the new step name into the data element RESTEP. One
method that is relatively reliable for a minimum effort
is to use the $USTEP format to contain both directions of
translation. For example, add to the USTEP member in the
above example the opposite translation:
PROC FORMAT LIBRARY=TMUOLIB.MICSFMTS PRINT;
VALUE $USTEP (MIN=16 MAX=16 DEFAULT=16)
'SYSOPDY STPDY000' = 'DAILY DAYALL '
'SYSOPDY STPDY001' = 'DAILY DAYSMF '
'SYSOPDY STPDY002' = 'DAILY DAY010 '
'SYSOPIU STPIU010' = 'INCRTSO INCR010 '
'SYSOPDY STPDY003' = 'DAILY DAY020 '
'SYSOPIU STPIU020' = 'INCRRMF INCR020 '
'SYSOPDY STPWK001' = 'WEEKLY WEEK010 '
'SYSOPDY STPWK002' = 'WEEKLY WEEK020 '
'SYSOPDY STPMN001' = 'MONTHLY MONTH010'
'SYSOPDY STPMN002' = 'MONTHLY MONTH020'
'SYSOPDY STPYR001' = 'YEARLY YEAR010 '
'SYSOPDT STPYR002' = 'YEARLY YEAR020 '
. . . = . . .
'SYSOPWK STPWK001' = 'WEEKLY WEEK010 '
'SYSOPWK STPWK002' = 'WEEKLY WEEK020 '
. . . = . . .
'SYSOPMN STPMN001' = 'MONTHLY MONTH010'
'SYSOPMN STPMN002' = 'MONTHLY MONTH020'
. . . = . . .
'SYSOPYR STPYR001' = 'YEARLY YEAR010 '
'SYSOPYR STPYR002' = 'YEARLY YEAR020 '
... etc ...
'DAILY DAYALL ' = 'SYSOPDY STPDY000'
'DAILY DAYSMF ' = 'SYSOPDY STPDY001'
'DAILY DAY010 ' = 'SYSOPDY STPDY002'
'DAILY DAY020 ' = 'SYSOPDY STPDY003'
. . . = . . .
'INCRTSO INCR010 ' = 'SYSOPIU STPIU010'
'INCRRMF INCR020 ' = 'SYSOPIU STPIU020'
. . . = . . .
'WEEKLY WEEK010 ' = 'SYSOPWK STPWK001'
'WEEKLY WEEK020 ' = 'SYSOPWK STPWK002'
. . . = . . .
'MONTHLY MONTHL10' = 'SYSOPMN STPMN001'
'MONTHLY MONTH020' = 'SYSOPMN STPMN002'
. . . = . . .
'YEARLY YEAR010 ' = 'SYSOPYR STPYR001'
'YEARLY YEAR020 ' = 'SYSOPYR STPYR002'
... etc ...
'+ ' = '+ '
; RUN;
The standard CA MICS job name can be found easily. The
_USRSTEP macro is invoked with the CA MICS restart step
name already in data element RESTEP. Thus, on entry to
_USRSTEP code, RESTEP will begin with either DAY, INCR,
WEEK, MONTH, YEAR, BKUP, or RSTR.
This sample code for the _USRSTEP macro, with the
expanded list in the $USTEP macro, may be used:
MACRO _USRSTEP
LENGTH USER16 USER16N $16 USER8 $8;
IF RESTEP EQ :'DAY' THEN USER8='DAILY';
ELSE IF RESTEP EQ :'INCR' THEN
USER8 = 'INCR' || SCAN(PUT(RESTEP,$STEP.),1);
ELSE IF RESTEP EQ :'WEEK' THEN USER8='WEEKLY';
ELSE IF RESTEP EQ :'MONTH' THEN USER8='MONTHLY';
ELSE IF RESTEP EQ :'YEAR' THEN USER8='YEARLY';
USER16 = PUT(USER8,$CHAR8.)||PUT(RESTEP,$CHAR8.);
USER16N = PUT(USER16,$USTEP.);
IF USER16N NE USER16 AND LENGTH(USER16N) GT 8
THEN RESTEP = SUBSTR(USER16N,8);
%
Note that the reverse translation does not require double
mapping of job step names. You need only list each job
step name once for reverse translation.
INSTALLING:
7. Install the modifications, format, and macro.
The most difficult part of installing step name
modifications is the coordination of events. There is no
unit-level concatenation of the JCL prototype library
PROTOLIB, so all changes to it are complex-wide.
If you are installing CA MICS for the first time, do the
following:
a. ___ Apply the changes to PROTOLIB by submitting the
IEBUPDTE modifications explained above.
b. ___ During unit database installation, after the
COPYLIBU job is run, copy the $USTEP format
changes to prefix.MICS.USER.SOURCE(USTEP) and
install the _USRSTEP exit. Subsequent steps in
the normal unit installation process will
complete the installation of the step name
modifications.
If you have installed CA MICS previously, and have unit
databases in production, do the following:
a. ___ Suspend all JCL generation activity in all unit
databases. CA MICS has no facility to guarantee
this suspension, so you (the CA MICS
administrator) must manually ensure this
suspension.
b. ___ Apply the changes to PROTOLIB by submitting the
IEBUPDTE modifications explained above.
*********************************************************
* Perform steps c to f for every unit database in *
* your CA MICS complex. *
*********************************************************
c. ___ Enter the Operational Status and Tracking SUSPEND
command to suspend operational processing in this
unit.
d. ___ Copy the $USTEP format changes to
prefix.MICS.USER.SOURCE(USTEP), and install the
_USRSTEP exit in the unit database.
e. ___ Submit prefix.MICS.CNTL(JCLGEND). This job
regenerates all operational JCL.
f. ___ Enter the Operational Status and Tracking RESUME
command to resume operational processing in this
unit.
*********************************************************
* Perform steps c to f for every unit database in *
* your CA MICS complex. *
*********************************************************
8. Keep complete written records.
Earlier sections of this book explain the benefits of
keeping accurate documentation on all user modifications
to CA MICS. Several suggestions for the form and storage
of such documentation are given.
CA MICS operational job step names are not modified
often, for the reasons listed at the beginning of this
section. If you elect to make such modifications, you
will help ensure your continued satisfaction from product
support incidents by having complete documentation of
your changes at hand when you call.
Copyright © 2014 CA.
All rights reserved.
|
|