* copyright (C) 1984-2019 merrill consultants dallas texas usa

other endtimes are pushed to the correct TOD value.

So the CEC-summary data can still be slightly wrong

because two slightly different intervals are summed

together, but that's all that can be done, unless

you change all of your interval and SYNCs to be the

same!

Each SMF70GIE and LPARNAME is summarized to combine the

short intervals into the summary interval, using

BY CECSER SYSPLEX LPARNUM LPARNAME SYSTEM SYSNAME

(revised) SMF70GIE

That summary of each LPARNAME is then sorted

BY CECSER SMF70GIE LPARNUM LPARNAME

DESCENDING SMF70LAC DESCENDING DURATM,

and the first instance of each LPARNAME is output

to create the PDB.ASUMCELP dataset, with the total

resoures consumed by each LPAR in that CEC for the

constructed CEC Interval. Variable STARTIME is

recalculated as SMF70GIE-CECINTRV so all of the obs

will have the same "pseudo" STARTIME for reporting.

-While the new sort order BY CECSER SYSPLEX .... is used

inside VMXG70PR to ensure correct assembly and summary,

at the end, the four output datasets are sorted back to

their old sort order, with the new variables added at the

end, hopefully to avoid NOTSORTED errors in your weekly

and/or monthly jobs that combine ASUMs built with both

the old and new logic. The final sort order is:

ASUM70LP:

BY SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER

LPARNAME LPARNUM

ASUM70PR:

BY SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER

ASUMCELP:

BY CECSER STARTIME SHIFT LPARNAME LPARNUM

ASUMCEC:

BY CECSER STARTIME SHIFT

-A new macro variable, &MXGNOBY, is created for NOTSORTED

circumvention in each of the WEEKxxxx/MONTHxxx members.

The current circumvention, documented in comments in each

of those members, still works fine, but it requires you

to EDIT your WEEKxxx/MONTHxxx member to insert:

MACRO _BY % MACRO _SORTBY %

which disables the BY processing in the SET statements.

Without the BY processing, the output dataset is not

in sort order, but instead is the concatenation of

the input datasets, but there is no requirement that

the datasets be sorted (except in MXG's MONTHxxx and

WEEKxxx code!!). Even though MXG normally builds its

datasets sorted, you should never make that assumption

and thus should always sort the input data yourself;

however, if the dataset is already sorted in the same

order, SAS will bypass your sort. Thus having output

of the weekly or monthly only impacts run times, but

not the contents of the output datasets.

This new &MXGNOBY macro variable is located so that it

can be used in your //SYSIN to disable BY processing,

without EDITing your WEEKxxx/MONTHxxx member, using

%LET MXGNOBY = MACRO _BY % MACRO _SORTBY % ;

%INCLUDE SOURCLIB(MONTHBLD);

And, then remove the %LET before the next MONTHBLD!

-May 11:

Variable LPARWAIT was incorrectly kept in ASUMCEC/TRNDCEC

but it is an LPAR-specific field that was stored into its

LCPUWAIn variable, so LPARWAIT is not kept in ASUMCEC nor

TRNDCEC. The labels for the LCPUWAITn variable now are

'LCPU n*WAIT*COMPLETE?'.

-May 13:

The variables NRIFCCPU/NRIFACPU/NRIFLCPU/NRZIPCPU that

count the number of "specialty engines" was sometimes

incorrect in the PDB.ASUMCEC and PDB.ASUM70PR datasets.

They are corrected, and documented as to when they will

be zero and when they won't:

For the "this system" PDB.TYPE70 dataset, SMF70CIN='IFA'

is used to count the NRIFAS available to "this system";

but even when SMF70CIN is not populated with that new

value, the original MXG heuristic algorithm detects and

counts IFAs, and populates CPUIFATM and the other IFA

durations. The "this system" datasets PDB.TYPE70 and

PDB.RMFINTRV do not depend on new values in SMF70CIN.
However, for "LPAR summary" PDB.ASUM70PR & PDB.ASUMCEC

datasets, SMF70CIN must be populated with "IFA" to count

each type of "specialty engines". But SMF70CIN is only

populated with new 'IFL' or 'IFA' values on z9 and later

