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

VMACVMXA incorrectly spelled/kept SSH_FSRIPV6.

VMACBETA -VMACVMXA STOLMODE is labeled.

ASUMTAPE -VMACBETA Dataset Labels clarified for BETA7, BETA8 and

ASUM113 BETA22. Variable BETARTIME is now the datetime value with

Jan 16, 2013 BETARDATE no longer kept in BETA51 dataset.

-ASUMTAPE Temporary dataset JES3MNTS is now deleted.

-VMAC99 Variable S99CCCCECUTIL label, asterisk removed.

-ASUM113 Variables SMF70CIN/CIX/CPA/HDM/ONT/PAT/CECSER

CPUTYPE LPARWLMG are labeld, PAT and ONT formatted.

Thanks to Chris Weston, SAS ITRM, USA.
Change 30.289 -RMF III Performance Enhancements, blocking, and Fixes

ASMRMFV -INCOMPATIBLE. ASMRMFV & VMACRMFV should always be used

EXZRBUWX from the same MXG Version. Using a new VMACRMFV to read

IMACRMFV data created by an old ASMRMFV may not work. Specifically

JCLCRMFV with this change, to populate the new variables in the

JCLRMFV UWD files, you must use ASMRMFV and VMACRMFV with 30.289.

VMACRMFV See MXG SOURCLIB member JCLASM3 for the example JCL to

VMXGINIT assemble and link-edit the ASMRMFV program. Skipping this

Jan 20, 2013 action will result in many missing UWD file variables and

is not recommended.

-The SHD (Sample Header), RED (Resource Data), and UWD

(USE/WAIT) RMF III tables are now blocked in the RMFBSAM

output file by ASMRMFV for improved I/O performance.

-UWD records are now extended with related data based on

type to make them useful. In the past these records had

no identification of the address space, device, nor the

enqueue that related to the USE/WAIT counts. The table

name now displays as UWDX in ASMRMFV output.

-VMACRMFV has been changed to support these new blocked

tables and the new UWD extended data.

-NOTE: VMACRMFV will no longer accept old unblocked UWD

records. If found, these are deleted and an MXGERROR

message issued once. Processing continues. The old

records had no information to show which address space

the USE/WAIT record was for and so had no practical

value.

-There is a new ZRBUWXCF dataset for UWD type X'0A' XCF

Message entries that includes new variables:

UWDXCDEV='DEV NUM*OF PATH*W MSG PENDING'

UWDXCMAS='ASID OF*MEMBER*SENDING*MSG'

UWDXCHAS='ASID THAT*INITIATED*MSG OUT'

-Validation of UWD entry flags and entry types is

improved. The UWD entry will be skipped for invalid data

and no Abend will occur.

-All ZRBUW* files include the following new variables:

UWDDELAY='DELAY*SAMPLES'

UWDREDID='PARENT*RED ID'

UWDSSN ='UWD*SAMPLE*SEQUENCE*NUMBER'

UWDUSING='USING*SAMPLES'

UWDUWDLE='UWD*BASE*LENGTH'

UWDUWDLX='UWD*EXTENDED*LENGTH'

UWDVERG3='UWD*VERSION*NUMBER'

-All ZRBUW* files now have the following address space

variables from the related ASI table entry added:

ASIENIDX ASIJOBNA ASIASINR ASIFLAG1 ASIJCLAS ASIJOBS

ASIJESID ASIMSTS TYPETASK

-ZRBUWDEV, ZRBUWSTO, and ZRBUWMNT files now have the

following variables from the related DVT table entry

added:

DVTVOLI DVTENIDX DVTDEVNR DVTFLAG1 DVTFLAG2 DVTMEXN

DVTTYP DVTIDEN DVTCUID DVTLCUNR DVTFLAG3 DVTHPCO

DEVTYPE DEVPLPA DEVCOMM DEVLOCL DEVSWAP DVTHPAV

-The ZRBUWENQ file now has the following variables from

the related ENT table entry added:

ENTENIDX ENTMAJNA ENTMINNA ENTSCOPE ENTFLAGS

-The ZRBASI file has two new variables for Memory Object

analysis:

ASITMO ='TOTAL*MEMORY*OBJECTS'

