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

as a SAS Date variable.
Change 28.202 Support for RACF EVENT 82 (PTCREATE) creates TYPE8082

EXTY8082 dataset.

IMAC80A

VMAC80A

VMXGINIT

Sep 1, 2010

Thanks to Bill Arrowsmith, EuroClear, BELGIUM.
Change 28.201 MXG 28.05 only. GOPTIONS DEVICE=GIF was added in VMXGINIT

VMXGINIT but could change the size of your graphs. Now, GOPTIONS

Aug 31, 2010 only sets default COLORs and PATTERNs.
Change 28.200 z/OS utility to construct VBS blocks in RECFM=U format

UDEBLOCK from a PC/ASCII VBS file failed when only one byte was

Aug 31, 2010 left at the end of a block, since that would be the first

byte of the two-byte length field. MXG logic worked with

zero or two-or-more, but not one; an extensive rewrite of

the program was required. This uploaded file had a series

of 32760 byte blocks, but then one block of 32759 bytes

that contained parts of three blocks, with only one byte

of the next block at the end, which exposed the error.

Thanks to Carl Sommer, SAS Institute, USA.

Change 28.199 -Variables added from PDB.TYPE70PR are now populated ONLY

ASUM113 when the SM113CTM end time is within one hour of STARTIME

VMAC113 of the RMF data; previously, any 70 from the same SYSTEM

Sep 2, 2010 was used. APAR OA30486 will synchronize 113 intervals

with SMF, so eventually an exact merge can be used.

-LPARNAME is added to PDB.TYPE113, but will be populated

only if matching PDB.TYPE70PR observations exist.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Change 28.198 -CA-NSM/TNG datasets RH021 thru RH030 had only variables

VMACTNG from the header and RH020xxx, because of incorrect KEEP=

Aug 26, 2010 arguments.

Sep 1, 2010 -Variable INSTANCE was not kept nor in BY list for AI010.

-Packet counters in AI010 and RH018 are accumulated, so

the SORT macros _STAI010 and _STRH018 are rewritten to

deaccumulate those four variables. You will need to use

%INCLUDE SOURCLIB(TYPSTNG); to create PDB.AI010/RH018 to

contain the interval (deaccumulated) values, or use

%LET PTAI010=WORK;

%LET PTRH018=WORK;

%INC SOURCLIB(TYPESTNG);

_STAI010;

_STRH018;

if you want the interval datasets in the //WORK library.

Thanks to Xiabo Zhang, FISERV, USA.

Change 28.197 INVALID DATA FOR CHAR1 caused INPUT STATEMENT EXCEEDED.

VMACITRF The INPUT of VER with $CHAR1 was corrected to $CHAR1.

Aug 26, 2010 (i.e., missing period was added to the informat) in two

places. But Change 28.227 is also needed for VER='01'x.

Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 28.196 If you asked for IFCIDS=STATISTICS and WANTONLY a list of

READDB2 DB2STA* datasets, macro variable KILLSORT showed up as

Aug 25, 2010 unreferenced in DB2PST where it did not belong.

Thanks to Dan Case, Mayo Foundation, USA.

Change 28.195 If NRECORD was a null value or an alpha string, VMXGGETM

VMXGGETM failed with an invalid numeric value. Now, if an invalid

Aug 24, 2010 string is detected, NRECORD is set to the then current

value of the OBS option. This change uses the %DATATYP

macro provided by SAS, in their autocall library.
Change 28.194 Using ONLY the MXG-supplied CONFIGV9 and NOT having the

CONFIGV9 SAS-supplied DSNAME=SASHLQ..CNTL(BAT&YY) in //CONFIG DD

SASAUTOS caused the SAS default LOCALE=ENGLISH_UNITEDSTATES to be

TRIM used, instead of the LOCALE=ENGLISH_UNITEDKINGDOM that

Aug 2, 2010 was required for this English Site. The result was that

Sep 24, 2010 MXG saw an invalid 'BA'x character (for NOT symbol) in

Sep 30, 2010 the TRIM member of the SAS-supplied SASAUTOS PDS, that

had been built with the UNITEDKINGDOM LOCALE, instead of

the expected '5F'x with LOCALE=ENGLISH_UNITEDSTATES.

MXG's CONFIGV9 intentionally does NOT specify LOCALE, as

that should be picked up from the site's BAT&YY member.

