ACCTNOx assignments incorrect some of the time

Document ID:  TEC1652663
Last Modified Date:  06/08/2017
{{active ? 'Hide' : 'Show'}} Technical Document Details

Products

  • CA MICS Resource Management

Releases

  • CA MICS Resource Management:Release:14.0
  • CA MICS Resource Management:Release:12.9

Components

  • CA MICS BATCH AND OPERATIONS ANALYZER:MSMF
Issue:

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.

Workaround:

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. 

 

 

 

 

 

Please help us improve!

Will this information enable you to resolve your issue?

Please tell us what we can do better.

{{feedbackText.length ? feedbackText.length : '0'}}/255

{{status}}

Not what you were looking for?

Search Again >

Product Information

Support by Product >

Communities

Join a Community >