4. CA MICS Facilities › 4.3 User Exit Facilities › 4.3.2 Types of CA MICS Exits › 4.3.2.1 General Operational Exits
4.3.2.1 General Operational Exits
Exits that apply to any or all installed components within
CA MICS can be used to add logic for selecting records,
extend checkpoint manipulation, rearrange operational jobs,
expand ZONE capabilities definition, etc.
These exits are part of the CA MICS Platform (BAS) and are
located in sharedprefix.MICS.SOURCE(#BASEXIT). The exits
are:
Exit Name: _USRSEL
Purpose: Perform input record selection in DAILY job.
Method: The macro is referenced in code that processes
input data. The routines are daily component
format routines and the CA MICS input reader.
Before invocation, the program variable SKIP_REC
is set to a value of zero. If the exit sets this
variable to a value of one, the calling routine
will bypass the current input record and go to
read the next record.
Because this exit is used in many places, it is
necessary to qualify all coding in this exit by
examining the name of the routine in which the
exit was invoked. The program variable ROUTINE
exists for this purpose. ROUTINE is an 8-byte SAS
character variable containing the name of the
invoking module in the DAILY update.
A typical implementation of this method follows.
MACRO _USRSEL
IF ROUTINE = 'INPUTRDR' THEN DO;
(exit code here)
END;
ELSE IF ROUTINE = 'DYIMSFMT' THEN DO;
(exit code here)
END;
%
Typical This macro can be used to remove unwanted data
Use: from CA MICS processing. For example, there is a
site with three CPUs logging to SMF. One of the
CPUs is normally dedicated to IMS; the SMF data is
not to be processed by CA MICS, and that CPU's
original SMF SYSID is not defined to CA MICS. If
SMF data from that system is ever input to CA
MICS, the CA MICS daily job will ABEND with a user
310 SAS ABORT ABEND when the UNDEFINEDSYSID
control parameter is set to ABORT, indicating that
CA MICS does not know what to do with the data.
If it is not practical to remove the data from the
input file defined in the INPUTSMF DD
concatenation or to use the UNDEFINEDSYSID control
parameter, you can code a _USRSEL exit to delete
the records. The following coding sample
illustrates this approach:
MACRO _USRSEL
IF ROUTINE = 'INPUTRDR' THEN DO;
IF ORGSYSID = 'CPU1' THEN DO;
SKIP_REC = 1; /* SKIP CPU1 RECORDS */
END;
END;
%
This macro can also be used to output SMF records
to the prefix.MICS.USER.DATA in the DAYSMF step.
Input records are stored in this file when the
element USERFILE is set to a value of "1" in the
_USRSEL exit. This file is allocated in the
DAYSMF step with DISP=OLD for output processing
and it is again allocated in the DAY500 step for
any user-defined processing, such as report
generation or user data collection.
The following coding sample illustrates how you
could output user SMF record type 299 to the USER
DATA file for processing by your own code in the
DAY500 step.
MACRO _USRSEL
IF ROUTINE = 'INPUTRDR' THEN DO;
IF SMFRTYPE EQ 299 THEN USERFILE = 1;
END;
%
Invoked Locations: This macro is referenced directly in the
following locations:
ROUTINE='INPUTRDR', DAILY job step DAYSMF
Reference sharedprefix.MICS.SOURCE(INPUTRDR)
ROUTINE='DYcccFMT', DAILY job step DAYsss
(where ccc is the component identifier of a
CA MICS product or a user component, and sss is
the step of the DAILY job coded on the COMP
statement in sharedprefix.MICS.GENLIB(cccGENIN))
NOTE: DYcccFMT processing is defined in one
or more similarly-named members of
sharedprefix.MICS.SOURCE.
Exit Name: _USRIHL
Purpose: Examine input history log
Method: The macro is referenced in code that passes the
DETAIL timespan checkpoint SAS file. This code
reads &ADMX..CKPTDATA as an integrity check on
that file, and in the process allows you to
inspect the file's contents.
Typical This macro can be used to abort daily update
Use: cycles based on an extended checkpoint examination
algorithm. For example, the daily CICS format
routine would end normally if data from at least
one CICS system were successfully processed.
However, you may not want the database to be
updated if CA MICS has not processed data from the
production CICS system. This exit could be used
to examine all the entries in &ADMX..CKPTDATA to
look for the CICS production system. If no data
has been found, the user exit code could execute a
SAS ABORT ABEND statement, stopping the CICS daily
update until the correct input data is available.
NOTE: If you code a user exit abend, it is your
responsibility to document the abend
condition and its correction for your
operations or quality control group.
Invoked Locations: This exit macro is referenced by the
checkpoint macro CKRTN4. CKRTN4 is a Macro
statement called _CKRTN4 located in:
sharedprefix.MICS.SOURCE(#CHECKPT)
and a Macro language macro in:
sharedprefix.MICS.MACAUTOS(CKRTN4)
The CKRTN4 macro is referenced by the DAILY job
steps for each component.
The following coding example illustrates how you
could ensure that at least 10 records from both
the production and test CICS regions were kept.
The element names to use with this exit can be
identified by doing a SAS PROC CONTENTS on the
DETAIL file CKPTDATA.
MACRO _USRIHL
IF ROUTINE EQ 'DYCICFMT' THEN DO;
RETAIN CICP CICT;
IF COMPT EQ 'CIC CICP' AND
KEPT GE 10 THEN CICP = 1;
IF COMPT EQ 'CIC CICT' AND
KEPT GE 10 THEN CICT = 1;
IF EOF THEN DO;
FILE PRINT;
IF (NOT CICT) THEN
PUT "INSUFFICIENT DATA FOR TEST REGION" /
"DAILY UPDATE RUN ABORTED";
IF (NOT CICP) THEN
PUT "INSUFFICIENT DATA FOR PROD REGION" /
"DAILY UPDATE RUN ABORTED";
IF NOT (CICP AND CICT) THEN ABORT ABEND;
END;
END;
%
Exit Name: _USRSPC
Purpose: Perform data selection and element manipulation
to the ADMSPC file.
Method: The macro is referenced prior to the output of
observations to the ADMSPC file. This exit starts
with a "%MACRO" statement and ends with a "%MEND"
statement. The exit is invoked as %USRSPC.
A typical implementation of this method follows.
%MACRO USRSPC;
IF SPCSTEP = 'DAY030' THEN DO;
(exit code here)
END;
%MEND USRSPC;
Typical This macro can be used to remove unwanted data
Use: from the ADMSPC file or alter data element
content. If the exit sets the program variable
SKIP_REC to a value of one, the current
observations will not be written to the ADMSPC
file. While the ADMSPC file is a spin file, only
new observations are presented to the USRSPC exit.
Existing observations in the ADMSPC file are not
affected.
To confine your exit code to a particular step,
test on the SPCSTEP data element, which will
contain the step name of the CA MICS operational
job step that is currently executing. The ADMSPC
file is updated in the DAILY and Incremental
Update job steps.
Invoked Locations: This exit macro is referenced by the
CA MICS run status report program, located in:
sharedprefix.MICS.SOURCE(RSTATUS)
Exit Name: _USRSTEP
Purpose: Provide user step name for restart messages
Method: The macro is referenced in code that prints the
restart message on the CA MICS run status report.
See the CA MICS PIOM, Sections 4.3 and 4.3.1, for
information on the content and use of the report.
Typical This macro can be used to ammend the restart
Use: instructions given by the CA MICS Run Status
Report. Refer to the OS Step Names information in
Chapter 2 of the Planning, Installation,
Operation, and Maintenance Guide for information
on using Generation Control Language to change
CA MICS operational job step names, including
instructions for coding this exit.
Invoked Locations: This exit macro is referenced by the
CA MICS run status report program, located in:
sharedprefix.MICS.SOURCE(RSTATUS)
Exit Name: USRZONE
Purpose: Override or expand ZONE definition options
Method: The macro is referenced in code that sets ZONE
values. This is a SAS version 6 (and above) style
macro which starts with a "%MACRO" statement and
ends with a "%MEND" statement. The exit is
invoked as %USRZONE.
Typical This macro can be used to alter or augment ZONE
Use: values. ENDTS (End Time Stamp), ZONE, HOUR and
SYSID are available at the point of invocation.
Great care must be exercised in using this
facility as misuse can corrupt the database,
increase DASD space requirements, and/or impact
chargeback or capacity planning activities as
noted below:
o Standard CA MICS ZONE definitions are based on
hour boundaries, for example 8 AM to 5 PM
Monday through Friday. Some organizations may
feel that they need to define CA MICS ZONEs
according to a work schedule based on 30 minute
or 15 minute boundaries. The %USRZONE exit may
be used to redefine the CA MICS ZONE on
sub-hour boundaries per the value of
TIMEPART(ENDTS). However, be aware of the
following issues/considerations:
- Defining ZONE on a sub-hour boundary
requires that ZONE be added as a
sequence/summary control element for the
DAYS timespan in each and every CA MICS
file. ZONE is not normally a
sequence/summary element at the DAYS
timespan because the standard ZONE
definition ensures that all records for a
YEAR, MONTH, DAY, and HOUR are assigned to
the same ZONE. But, if you redefine ZONE on
a sub-hour basis (without adding ZONE to the
summarization key), data in the DAYS
timespan will contain corrupted ZONE values
because some DAYS time span records will
contain composite records for an HOUR which
at the DETAIL timespan reflected more than
one ZONE. Data in the WEEKS and MONTHS
timespans (which is summarized by ZONE),
will also be corrupt since the MONTHS
timespan is derived from the DAYS timespan
data (when DAYS is active).
- Defining ZONE on a sub-hour boundary (along
with appropriate DAYS timespan summary key
updates) will enlarge the CA MICS database.
For example, the standard DAYS timespan
cycle contains 24 observations for each
SYSID -- one for each hour. However, with a
sub-hour ZONE definition, there will be two
observations in the database for those hours
that cross the ZONE definition boundary.
Likewise, since the WEEKS timespan is
summarized by ZONE and HOUR, additional
observations will appear in WEEKS timespan
files.
o Some organizations may have structured their
workloads such that the "prime shift" period
varies by SYSID. For example, if one LPAR
processes internal production activities such
as accounts receivable, shipping, etc., with a
normal 8 to 5 prime shift, while another LPAR
is dedicated primarily to the company's WEB
server for direct customer order and inquiry
where peak workloads arrive after 6 PM, then
different ZONE structures may be appropriate.
This requirement can be addressed by splitting
data for these different functional systems
into individual CA MICS unit databases, where
each can have a unique ZONE definition. Or, if
data for these unique systems is maintained in
a single unit database, the ZONE definition
could be structured with unique ZONE values for
each of the "prime shift" periods (e.g., ZONE 1
is 8 to 5, ZONE 2 is 6 PM to midnight, ZONE 3
is the 5:00 hour, etc. An alternative is to
use the %USRZONE exit facility to define ZONE
1 uniquely by SYSID. However, this may lead to
problems and/or confusion in reporting and
analysis. For example, attempting to report
grand total workload (say for financial
planning) for the day time period by selecting
data for ZONE 1 will actually combine data from
two separate time periods. Likewise, activity
graphs by HOUR may report unexpected workload
gaps if ZONE is included in data selection
criteria.
Invoked Locations: This exit macro is referenced by the
code that sets ZONE values and is located in:
sharedprefix.MICS.MACAUTOS(ZONE)
The %ZONE macro is referenced by the DAILY job
steps for each component. It may also be invoked
at other locations where processing routines
compute or re-compute the ZONE value.