The error was in the %TRIM macro (now used in VMXGSUM),

but it caused this completely-off-the-wall error:

NOTE: LINE GENERATED BY THE INVOKED MACRO "VMXGEXP".

&WORD = &WORD * &BY ;

_

22

(Long ago, problems with character conversion of the

NOT symbol caused me to NEVER use that symbol, and

instead MXG uses NE or NOT character text.)

-SAS did detect the incorrect LOCALE setting, printing

WARNING: There is an incompatibility between session

encoding and the SASHELP encoding. When such a

mismatch occurs, some features may not behave as

expected. For additional information, contact your Site

Administrator
-The original text of this change INCORRECTLY blamed the

error on the DSN=*.NULLPDS syntax in their //SASAUTOS DD

//SASAUTOS DD DSN=*.NULLPDS,DISP=SHR

// DD DSN=SAS.yadayada.SASAUTOS

which was INCORRECTLY thought to have prevented the %TRIM

macro from being resolved. While *.NULLPDS in MXGSASxx

JCL examples was removed in Change 27.108 in MXG 27.05,

because it was no longer needed and MIGHT cause errors,

in fact its removal, while recommended, is not required.

Thanks to George Canning, Produban UK, ENGLAND.

Thanks to Mark Dawson, SAS Institute, ENGLAND.
Change 28.193 -Full support for IMF records in SMF format, so IMF SMF

VMACCIMS records can be processed with BUILDPDB. Change 28.137

TYPEIMFS created TYPEIMFS to process IMF-SMF data, but was only

Aug 23, 2010 for "stand-alone" execution. This update to VMACCIMS

moved the "IMF-SMF-unique" logic inside the _CDECIMS code

and (transparently) recognizes the input file is SMF or

IMSLOG. Member TYPEIMFS was then updated/simplified.

-To add IMF processing to your BUILDPDB, you use the four

EXPDBxxx exit members, with this syntax:

EXPDBINC: %INCLUDE SOURCLIB(VMACCIMS);

EXPDBVAR: MACRO _VARUSER _VARCIMS ... %

EXPDBCDE: MACRO _CDEUSER _CDECIMS ... %

EXPDBOUT: _CHAIN

_SIMFDBD

_SIMFDB2

_SIMFPGM

and you must define the output DDNAME/DDNAMES for the

one or four data libraries where you want your output

datasets written, before the include of BUILDPDB?

- If you output to Disk, the same DDNAME can be used

for all four datasets, but,

- if you want to write your IMF data to tape, you must

have a separate DDNAME and DSNAME for each dataset

(because, internally, for performance run times, MXG

must open two of those datasets simultaneously, and

z/OS does not allow more than one dataset opened on

tape media).

%LET PIMFDBD=CIMSDBDS; /*DEFINE OUTPUT DDNAMES */

%LET PIMFDB2=CIMSDB2;

%LET PIMFPGM=CIMSPROG;

%LET PIMFTRN=CIMSTRAN;

Thanks to Denise Willers, Infocrossing, USA.

Thanks to Ken Steiner, Infocrossing, USA.
Change 28.191 Cosmetic cleanup when ITRM validated MXG 28.05:

ASUM113 -VMAC84 variables R84FN, R84DMA and R84GMSMIN are now

CREATEBC spelled R84FNFW, R84DMAV and R84_GMSMIN in the KEEP=. Two

PROCSRCE instances of '97'x (ASCII) or '00'x (EBCDIC) are removed.

VMAC7072 -Detection of ASCII '97'x (long dash) added in PROCSRCE.

VMAC84 -And, detection of '00'x in the EBCDIC output created by

Aug 23, 2010 CREATEBC converts it to blank (in case the PROCSRCE error

messages added above were overlooked!).

-Temporary datasets ZxTYxxx created by TYPE113/ASUM113 are

deleted. Temporary dataset BADINTRV is left intentionally

in case you need to see which intervals were dropped.

-Temporary TYPE70EC/TYPE70EL datasets are deleted; they

are used to create the new PDB.TYPE70EN.

-TYPE80A variable RACF329 is now spelled RACF320.

Thanks to Chris Weston, SAS ITRM Development, USA.
Change 28.190 MXG 28.05, QLACLOCN wrong if it is longer than 16 bytes.

VMACDB2 There is a fixed 16-byte field for QLACLOCN, but if that