processors, so only z9+ systems will have the correct

count values in all four NRxxxCPU counters. Pre-z9

systems have only 'CP' or 'ICF' in SMF70CIN so they will

have zeros in NRIFACPU and NRIFLCPU, and the NRICFCPU

variable will contain the total count of all of the

specialty engines in that CEC.

But it is only the NRxxxCPU counters that may be zeroed.

Whether it's a z9+ or not, the IFACPUTM,IFAUPTM,IFAWSTTM

duration variables were correct when an IFA is used, and

you can have NRIFACPU=0 with IFACPUTM non-zero pre-z9's!

Change 24.063 The calculation of MACHTIME in TYPE89 & TYPE892 datasets

VMAC89 was revised with SMF data that had SMF89DTO and SMF89HOF

Apr 29, 2006 populated. Now, MACHTIME=SMF89UET-SMF89DTO-SMF89HOF, and

May 4, 2006 it is the "TRUE" GMT Clock datetime when the actual usage

occurred to be used by IBM for usage charges. MACHTIME is

needed for IBM to charge you correctly, since you can IPL

IPL with any date/time/offset, as you did for Y2K tests,

and may to do again for Y2042 testing (8-byte STCK fields

will wrap at 23:53:48 on Sep 17, 2042, but must be fixed

prior to 2012, because tape retention can be 30 years.)

Only MACHTIME is is adjusted, as all of the other times,

SMF89UST, SMF89IST, SMF89IET, SMF89UET and SMFTIME are

always on the same (local) time zone.

And SMF89DTO, unlike all other SMF GMT Offset fields,

is the offset from local back to GMT.

The SMF89IST/SMF89IET times are the start/end of the

interval of data (twelve 5-minute intervals in an hour),

while the SMF89UST/UET are always the hourly start/end

of each usage hour, so they have the same value in all

twelve detail observations for that hour.

Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.

Thanks to Stephen H. Hodges, OneBeacon, USA.

Change 24.062 SAS ERROR: BIT CONSTANTS ARE NOT SUPPORTED BY SQL because

MXGSASV9 the Service Pack SASMSG DSN was not first in the //SASMSG

Apr 27, 2006 concatenation. When you install a SAS Service Pack, the

new SASMSG DSNAME contains ...SL..., and that DSNAME must

be first in the //SASMSG DD concatenation. This change

adds a ...SL... DD/DSNAME to the MXG Example JCL Proc.

Due to how SAS messages are built, if the wrong SASMSG

is first, you can get all types of failures, including

ABENDS. Many times there will be a message text that

makes no sense (there are no BIT tests in any of the

code that produced the above error), because the SAS

message formatting is processing the wrong message ID,

due to the incorrect library being first.

Thanks to Jim Horne, Lowe's Companies, Inc, USA.

Change 24.061 Revised to work on ASCII systems; SAS WENT TO A NEW LINE

TIMEBILD error message if there was no data in the OFFGMT column.

Apr 26, 2006 On z/OS, TIMETABL is a RECFM=F/FB file, so there always

May 22, 2006 is at least a blank in column 64, where OFFGMT was read,

but on ASCII, the text file is variable length, and that

unconditional INPUT @64 with no data caused SAS to skip

the next line in TIMETABL. The INPUT @64 OFFGMT is now

conditionally executed only if there is data there.

The error was observed when the time stamps on systems

that were listed in TIMETABL were not being changed.

-May 22: The LRECL=72 in the INFILE &TIMETABL statement

left during testing this change was removed.

It caused an OPEN ERROR if the &TIMETABL DD

pointed to an LRECL=80 dataset (i.e. SOURCLIB).

Thanks to Ingegerd Jansson, Volvo, SWEDEN.
Change 24.060 The RMF-like CPU Activity Report is updated for IFAs and

ANALRMFR IFL engines.

Apr 26, 2006

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 24.059 For z/890's only, the three IFA CPU Time variables in the

VMAC30 TYPE30/STEPS/JOBS, CPUIFATM, CPUIFETM CPUIFDTM, were the

Apr 26, 2006 "measured" rather than "normalized to CP seconds" in MXG,

and thus their values were too large on z/890s. The

three times are now revised to be the "normalized" time:

CPUIFATM=CPUIFATM*SMF30ZNF/256;

CPUIFETM=CPUIEATM*SMF30ZNF/256;

CPUIFDTM=CPUIDATM*SMF30ZNF/256;

and those equations could be used to correct existing

MXG datasets.

Change 24.058 -The SORT order of PDB.ASUMTAPE was changed in MXG 23.09

ASUMTAPE (Change 23.300) to BY "LOCATION" DEVNR. Previously, it

WEEKBLD was BY SYSTEM DEVNR, but it was never correct to include

Apr 26, 2006 SYSTEM if you shared tape devices across systems. One of

the major corrections in Change 23.300 was the removal of

SYSTEM from the ordering (and the creation the optional

"LOCATION" to support multiple locations with the same

DEVNR for two different devices), as well as the addition

of the SYSLOG mount-related messages in the redesign.

Unfortunately, I did not document this change in the sort

order of PDB.ASUMTAPE, and I failed to update the WEEKBLD

programs, which still had the old BY statement. SYSTEM

has now been removed from the BYLIST in those WEEKBLx's.

-Macro _GRPMNCD to define the optional "LOCATION" was not

invoked in the ASUMTAPE member (which only proves that no

one yet had tried to use that option!), but now it can be

used if needed.

====== Changes thru 24.057 were in MXG 24.02 dated Apr 26, 2006=========

Change 24.057 New analysis of RAID boxes, creates new PDB.RAIDMAP and

ASUMCACH PDB.CSSSID datasets that shows, for each CSSID, all of

ASUMRAID the volumes on that CSSSID (typically 80 to 256). Some

GRAFRAID user tailoring of the ASUMRAID member will be required;

Apr 25, 2006 read the comments in ASUMRAID.

-The ASUMRAID analysis requires ASUMCACH to have been run

to create PDB.ASUMCACH; this change cleaned up ASUMCACH

so it won't fail even if there was no TYPE74CA dataset

observations.

Thanks to Chuck Hopf, Bank of America, USA.

Change 24.056 New GLOBAL macro variable MGCMPNY is now defined as null

VMXGINIT in VMXGINIT, but it will be used in MXG reports so your

Apr 25, 2006 Company Name can be printed on reports. You could set it

permanently in IMACINIT, with

%LET COMPANY='MERRILL CONSULTANTS;

or you could just put that %LET in your //SYSIN stream.

The reports that have been revised to use &MGCMPNY will

be added to this list:

ASUMRAID
Change 24.055 See Change 24.063.

VMAC89

Apr 25, 2006
Change 24.054 This example, which reads SMF data to run ASUMTAPE, was

ASMFTAPE not updated for the new SYSLOG Messages dataset, which

Apr 24, 2006 caused FILE PDB.TYPESYMT NOT FOUND error. The example

was revised to use the _STMNT product sort macro so that

all present and future TMNT datasets are sorted.

Thanks to Andre Vossen, ABN AMRO Bank, THE NETHERLANDS.

Change 24.053 Error messages printed for negative CPUUNITS are now only

VMAC30 printed if the delta is 1000 unweighted service units, or

Apr 24, 2006 about 0.05 CPU seconds on an SU_SEC=25000 machine. The

messages were added by Change 23.323 when the cause was

not known, but new analysis of a full day's SMF interval

records had only 56 records which had IFAUNITS greater

than ORGUNITS, but the max delta was only 650 units, or

0.03 seconds on the SU_SEC=25000 machine. The CPUTCBTM

was 0.00 or 0.01 CPU seconds, and CPUIFATM was between

0.25 to 0.44 CPU seconds for the 30 minute intervals.

MXG's value of CPUUNITS will not be changed, so you can

see if this occurs, but the MXG Error Message will only

be printed when the negative delta is significant.
After discussions of this data with IBM, I agree that

these negative values are the result of imprecision in

CPU timings (.01 resolution) and in the way Service Units

are calculated (remainders are discarded in some fields,

rounding is done in others) and are not a problem to be

immediately corrected, although IBM does plan to review

their remaindering/rounding logic.

Jul 27, 2006: It appears the correction to IBM Service

Unit remaindering is corrected by APAR OA16005.
Change 24.052 Debugging PUT statement removed.