ASITMOBY='TOTAL*MEMORY*OBJECT*BYTES'

-The ZRBASM file has four new variables added in support

of UWD extensions:

ASMUWDHL='UWD*HEADER*LENGTH'

ASMUWDAL='UWD ASI*EXTENSION*LENGTH'

ASMUWDDL='UWD DEV*EXTENSION*LENGTH'

ASMUWDEL='UWD ENQ*EXTENSION*LENGTH'

-The RMFBASM file version is raised to X'02' from X'01';

-A new final message RMFV999I is now issued at the end of

ASMRMFV processsing. The message shows the total number

of WARNINGS, ERRORS, SEVERES (severe errors), and the

final Return Code. In the case of an abend the Abend

Code and Reason Code are also shown. The message appears

in both SYSPRINT and in the JES JOB log. This provides

one message to check to get the final status of ASMRMFV.

-A BYTES WRITTEN column is added to all ASMRMFV RMFV105I

messages for each combination of DATA ACTION and RMF III

table. The column is displayed regardless of the

BYTES/NOBYTES parameter setting. This shows what tables

are contributing most to the RMFBSAM output file size.

The byte count doesn't include the 4 bytes for each BDW

(block descriptor word).

-Support for the RMF III ARCHAIC PGP table is suppressed,

but could be enabled if needed. The PGP does NOT appear

in ASMRMFV detail and summary reports when disabled. The

PGP is only generated and available in z/OS Compatibility

Mode. IBM support for Compatibility Mode ended in March

2002 with the release of z/OS 1.3 as Goal Mode became

required. But it was safer to just suppress than to

remove code that will never be executed.

-ASMRMFV no longer abends when an invalid RED entry is

found. Instead the record is skipped.

-ASMRMFV message RMFV014I is now always issued regardless

of the DETAIL/NODETAIL setting.

-New ASMRMFV message RMFV035E is now issued when errors

are detected processing the SPG, RED, UWD, DSH, or SSH

tables. These are intended to attract the attention of

the support person who might otherwise overlook the less

obvious record SKIP counts.

-NOTE: Message RMFV035E can occur when the ERBRMFxx

PARMLIB member for RMF Monitor specifies a non-existent

Storage Group in the SGSPACE ADD parameter. RMF Monitor

III message ERB329I indicates this condition: ERB329I

III: ONE OR MORE STORAGE GROUP NAMES ARE NOT DEFINED IN

SMS. In this case the entire SPG table is skipped as the

integrity of the entries cannot be trusted as confirmed

by RMF Support. Correct the ERBRMFxx start up member for

RMF III as soon as possible and modify or restart RMF III

to restore SPG table processing. Corrupted SPG tables

cannot be processed by TYPERMFV.

-ASMRMFV message RMFV033E is now RMFV033S to indicate a

severe error when an I/O error occurs.

-The handling of unsigned halfword binary integers in RMF

III table fields by ASMRMFV is corrected when the high

order bit is on.

-Prologue documentation in the ASMRMFV source has been

updated to provide detail on BYTES WRITTEN column and the

skipping of UWD records.

-Member JCLRMFV in MXG SOURCLIB now shows examples of

building an RMF Monitor III PDB by the Direct JCL method.

-Member JCLCRMFV in MXG SOURCLIB now shows examples of

building an RMF Monitor III PDB by the Batch TSO CLIST

method.

Thanks to Steve Dyck, The Canadian Depository for Securities, Canada

Thanks to Neil Ervin, Wells Fargo, USA

Change 30.288 Velocity Software zVPS (a/k/a XAM) records are Variable

UXAMNRDW Length CMS files but when first copied to their ftp site

Jan 15, 2013 so I could ftp to ASCII to test new data, the two-byte

CMS record length field had been stripped, so I wrote

this heuristic that uses the structure of the first 16

bytes of each XAM logical record to create a readable

"z/OS" VB file. However, here is the correct way to

create a "RECFMU" file from a CMS variable file. This

note has been added to the MXG member FTPING:

23. Syntax to copy the XAM z/VM CMS Variable File to

RECFMU on z/VM:

z/VM exec to pipe the XAM CMS Variable data file (which

contains a two-byte record length) thru the BLOCK command

to create a file with the two four-byte z/OS BDW and RDW

fields; that output file can then be downloaded by ftp as

BINARY to an ASCII system where the file can be read with

SAS INFILE with RECFM=S370VBS and LRECL=32760. The

output filetype "RECFMU" is used as this data is the same

date with preserved BDW/RDW on z/OS created with

DCB=RECFM=U.
parse arg fn ft fm
'ACC FTPPOOL:MXG.XAMDATA x (FORCERW'
'pipe < 'fn ft fm,

' | block 32760 V',

' | >' fn 'RECFMU X'

1) The Parse arg fn ft fm is actual code.

It assumes you would start executing the EXEC with:
inputfilename inputfiletype inputfilemode
Parse arg pulls in the filename/type/mode that you

specified when you started the EXEC.

2) Looking at FTPPOOL:MXG.XAMDATA,

FTPPOOL is the SFS filepool name.

MXG is the filespace name (USERID)

XAMDATA is the subdirectory under the FTPPOOL root

Maybe a good PC analogy would be

filepool name = drive letter (such as C:);

USERID = a directory under C:(such as MXG)

subdirectory something under MXG (C:\MXG\XAMDATA)

Thanks to Dewayne Thomas, Velocity Software, ???
Change 30.287 Executing MXG on ASCII to read compressed CICS/DB2 SMF is

JCLSPLIT generally much faster if you FIRST decompress SMF records

JCLSPLT1 on z/OS (using IBM ASM PGM=DFH$MOLS, PGM=DSNTSMFD, or SAS

JCLSPLT2 and EXITCICS - all call IBM's CSRCESRV ASM service to do

DFH$MOLS the decompression) and then SECOND, you run MXG on ASCII

DSNTSMFD to read that uncompressed SMF file. The simpler process

Jan 19, 2013 of running MXG on ASCII to directly both read compressed

SMF data AND to uncompress it is MUCH slower because the

CSRCESRV doesn't exist on ASCII and the ASCII alternative

byte-by-byte SAS code decompress algorithm is functional

but it is VERY CPU intensive (by a factor of MANY times).
Newsletter SIXTY-ONE had execution comparison results.
Only if you have network contention when MXG reads the

uncompressed data might your results be different; you

should at least test this alternative.
These members provide examples of how to parallelize

the MXG "BUILDPDB" process and first decompress on z/OS.

JCLSPLIT - changes are primarily comments but the split

of IO and MQ data is commented out as well as

the SYSIN for those datasets

JCLSPLT1 - the same as JCLSPLIT but also contains steps

for DFH$MOLS and DSNTSMFD

JCLSPLT2 - the same as JCLSPLT1 but uses temp dataset

names for the outputs, runs DFH$MOLS, DSNTSMFD

and then combines all the temp datasets with

IFASMFDP to be fed to MXG

DFH$MOLS - JCL to run DFH$MOLS

DSNTSMFD - JCL to run DSNTSMFD
Change 30.286 A new program that graphically compares values over time.

ANALCOMP Any number of variables from any number of SAS datasets

Jan 14, 2013 are aligned for starting days, weeks, months, or years,

with ODS Graphic's PROC SGPLOT (included in Base V9.3).

V9.2 SGPLOT does require SAS/GRAPH. One of many examples:

Compare hourly CPU time for each Service and Reporting

Class, for two weeks in November, from MONTH.TYPE72GO:

%ANALCOMP(INDATA=MONTH.TYPE72GO,

VARS=CPUTM,

COMPINTV=WEEK,

COMPARE=11NOV12 18NOV12,

SUMMARY=YES,

XAXIS=HOUR,

DATETIME=STARTIME,

SORTBY=SYSTEM RPRTCLAS SRVCLASS);
Change 30.285 Support for BETA93 subtype 51 which had been overlooked.

EXTYBETJ This record has 10 possible field formats, so there are

IMACBETA ten variables BETAFIELDC/H/I/V/D/T/S/B/F/P created for

VMACBETA Character/Hex/Integer/Variable/Date/Time/Small/Byte/Flag/

VMACBETA Pool which are populated based on BETAFTYPE value. But,

