This section shows you how to specify the operational
statements that control CA MICS System Reliability Analyzer
processing.
Operational statements are stored in the prefix.MICS.PARMS
cccOPS member, where ccc is the component identifier, and are
incorporated into the CA MICS system by running the
prefix.MICS.CNTL(cccPGEN) job.
*************************************************************
* *
* NOTE: CHANGES to prefix.MICS.PARMS(cccOPS) members *
* REQUIRE EXECUTION of prefix.MICS.CNTL(cccPGEN) *
* to take effect. *
* *
* In addition, any change to parameters that *
* impact the DAILY operational job JCL such as, *
* *
* o changing RESTART NO to RESTART YES, *
* *
* o WORK parameter changes when RESTART NO is in *
* effect, *
* *
* o Specifying TAPEfff (if this product supports *
* a DETAIL level TAPE option), *
* *
* o or changes to prefix.MICS.PARMS(INPUTccc), *
* *
* will require regeneration of the DAILY job by *
* executing prefix.MICS.CNTL(JCLGEND) or by *
* specifying DAILY in prefix.MICS.PARMS(JCLGENU) *
* and executing prefix.MICS.CNTL(JCLGENU). *
* *
* Refer to the checklist (if provided) for updating *
* cccOPS parameters and running required generation *
* jobs. *
*************************************************************
There are three types of information about the LOGREC data
at your installation that you must specify to the System
Reliability Analyzer (SRL).
o The LOGREC data from each System Control Program (SCP)
must be mapped to an SMF system identifier (original
SYSID). This is necessary because the LOGREC data does
not contain this identification and because CA MICS
associates and summarizes the data in the database
according to the computer system producing the data.
The original SYSID can be expressed to CA MICS in more
than one way and is determined by how the LOGREC data
is input to the CA MICS system. The methods for
identifying the original SYSIDs to CA MICS are
discussed later in this section.
o The second type of information to be supplied to
CA MICS is the types of LOGREC data you want recorded
in the CA MICS Database. For instance, do you want to
have CA MICS record data on DASD devices, tape devices,
systems software, user software, etc. The ten
categories of LOGREC data are explained later in this
section.
o CA MICS enables special tracking of jobs and system
modules that are critical to your installation. The
third type of information that you must specify to SRL
is a list of these critical jobs and system modules.
The information for SRLOPS is specified in four types of
statements: OPTIONS, CPUSYSID, CMOD, and CJOB. Each
statement type is described below in detail. Figure 7-2 is
a worksheet to aid in collecting data with which to
complete prefix.MICS.PARMS(SRLOPS). As with most CA MICS
PARMS members, the format of the statements is free-form,
but positional. If a statement is to be coded, then all of
the parameters in that statement must be coded. Comments are
coded by beginning the statement with an '*'. Blank
statements are allowed.
Modify the sample SRLOPS member supplied with the
prefix.MICS.PARMS library distributed with the CA MICS
system rather than code it from scratch. Starting with an
existing, correct specification may spare you annoying
syntax errors. An example SRLOPS member is shown below:
*
* SYSTEM RELIABILITY (SRL) PROCESSING OPTIONS
*
OPTIONS SYSA SRLSYSA 5 WARN SS US PR CH DA MT XR TP DM MM NT
OPTIONS SYSB SRLSYSB 5 ACCEPT SS US PR CH DA MT XR TP DM MM
OPTIONS PSYS SRLPROD 5 ABEND SS US PR CH DA MT XR TP DM MM NT
CPUSYSID PSUB 3090 012345
CPUSYSID PSUB 3090 112345
CPUSYSID PSUB 3090 212345
CPUSYSID PSUB 3090 312345
CPUSYSID CORP 3090 054321
CPUSYSID CORP 3090 154321
CPUSYSID CORP 3090 254321
CPUSYSID CORP 3090 354321
OPTIONS TSYS SRLTEST 5 WARN SS US PR CH DA MT XR TP DM MM NT
CPUSYSID DEVL 3084 034512
CPUSYSID DEVL 3084 134512
CPUSYSID MAIN 3084 234512
CPUSYSID MAIN 3084 334512
CMOD IEFW21SD C INITIATOR/TERMINATOR
CMOD IEFACTRT C SMF ACCOUNTING EXIT
CMOD IEFUJV I SMF JOB VALIDATION EXIT
CMOD IFASMFDP C SMF DUMP UTILITY PROGRAM
CMOD ISTINM01 C VTAM CONTROL PROGRAM
CMOD READPSWD W SYSTEM PASSWORD READING ROUTINE
CJOB JES2 C JOB ENTRY SUBSYSTEM 2
CJOB JES3 C JOB ENTRY SUBSYSTEM 3
CJOB NET C VTAM CONTROL PROGRAM
CJOB HSM C HIERARCHICAL STORAGE MANAGER
SYSTEM DEFINITIONS
OPTIONS Statement
The OPTIONS statement is used to define the ddnames used to
input data so that SRL can logically associate the defined
processing options in SRLOPS with the appropriate input data.
This statement also provides for identifying the types of
LOGREC data to be included in the CA MICS Database. In
conjunction with the CPUSYSID statement, an important
function of the OPTIONS statement is to conditionally provide
an original SYSID (ORGSYSID) to be assigned to the input
data.
At least one OPTIONS statement is required, but you can have
as many as are needed to define each of the ddnames that are
to be used as input to SRL.
The format of the OPTIONS statement is:
OPTIONS sysid ddname gmt action ds1 ds2 ds3 ds4 ... ds11
where the parameters are:
sysid = Original SYSID. This parameter can be used in one
of two ways depending upon whether the OPTIONS
statement is used with associated CPUSYSID
statements. The two uses of this parameter are as
follows.
o If the OPTIONS statement is coded without any
associated CPUSYSID statements, this parameter is
the original SYSID (ORGSYSID) to be assigned to
the input data identified by the ddname. In this
case, it will be assigned to all of the data
processed by the ddname.
o When the associated CPUSYSID statements are coded
along with an OPTIONS statement, then this
parameter becomes the default original SYSID
(ORGSYSID) which will be assigned to any data not
fully identified by the associated CPUSYSID
parameter information.
This parameter is a 1- to 4-character SMF SYSID.
The SYSID must be one of those defined in the
prefix.MICS.PARMS member SYSID, but not every SYSID
defined in the SYSID member must appear here.
ddname = This is the ddname that will be used to input the
LOGREC data for the SYSID specified on the OPTIONS
statement or associated CPUSYSID statements. One
OPTIONS statement is required for each DDNAME that
will be used. All ddnames specified in this
parameter must also appear in the INPUTSRL
specifications in prefix.MICS.PARMS(INPUTSRL).
INPUTSRL is used to supply the actual job control
language to be used to read the LOGREC data into
CA MICS (See Section 7.3.4).
gmt = The Greenwich Mean Time (GMT) offset is required
because LOGREC may use the computer time-of-day
clock in doubleword format to time stamp records
written to the LOGREC data set. The GMT offset must
be specified in whole hours. The Eastern Standard
Time offset is 5 hours. The GMT offset may vary
from +12 to -12 hours.
Note that the GMT offset is changed by daylight
savings time. In order for this value to remain
accurate, you must update the value and run the
SRLPGEN job if you change to or from daylight
savings time.
action = ABEND/ACCEPT/WARN. This parameter is provided as a
precaution against accidental inclusion of data for
an SCP which has not been defined to SRL. It allows
the administrator to determine in advance how SRL
should handle this situation by specifying what
action is to be taken. This parameter takes affect
only when CPUSYSID statements are associated with
the OPTIONS statement. There are three possible
actions which you can have SRL take in this
situation:
ABEND - The DAY070 step of the DAILY job will abend
with a USER abend code of 0998. An
appropriate error message is written to
MICSLOG to explain the abend.
ACCEPT - This specification tells SRL to accept the
data and use the original SYSID specified
in the OPTIONS statement as the default
original SYSID.
WARN - This specification of action tells SRL to
ignore the data but write a message to
MICSLOG indicating that data had been input
to SRL which was not processed.
Since the parameters on the OPTIONS statement are
positional, this parameter must be coded even if
there are no CPUSYSID statements associated with it.
ds_ = Data Selection (ds1 ds2 ds3 ds4 ... ds11). Data
selection options determine the type of LOGREC data
that will be recorded in the CA MICS Database. The
two letter codes cause the data to be selected while
the three letter codes cause the data to NOT be
selected. There are no defaults, so an entry must
be coded for each data selection option.
Each data selection option corresponds to one or
more CA MICS SRL files but does not determine
whether the file(s) will exist in the database.
The code specification simply determines whether or
not data from this ddname is to be written to the
database file(s). For example, if Nxx is selected
for the same data selection option on all of the
OPTIONS statements, then the file will be present in
the database, but will not contain any data. The
data selection codes are:
SS/NSS - Controls the selection of system software
information. The data affected by this
option is the data in the System Software
Diagnostic and System Software Malfunction
Summary Files.
US/NUS - Controls the selection of user software
information. The data affected by this
option is the data in the System Software
Diagnostic and User Software Malfunction
Summary Files.
PR/NPR - Controls the selection of processor and
processor storage information. The data
affected by this option is the data in
the Processor Reliability and Storage
Reliability Files.
CH/NCH - Controls the selection of channel
information. The data affected by this
option is the data contained in the
Channel Reliability File.
DA/NDA - Controls the selection of DASD device
information. The data affected by this
option is the data in the DASD Device
Reliability File.
MT/NMT - Controls the selection of magnetic tape
device information. The data affected by
this option is the data in the Magnetic
Tape Device Reliability File.
XR/NXR - Controls the selection of unit record
device information. The data affected by
this option is the data in the Unit
Record Device Reliability File.
TP/NTP - Controls the selection of teleprocessing
device information. The data affected by
this option is the data in the TP Device
Reliability File.
DM/NDM - Controls the selection of DASD media
information. The data affected by this
option is the data in the DASD Media
Reliability File.
MM/NMM - Controls the selection of magnetic tape
media information. The data affected by
this option is the data in the Magnetic
Tape Media Reliability File.
NT/NNT - Controls the selection of Communications
Controller Reliability Information. The
data affected by this option is the data in
the Communications Controller Reliability
File.
CPUSYSID Statement
The CPUSYSID statement is an optional SRLOPS statement that
provides you with more flexibility in assigning an original
SYSID (ORGSYSID) to LOGREC data. If you code a CPUSYSID
statement, you can make CA MICS SRL process LOGREC data from
more than one SCP and/or CPU using a single ddname by
concatenation. Concatenating more than one SCP allows you
to logically group input data by CPU, processing site, or
other installation grouping requirements. The only
restriction to this grouping capability is that multiple
guests of the same SCP under VM without dedicated
processors cannot be separately identified requiring that
OPTIONS statements be coded to process them via separate
ddnames.
The CPUSYSID statement allows you to identify data for the
assignment of the original SYSID by CPU serial number and
model number. CPUSYSID statements must follow an OPTIONS
statement and are associated with the OPTIONS statement
that they follow. The associated OPTIONS statement contains
the ddname that identifies the data to which the CPUSYSID
statements pertain. The sample SRLOPS member listed above
illustrates how these statements are coded.
The format of the CPUSYSID statement is:
CPUSYSID sysid cpu.model cpu.serial
where the parameters are:
sysid = Original SYSID. This parameter is a 1- to 4-
character SMF SYSID. The SYSID must be one of
those defined in the prefix.MICS.PARMS member
SYSID, but not every SYSID defined in the SYSID
member must appear here. Data in the data
set(s) defined by the ddname of the preceding
OPTIONS statement will be assigned this original
SYSID if the CPU serial and model numbers of the
data match those found in this CPUSYSID
statement.
cpu.model = CPU model number. This parameter identifies
the CPU model number associated with the
original SYSID. It is 1 to 4 digits in length.
cpu.serial = CPU serial number. This parameter identifies
the CPU serial number that is to be associated
with the original SYSID. The serial number
identifies a specific CPU or processor by its 6
hexadecimal character serial number. The serial
number is the number stamped on the frame of the
processor and is the number returned from
executing the instruction 'Store CPU ID'. The
serial number may contain any combination of the
digits 0-9 and the hexadecimal characters A-F.
CRITICAL FUNCTIONS DEFINITION
The LOGREC Exception Reports will track failures of
important system software modules and processing jobs that
you identify in the CMOD and CJOB statements. A default
list of system modules is contained in the
prefix.MICS.PARMS(SRLOPS) member shipped with the CA MICS
system. In addition, you may wish to specify other system
modules that are to be added to this list. You may also
specify the job name of one or more jobs at your
installation which you would like to track in the same
way. The statements for doing this are:
CMOD Statement
Use the CMOD statement to specify system modules. One module
is specified per statement, using the following three
parameters:
MODULE - The program name of the module.
SEVERITY - 'C' for Critical, 'I' for Impacting, or 'W' for
Warning.
DESCRIPTION - A 1- to 38-character description of the
module.
CJOB Statement
Use the CJOB statement to specify processing jobs. One
jobname is specified per statement, using the following three
parameters:
JOB - The job name.
SEVERITY - 'C' for Critical, 'I' for Impacting, or 'W'
for Warning.
DESCRIPTION - A 1- to 38-character description of the job.
The SEVERITY level will be carried in the CA MICS Database
for all software records created from the LOGREC data. Both
CMOD and CJOB will be present in each record and, in addition
to the values of 'C', 'I', and 'W', mentioned above, can have
a default value of blank. The blank CMOD and CJOB values
indicate that the module and jobname were not specified in
the SRLOPS member and therefore will not be tracked.
WORK
----
This statement is optional. It enables sites experiencing
either SAS WORK space allocation problems or out of work
space conditions during DAYnnn or INCRnnn (where nnn is the
job step number), daily or incremental update processing, to
allocate multiple WORK files.
You can allocate multiple WORK files for use during the daily
and/or incremental update job step. The maximum number of
WORK files you can allocate varies by product. These
additional work files are used in conjunction with the single
work data set allocated by default using the JCLDEF
parameters WORKUNIT and WORKSPACE.
Because the individual space allocation requirement for each
WORK file is typically much smaller, it is more likely to be
satisfied.
To take advantage of multiple WORK files support, edit
prefix.MICS.PARMS(cccOPS) and insert a WORK statement as
shown below:
WORK n data_set_allocation_parameters
where n is the number of WORK data sets
data_set_allocation_parameters is one or more data
set allocation parameters (for example, STORCLAS or
SPACE) separated by spaces.
You can also specify the WORK parameter as the following:
WORK n XXX pppp ssss
where:
n is the number of WORK data sets
XXX is TRK or CYL
pppp is the primary allocation
ssss is the secondary allocation
Note: When allocating any number of SAS WORK data sets, be
aware that one additional SAS WORK data set is automatically
allocated to facilitate sorting. For example, if you
allocate six SAS WORK data sets, you will actually get seven.
If you omit the data_set_allocation_parameters or the WORK
parameter, the work data sets are allocated according to the
values you specified for the WORKUNIT and WORKSPACE
parameters in prefix.MICS.PARMS(JCLDEF). Use the
data_set_allocation_parameters to override this default,
either to alter the space allocation or to use System Managed
Storage (SMS) parameters to control data set placement and
characteristics.
Note: If you allocate insufficient space for the WORK data
sets, DAYnnn and/or INCRnnn processing will fail and can only
be restarted from the beginning.
Note: If internal step restart is active, you can override
the WORK data set allocation parameters at execution-time
using the //PARMOVRD facility. For more information about
execution-time override of dynamic data set allocation
parameters, see the PIOM, section 2.3.6.
Specify data set allocation parameters, separated by blanks,
according to SAS LIBNAME statement syntax. If you need
multiple lines, repeat the WORK keyword on the continuation
line.
WORK accepts the engine/host options documented in the SAS
Companion for the z/OS environment, including STORCLAS, UNIT,
SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and VOLSER.
Important! Do not specify the DISP parameter.
Example 1:
WORK n STORCLAS=MICSTEMP SPACE=(XXX,(pppp,ssss),RLSE)
where:
n - is the number of WORK data sets.
STORCLAS - specifies a storage class for a new data set.
The name can have up to 8 characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
XXX - is TRK or CYL.
pppp - is the primary allocation.
ssss - is the secondary allocation.
RLSE - specifies that free-space should be released
when the data set is closed.
Example 2:
WORK n XXX pppp ssss
where:
n - is the number of WORK data sets.
XXX - is TRK or CYL.
pppp - is the primary allocation.
ssss - is the secondary allocation.
Example 3 (multiple lines):
WORK n STORCLAS=MICSTEMP UNIT=SYSDA
WORK SPACE=(xxxx,(pppp,ssss),,,ROUND))
where:
n - is the number of WORK data sets.
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
XXX - is TRK or CYL.
pppp - is the primary allocation.
ssss - is the secondary allocation.
Note: Since there is some performance impact when using
multiple WORK files, you should specify the minimum number of
WORK data sets to meet your work space requirements. As a
start, try incrementing the number gradually beginning from
the default.
WORK Considerations
--------------------
How Much Space Should You Allocate?
o First Time Implementation of Multiple Work Files
If this is the first time you are implementing multiple
work files for this product in this unit, review
prefix.MICS.PARMS(JCLDEF) and find the WORKSPACE
parameter. It will resemble this sample statement:
WORKSPACE TRK 500 250
The value shows the current SAS WORK space allocation for
the unit as a single data set. It also serves as the
default value used in the unit's DAYnnn daily update
(and/or INCRnnn incremental update) step unless you
provide a WORK parameter.
To achieve the equivalent work space allocation of
WORKSPACE TRK 500 250 using multiple WORK data sets that
will collectively share the work space requirements of
the daily and/or incremental update step, you could code
either one of these:
WORK 2 SPACE=(TRK,(250,125))
WORK 5 SPACE=(TRK,(100,50))
To determine the total work space, multiply the number of
WORK files (n) by the primary (pppp) and secondary (ssss)
values specified.
Note: To simplify the example, only the SPACE parameter
is shown above. You can follow either with data set
allocation parameters like UNIT or STORCLAS as required
for your site.
o Adjusting Allocation for Existing Multiple WORK Files
If you have previously implemented multiple WORK file
support for this product in this unit, and you want to
change either the number of WORK files or the space
allocations, examine prefix.MICS.PARMS(cccOPS) and find
the existing WORK statement.
- If the existing WORK statement only specifies the
number of WORK files but does not contain space
allocation information as shown below:
WORK 5
Then each of the multiple WORK files is allocated
using the values from the WORKSPACE parameter of
prefix.MICS.PARMS(JCLDEF), as described earlier under
First Time Implementation of Multiple Work Files.
To increase workspace, you can increase the number of
WORK files (for example, change WORK 5 to WORK 6,7,8,
or 9), increase the space allocation in the WORKSPACE
parameter, or do both.
To decrease workspace, you can decrease the number of
WORK files (for example, change WORK 5 to WORK 4,3,2,
or 1), decrease the space allocation in the WORKSPACE
parameter, or do both.
You can also elect to explicitly specify the multiple
WORK file space allocation by adding the space
allocation values directly to the WORK statement. This
will remove the link to the prefix.MICS.PARMS(JCLDEF)
WORKSPACE parameter for multiple WORK file space
allocation. This is recommended as it serves to
clearly document, in one place, how multiple WORK files
are allocated.
- If the existing WORK statement does include space
allocation as shown in the examples below:
WORK 5 TRK 200 100
or
WORK 5 SPACE=(TRK,(200,100)) STORCLAS=MICSTEMP
Simply change the values to meet your needs.
If you need more work space, you can increase the
number of WORK files (for example, change WORK 5 to
WORK 6,7,8, or 9), increase the space allocation (for
example, change TRK 200 100 to TRK 250 120), or do
both.
To decrease work space, you can decrease the number of
WORK files (for example, change WORK 5 to WORK 4,3,2,
or 1), decrease the space allocation (for example,
change TRK 200 100 to TRK 150 80), or do both.
Note: If internal step restart is NOT active (RESTART NO)
and you change the WORK parameter, you must:
o Run cccPGEN
o Run JCLGENU for DAILY (to regenerate DAILY) and, if
incremental update is enabled, INCRccc
When internal step restart is active, (RESTART YES), then,
when you change WORK and run cccPGEN, changes take effect
immediately. There is no need to run JCLGENU.
SASWORK
-------
This statement is optional.
The WORK DD statement in the CA MICS procedures allocates
a temporary data set where SAS keeps its temporary data
files and other items that SAS uses during processing of
the current job.
By default, the space allocated is defined in the member
prefix.MICS.PARMS(JCLDEF) with the WORKSPACE and WORKUNIT
parameters, then generated into all the JCL procedures for
a given unit.
With the SASWORK statement you have the option to override
this unit-wide definition to specify the space allocation
individually for the current step.
The format of the SASWORK statement is:
SASWORK data_set_allocation_parameters
where data_set_allocation_parameters is one or more data set
allocation parameters (for example, STORCLAS or SPACE)
separated by spaces.
You can also specify the SASWORK parameter as the following:
SASWORK XXX pppp ssss
where:
XXX is TRK or CYL
pppp is the primary allocation
ssss is the secondary allocation
If you omit the data_set_allocation_parameters or the SASWORK
statement, the WORK data set is allocated according to the
values you specified for the WORKUNIT and WORKSPACE
parameters in prefix.MICS.PARMS(JCLDEF). Use the
data_set_allocation_parameters to override this default,
either to alter the space allocation or to use System Managed
Storage (SMS) parameters to control data set placement and
characteristics.
Specify data set allocation parameters, separated by blanks,
according to SAS LIBNAME statement syntax. If you need
multiple lines, repeat the SASWORK keyword on the
continuation line.
Example:
SASWORK STORCLAS=MICSTEMP SPACE=(XXX,(pppp,ssss))
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to 8 characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
XXX - is TRK or CYL.
pppp - is the primary allocation.
ssss - is the secondary allocation.
Note: If you change the SASWORK parameter, you must:
o Run cccPGEN
o Run JCLGENU for DAILY (to regenerate DAILY) and, if
incremental update is enabled, INCRccc
MULTWORK|NOMULT fff fff ... fff
-------------------------------
Since multiple work files usage impacts performance, this
product provides these optional parameters so you can
restrict multiple work files usage to only those files having
excessive space requirements.
Note: You can only use one of these optional parameters with
the WORK statement, NOT both.
The MULTWORK parameter restricts the use of multiple WORK
files to ONLY those listed after the MULTWORK keyword.
MULTWORK fff fff ... fff
where fff is the unique three character identifier
If you need multiple lines, repeat the MULTWORK on the
continuation line.
The NOMULT parameter forces the use of multiple WORK files
for all files EXCEPT those specified after the NOMULT
keyword.
NOMULT fff fff ... fff
where fff is the unique three character identifier
If you need multiple lines, repeat the NOMULT on the
continuation line.
NOTE: The default is zero (0).
The maximum is nine (9).
The default is
MULTWORK _UD _UM CRL DMR DRL MMR MRL PRL RNC STR SSD SSM
MULTWORK TRL XRL NTC
if neither MULTWORK or NOMULT parameters are specified.
The following files are eligible for multiple WORK support.
SRL System Reliability Information Area Files
_UD User Software Diagnostic File
_UM User Software Malfunction Summary
CRL Channel Reliability File
DMR DASD Media Reliability
DRL DASD Device Reliability File
MMR Mag. Tape Media Reliability
MRL Mag. Tape Device Reliability
PRL Processor Reliability File
RNC Reliability Incident File
STR Storage Reliability File
SSD System Software Diagnostic File
SSM System Software Malfunction Summary
TRL TP Device Reliability
XRL Unit Record Device Reliability
NTC Communications Controller Rel. File
RESTART YES/NO
--------------
This statement is optional. Specify this to activate
internal step restart for this product's DAILY and/or INCRccc
database update job steps:
RESTART YES
If you do not specify or enable the RESTART parameter, then
this option defaults to the following and internal step
restart is disabled:
RESTART NO
*************************************************************
* *
* Note: Changing the RESTART parameter (either from NO *
* to YES or from YES to NO) requires regeneration *
* of the DAILY operational job by executing *
* prefix.MICS.CNTL(JCLGEND) or by specifying *
* DAILY in prefix.MICS.PARMS(JCLGENU) and *
* executing prefix.MICS.CNTL(JCLGENU). *
* *
* If incremental update is active for this product, *
* you must also regenerate the INCRccc job. *
* *
*************************************************************
Internal step restart can significantly reduce time and
resource usage to recover from daily and/or incremental
update processing failures. CA MICS uses a
checkpoint/restart technique.
o When internal step restart is activated, the database
update job step "checkpoints" (or saves) intermediate
results (work file contents) and the operational
environment at the end of each processing phase.
o Then, if required, the database update step can resume
execution at the beginning of the processing phase in
which the failure occurred.
o Restart is accomplished by restoring the operational
environment from the last checkpoint, bypassing completed
processing phases, and resuming execution using
intermediate results (work files) from the last
checkpoint.
Note: When you activate internal step restart (RESTART YES),
the following optional restart parameters are enabled.
These parameters have no effect if restart is disabled
(RESTART NO). For more details, see the individual
parameter descriptions later in this section.
o RESTARTCKPT data_set_allocation_parameters
o RESTARTWORK data_set_allocation_parameters
o DYNAMWAIT minutes
Processing Phases:
------------------
This product employs two database update processing phases
followed by the two common roll-up phases.
Phase Description
------------- ------------------------------------------
FORMAT Read raw input data, convert to SAS
format, and output to intermediate work
files.
DBUPDATE Sort intermediate work file contents,
eliminate duplicate input data, prepare
for DETAIL cycle creation, merge data
across optional multiple work files,
enhance data content, and create the new
DETAIL cycle.
DYSUM Summarize DETAIL data to create new DAYS
cycles and to update current week-to-date
and month-to-date cycles.
DYAGE Cutover new database cycles to production
and "age" existing cycles.
RESTART Considerations
----------------------
o Overhead
Enabling internal step restart adds some overhead to the
database update job step -- the cost of taking
checkpoints and managing saved materials. Since this
overhead is relatively constant and independent of input
data volume, you may find that costs outweigh potential
savings when input data volume is low, for example in a
test unit. For high volume, production units, internal
step restart support overhead should be a minor portion
of total resource usage.
o Cataloged Work Files
When internal step restart is enabled, the SAS work data
set, internal step restart control data set, and multiple
work file data sets are allocated and cataloged with
permanent dataset names so they will be retained for use
in restart if the step abends. These data sets are
deleted when the step completes successfully.
Prior to enabling internal step restart support, these
data sets were probably allocated on system "scratch"
space with a temporary, system assigned data set names.
If your installation standards do not allow "permanent"
data sets on DASD volumes used for temporary work space,
you may need to use the WORK, RESTARTCKPT, and
RESTARTWORK parameters to direct the internal step
restart data sets to a generic unit or storage class that
allows cataloged data sets.
o Dynamic Allocation
When internal step restart is active, dynamic allocation
is employed for the work data sets. If your installation
restricts dynamic allocation of large, cataloged data
sets, you may need to use the WORK, RESTARTCKPT, and
RESTARTWORK parameters to direct work data set allocation
to a generic unit or storage class where dynamic
allocation is allowed.
o Data Set Names
The SAS work data set, internal step restart control data
set, and multiple work file data sets are allocated and
cataloged according to the standard CA MICS unit database
data set name conventions. The default DDNAME and data
set names are:
o SAS work data set,
//cccXWORK DD DSN=prefix.MICS.cccXWORK,.....
o Internal step restart control data set,
//cccXCKPT DD DSN=prefix.MICS.cccXCKPT,.....
o Multiple work file data sets,
//WORKnn DD DSN=prefix.MICS.cccWRKnn,.....
Since these data sets conform to the same data set name
conventions as your existing CA MICS data sets, there
should be few, if any, data set name related allocation
issues. However, it is possible to override the data set
names if required. Please contact CA MICS Product
Support for assistance if you must alter data set names.
RESTARTCKPT
-----------
This statement is optional. Specify the following to
override default data set allocation parameters for the
internal step restart checkpoint data set:
RESTARTCKPT data_set_allocation_parameters
Note: RESTARTCKPT is ignored when you specify RESTART NO.
The internal step restart checkpoint data set (or cccXCKPT
data set) contains processing status, control, and SAS
environmental information for internal step restart
processing checkpoints. This includes a copy of the SAS WORK
format and macro catalogs, current macro variable values, and
a description of work files that may be needed to restart
DAYnnn processing.
By default, the cccXCKPT data set is allocated according to
the values you specified for the WORKUNIT and WORKSPACE
parameters in prefix.MICS.PARMS(JCLDEF). Specify RESTARTCKPT
to override this default, either to alter the space
allocation or to use System Managed Storage (SMS) parameters
to control data set placement and characteristics.
Note: If you allocate insufficient space for the cccXCKPT
data set, DAYnnn processing will fail and can only be
restarted from the beginning.
Note: You can override the RESTARTCKPT data set allocation
parameters at execution-time using the //PARMOVRD facility.
For more information about execution-time override of dynamic
data set allocation parameters, see the PIOM, section 2.3.6.
Specify data set allocation parameters, separated by blanks,
according to SAS LIBNAME statement syntax. If you need
multiple lines, repeat the RESTARTCKPT keyword on the
continuation line.
RESTARTCKPT accepts the engine/host options documented in the
SAS Companion for the z/OS Environment, including STORCLAS,
UNIT, SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and VOLSER.
Important! DO NOT SPECIFY THE DISP PARAMETER.
Example 1:
RESTARTCKPT STORCLAS=MICSTEMP SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated, where:
xxxx is TRK, CYL, or blklen
pp is the primary allocation
ss is the secondary allocation
and ROUND specifies that the allocated space be
"rounded" to a cylinder boundary when the unit
specified was a block length. ROUND is ignored
with the TRK or CYL options.
Example 2 (multiple lines):
RESTARTCKPT STORCLAS=MICSTEMP UNIT=SYSDA
RESTARTCKPT SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
RESTARTWORK
-----------
This statement is optional. Specify the following to
override default data set allocation parameters for the
internal step restart WORK data set:
RESTARTWORK data_set_allocation_parameters
Note: RESTARTWORK is ignored when you specify RESTART NO.
The internal step restart WORK data set (or cccXWORK data
set) contains the intermediate work files that are not
enabled to multiple work file support, including those files
you may have specified on the optional NOMULT statement.
By default, the cccXWORK data set is allocated according to
the values you specified for the WORKUNIT and WORKSPACE
parameters in prefix.MICS.PARMS(JCLDEF). Specify RESTARTWORK
to override this default, either to alter the space
allocation or to use System Managed Storage (SMS) parameters
to control data set placement and characteristics.
Note: If you allocate insufficient space for the cccXWORK
data set, DAYnnn processing will fail and can only be
restarted from the beginning.
Note: You can override the RESTARTWORK data set allocation
parameters at execution-time using the //PARMOVRD facility.
For more information about execution-time override of dynamic
data set allocation parameters, see the PIOM, section 2.3.6.
Specify data set allocation parameters, separated by blanks,
according to SAS LIBNAME statement syntax. If you need
multiple lines, repeat the RESTARTWORK keyword on the
continuation line.
RESTARTWORK accepts the engine/host options documented in
"SAS Companion for the z/OS Environment", including STORCLAS,
UNIT, SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and VOLSER.
Important! DO NOT SPECIFY THE DISP PARAMETER.
Example 1:
RESTARTWORK STORCLAS=MICSTEMP SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated, where:
xxxx is TRK, CYL, or blklen
pp is the primary allocation
ss is the secondary allocation
and ROUND specifies that the allocated space be
"rounded" to a cylinder boundary when the unit
specified was a block length. ROUND is ignored
with the TRK or CYL options.
Example 2 (multiple lines):
RESTARTWORK STORCLAS=MICSTEMP UNIT=SYSDA
RESTARTWORK SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to 8 characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
DYNAMWAIT
---------
This statement is optional. Specify the following:
DYNAMWAIT minutes
to override the default amount of time, in minutes, the DAILY
and/or INCRccc job will wait for an unavailable data set.
Note: This optional parameter is not normally specified.
The system default is adequate for most data centers.
Internal Step Restart and Incremental Update facilities use
z/OS dynamic allocation services to create new data sets and
to access existing data sets. Data set naming conventions
and internal program structure are designed to minimize data
set contention. However, if data set allocation does fail
because another batch job or online user is already using a
data set, DAILY and/or INCRccc processing will wait 15
seconds and then try the allocation again. By default, the
allocation will be attempted every 15 seconds for up to 15
minutes. After 15 minutes, the DAILY or INCRccc job will
abort.
If data set contention in your data center does cause
frequent DAILY or INCRccc job failures, and you are unable to
resolve the contention through scheduling changes, you may
want to use the DYNAMWAIT parameter to increase the maximum
number of minutes the DAILY and/or INCRccc jobs will wait for
the data set to become available.
On the other hand, if your data center standards require
that the DAILY and/or INCRccc jobs fail immediately if
required data sets are unavailable, specify the following:
DYNAMWAIT 0
Note: You can override the DYNAMWAIT parameter at
execution-time using the //PARMOVRD facility. For
more information about execution-time override of
dynamic data set allocation parameters, see the PIOM,
section 2.3.6.
+--------------------------------------------------------------------------------+ | INSTALLATION PREPARATION WORKSHEET: System Reliability Options | | | | PARMS Library Member is SRLOPS | | Reference Sections: 7.3.2 | +--------------------------------------------------------------------------------+ | | SYSTEM DEFINITIONS--> | ABEND | | Orig GMT ACCEPT SS US PR CH DA MT XR TP DM MM | One OPTIONS statement is | SYSID DDNAME OFF WARN NSS NUS NPR NCH NDA NMT NXR NTP NDM NMM | required for each ddname | | included in INPUTSRL. One| OPTIONS ____ ________ ___ ______ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ | or more optional CPUSYSID | | statements follow the | Orig CPU CPU | OPTIONS statement if data | SYSID Model Serial | for more than one CPU | | or SCP is included in the | CPUSYSID ____ ____ ______ | data sets(s) which make up| CPUSYSID ____ ____ ______ | the ddname on the OPTIONS | | statement. | OPTIONS ____ ________ ___ ______ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ | | | | CPUSYSID ____ ____ ______ | | CPUSYSID ____ ____ ______ | | | | | CRITICAL FUNCTIONS---> | | | SYSTEM MODULES | One statement per module | | that the user has selected| MODULE SEVERITY DESCRIPTION | for special tracking. | | | CMOD ________ _ ______________________________________ | | CMOD ________ _ ______________________________________ | | CMOD ________ _ ______________________________________ | | CMOD ________ _ ______________________________________ | | CMOD ________ _ ______________________________________ | | | | |
| PROCESSING JOB | One statement per job | | that the user has selected| JOB SEVERITY DESCRIPTION | for special tracking. | | | CJOB ________ _ ______________________________________ | | CJOB ________ _ ______________________________________ | | CJOB ________ _ ______________________________________ | | CJOB ________ _ ______________________________________ | | CJOB ________ _ ______________________________________ | | | | WORK n data_set_allocation_parameters | | | | MULTWORK|NOMULT fff ... fff | | | | RESTART YES/NO | | | | INCRUPDATE YES/NO | | INCRDB PERM/TAPE/DYNAM | | INCRDETAIL data_set_allocation_parameters | | | +--------------------------------------------------------------------------------+ | ....5...10...15...20...25...30...35...40...45...50...55...60...65...70.. | +--------------------------------------------------------------------------------+
|
Copyright © 2014 CA.
All rights reserved.
|
|