VMACFILA

Apr 24, 2006

Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.

Change 24.051 In DB2 V8.1, QISEDBW was missing but shouldn't have been,

VMACDB2 QISEDSC should have been but wasn't, and these four new

Apr 24, 2006 variables are now INPUT for the DB2ACCT dataset.

Apr 25, 2006 QISEDYNP QISECFAL QISECPGE QISECFRE

Apr 27, 2006 And, QISESTMT should not have been de-accumulated.

And, QISEDSI and QISEDSG are now de-accumulated.

Thanks to Clayton Buck, UniGroup, iNC.
====== Changes thru 24.050 were in MXG 24.02 dated Apr 24, 2006=========
Change 24.050 New variables INDXUSED and POLYUSED are created from DSIG

VMACRMFV offset variables that are now kept in ZRBBDSHI dataset,

Apr 23, 2006 to detect and eliminate "dead space" in RMF VSAM files.

RMF Monitor III "indexes" each Sample Set in the DSH

table; a sample set is written for each MINTIME interval

and the index provides the offset into the data set for

each sample. But the max DSH is 32K long; the fixed DSH

header is 256 bytes, leaving 32512 bytes for the 28-byte

indexes, for a maximum possible of 1161 indexes; Cheryl

Watson reported 50 are saved for Policy Indexes, leaving

1111 indexes for the actual sample data indexes. In the

past sites had cumbersome calculations to insure the RMF

III VSAM files were not too large; otherwise, those 1111

index entries could be exhausted. But with the INDXUSED

calculation, Jerry found they were only using 80-95 of

the indexes on each dataset because their sample sets are

so large. With RMF III data sets of only 2250 tracks

each, they would exhaust space long before running out of

indexes. The datasest could be made much bigger, keeping

more data online for interactive analysis, and still not

risk creating any "dead space". And adding new RMF III

datasets may not be an option, as there is a hard limit

of 100 datasets.

Thanks to Jerry Urbaniak, Acxiom CDC, USA.

Change 24.049 Variables WTASFLAG and WTASFLG2 are now kept in MQMQUEUE

VMAC116 dataset, from MQMACCTQ segment, and new variable SM116EVT

Apr 23, 2006 is created to distinguish between records written at the

Apr 25, 2006 end of each thread from records written at interval end.

Data showed that the thread end had WTASFLAG='30'x and

the interval end had WTASFLAG '00'x or '20'x.

IBM now provided these bit explanations:

WTASFLAG

WTASERR 0 set if an error occurred

WTASLAT 1 Latency Error

WTASAEOT 2 Accounting End of Thread

WTASDEAL 3 Thread Deallocated

WTASFLA2

WTASHERE 8 WTASHERE Block has been used

So new MXG variable SM116EVT is now created, with

LABEL S116VENT='EVENT*I=INTERVAL*T=THREAD END';

IF WTASFLAG='..11....'B THEN SM116EVT='T';

ELSE SM116EVT='I';

Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.048 A new version of the CLRMFV TSO Clist, the driver for the

CLRMFV ASMRMFV RMF Monitor III decompression utility, adds new

DOCLRMFV options to provide better support for the single large

Apr 23, 2006 output file if can now create with CALLBY(ALL):

-OUTSCL() SMS STORCLAS, now default is null.

-OUTMCL() SMF MGMTCLAS, now default is null

-OUTMLQ() to specify middle level qualifier for RMF dsn.

-OUTRLSE() to specify YES or NO (YES is default)

-OUTTYPE() to specify DSNTYPE.

See DOCLRMFV for full description and usage notes.

A special thanks to Acxiom leadership for allowing this

effort to continue to go forward.

Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.047 LABEL statements with duplicated variable names are now

Apr 23, 2006 detected in MXG's QA stream, and all have now been fixed.

DOC In some cases, this was a real error: two different data

fields were stored in the same variable, so a new named

variable had to be created for that second field. All of

the other cases were examined and the "better" label was

kept. SAS uses the last label it compiles, so if "last"

was "better", then there was no change, but some labels