Aug 20, 2010 remote location address is longer, it is "truncated", and

a non-zero offset to the full "un-truncated" field exists

but 28.05 incorrectly INPUT that longer field. This has

ONLY been seen with DB2 V9 with IPV6 IP addresses, which

are usually 17-20 bytes long, but can be up to 39 bytes.

2012: Not noted in 2010, QLACLOCN/QWHDSVNM were increased

to $128.
Change 28.189 The COMPALL program requires REGION=1700MB to compile all

COMPALL MXG members that process SMF records (to verify that they

VMACCMHM can all be combined without conflicts for any temporary

Aug 20, 2010 variables). The program contained 407,097 source lines.

It also exposed an error in VMACCMHM that did not have an

IF ID=_IDCMHM THEN DO; code block.

Change 28.188 RMM INVALID NUMERIC DATA NE notes are produced when the

VMACEDGR expiration date is "PERMANENT". The DATE fields will be

Aug 19, 2010 missing values, like other non-date-expiration-dates, but

the variables RDEXPDCH,RVEXPDTO, the "ORIGINAL*CHARACTER"

expiration dates will contain PERMANENT, with no NOTES.

Thanks to Sam Bass, McLane Co., USA.

====== Changes thru 28.187 were in MXG 28.05 dated Aug 18, 2010=========
Change 28.187 -First 28.05, JCLTESTx jobs only, VARIABLES NOT FOUND in

ASUM113 ASUM113 which is included automatically by TYPE113.

Aug 18, 2010 The ASUM113 member adds data from TYPE70PR when it is

found, but incorrect logic in the new ASUM113 failed when

there was no TYPE70PR dataset found. ASUM113 was revised.

SMF records. The error was missed because JCLQASAS is the

primary z/OS QA job now, and it (accidentally) always had

a PDB.TYPE70PR created when the ASUM113 was executed.

I'll now ensure JCLTESTx is also tested for z/OS QA.

-NEWSLETTER FIFTY-SIX is now dated August 18, 2010, as it

should have been.
====== Changes thru 28.186 were in MXG 28.05 dated Aug 17, 2010=========
Change 28.186 Support for ThruPut Manager V6.2(PTF 6209) adds these

VMACTPMX variables to dataset TYPETPMX:

Aug 17, 2010 DBS_SDBL DBS_SDPA DBS_SDPL PCS_EP PCS_MP PCS_PPSQ

Other new fields could be created, but I can only

update MXG for the data fields that exist in sample

SMF records.

Thanks to Scott Barry, SBBWorks, USA.

Thanks to Rick Ralston, Humana, USA.

Change 28.185 Cosmetic. TYPETMNT records with unexpected MSGID printed

VMACTMNT log messages for every instance; now, only the first 10

Aug 17, 2010 instances will be printed.

Thanks to Linda Berkley, DISA, USA.

Change 28.184 The syntax LIBNAME TYPE30 'D:\MXG\ANALDSET\TYPE30 \'; is

ANALDSET not valid on PC SAS; the blanks before the back-slash

Aug 17, 2010 must be removed.

Thanks to Sarel Swanepoel, South African Revenue, South Africa

Change 28.183 Documentation and cosmetic changes to DB2 102 data.

VMAC102 -QWP1IXPX contains the name of the default Buffer Pool; it

Aug 16, 2010 is $EBCDIC6 and replaced QWP1IXPL which was only $EBCDIC4

Aug 24, 2010 -QWP9MISC is now formatted $HEX2.

-QWP1SCER, QWP4STHT, QWP4STRL, QWPBDB2S are now $EBCDIC1.

instead of $CHAR1. and no longer formatted $HEX2., and

their labels now contain ? to indicate they are Y/Ns.

-QWP1BDUR/QWP1URCK/QWPBDLEN/QWPBTLEN/QWP1FLBX are CHAR

variables with $HEX format, but they contain numbers.

Rather than create a conflict of CHAR vs NUM variables,

they are expanded to 3 bytes and the numeric value is now

carried in the character variable.

-QWP4ESC now formatted $HEX2. instead of $HEX4.

-QWP4RMAX is the maximum number of RID blocks, for example

147. TMON reported QWP4RMAX=4,816,896, which (I think)

is the number of bytes, because 147*32768=4,816,896.

-IFCID=106 fields that are now input:

QWP4MIS5 QWP4MS4B QWP4MS4D QWP4MS4E QWP4METR QWP4CHEC

Thanks to Rachel Holt, Fidelity Systems, USA.
Change 28.182 MXG 28.05 is REQUIRED for APAR OA30563 and APAR OA33976,

VMAC30 which increased Service Unit fields in SMF 30 records to

Aug 16, 2010 8-bytes, but MXG 27.10 thru MXG 28.04 were in error and

Sep 9, 2010 caused VERY LARGE SERVUNIT values and in these variables

SERVUNIT CPUUNITS SRBUNITS IOUNITS MSOUNITS ENCLCPSU

IFEUNITS IFAUNITS ZIPUNITS ZIEUNITS

and the CPU times that are calculated from Service Units

CPUTOTTM/SRVTCBTM/SRVSRBTM

to all be extremely wrong when those APARs are installed.

The variables are in TYPE30_4/TYPE30_5/TYPE30_V/TYPE30_6

and PDB.JOBS/PDB.STEPS/PDB.SMFINTRV datasets.

MXG 28.05 is required to support OA30563 and OA33976.

FORTUNATELY: the SRVTCBTM/SRVSRBTM/CPUTOTTM time that are

calculated from Service Units were created in MXG only

for comparison with the real CPUTM/CPUTCBTM/CPUSRBTM time

and are not used in any MXG reporting

-because long ago it was claimed that using service units

to calculate CPU times (TCB and SRB and TOTAL) was more

accurate than the CPUTCBTM/CPUSRBTM/CPUTM variables that

are in the SMF 30 record, a claim I have never been able

to verify, as I have only seen VERY small differences

between CPUTM and CPUTOTTM.

Only these three calculated CPU times are wrong:

CPUTOTTM/SRVTCBTM/SRVSRBTM

ALL other CPU time variables are correct and are NOT

impacted by this error in service units in TYPE30.

Originally, APAR OA26832 added 8-byte service unit fields

to the PERF segment, increasing LENPERF to 192, but MXG

Change 27.122 was wrong, testing for LENPERF GE 196, so

that new code block was never being executed, and the

new, longer service unit fields were never being input.

But when OA30563/OA33976 added more fields that increased

LENPERF to 211, so the code block was now executed, that

exposed a second error in Change 27.122, where a +3 was

coded instead of +6 to skip reserved field SMF30RS6,

causing all variables after that +3 to be misaligned,

with VERY large values in those service unit fields,

which are used to calculate the service-unit-based CPU

time variables CPUTOTTM, SRVTCBTM, and SRVSRBTM.

The original change text cited RSU1006 as the cause, but

that is not true; the two APARs happened to be installed

along with RSU1006, causing the incorrect citation.

Thanks to Jerry Urbaniak, Acxiom, USA.

Thanks to Cheryl Watson, Watson and Walker, USA.

Change 28.181 Updates made as a result of MXG 28.05 QA jobstream:

ANALCAPD -CLEARDB2 updated for new datasets created from DB2 SMF.

ANALRAID -READDB2 suppresses sorts when PDBOUT=WORK, suppressed

ASUMCACH sort of DB2GBPST, and some of the variables needed by the

ASUMDBAA ANALDB2R program are created in the _S macros.

CLEARDB2 -ASUMCACH did not support DEVMODEL='3390A'; to avoid full

EXZCO02 sort of both TYPE74 and TYPE74CA, variable MODEL was

READDB2 created as a numeric, MAXed to carry thru in lieu of ID.

TRNDDBAA But '3390A' caused INVALID ARGUMENT as it's not numeric.

VMAC42 Conflict resolved internally by making MODEL a HEX value

VMAC7072 and that will work until '3390G' DEVMODEL shows up.

VMAC74 -ANALRAID had site-specific ODS token

VMACDB2 -Cosmetic updates to ANALCAPD/ASUMDBAA/TRNDDBAA/VMXGDBAA

VMXGSRCH VMXGSRCH/VMAC42/EXZCO02 and updates to VMAC7072/VMAC74.

Aug 15, 2010
Change 28.180 -Support for user-created MQNAME segment that creates the

IMACICUL optional MQNAMECI variable in CICSTRAN dataset.

UTILEXCL

VMAC110

Aug 13, 2010

Thanks to Leendert Keesmaat, UBS, SWITZERLAND.

