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

Change 31.207 -MXG 31.07. Debugging PUT statement in VMAC6 printed

VMAC6 SMF6LN3=162 LENLEFT=552 for every SMF 6 record.

Sep 24, 2013

Thanks to Jim Horne, Lowe's, USA.

Change 31.206 -Support for IMF 5.1 (INCOMPATABLE, but only impacting the

VMACCIMS CIMSDBDS dataset; other existing datasets are unchanged.)

EXIMFMQ -New variables added to CIMSDBDS dataset:

IMACCIMS DBTDBVER='DB*VERSION'

VMXGINIT DBTFLOVF='FALSE*OVERFLOW*OCCURRED?'

FORMATS -New CIMSMQ dataset contains these MQ variables:

Sep 23, 2013 MQSSID ='MQSSID' MQGET ='MQGET*CALLS'

MQBACK ='MQBACK' MQINQ ='MQINQ '

MQCLOSE ='MQCLOSE' MQOPEN ='MQOPEN'

MQCMT ='MQCMT' MQPUT ='MQPUT*CALLS'

MQCOMM ='MQCONN' MQPUT1 ='MQPUT1*CALLS'

MQDISC ='MQDISC' MQSET ='MQSET*CALLS'

MQFLG1 ='MQFLAG1' MQUNKN ='MQUNKN'
Change 31.205 A graphical analysis of Latent Demand, based on Tivoli's

ANALATEN discussion found at:

Sep 21, 2013 HTTP://PUBLIB.BOULDER.IBM.COM/TIVIDD/TD/TDS390/

SH19-6818-08/EN_US/HTML/DRLM9MST50.HTM

Mar 22, 2014: Check for postings in archives and try:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/

/BOOKS/DRL5FS09/3.3.3?DT=20100105101315
====== Changes thru 31.204 were in MXG 31.07 dated Sep 20, 2013=========
Change 31.204 Change 31.200 (VGETOBS enhancement) stumbles with PDB=PDB

ANALDB2R if the data library that contains all of the DB2 datasets

Sep 19, 2013 is on tape. While that is, in general, bad practice, as

a mount and read is required for EVERY dataset needed by

your ANALDB2R request, it previously worked and will in

the near future, but for now, if your PDB is on tape and

you used ANALDB2R(PDB=PDB), this circumvention will avoid

the error (UNINIT variables messages, then other errors).

%ANALDB2R(PDB=WORK,DB2ACCT=PDB,USEACCT=YES,PMSTA02=NO,

PMSPR01=NO);

%ANALDB2R(PDB=PDB,STATSUSE=DETAIL,PMACC01=NO,

PMACC02=NO);

Please contact [e-mail] to request CHANGE 31.204

when it is available.

This change is only documentation as of this date.

Thanks to John Schoenbeck, IBM Global Services, USA.

Thanks to Larry Stahl, IBM Global Services, USA.
Change 31.203 -TYPE70 calculations of SHARE values were wrong if there

VMAC7072 were IFL engines in the CEC, because MXG output those IFL

VMXG70PR engines in TYPE70EN/EC/FORRMFI datasets and those SHAREs

Sep 23, 2013 values for the IFLs were incorrectly included in the z/OS

SHARE calculations. Only if IFLs are shared are there

non-zero SHARE values.

-ASUM70PR count of LPARIFLS in PDB.ASUM70LP/PDB.ASUMCELP

was wrong (larger than NRIFLCPU) if there were multiple

RMF intervals for the same summary INTERVAL, as when RMF

was stopped/started/changed.

Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 31.202 -Variable SM120AD4 was a missing value because AD3 and AD4

VMAC120 are 16-byte fields with 8-low order bytes of nulls and

Sep 18, 2013 MXG did not skip the AD3 low order bytes.

-But my data does not match the documentation. Following

SM120AD4 there is an 8-byte undocumented field containing

'FFFFB62000000000'X (-19830.66931 decimal) that looked to

be a GMT OFFset, but SM120ACD 'FFFFBCF10CC00000'X has the

correct value of -18000.85 for the -5 hour timezone so I

have no idea what that value actual is; it is input into

SM120TZX but not kept nor used. After that field there

are 24 reserved bytes.

Thanks to Mark Wittie, Fidelity Institutional, USA.

Change 31.201 Support for APAR OA40376 for z/OS 1.3 adds variables to

VMAC74 SMF 74 Subtype 5 RAID Rank/Extent Pool data; these vars

Sep 18, 2013 were added in z/OS 2.1 but overlooked previously:

R7451ZHL='ZHPF*LIST PREFETCH I/O REQUESTS'

R7451ZHH='ZHPF*LIST PREFETCH I/O HITS'

R7451GSF='GLOBAL*MIRROR*COLLISIONS*SIDEFILE'

R7451GSS='GLOBAL*MIRROR*COLLISIONS*SYNCHRONOUS'

APAR OA42682 adds BIT 4 value to R744FFLG.

Thanks to Lou Horton, NYS Office of Info Technology, USA.
Change 31.200 MXG 31.06 READDB2 could still fail on z/OS only, mostly

VGETOBS due to the IFCID=225 which has a unique requirement to

VMXGWORL use VMXGWORL, but recent changes to VGETOBS, which now

Sep 18, 2013 always returns the DSN of all sequential format datasets,

confused VMXGWORL which incorrectly used the _L102225

token instead of _W102225. Now, VGETOBS passes SEQ back

in the VGETMTYP macro variable, which, when detected,

redirects VMXGWORL to use the _W rather than the _L, that

might not exist. If the _W doesn't exist, then the _L

will be used, but if it does not exist, then there will

be a dataset not found failure.

-The incorrect note in comments in 31.06 READDB2 that the

PDB=XXX option of READDB2 required DISK was incorrect

and has been removed.

-Perhaps in our defense of this error:

The 31.06 VGETOBS solved two very different problems:

1. WPS failed when there was no LIBNAME when there was a

WHERE clause on PROC SQL read of DICTIONARY.TABLES.

Solved by looking at DICTIONARY.FILENAMES without a

WHERE first to see if the DD even exists.

2. SAS mounting and rereading every tape with every

execution of VGETOBS reading DICTIONARY.TABLES, even

when there was NO where clause.

Solved by keeping track of tape DDs and excluding

them from DICTIONARY.TABLES searches with a WHERE

CLAUSE NE.

-Solving problem 2 cut tape mounts in daily CICS/DB2 job

at one site from over 90 to less than 20.

Thanks to John Schoenbeck, IBM Global Services, USA.
Change 31.199 Variable S17NNDM was added to the BY list _B117NOD macro

VMAC117 to order by NODE name and to fully remove duplicates.

Sep 17, 2013 I missed this because my test data had only one value.

Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.

Change 31.198 -This JCL example changes the DSCB of a z/OS dataset from

JCLVBS2U RECFM=VBS to RECFM=U, WITHOUT copying the data, saving

Sep 17, 2013 the CPU and I/O and time for the copy. The changed file

can then be downloaded with ftp (the RECFM=U preserves

BDWs and RDWs) for sites that want to archive AND process

the file on the download platform (using RECFM=S370VBS &

LRECL=32760 on the FILENAME statement to read).

//JCLVBS2U EXEC PGM=IEBGENER

//SYSIN DD DUMMY

//SYSPRINT DD SYSOUT=*

//SYSUT2 DD DSN=ZOS.VBS.FILE.TO.CHANGE,

// DISP=MOD,DCB=RECFM=U

//SYSUT1 DD DSN=NULLFILE,DCB=*.SYSUT2

The key is to use DISP=MOD and to copy NULLFILE which

ONLY changes the DSCB attributes and does NOT touch

the actual data in the original file.

-Note: if you ONLY want to READ the data and do not need

to archive, you would use the SAS ftp Access method that

is documented in the INSTALL member to directly read the

z/OS data over ftp without prior download, only writing

the SAS datasets on the download platform.

-While the technique can also change RECFM=U to VBS, and

while you can create a RECFM=VBS file on ASCII and upload

to z/OS, you cannot simply upload that file into RECFM=U

and then change the RECFM; you must upload the VBS data

into a RECFM=U,BLKSIZE=32760 file on z/OS, and then use

either the SAS UDEBLOCK or the ASM ASMDBLKU program to

reconstruct legitimate VBS data to read on z/OS.

Thanks to Dan Kaberon, EMC, USA.
Change 31.197 After MXG 30.30, for IDMS 17, dataset IDMSINS had zero

VMACIDMS obs because only SEQN=1 exists in version 17, but MXG

Sep 12, 2013 update expected SEQN=2 and did not output.

Thanks to Gitta Janssens, ColruytGroup, BELGIUM

Change 31.196 Support for APAR PM67806 adds new QW0225DMH with total

VMACDB2 DMH GETM storage, for both DB2 V9 and DB2 V10.

Sep 11, 2013 Today's change only supports V9 pending V10 APAR doc.

Thanks to Kerry J. Sommers, John Deere, USA.

Change 31.195A Cosmetic. DEBUGGING PUT statement TY50xxxx= in line 306

VMAC50 is now commented out.

Sep 10, 2013

Thanks to Dan Case, Mayo Clinic, USA.

Change 31.195 Cosmetic. Missing values messages for TASSYTI-TASENTI

VMACIDMS division by 4096 are eliminated by making the INPUT and

Sep 9, 2013 calculation inside a conditional DO group.
Change 31.194 31.02-31.06, z/VM 6.2.12 BROKEN CONTROL RECORD error. The

VMACVMXA MXG input INCORRECTLY expected 120 bytes in STOSHD (3.16)

Sep 9, 2013 record, but this record had only 112 so the INPUT of

ASCCTRSV and ASCDSRSV are now conditional and corrected.

Thanks to David Campbell, SunTrust, USA.
Change 31.193 -An undocumented change in z/OS 2.1 increased the length

VMAC0 of ID=0 records to 68 bytes, which caused the MXG ERROR

Sep 9, 2013 message that the ID=0 record was invalid and was deleted.

Sep 19, 2013 MXG 31.06 eliminated that ERROR message and the DELETE;

31.07 creates these two new variables in TYPE0 dataset:

SMF0MSWT='SWT STC*WAIT TIME*LIMIT*MINUTES'

SMF0MTWT='TWT TSO*WAIT TIME*LIMIT*MINUTES'

These fields are non-zero only if the corresponding new

SWT or TWT keywords are specified in your SMFPRMxx.

-That length test for the TYPE 0 record is ancient, from

the days when a TYPE 0 WAS an IPL event; many times when

a SYSPROG attempted to create a USER SMF record they had

accidentally created a record with ID=0, which then was

reported as an IPL, when there had been no IPL. Now, as

BUILDPDB creates the PDB.IPLS dataset from ID=90 that

DOES report an IPL event, the erroneous deletion of these

valid ID=0 records should not impact your IPL reporting.

But, because some sites still treat a zero as an IPL,

I chose to leave the length check in place for future

a SYSPROG to trigger!

Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 31.192 Cosmetic. Comments for IMACICE1/E2/EZ tailoring now cite

UTILEXCL REPORT THREEA to find the counts of fields in those

Sep 9, 2013 optional members.
Change 31.191 READDB2 did not handle PDBOUT=WORK nor PDBOUT=XXX as

READDB2 documented, and could need an unneeded //PDB DD.

Sep 11, 2013 -PDBOUT=WORK, or PDBOUT=, was unintentionally changed by

Change 31.128 (MXG 31.05), writing DB2ACCT to the //PDB

LIBNAME instead of to //WORK, which caused an ABEND if

there was no //PDB DD in the JOB (and one is not needed

with PDBOUT=WORK). Circumvention: add a temporary DD;

//PDB DD UNIT=SYSDA,SPACE=(CYL,(500,500))

-PDBOUT=XXXXX (for some time) only wrote the T102Sxxx data

to the XXXXX LIBNAME; all DB2xxxxx Account and Statistics

datasets were instead written to their default (PDB).

-Now, PDBOUT= null, WORK, or XXXXX will create all output

only in the expected LIBNAMEs; as has been documented in

READDB2, with those PDBOUT vaLUES, you can not change the

output libnames, neither with a %LET Pdddddd=DDNAME nor

nor by using READDB2's LDB2ddd=DDNAME option.

-ACCIDENTALLY, if your PDBOUT=XXX was PDBOUT=PDB, almost

everything DID work as you expected.

Thanks to Otto Burgess, ATPCO, USA.
Change 31.190 -New variables are now INPUT and kept in TMMQQU dataset:

VMACTMMQ QUACCT QUAPPLNM QUAPPLTY QUASID QUBROWSE QUCCONNM

Sep 6, 2013 QUCFSTR QUCHNL QUCLWPRI QUCLWRNK QUCLWUSQ QUHSTAT

Oct 14, 2013 QUINPUT QUINQUR QULGD QULGT QULPD QULPT

QUMEDLGE QUMSGAGE QUMSGQTL QUMSGQTS QUNPMCLS QUOPENOP

QUOUTPUT QUPID QUPSBN QUPSID QUPSTID QUQMON

QUQMONST QUQMURID QUQSGD QUSET QUSTATQ QUTASKNO

QUTID QUTPIPE QUTRANID QUUNCOM QUURID QUURTYPE

QUUSERID QUALTDTE

-A new message reports record counts and bytes of both

compressed and uncompressed input.

-BY List macros have been revised to remove duplicates.

Change 31.189 Format $MGRMFCX for Crypto Coprocessor type expected

FORMATS '10'X for CEX41, but the value in the RMF record is an

Sep 6, 2013 '0A'x, so that value is now used for R7023CT/R7024CT.

Thanks to Michael Creech, Lender Processing Services, Inc., USA

Change 31.188 Change 31.120 added support for MQ SMF 115 ST2 SMDS/QESD

EXTY115S data new in MQ 7.1.0, but output only the first segment

IMAC115 and output it in incorrectly in MQMMSGDM, an interval

VMAC115 dataset. Since there are many structures, now, the SMDS

VMXGINIT data is output in new TYPE115S dataset with one obs for

Sep 4, 2013 for each application structure.

The IBM doc in CSQDQESD is incorrect, showing a length

of 328, but that includes the 8-bytes of the ID/EYEC,

and so only 320 bytes of data is documented. However,

the LQ length is 328, and IBM has added 8 bytes at the

end of each segment. but then, that first entry is 332!

MXG recognizes the IBM error and circumvents in code.

Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
====== Changes thru 31.187 were in MXG 31.06 dated Sep 3, 2013=========
Change 31.187 MXG 31.05. After Change 31.156, z/OS under VM only, zero

VMAC7072 obs in PDB.TYPE70. Variable VMSYSTEM is now set from the

Sep 2, 2013 NRCPUID if that APAR is not installed and then used to

force the output.

Thanks to Frank Lund, Evry AS, NORWAY.
Change 31.186 -Variable LSPRWKLD was incorrectly set to 'HIGH' instead

ASUM113 of 'LOW' when 3 LE L1MP LE 6 AND RNI LT 0.6.

Sep 2, 2013 -Cosmetic. LENGTH DEFAULT=&MXGLEN added Sep 17.

Thanks to Wayne Montefiore, CSC, AUSTRALIA.

Change 31.185 Original 31.06 VGETOBS member was not the final update.

VGETOBS See Change 31.180 for the final documentation.

Sep 3, 2013
====== Changes thru 31.184 were in MXG 31.06 dated Sep 1, 2013=========
Change 31.184 -Multiple executions of BLDSMPDB after UTILBLDP now works.

BLDSMPDB Old-style macros _SPINCNT _SPINUOW and _TIMEDIF, (and,

UTILBLDP with USERADD=, _VARUSER and _CDEUSER and any generated

Aug 31, 2013 _CDE _VAR macros are now cleared when BUILDPDB=YES is

Sep 17, 2013 specified, AFTER any generated code has been executed,

with MACRO _xxxxxx _xxxxxx % syntax to redefine an

old-style macro for reuse. This part of this change is

really likely needed only for the MXG QA job since it

is unlikely actual use would need multiple executions

of BLDSMPDB in the same SAS session, but now can be done.

-BLDSMPDB is now protected and will fail if the option to

use the "INSTREAM" SAS code created by UTILBLDP does not

exist, i.e., if that INSTREAM file has zero records.

-Other errors were found in testing on zOS with RUNDAY=PDB

which suppressed running weeklies. The logic looking for

the WEEK FILENAME failed with missing SUBSTR values.

-On zOS BUILDPDB may now point at a dataset name rather

than a DDNAME/FILENAME as it always could on ASCII.

Change 31.183 TYPE50 OSA-EXPRESS READ variables were incorrectly INPUT

VMAC50 TY50REDE /*OSA-EXP*REPLN*DEFR*FOR RD*/

Aug 30, 2013 TY50RDEX /*OSA-EXPREADS*EXH*FOR RD*/

TY50SBRD /*OSA-EXP*SBAL*COUNT*FOR RD*/

TY50PKCN /*OSA-EXP*PACKET*COUNT*/

and these Write variables are now created

TY50PKAC='OSA-EXPRESS*ACCELERATED*PACKET*COUNT'

TY50BYAC='OSA-EXPRESS*ACCELERATED*BYTE*COUNT'

Thanks to John M. McLaughlin, Bank of America, USA.
Change 31.182 -The MXG message SUCCESSFULLY COMPLETED READING SMF now

VMACSMF has new text that reports (mostly for MXG diagnostics) if

Aug 28, 2013 *** THE INPUT SMF FILE DID NOT END WITH ID=3, BUT

*** THIS CAN BE NORMAL - SEE CHANGE 31.182 TEXT.

which MIGHT be an indication that SMF data was lost.

Each SMF file created OR copied by IFASMFDP/IFASMFDL ends

with an SMF ID=3 record, and so even concatenations of

SMF dumps will end with an ID=3 (in fact, each copy with

or subset adds yet another ID=3 at the end of output).

So if the last record is not ID=3, it could be a problem.

For example, a disconnect using the ftp access method, or

during download, or an overlooked out-of-disk-space issue

could be detected by its absence.
-BUT THIS CAN BE NORMAL: If your data has been sorted, or

if you used a utility program that removes type 2 and 3

SMF records (e.g., SMFUTIL, but it could be any program

that processes the SMF data before you read it), or if

you used SAS (AND NOT IFASMFDP, which writes a 2 and 3

when used to copy SMF) and either selected records or

used OPTIONS OBS=nnn; to limit the number of SMF records

read when testing: THESE ARE NOT ERRORS AND THE MESSATE

HAS NO IMPACT.
-If the last record is the ID=3, that text then reads

*** AND THE INPUT SMF FILE ENDED WITH EXPECTED ID=3.***

If absence of that ID=3 would be an error in your SMF

processing, where you ALWAYS expect complete dumped data,

variable ENDISID3 can be used in your IMACFILE/&MACFILE

tailoring to take more aggressive action.

Change 31.181 -RMF III Support for z/OS 2.1 plus Enhancements and Fixes.

ADOCRMFV -Support for z/OS 2.1 changes to the ASI, CFI, CPDCB, and

ASMRMFV GEI RMF III tables.

EXZRBCHP -Two new CFI table sections CFICHPAS (Channel Path) and

EXZRBSCM CFISSCMS (Storage Class Memory) added with z/OS 2.1 are

JCLCRMFV now created by ASMRMFV, and VMACRMFV creates datasets:

JCLDRMFV dddddd dataset description

JCLRMFV ZRBCHP ZRBCHP CFICHPAS CHANNEL PATH

VMACRMFV ZRBSCM ZRBSCM CFISSCMS STORAGE CLASS MEMORY

VMXGINIT -New ZRBCHP dataset variables (20):

ZASMRMFV ZDATE ='ZEE DATE*ZEE OBS*WAS CREATED'

Aug 30, 2013 CFICHAID='HOST CHANNEL ADAPTER ID'

CFICHAPN='HOST CHANNEL ADAPTER PORT NUMBER'

CFICHEIN='INDEX OF CFI TABLE ENTRY'

CFICHFLAGS1='1ST*CHANNEL PATH VALIDITY FLAG'

CFICHLAT='CHANNEL PATH LATENCY TIME'

CFICHOPM='CHANNEL PATH OPERATION MODE'

CFICHPCP='PHYSICAL*CHANNEL*PATH*ID'

CFICHPID='CHANNEL*PATH*ID'

CFICHSAP='SAP-S TO WHICH CHP IS ACCESSIABLE'

CFICHSTA='CHANNEL PATH STATUS FLAGS'

CFICHTYPE='CHANNEL PATH TYPE'

CFIENNAM='NAME OF*COUPLING*FACILITY'

CFIENSYS='NAME OF*SYSTEM'

SSHGOMNT='GATHERER*MINTIME*OPTION'

SSHRMFVN='RMF*VERSION*NUMBER'

SSHSMPNR='NUMBER*OF VALID*MINTIME*SAMPLES'

SSHTIBEG='BEGIN TIME*FOR THIS*SET OF SAMPLES'

SSHTIEND='END TIME*FOR THIS*SET OF SAMPLES'

SYSPLEX ='SYSPLEX*NAME*FROM*COUPLEXX'

SYSTEM ='SYSTEM*ID'

SHIFT ='SHIFT*OF*START'

-New ZRBSCM dataset variables (21):

ZDATE ='ZEE DATE*ZEE OBS*WAS CREATED'

CFISCALG='SCM*ALGORITHM*TYPE'

CFISCEMA='EST MAX*AUSMENTED*SPACE*4K BLOCKS'

CFISCEME='EST MAX*LIST ELEMENTS*RESIDE*IN SCM'

CFISCEML='EST MAX*LIST ENTRIES*RESIDE*IN SCM'

CFISCENE='EXIST STRUCT*LIST ELEMENTS*RESIDE*SCM'

CFISCENL='EXIST STRUCT*LIST ENTRIES*RESIDE*IN SCM'

CFISCFAU='FIXED*AUGMENTED*SPACE*4K BLOCKS'

CFISCIUA='AUGMENTED*SPACE IN USE*4K BLOCKS'

CFISCIUS='SCM MEMORY*IN USE*4K BLOCKS'

CFISCMAX='MAX*SCM*STRUCTURE*CAN USE*4K BLOCKS'

CFISCNAM='NAME OF CONNECTED STRUCTURE'

CFISCVER='STRUCTURE*VERSION*NUMBER'

CFIENNAM='NAME OF*COUPLING*FACILITY'

CFIENSYS='NAME OF*SYSTEM'

SSHGOMNT='GATHERER*MINTIME*OPTION'

SSHRMFVN='RMF*VERSION*NUMBER'

SSHSMPNR='NUMBER*OF VALID*MINTIME*SAMPLES'

SSHTIBEG='BEGIN TIME*FOR THIS*SET OF SAMPLES'

SSHTIEND='END TIME*FOR THIS*SET OF SAMPLES'

SYSPLEX ='SYSPLEX*NAME*FROM*COUPLEXX'

SYSTEM ='SYSTEM*ID'

SHIFT ='SHIFT*OF*START'

-ASMRMFV now exploits z/Architecture (zSeries)

instructions to relieve 4K base register addressing

constraints and improve performance. ASMRMFV should run

without error on this hardware. zSeries machines have

been available since 2000.

-MXG users with only pre-z/Architecture machines available

can install the legacy version of ASMRMFV called

ZASMRMFV. Contact MXG Technical Support for details.

-ZASMRMFV includes all Change 31.181 features for z/OS 2.1

support, but is functionally stabilized and will not be

further enhanced.

-ASMRMFV WTO messages RMFV099S and Abend U0998 will be

issued if execution is attempted on a non-zSeries

processor. This prevents an abrupt and unexplained S0C1

Abend that would otherwise occur. If this occurs either

run ASMRMFV on a zSeries machine or use ZASMRMFV instead.

-Initial message RMFV000I will indicate whether the

current ASMRMFV or legacy version ZASMRMFV is being used.

-Four internal ASMRMFV subroutines have been migrated into

mainline code to eliminate the entry/exit linkage CPU

overhead required for each call.

-ASMRMFV now supports keywords up to 10 characters in

length.

-ASI table bit string field ASIMSTS (Miscellaneous States)

is now decoded into 8 new Y/N valued variables in the

ZRBASI data set.

-New ZRBASI dataset variables (10):

ASI1MBFF='1MB*FIXED FRAMES*PAGEABLE*DREF-MEM OBJS'

ASI1MBPF='PAGEABLE*PAGEABLE*DREF-MEM OBJS'

ASICICST='CICS TOR*MANAGED TO*REGION GOALS?'

ASICPUPR='CPU*PROTECTION*ASSIGNED?'

ASIIOPGH='I/O PRIORITY*GROUP HIGH*ASSIGNED?'

ASIMAOSC='MANAGE AS*TO GOALS*OTH SERV CLASSES?'

ASIOMVS ='ADDRESS*SPACE*IS OMVS*RELATED?'

ASIPRMRT='PREVENT*REGN MGT*BY RESPTIME*GOALS?'

ASISDCAS='SERVICE TRANS*IN DIFF CLASS*THAN AS?'

ASISTGPR='STORAGE*PROTECTION*ASSIGNED?'

-CPC table bit string field LCPUCHIN (Processor Status

Indicators) is now decoded into 7 new Y/N valued

variables in the ZRBLCP data set.

-New ZRBLCP dataset variables (21):

CPCCAPG ='LPAR*BELONGS TO*CAPACITY GROUP?'

CPCHOME ='THIS IS*THE HOME*PARTITION?'

CPCLPARI='LPAR DATA*INVALID?'

CPCLPMAX='LPAR PROCESSORS*DEFINED*EXCEED*LIMIT?'

CPCUPIDV='USER*PARTITION ID*IS VALID?'

CPCUSEIW='USE INIT WEIGHT*FOR CAP GROUP*PROJECT?'

CPCWMGT ='WLM WEIGHT*MANAGEMENT*ENABLED?'

LCPUABSL='ABSOLUTE LIMIT*ON LPAR USAGE*CHANGED?'

LCPUDED ='PROCESSOR DEDICATED?'

LCPUHIPD='HIPERDISPATCH*MODE IS ACTIVE?'

LCPUHWCL='ABS LIMIT*LPAR USAGE*THIS TYPE'

LCPUICAP='INITIAL*CAPPING*ON?'

LCPUICST='INITIAL CAPPING*STATUS CHANGED?'

LCPUMAWC='MAXIMUM*WEIGHT*CHANGED?'

LCPUONL ='PROCESSOR*ONLINE?'

LCPUONOF='PROC*ONLINE TO*OFFLINE OR*VICE-VERSA?'

LCPUPRNA='PROCESSOR*NOT AVAILABLE*IN MINTIME?'

LCPUSD ='PROC*SHARED TO*DEDICATED OR*VICE-VERSA?'

LCPUWCCH='WAIT*COMPLETION*CHANGED?'

LCPUWCN ='WAIT*COMPLETION*NO?'

LCPUWCY ='WAIT*COMPLETION*YES?'

-CPC table bit string field LCPUSTIN (Processor Status

Change Indicators) is now decoded into 6 new Y/N valued

variables in the ZRBLCP data set.

-Part of the GEI table was not being processed by VMACRMFV

and new fields added by z/OS 2.1 are now also supported

in the ZRBGEI dataset.

-The PDB build for the ZRBGEI dataset variable

GEICPUOL='AVERAGE*OF ONLINE*PROCESSORS' was inputting

from a GEI table field that has been reserved since z/OS

1.1 and was always zero. GEICPUOL and derived variable