will now be different (and, hopefully, "better').
Change 24.046 zIIP support. (APAR OA13499, z/OS 1.6, 1.7, and 1.8).

VMAC30 The metrics and variables for the new zIIP engines are

VMAC7072 very much like the metrics for IFA/zAAP engines.

VMACDB2 -TYPE30 New Variables:

VMACRMFV CPUZIPTM='TOTAL*EQUIVALENT*CPU TIME*ON_ZIP'

VMXG70PR CPUEZITM='INDEPENDENT*ENCLAVE*CPU TIME*ON ZIP'

Apr 20, 2006 CPUDZITM='DEPENDENT*ENCLAVE*CPU TIME*ON ZIP'

Jun 5, 2006 CPUZIETM='ZIP-ELIGIBLE*CPU TIME*ON CP'

Jun 13, 2006 CPUEZETM='ZIP-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP'

Jun 14, 2006 CPUDZETM='ZIP-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP'

Jun 15, 2006 CPUEZQTM='ZIP-QUALIFIED*IND ENCLAVE*CPU TIME'

Jun 22, 2006 CPUDZQTM='ZIP-QUALIFIED*DEP ENCLAVE*CPU TIME'

Oct 13, 2006 ZIPUNITS='ZIP-EQUIVALENT*CPU*SERVICE*UNITS'

ZIEUNITS='ZIP-ELIGIBLE*CPU*SERVICE*UNITS'

-TYPE70 New Variables

NRZIPCPU='NUMBER OF*ZIP*ENGINES*AVAILABLE'

Oct 13, 2006 Note: Originally spelled NRZIPS in

this text, I chose NRZIPCPU for the new name in all

TYPE70/RMFINTRV/ASUM70PR/ASUMCEC/etc datasets.

Since NRIFAS already existed in TYPE70/RMFINTRV,

I had to leave that spelling in those datasets, but

I used NRIFACPU in the ASUM70PR/ASUMCEC/.. datasets

which previously didn't have a count of IFAs.

SMF70SUP='ZIP PROCESSORS*ONLINE*AT END OF*INTERVAL'

PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)'

ZIPAVAIL='ZIP*PROCESSOR*AVAILABLE?'

ZIPACTTM='ZIP ENGINE*EXECUTING*(ACTIVE) CPU TIME'

ZIPUPTM ='ZIP ENGINE*AVAILABLE*(UP) TIME'

ZIPWAITM='TOTAL*ZIP WAIT*DURATION'

ZIPWAIT0='ZIP WAIT*DURATION*ZIP 0'

ZIPWAIT1='ZIP WAIT*DURATION*ZIP 1'

ZIPWAIT2='ZIP WAIT*DURATION*ZIP 2'

... 3 thru 30 ...

ZIPWAITW='ZIP WAIT*DURATION*ZIP 31'

ZIPWAITX='ZIP WAIT*DURATION*ZIP 32'

PCTZIBY0='ZIP 0*PERCENT*CPU BUSY TIME'

PCTZIBY1='ZIP 1*PERCENT*CPU BUSY TIME'

PCTZIBY2='ZIP 2*PERCENT*CPU BUSY TIME'

... 3 thru 30 ...

PCTZIBYW='ZIP 31*PERCENT*CPU BUSY TIME'

PCTZIBYX='ZIP 32*PERCENT*CPU BUSY TIME'

-TYPE72GO New Variables

CPUZIETM='ZIP*ELIGIBLE*CPU*TIME'

CPUZIPTM='ZIP*CPU*TIME'

R723CIFA='IFA*SERVICE*UNIT'

R723CIFC='IFA-ELIGIBLE*SERVICE*UNITS'

R723CSUC='ZIP-ELIGIBLE*SERVICE*UNITS'

R723CSUP='ZIP*SERVICE*UNITS'

R723SUCU='ZIP-ELIGIBLE*ON CP*USING SAMP'

R723SUPD='ZIP*DELAY*SAMPLES'

R723SUPU='ZIP*USING*SAMPLES'

ZIEUNITS='ZIP*ELIGIBLE*UNITS'

ZIPUNITS='ZIP*SERVICE*UNITS'

-DB2 CPU Time fields added to DB2ACCT (APAR PK18454).

QWACZIEL='CPU TIME*ZIP ELIGIBLE*ON CP*ENGINE'

QWACZIS1='CPU TIME*EXECUTING*ON ZIIP'

QWACZIS2='CPU TIME*IN DB2*EXECUTING*ON ZIIP'

QWACZITR='CPU TIME*IN TRIGGERS*EXECUTING*ON ZIIP'

-DB2 CPU Time field QPACZITM for Package ZIP execution:

QPACZITM='CPU TIME*

-RMF Monitor III fields added to CPUG3 segment for zips:

CPUITSUP='LOGICAL CPU*TIME ON*ZIP*PROCESSORS'

CPUPRSUP='ONLINE*TIME ON ZIP*PROCESSORS'

CPUSTSUP='PHYSICAL CPU*TIME ON*ZIP*PROCESSORS'

CPUSUCOL='AVERAGE*ZIPS*ONLINE*DURING*INTERVAL'

CPUSUCON='ZIP ENGINES*ONLINE*AT END'

See Change 24.181 for more RMF III zIIPs data.

-ASUMCEC new calculated variables:

PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'

PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)'

Jun 5: VMAC7072 was revised to correctly input variables

R723SUP/R723CSUC/R723CIFA/R723CIFC.

Jun 13: Some 70 zIIP variables had IFA in their labels.

Jun 14: Some 30 zIIP variables had IFA in their labels.

Jun 15: DB2 zIIP variables created in DB2ACCT,DB2ACCTP

Jun 15: TYPE72GO fields added to KEEP=, LABEL.

Jun 20: Change 24.105 revised ASUM70PR for zIIPs.

Jun 22: VMACRMFV updated for RMF Monitor III Zip data.

-And now that IFA/ZIP text is in all MXG variable labels,

the APAR documents that IBM has changed RMF reports to

now print 'AAP' for IFA/zAAPs and 'IIP' for zIIPs, but

I am not going to change either those existing labels nor

the variable names that already exist.
Change 24.045 Support for APAR UK12301 (Tivoli Allocation Optimizer SMF

VMACTIAO record) adds flag bit for Not Cataloged 2 error condition

Apr 19, 2006 (which only applies to non-SMS-managed datasets!), and

new TIAOVOL variable if Not Cataloged bit is on, with the

VOLSER of the dataset in error.
Change 24.044 Variable BEGTIME was missing in DB2STATB dataset for the

VMACDB2 startup record (QWHSISEQ=1), which is now corrected (by

Apr 19, 2006 setting BEGTIME=ENDTIME=QWHSSTCK and DURATM=0). But for

the first instance of each Buffer Pool that was not a

startup record, not only was BEGTIME a missing value,

but also the rest of the variables were trash, because

the accumulated values were output. A long term solution

would be to introduce "SPIN" logic into DB2 processing,

but as no one has noticed the trashed data, and as the

introduction of the need for the //SPIN DD into stanalone

DB2 processing could cause well-running programs to fail,

my present solution is to not output that first instance,

and if that observation is truly ever needed for ad hoc

problem analysis, using the prior day's SMF data and

today's SMF data, concatenated as input, will completely

provide correct data, without a redesign to use SPINing.

Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.043 Variables PCTCPUBY=. and CPUACTTM=. in PDB.TYPE70 dataset

VMAC7072 if the SYSTEM is is not-LPARed, but instead only exists

Apr 7, 2006 as a single image. This case is now detected and the

code sets PCTCPUBY=PCTMVSBY, and CPUACTTM=CPUMVSTM.

Thanks to Ronald Kveton, Experian, USA.

Thanks to William Whitehead, Experian, USA.

Thanks to John Rourke, Experian, USA.
Change 24.042 Support for CPC RMF III report data, which is now INPUT

EXZRBLCP from the ERBCPUG3 segment; some of the variables are

IMACRMFV output into the existing ZRBCPU dataset, but the LCPUADDR

VMACRMFV details are output in the ZRBLCP dataset.

VMXGINIT Five of the new fields in ZRBCPU dataset are accumulated:

Apr 7, 2006 CPUPRIFA, CPUWEICD, CPUWEIND, CPUUNCTD and CPUCAPTD and

a revision to this change will be made shortly to sort

and deaccumulate those values, and this text will be