Change 28.179 Utility to read PDS/PDSE directories of a concatenation,

UTILPDSL assigning the level from 1 to X (x being the number of

Aug 11, 2010 libraries in the concatenation) to each member of each

library, so a pair (for example, two JES2 PROCLIBs or

two STEPLIBs, etc.) can be compared for member matches.

Place your concatenation in the JCL (in the example it

is a PROCLIB concatenation copied from SYS1.PROCLIB

member JES2) and point the PDS= parameter at that DD.

If you want the second report to contain ONLY those

cases where a member first appears in a specific PDS,

count down from the top of the concatenation to that

PDS and use that as the LEVEL= parameter. If that

LEVEL= is empty, all members will be listed in the

second of the two reports. This could be used to

determine if a PROCLIB (for example) has members that

are being used. If you specify LEVEL= and the second

report is not there, then no members in that PDS are

being referenced in this particular concatenation.

Reports:

1) The datasets in the concatenation

2) The PDS members, the dataset, and the level in

concatenation from whence they came.

Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.178 Comments had the correct output FILENAME UOUT but the

UDEBLOCK actual code had the FILENAME misspelled as UOW. ALL of

Aug 9, 2010 the references are now corrected to UOUT.

Thanks to Carl Sommer, SAS Institute, USA.

Change 28.177 -Modified to carry the SORTEDBY values into the output

BLDSMPDB datasets. In addition, now uses the datasets in the

VMXGALOC MON LIBNAME to determine which datasets will be kept

Aug 9, 2010 and the sort orders, and uses the WEEK1 LIBNAME for

ASUMDBSS monthly processing.

ASUMDBAA -If you need to build old data, you can use BLDSMPDB

Sep 9, 2010 but you need to specify RUNDAY=PDB,RERUN=ddmmmyy

where ddmmmyy is the SAS date value you want to have

in ZDATE. ZTIME will be set to midnight of that day.

-ASUMDB2A and ASUMDB2B members have ASUMDBAA and

ASUMDBSS alternates.

-VMXGALOC did not allocate CICSTRAN and DB2ACCT libs

as the doc said they did. Now it does. They are

allocated as:

CICSTRAN is allocated as basedir\cicsddmmmyy

DB2ACCT as basedir\db2ddmmmyy

both are retained based on the number of days specified

by DB2KEEP and CICSKEEP, with defaults of 14.

Change 28.176 Support for SARMON, a free tool that converts SOLARIS SAR

EXNMONIS data into the NMON format. The home page of the tool is:

VMACNMON http://www.geckotechnology.com/sarmon

VMXGINIT Some changes were required to MXG to support SARMON data:

Aug 8, 2010 -TOP record with 'NaN' (a UNIX unique "NOT A NUMBER")

which required protection with double question marks.

-Array size of WORDS increased from 255 to 1024 because

the SARMON 'IOSTATxxxx' records all contained 340 words.

-NMON or SARMON data could be incorrectly processed if

"descriptor records" were longer than 2048 bytes; the

NMONTEXT INPUT was increased to $VARYING32000.

-DISNAME was increased from $20 to $64 because SARMON

DATA had longer "disk" names for the IOSTAT data.

-SARMON RECTYPE=DISKSVCTM and DISKWAITTM are the same as

NMON DISKSERV and DISKWAIT, with different WORD2 names.

-Other SARMON DISKxxxx RECTYPEs have same spelling for

both RECTYPE and WORD2 so they were automatically output

and combined to create PDB.NMONDISK dataset.

-Seven IOSTAT (BUSY/READ/WRITE/XFER/BSIZ/SERV/WAIT) data

are supported and create new PDB.NMONIOST dataset with

I/O statistics for the non-disk I/O.

-SARMON objects WLMPROJECTCPU,WLMPROJECTMEM,WLMZONECPU,

WLMZONEMEM, and PROCSOL are supported and those variables

are output in the PDB.NMONINTV dataset.

Thanks to Marc-Antoine Gouillart, AMF, FRANCE.
Change 28.175 -Support of z196 WITH MORE THAN 64 ENGINES REQUIRES 28.05.