Jan 14, 2013 the Character type has both EBCDIC and HEX values so it

must be displayed as a hex string, since the vendor does

not identify which Field Names are text versus hex.

Change 30.284 Support for additional fields in PHYSVOL and VOLUME file.

VMACTAPR Now, PHYSVOL has 67 variables and VOLUME has 71.

Jan 11, 2013

Thanks to Xiaobo Zhang, Fiserv, USA.

Change 30.283 When UTILEXCL found an UNKNOWN FIELD, the circumvention

UTILEXCL to skip over that field could generate 180 syntax errors,

Jan 11, 2013 depending on the syntax generated for the prior and/or

the subsequent field. This update revises the logic to

provide a more reliable circumvention. UNKNOWN FIELD

message can occur when a back-level of UTILEXCL is used

to process a new CICS version's dictionary, or when there

are "user" fields created by the site with names other

than "USER". Sending the UTILEXCL log executed with

_BLDDICT; _BLDEXCL; _RPTEXCL ; to [e-mail]

is the correct "circumvention", as that allows MXG to

add support for a user field or detect back-level.

Thanks to Victoria Lepak, Aetna, USA.
Change 30.282 Comments updated to document all parameters. The default

ASUMDBSS SUMBY list includes SHIFT, so if you change the interval

VMXGDBSS value to DATE, wanting one observation per day, you get

Jan 10, 2013 multiple observations for each SHIFT value. You need to

remove SHIFT from the SUMBY list to get daily output:

%VMXGDBSS(

D2STATIN=&PDBMXG..DB2STATS,

D2STATOT=&PDBMXG..ASUMDBSS,

D2GBPSIN=&PDBMXG..DB2GBPST,

D2GBPSOT=&PDBMXG..ASUMDBSG,

D2BPSIN =&PDBMXG..DB2STATB,

D2BPSOT =&PDBMXG..ASUMDBSB,

ASUMINTV=DATE,

SUMBY=QWHSSSID BEGTIME,

INVKBY=DAILYDBSS

);

Thanks to Stu Samuels, Blue Cross Blue Shield of Illinois, USA.

Change 30.281 -BUILD005/BUIL3005 used in ONLYJOBS (create only PDB.JOBS)

BUILD005 set a return/condition code four for a PROC COPY message

BUIL3005 "WARNING: IN= and OUT= are the same" that is eliminated

ONLYJOBS by this change that creates an internal %SPINCOPY macro

ONLYJOBZ that conditionally issues the PROC COPY only when they

Jan 19, 2013 are different (as they are in all other uses of BUILD005)

For ONLYJOBS, they are correctly the same and the COPY

is not needed nor wanted.

-The original ONLYJOBS is now stored as ONLYJOBZ as a fine

example of how to tailor BUILDPDB using the old-style

macros, because the new ONLYJOBS now uses the newer and

more powerful %UTILBLDP macro (but still needing some of

those old-style macros) to create ONLY the datasets that

are actually needed by BUILD005.

Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 30.280 -MXG 30.10 iteration, IFCIDS=STATS still failed even after

READDB2 Change 30.257, generating DB2STAT4 NOT SORTED ERROR, due

Jan 9, 2013 to my insufficient testing with only OBS=0. You can use

IFCIDS=STATISTICS with 30.10 to circumvent this error.

-And the intended change to NOT create T102S106 unless it

was requested went too far, since it was NOT created when

106 was in the list of requested IFCIDS. (30.01 can be

circumvented by adding T102106=YES as an argument).

Thanks to Rachel Holt, Fidelity Systems, USA.
Change 30.279 The VFMT102 mapping of DBID/OBID/PSID value to the DB2

VFMT102 name has been reset to the safer algorithm that uses

Jan 8, 2013 PROC SORT to remove duplicate values; recent attempts to

construct the format and/or to use a MERGE have never

completely removed the overlap in values; that code is

kept in ZFMT102 from the last try until time and more

guidance from IBM DB2 support is available.
Change 30.278 -The MXG-created TASZIPTM/TASELGTM variables in CICSTRAN,

VMAC110 CICS/TS 5.1, were only populated when UTILEXCL was used

UTILEXCL to create an IMACEXCL, but are now populated in default

VMXGUOW 5.1 VMAC110 code, from IBM CPUTONCP/OFFLCPUT fields also

Jan 7, 2013 used to create CPUTONTM/CPUTONCN/OFFLCPUTM/OFFLCPCN in

Jan 13, 2013 Change 30.228 (CICS/TS 5.1 and APAR OA38409 is required).

Labels are corrected to provide clearer documentation:

CPUTONTM='TASK TOTAL*CPU TCB TIME*ON CP ONLY'

CPUTONCN='TASK TOTAL*DISPATCHES*ON CP ONLY'

TASCPUTM='TASK TOTAL*CPU TCB TIME*ON BOTH*CP+ZIIP'

(This is NOT NEW - has always been the sum of

CP and (normalized) zIIP CPU time).

TASDSPCN='TASK TOTAL*DISPATCHES*ON BOTH*CP+ZIIP'

TASZIPTM='TASK*ZIIP ONLY*CPU TCB*TIME'

TASELGTM='TASK*ZIIP-ELIGIBLE*RAN ON CP*CPU TCB TIME'

OFFLCPTM='TASK*ZIIP-ELIGIBLE*RAN ON CP*CPU TCB TIME'

OFFLCPCN='TASK*ZIP-ELIGIBLE*RAN ON CP*DISPATCHES'

-The calculation of TASZIPTM and TASELGTM were not shown,

and TASELGTM WAS WRONGLY CALCULATED prior to this change;

TASELGTM is equal to OFFLCPTM, but having created it, I'm

now compelled to keep the two identical variables:

TASELGTM=OFFLCPTM;

TASZIPTM=TASCPUTM-CPUTONTM;

-UTILEXCL now creates a new MXGNOTE in the IMACEXCL that

identifies the creation date of that IMACEXCL on the SAS

log when it is included, to confirm there is a tailored

IMACEXCL in use.

-ASUMUOW now keeps TASZIPTM TASELGTM and CPUTONTM.

Change 30.277 Support for TMON for CICS Release 3.4 for CICS/TS 5.1

EXMONTV INCOMPATIBLY adds variables to existing datasets and

IMACTMO2 creates one new dataset:

VMACTMO2 DDDDDD DATASET DESCRIPTION

VMXGINIT MONTV MONITV JVM SERVER STATISTICS

Jan 6, 2013 -Dataset MONITASK new variables:

TAU64HWM='USER 64 POOL HWM'

TAC64HWM='CICS 64 POOL HWM'

TASTCPUT='STANDARD*CP*CPU*TIME'

TASTCPUC='STANDARD*CP*COUNT'

TASTCPOT='OFFLOAD*ON*STD*CPU'

TASTCPOC='OFFLOAD*ON*STD*COUNT'

-Dataset MONISYST new variables:

TIENCCTM TIHU64ID TIU64HWM TIHC64ID TIC64HWM TISTCPUT

TISTCPUC TISTCPOT TISTCPOC

-Dataset MONIPA new variables:

PAACAPPL PAACMAJV PAACMICV PAACMINV PAACOPER PAACPLAT

PACECMCH PACECMDL PACLIPPO PACURTAS PAISIPNM PAMAXTAS

PAOADAT1 PAOADAT2 PAOADAT3 PAOADID PAOAPPL PAOASTRT

PAOCLIPA PAOCLIPP PAOFCTNM PAONETWK PAOPORTN PAOTCPSV

PAOTRAN PAOTRNUM PAOUSER PAOUSRCO PAPHAPPL PAPHCNT

PAPHNTWK PAPHSTRT PAPHTRAN PAPHTRNO PASOCIPH PAWBATNM

PAWBPINM PAWBPRON PAWBSVCN PAWBSVON PAWBURNM PASC64CC

PASC64CH PASC64FS PASC64GS PASC64SC PASC64UC PASC64UH

PADHDLC PAWMQREC PACPUTOC PACPUTOT PAOFFLCC PAOFFLCT

PAMQGETC PAMQGETT PAMQGETC PAMQGETT PACLIPAD PAFCVSWC

PAFCVSWT PAFCXCWC PAFCXCWT PAISALWC PAISALWT PAISIOWC

PAISIOWT PAJVMTHC PAJVMTHT PAMQSRBC PAMQSRBT PAMXDLYC

PAMXDLYT PAROMODC PAROMODT PASOMODC PASOMODT PAT8CPUC

PAT8CPUT PATCALWC PATCALWT PATDELWC PATDELWT PATDILWC

PATDILWT PABFDGSC PABFTOTC PAECEFOC PAECEVNC PAECSEVC

PAECSIGC PAEICTOC PAISALOC PAMLXMLC PAMLXSSL PAPGCSTH

PATIASKC PATITOTC PAWBISSC PAWBSFCC PAWBSFTC PAWBSREL

PAWBSRSL PAWSACBC PAWSACGC PAWSAEPC PAWSATOC

-Dataset MONIPI new variables:

PIPCDLL PIPCDRL PIPCLCC PIPCXCC PIPCDCC PIPCRCC

PIPCRCL PIICSCC PIICSCD PIICSRC PIICSRD PIWBROC

PIWBWOC PIWBIRC PIWBI1C PIWBOSC PIWBO1C PIWBPRC

PIWBBOC PIWBIWC PIWBRDL PIWBWDL PIPGCTC PIPGBCC

PIPGGCC PIPGPCC PIPGMCC PIPGGCL PIPGPCL PIPGCCC

PIISALOC PIEICTOC PIECSIGC PIECEFOC PIECEVNC PIECSEVC

PITIASKC PITITOTC PIBFDGSC PIBFTOTC PIMLXMLC PIWSACBC

PIWSACGC PIWSAEPC PIWSATOC PIWBSFCC PIWBSFTC PIWBISSC

PIPRTXCD PIL9CPUC PIL9CPUT PIX8CPUT PIX8CPUC PIX9CPUT

PIX9CPUC PIT8CPUC PIT8CPUT PIXTDLYT PIXTDLYC PISTDLYT

PISTDLYC PIMXDLYC PIMXDLYT PICMDLYC PICMDLYT PIFCXCWC

PIFCXCWT PIFCVSWC PIFCVSWT PIISIOWC PIISIOWT PIJVMTHC

PIJVMTHT PIMQSRBC PIMQSRBT PITDILWC PITDILWT PITDELWC

PITDELWT PIROMODC PIROMODT PISOMODC PISOMODT PIMQGETC

PIMQGETT PIISALWC PIISALWT PITCALWC PITCALWT PICPUTOC

PICPUTOT PIOFFLCC PIOFFLCT PIPHCNT PISC64CC PISC64FS

PISC64GS PISC64SC PISC64UC PIWMQREC

-The SMF format SMF 110 "CICSTRAN" records that can be

created by TMON don't contain the eight DFHRMI S001-S008

fields, previously optional, now created by default in

the IBM CICS/TS 5.1 SMF 110 records and thus expected in

the default MXG VMAC110 code for 5.1, so you will need to

use the UTILEXCL program to create a tailored IMACEXCL to

process these SMF records from TMON Version 3.4.
Change 30.276 Support for Mainview for CICS Release 6.5 for CICS/TS 5.1

EXMVCITD COMPATIBLY adds variables to CMRDETL and creates these

EXMVCITS two new datasets:

IMACMVCI DDDDDD DATASET DESCRIPTION

VMACMVCI MVCITD MVCITDQU TD QUEUE

VMXGINIT MVCITS MVCITSQU TS QUEUE

Jan 6, 2013 -New variables in CMRDETL for CICS/TS 3.2 and later:

T6EXCFLC='CFDT*LOCK*WAIT*COUNT'

T6EXCFLT='CFDT*LOCK*WAIT*TIME'

T6EXCFNC='CFDT*NONLOCK*WAIT*COUNT'

T6EXCFNT='CFDT*NONLOCK*WAIT*TIME'

T6EXLBC ='LSR*BUFFER*WAIT*COUNT'

T6EXLBT ='LSR*BUFFER*WAIT*TIME'

T6EXLSC ='LSR*STRING*WAIT*COUNT'

T6EXLST ='LSR*STRING*WAIT*TIME'

T6EXSTGC='STORAGE*WAIT*COUNT'

T6EXSTGT='STORAGE*WAIT*TIME'

T6EXTBC ='TS*BUFFER*WAIT*COUNT'

T6EXTBT ='TS*BUFFER*WAIT*TIME'

T6EXTMPC='TEMP*STG*WAIT*COUNT'

T6EXTMPT='TEMP*STG*WAIT*TIME'

and new CMRDETL variables populated only in CICS/TS 5.1:

T6E68XCT='68*EXTENSIONS'

T6EAPPLN='APPLICATION*NAME'

T6ECECID='CEC*MODEL*ID'

T6ECECTP='CEC*MACHINE*TYPE'

T6ECHWMG='GCDSA*HWM'

T6ECTSKS='CURRENT*TASKS AT*TRAN*ATTACH'

T6EFCSWC='FC VSAM*STRING*WAIT*COUNT'

T6EFCSWF='FC VSAM*STRING*WAIT*FLAG'

T6EFCSWT='FC VSAM*STRING*WAIT*TIME'

T6EFCXWC='FC*EXCLUSIVE*WAIT*COUNT'

T6EFCXWF='FC*EXCLUSIVE*WAIT*FLAG'

T6EFCXWT='FC*EXCLUSIVE*WAIT*TIME'

T6EISAWC='IS*ALLOCATE*WAIT*COUNT'

T6EISAWF='IS*ALLOCATE*WAIT*FLAG'

T6EISAWT='IS*ALLOCATE*WAIT*TIME'

T6EMAJVR='APPL*MAJOR*VERSION*NUMBER'

T6EMICVR='APPL*MICRO*VERSION*NUMBER'

T6EMINVR='APPL*MINOR*VERSION*NUMBER'

T6EMPPTX='POLICY*THRESHOLDS*EXCEEDED'

T6EMTSKS='MXT*AT*TRAN*ATTACH'

T6EOFCPC='ELIGIBLE*CPU TIME*COUNT'

T6EOFCPF='ELIGIBLE*CPU TIME*FLAG'

T6EOFCPT='ELIGIBLE*CPU TIME'

T6EONCPC='STD*PROC*CPU TIME*COUNT'

T6EONCPF='STD*PROC*CPU TIME*FLAG'

T6EONCPT='STD*PROC*CPU*TIME'

T6EOPERN='OPERATION*NAME'

T6EPLATN='PLATFORM*NAME'

T6ERODLC='RO*TCB*DELAY*COUNT'

T6ERODLF='RO*TCB*DELAY*FLAG'

T6ERODLT='RO*TCB*DELAY*TIME'

T6ESC64F='TOTAL*BYTES*FREED'

T6ESC64G='TOTAL*BYTES*OBTAINED'

T6ESC64S='SHARED*STORAGE*GET MAINS'

T6ESCCGG='GCDSA*GET*MAINS'

T6ESCUGG='GUDSA*GET*MAINS'

T6ESOCPH='CIPHER*SELECTED'

T6ESODLC='SO*TCB*DELAY*COUNT'

T6ESODLF='SO*TCB*DELAY*FLAG'

T6ESODLT='SO*TCB*DELAY*TIME'

T6ETCAWC='TC*ALLOCATE*WAIT*COUNT'

T6ETCAWF='TC*ALLOCATE*WAIT*FLAG'

T6ETCAWT='TC*ALLOCATE*WAIT*TIME'

T6ETDELC='TD*EXTRA*LOCK*COUNT'

T6ETDELF='TD*EXTRA*LOCK*FLAG'

T6ETDELT='TD*EXTRA*LOCK*TIME'

T6ETDILC='TD*INTRA*LOCK*COUNT'

T6ETDILF='TD*INTRA*LOCK*FLAG'

T6ETDILT='TD*INTRA*LOCK*TIME'

T6EUHWMG='GUDSA*HWM'

-An existing INVALID DATA error for T6ECNCNT, was found in

MXG code and corrected; it did not affect anything else.

Change 30.275 MXGNAMES/CONFIMXG adds support for a USER FORMAT library.

VMXGCNFG %LET MXGFMTU=DSNAME; dynamically allocates //USRFORMAT