Customer notices that some of their reports
for billing processes are showing incorrect
ACCTNOx values for some jobs in the step level
files. This can happen if ACCTRTE makes ACCTNOx
assignments based on SYSID value.
The problem can occur because the SMF component
considers an address space to be based on a unique
value of job name (JOB) and Reader Time Stamp (RDRTS).
RDRTS has a granularity of 1/100th of a second.
It is possible for multiple jobs, that have the same
job name to be submitted to JES for execution in
the same 1/100th of a second.
These jobs will have different JES Job Numbers
(JESJOBNO), but the SMF component does not use
JESJOBNO when determining which records are
associated with an address space.
The SMF component account routine (sp.PARMS(ACCTRTE))
is entered one time for each address space.
ACCTRTE assigns ACCTNOx values that are used for
all observations that are written to the various
database files (BATPGM, BAT_TS, BAT_ST, BAT_TP,
BAT_OE, BAT_SA, BATSPL, BATJOB, etc.) for that
address space.
When the ACCTRTE uses SYSID to assign one or more
of the ACCTNOx values, and there are multiple
jobs with an identical JOB and RDRTS values,
the ACCTNOx values will be assigned based on the
first record that the ACCTRTE encounters.
This can create some confusion when the two
jobs that have identical JOB and RDRTS values
ran on different systems.
The SMF component has several different
records to examine when it is determing what
value to use for SYSID. The preferred record
is the job end record (SMF type 30 subtype 5).
In the case discussed here, there will be two
or more of these job end records, but only one
of them will be "first"--and the SYSID value
value selected by the code logic will be
incorrect for the step records for one of the
jobs.
At the point where records are written to the
step level files, the SYSID value assigned to
the step level file is the system where the
step executed. (The logic saves the "address
space level" SYSID value initially determined,
and substitutes the value where the step actually
executed, writes the step level observation, then
restores the job level SYSID that will be used
when the BATJOB file observations is written.
In the case where two jobs have the same JOB
and RDRTS, the step level observations will all
have the correct value for SYSID--showing where
the step executed.
But any ACCTNOx values that were based on the
SYSID value, in the same observations, will
be correct in the step observations for the steps
from one of the jobs, but not for the other.
Release: MICSAC00200-12.9-MICS-Resource Management-Accounting and Chargeback Opt
Component:
There is good information in the SMF component guide in chapter 7
that discusses step level accounting. Section 7.2.2.2
Step-Level Account Code Specification. The discussion there is focused
on using step level accounting fields, and is rather involved.
In the simple case where the customer wants to override any
ACCTNOx values that are based on the SYSID where the step executed,
that are incorrect because of the "two jobs with the same RDRTS and
JOB Name issue", it can be easily accomplished as shown below.
You do have opportunities to use the USRSPGM exit to override the ACCTNO1 value for
each step record, as it is written, based on the SYSID value for each step record.
You could do this by adding your cascading IF statement to the USRSPGM exit like this.
It is best to do this in your unit level USER.SOURCE library in prefix.MICS.USER.SOURCE(#SMFEXIT).
The module looks like this:
/* MICS6
/*-----------------------------------------------------------------*/
/* (C) COPYRIGHT, 1992 LEGENT SOFTWARE, INC. ALL RIGHTS RESERVED. */
/*-----------------------------------------------------------------*/
/* CHANGE | PROBLEM|MMYY|VENDOR CHANGE DESCRIPTION */
/*--------+--------+----+------------------------------------------*/
/* SMF6000| |0792|MICS6 INITIAL RELEASE, MICS6.0 */
/*-----------------------------------------------------------------*/
/* CHANGE |MMYY|USER CHANGE DESCRIPTION */
/*--------+----+---------------------------------------------------*/
/*-----------------------------------------------------------------*/
/* */
%INCLUDE SOURCE(#SMFEXIT);
What you would do is to redefine the _USRSPGM MACRO that is already defined in sp.SOURCE(#SMFEXIT).
You would redefine it like this:
* MICS6
...
... code from prefix.USER.SOURCE(#SMFEXIT)
....
...
%INCLUDE SOURCE(#SMFEXIT);
/* code added to ensure ACCTONO1 is correct in step level records */
MACRO _USRSPGM
/* BATCH PROGRAM FILE OUTPUT EXIT */
IF SYSID='GENB' THEN ACCTNO1='GENWORTH';
ELSE IF SYSID='GEN6' THEN ACCTNO1='GENWORTH';
ELSE IF SYSID='GE1H' THEN ACCTNO1='SUNLIGHT';
ELSE IF SYSID='ICON' THEN ACCTNO1='UI ';
ELSE IF SYSID='NIKE' THEN ACCTNO1='NIKE ';
ELSE IF SYSID='NIKP' THEN ACCTNO1='NIKE ';
ELSE ACCTNO1 = 'OTHER';
_USRUPGM
_USRUJBP
%
This update would only impact ACCTNO1 values for the BATJOB, BAT_TS, BAT_ST, and other step level files.
In the BATJOB file, you would have a single record for these two jobs—where all 12 steps are “summed”
to the job level, and one SYSID value and the ACCTNO1 value for thathat SYSID.
Until we update DAY030 to differentiate by JESJOBNO, BATJOB will still see these two jobs as a single job.
Make sure you examine your sharedprefix.MICS.SOURCE(#SMFEXIT) and find the _USRSPGM MACRO definition.
It is possible that you already have some code in this exit that is doing something to the step level file observations.
If you want to redefine the exit at the unit level, in prefix.MICS.USER.SOURCE (#SMFEXIT), as shown above,
then you need to copy the _USRSPGM MACRO definition exactly as it currently is in sharedprefix.SOURCE(#SMFEXIT),
and then add the cascading IF statement for ACCTNOx value setting to whatever code is currently in the _USRSPGM MACRO.
The example above uses the DEFAULT _USRSPGM MACRO definition...but it may be modified at your site,
so you would want to keep those modifications in your updated definition.