EXT11904 (Earlier MXGs will NOT contain any CPU data for engines

EXT11932 64-95 in TYPE70 and RMFINTRV datasets.

EXT11933 -A z196 with LESS THAN 64 engines with z/OS 1.11-1.09 does

EXT11934 NOT require MXG 28.05.

EXT11935 -Support of z/OS 1.12 enhancements requires MXG 28.05.

EXT11935 -DO NOT USE MXG 28.04 to read z/OS 1.12 RMF data, due to

EXT11936 errors (including ARRAY SUBSCRIPT OUT OF RANGE in ID=70),

EXT11937 and other errors in VMAC74 processing with MXG 28.04.

EXT11948 -MXG 28.03 and earlier MXG Versions that support 1.11 data

EXT11949 TOLERATE z/OS 1.12 records, but with no new data fields.

EXT11950

EXT11951 -The TYPE70 architecture is revised for z196s with 64 plus

EXT11952 engines. Sixty-four sets of variables for CPUs 0-63 are

EXT11973 still in TYPE70, but no new variables for CPUs 64+ were

EXT11974 created in this change. Instead, the new PDB. YPE70EN

EXT11975 "CPU Engine" dataset is created with one set of names and

EXT11976 with one observation for EACH engine, with no limit to

EXT11977 the number of engines, ever, should you actually need to

EXT11978 know the metrics for a specific MVS TYPE70 CPUID.

EXT11979 -The PDB.TYPE70PR dataset will also contain an observation

EXT11980 for every LCPUADDR.

EXTY4226

EXTY9033 All of the z/OS 1.12 changes are COMPATIBLY made.

EXTY9034

FORMATS -TYPE7 New variables:

VMAC113 SMF7DTYP SMF7LSD SMF7DRP SMF7LSN

VMAC30 -TYPE30 New variables:

VMAC42 The CPITCBTM and CPISRBTM "Initiator" CPI CPU times

VMAC64 are split into their "INIT" versus "TERM" events in

VMAC7 four new CPI variables in TYPE30_4/STEPS data:

VMAC7072 CPISRITM='CPI*SRB*STEP*INIT'

VMAC74 CPISRTTM='CPI*SRB*STEP*TERM' (Sum is CPISRBTM)

VMAC89 CPITCITM='CPI*TCB*STEP*INIT'

VMAC90A CPITCTTM='CPI*TCB*STEP*TERM' (Sum is CPITCBTM)

VMACDCOL SMF30CAI='CAPACITY*ADJUSTMENT*IND'

VMXGINIT SMF30CCR='CAPACITY*CHANGE*REASON'

Aug 8, 2010 SMF30CHC='CAPACITY*CHANGE*CNT'

Aug 15, 2010 SMF30ACR='RCTPCPUA*ACTUAL'

SMF30NCR='RCTPCPUA*NOMINAL'

SMF30SCF='RCTPCPUA*SCALING*FACTOR'

SMF30PCF='CAPACITY*FLAGS'

Note that these CPI times are NOT captured in RMF 72s,

and previously the INIT/TERM CPU times were lumped into

one bucked. Now, you can assign the "INIT" CPU time

to the INITTIME interval and the "TERM" CPU time to the

TERMTIME interval and improve the capture ratio.

-TYPE42 New Dataset: TYPE4226 NFS CREATE/DELETE/RENAME

The documentation of the subtype 7 and 8 and the new 26

are in the Network File System Guide and Reference.

-TYPE42 New variables:

Dataset: TYPE42VS:

SMF42VNL='VOLUME NAME LIST'

Dataset: TYPE42NF and TYPE42NU:

SMF42CI6='IPV6*ADDRESS*OF CLIENT HOST'

-TYPE64 New variables:

SMF64FD1 SMF64FD2 SMF64DAU

-TYPE70 New variables:

SMF70CR SMF70ZEI

SMF70NCR SMF70NPR SMF70NTR SMF70CAI SMF70CCR

SMF70SRM SMF70CMN SMF70CMM SMF70CTT SMF70DMN SMF70DMM

SMF70DTT SMF70EMN SMF70EMM SMF70ETT SMF70U00-SMF70U15

-TYPE70PR New variables:

SMF70TCB SMF70SRB SMF70NIO SMF70SIG SMF70WTD

APAR OA29820 also added SMF70WTD "LPAR Overhead"

-TYPE70X2 New variables:

R7024MSK R7023MET R7023MEC

-TYPE72GO New variables:

R723NADJ R723CECA

-TYPE74CA New variables:

R7451CT5 R7451CT6

-TYPE747P New variables:

R747PAND

-TYPE748 New variables: