impossible, even when IBM called it a signed value.
(For the miniscule number of variables that actually can
have a negative value, MXG uses IB4 INFORMAT.)
Thanks to Brian A. Harvey, HCL America, USA.
Thanks to Paul Ashford, USAA, USA.
Change 27.081 Support for APAR OA27623 that adds CPU Speed, SM1132SP,
VMAC113 speed in cycles per microsecond, to TYPE113 dataset.
Apr 30, 2009
Change 27.080 -Improved protection for inconsistent NMON data that has
VMACNMON fewer counters in the data records than the number of
Apr 30, 2009 field names in the header record, primarily observed in
May 2, 2009 the DISKxxxx and JFSxxxxx records. The short records were
erratic; most data records had the correct number of data
values, but, interspersed, there were the short records.
-The INPUT statements for each record type are replaced by
an initial INPUT and then the SCAN() function is used to
populate the new WORDS array, so that the NRWORDSIN can
be initially counted, but then the WORDS array is read to
find the last field that is non-blank, and its position
is then NRVALUES, which is used in all comparisons with
the expected number of fields from the header record.
This was because (for example, DISKBUSY) records with 19
header fields, but with only the first 3 populated, were
found, and subsequent data records had 19 fields usually,
but some had only 15 fields, but all of the data records
had only 3 fields populated. The old algorithm deleted
those short data records, but now, if the last non-blank
field locations match, the data record can be decoded and
is now output eliminating COUNTERS ARE DIFFERENT messages
(unless the counts really are different).
-The BBBP record still has to be INPUT rather than scanned
because I couldn't find how to SCAN a comma-delimited
field with double-quotes around embedded comma(s)!
-The COUNTW(FIELD,','); function does NOT correctly count
fields with repeated commas, and it took two invocations
of TRANWRD(WORD,',,',',') to separate all of the commas
to get the correct count of fields.
-The AAA Record DATE value was expected to be a 4-digit
YYYY value, so records with only YY (non-Y2K compliant!)
caused INVALID ARGUMENT TO FUNCTON error message. MXG
now protects NMON for YY in the date field, and the
MONTH argument was protected with an UPCASE() function.
Thanks to Arthur Sy, Depository Trust, USA.
Change 27.079 The Elapsed Time variable in the ORACLE dataset was still
VMACORAC missing; Change 26.099 was apparently lost. Now,
Apr 27, 2009 ELAPSTM=SMFTIME-STARTTS;
Thanks to Bret Hoesly, Telephone and Data Systems, USA.
Change 27.078 Support for IMS Log Record 45X IMS Interval Statistics
ASMIMSL6 creates 24 new datasets from its 22 subtypes:
TYPEIMSA dddddd Dataset Description
TYPSIMFL IMS450 IMS4500 IMS 4500 BEGIN STATISTICS'
TYPSIMS7 IMS452 IMS4502 IMS 4502 QUEUE POOL STATISTIC'
VMACIMS IMS453 IMS4503 IMS 4503 FORMAT BUFFER POOL S'
VMACIMSA IMS454 IMS4504 IMS 4504 DATABASE BUFFER POOL'
VMXGINIT IMS455 IMS4505 IMS 4505 VARIABLE POOL STATIS'
May 4, 2009 IMS456 IMS4506 IMS 4506 SCHEDULING STATISTIC'
IMS457 IMS4507 IMS 4507 LOGGER STATISTICS'
IMS458 IMS4508 IMS 4508 VSAM SUBPOOL STATIST'
IMS459 IMS4509 IMS 4509 PI STATISTICS'
IMS45A IMS450A IMS 450A LATCH STATISTICS'
IMS45C IMS450C IMS 450C CBT STATISTICS'
IMS45D IMS450D IMS 450D RECEIVE ANY BUFFER P'
IMS45E IMS450E IMS 450F FIXED POOL STATISTIC'
IMS45F IMS450F IMS 450F DISPATCHER STATISTIC'
IMS45O IMS450O IMS 450F DISPATCHER TCB STATISTIC'
IMS45P IMS450P IMS 450F DISPATCHER SAP STATISTIC'
IMS45G IMS4510 IMS 4510 RCFT STATISTICS'
IMS45H IMS4511 IMS 4511 STORAGE STATISTICS'
IMS45I IMS4512 IMS 4512 IMODULE STATISTICS'
IMS45J IMS4513 IMS 4513 MSC STATISTICS'
IMS45K IMS4514 IMS 4514 EWLM STATISTICS'
IMS45L IMS4521 IMS 4521 IRLM USERT STATISTIC'
IMS45M IMS4522 IMS 4522 IRLM SYSTEM STATISTI'
IMS45N IMS45FF IMS 45FF END STATISTICS'
The IMS Interval Statistics contain many accumulated
variables, which are deaccululated in the _SIMS45X macro,
which has been added to TYPSIMS7 ("old" log records only)
and to TYPSIMFL (processes IMF/CIMS and the IMS records),
and to TYPEIMSA (part of JCLIMSL6 IMS Log Processing),
but only those variables that were non-zero in my small
test file have been validated. You can use _MEANDBG
after your include of either TYPSxxxx member to run a
PROC MEANS against all of the statistics datasets, and
look for a negative MINIMUM value to identify fields that
are being deaccumulated that should not be.
-TYPSIMFL has been updated with comments and sample JCL to
select only the 0F9x, 0FAx, and 45x log records and to
write the four IMF datasets to separate DDs, writing all
of the new statistics data to the default //PDB DDname.
-ASMIMSL6 (for the JCLIMSL6 MXG IMS Log Processing, used
only if you do NOT have IMF or another IMS monitor) is
updated to also select the 45x records; since they are
interval records, their volume should always be small.
-Note that the default output destination of these new
IMS45xx datasets is the //WORK ddname, just like the
Fastpath and CPIC datasets. You can use
%INCLUDE SOURCLIB(TYPEIMSx);
PROC COPY IN=WORK OUT=whatever MT=DATA;
SELECT IMS45: ;
to copy these new (low volume) datasets to whatever
DD/LIBNAME you want, or you can override individual
datasets with %LET PIMS45z=whatever; before the %INCLUDE.
Note the Pdddddd macro token must be used because of the
de-accumulation that is required.
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 27.077 BVIR variable GLIBSEQN was documented as EBCDIC and early
VMACBVIR test data had '00'X values, but new data with ASCII data
Apr 27, 2009 is found, so MXG logic now tests for '00'x, or for EBCDIC
hex values ('81'x-'A9'x,'C1'x-'E9'x,'F0'x-'F1'x) or falls
thru for ASCII to input GLIBSEQN in the correct format.
Thanks to Rob D'Andrea, Royal Bank of Scotland, SCOTLAND.
Thanks to Penny Dudgeon, Royal Bank of Scotland, SCOTLAND.
Change 27.076 Significant enhancements to ASUM70PR summarization of
VMAC7072 TYPE70PR adds support for HiperDispatch by subtracting
VMXG70PR Parked Time SMF70PAT from both Online Time SMF70ONT and
Apr 30, 2009 from Wait Time SMF70WST, AND adds new IFA, IFL, and ZIP
variables to each LPAR to fully support those Specialty
engines (especially IFLs which were not captured in the
previous ASUM70PR implementation), captures the PHYSICAL
LPAR time for each type of Specialty Engine, and adds it
into the CPUIFATM, CPUIFLTM, CPUZIPTM totals in Interval
datasets, calculates the Average Number of Online Engines
for CPs, IFAs, IFLs, and ZIPs, provides counts of the
number of Installed Engines of each type, cleaned up the
inconsistencies in the variable's names and contents,
and documents what variables contain what, below!
It has always been my recommendation that the datasets
created by ASUM70PR should be used for LPAR analysis,
since it avoids you having to understand the complexity
of the raw TYPE70PR dataset; with this enhancement, all
of the information is summarized, and you have four ways
of analysis with the four output datasets created.
-ASUM70PR is enhanced with new variables for IFL LPARs and
consistent contents in the CPUxxxTM total variables, and
the HiperDispatch Parked Time SMF70PAT and Wait SMF70WST
are kept for each LPAR in all four datasets. If SMF70PAT
is non-zero, i.e., engines were parked, the SMF70ONT LPAR
Online Up Time, and the LPAR Wait Time SMF70WST are each
reduced by the Parked Time.
-The datasets ASUM70LP and ASUMCELP contain an observation
for each LPARNAME, with a single set of variable names
for each INTERVAL (that you set in your ASUM70PR member).
-ASUM70LP is created per SYSTEM, with each system's view
of the resources consumed by ALL of the LPARs seen by
that SYSTEM, so there will be replicated/repeated data
for each LPARNAME when you process SMF/RMF data from
multiple systems.
-ASUMCELP is created per CECSER with a single observation
for each LPARNAME for each INTERVAL.
In both of the per-LPARNAME datasets, ASUM70LP/ASUMCELP,
IFL LPARs are measured in these new variable names:
NRIFLCPU='INSTALLED*IFL*ENGINES'
IFLACTTM='IFL*PROCESSORS*CPU*ACTIVE*TIME'
PCTIFLBY='IFL*PERCENT*CPU*BUSY'
IFLCPUS ='IFL*AVERAGE*ONLINE*CPU COUNT'
IFLUPTM ='IFL*PROCESSORS*UP*TIME'
IFLPATTM='IFL*PARKED*PAT*TIME'
IFLWSTTM='IFL*PROCESSORS*WST*TIME'
As these datasets are per-LPARNAME their CPU active time
in variables IFAACTTM, IFLACTTM, and ZIPACTTM, do not
contain the Physical Engine CPU times.
-The datasets ASUM70PR and ASUMCEC contain an observation
for each interval, with a set of variables for the totals
and 60 separate sets of LPnAAAAA variables with resource
usage for each LPARNAME.
-ASUM70PR is created per SYSTEM, with each system's view
of the resources consumed by ALL of the LPARs seen by
that SYSTEM, so it, too, will have replicated/repeated
data when you process data from multiple systems.
-ASUMCEC is created per CECSER with a single observation
for each INTERVAL.
Since ASUM70PR/ASUMCEC are interval summaries across ALL
LPARs, the total-CPU-time variables now consistently
include the Physical LPAR CPU time; previously, only the
CPUACTTM for CP engines included the Physical time.
And the Physical CPU time for each engine type are now
available in ICFPHYTM, IFAPHYTM, IFLPHYTM, and ZIPPHYTM.
Those 60 sets of per-LPAR LPnAAAAA variables have these
new variables for each LPAR's IFA, IFL and ZIP usage:
LPnIFATM='LPAR n*IFA*DISPATCH*TIME'
LPnIFUTM='LPAR n*IFA*UP*TIME'
LPnIFKTM='LPAR n*IFA*PARKED*TIME'
LPnIFWTM='LPAR n*IFA*WST*TIME'
LPnILATM='LPAR n*IFL*DISPATCH*TIME'
LPnILUTM='LPAR n*IFL*UP*TIME'
LPnILKTM='LPAR n*IFL*PARKED*TIME'
LPnILWTM='LPAR n*IFL*WST*TIME'
LP1ZIPTM='LPAR n*ZIP*DISPATCH*TIME'
LP1ZIUTM='LPAR n*ZIP*UP*TIME'
LP1ZIKTM='LPAR n*ZIP*PARKED*TIME'
LP1ZIWTM='LPAR n*ZIP*WST*TIME'
-If you have IFLs, many "Missing Values" messages will be
printed on the SAS log, but they are harmless; IFL LPARs
have missing values for all of the old CP variables.
ASUM70LP/ASUMCELP - Per-LPARNAME Variables
============ Engine Type =============
CP IFA IFL ZIP ICF
Metric:
Installed Engines PARTNCPU NRIFACPU NRIFLCPU NRZIPCPU NRICFCPU
Avg Online Engines LPARCPUS IFACPUS IFLCPUS ZIPCPUS
CPU Busy Time LCPUPDTM IFAACTTM IFLACTTM ZIPACTTM
Percent CPU Busy PCTLPBY PCTIFABY PCTIFLBY PCTZIPBY
Online Total Time LPARDUR IFAUPTM IFLUPTM ZIPUPTM
Parked Time SMF70PAT IFAPATTM IFLPATTM ZIKPATTM
Wait State Time SMF70WST IFAWSTTM IFLWSTTM ZIPWSTTM
ASUM70LP Sorted BY list:
SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER LPARNAME LPARNUM
ASUMCELP Sorted BY list:
CECSER STARTIME SHIFT LPARNAME LPARNUM
ASUM70PR/ASUMCEC - Per-Interval Variables
============ Engine Type =============
CP IFA IFL ZIP ICF
Metric:
Installed Engines PARTNCPU NRIFACPU NRIFLCPU NRZIPCPU NRICFCPU
Avg Online Engines LPARCPUS IFACPUS IFLCPUS ZIPCPUS
CPU Busy Time CPUACTTM CPUIFATM CPUIFLTM CPUZIPTM
Percent CPU Busy PCTLPBY PCTIFABY PCTIFLBY PCTZIPBY
Online Total Time LPARDUR IFAUPTM IFLUPTM ZIPUPTM
Parked Time SMF70PAT IFAPATTM IFLPATTM ZIKPATTM
Wait State Time SMF70WST IFAWSTTM IFLWSTTM ZIPWSTTM
ASUM70PR Sorted BY list:
SYSPLEX SYSTEM &MXGSYSN STARTIME SHIFT CECSER;
ASUMCEC Sorted BY list:
CECSER STARTIME SHIFT;
-PDB.TYPE70PR dataset was also enhanced with the counts
and CPU Active time for all four specialty engines for
each LCPUADDR, with these new or updated variables:
NRICFCPU NRIFACPU NRIFLCPU NRZIPCPU total engines
ICFACTTM IFAACTTM IFLACTTM ZIPACTTM CPU this LCPUADDR
-Validation notes. Using PROC COMPARE can often identify
differences, but comparing across this change can cause
lots of "false positives", especially in the count of the
Specialty Engine NRIFACPU,NRZIPCPU,NRICFCPU,NRIFLCPU as
they sometimes wrong or always missing in prior PDBs.
Small changes are expected in the CPUxxxTM for Specialty
Engines because their PHYxxxTM is now included.
And the xxxUPTM "Uptime" variables are now differently
calculated, as the actual Online Time, rather than the
old values of NRxxxCPU*DURATM.
Thanks to Robert Hamilton, Fifth Third Bank, USA.
Thanks to Zhan Wang, AIG, USA.
Change 27.075 Cosmetic. For Offline LPARS (LPARCPUX=0) these variables
VMAC7072 in PDB.TYPE70PR: LCPUADDR SMF70CIX SMF70ONT NRCIXGT0
Apr 23, 2009 could have non-missing values. Now, all are set missing.
Unchanged, but noted: SMF70CIN is blank when LPARCPUX=0.
Change 27.074 Group Capacity datasets ASUM70GC & ASUM70GL were wrong if
VMXG70PR multiple SYSTEMs data was in TYPE70PR; each SYSTEM has an
Apr 23, 2009 observation with repeated data for each LPARNAME that was
being summed for each Group Name. This change selects a
single system per interval for the revised summation.
It has been observed in the data and in IBM RMF reports
that actual Group MSU used, LPARMSU, can exceed SMF70GMU,
the Maximum License Units of the Group, causing PCTGCUSE,
the Percent of Group Capacity Used, to exceed 100%.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.073 Variable EVENTIME in data set TSMACCT was wrong; the YYYY
VMACTSMA INPUT function was revised to use informat 4.
Apr 22, 2009 YYYY=INPUT(SUBSTR(DATECH,7,4),4.);
Thanks to Craig Collins, State of Wisconsin DOA, DET, USA.
Change 27.072 Updates for VTCS subtypes of the STC/STK User SMF record.
FORMATS -Format $MGSTCCT adds 2000MB and 4000MB values.
VMACSTC -Format $MGSTCMN adds MOUNT ANSI SCRATCH VTV value.
Apr 22, 2009 -Dataset STCVSM18 variables STC18CTP and STC18MT were not
input for the longer length segment, STC18CTP was not
kept, and all three CTP variables are now length $2 and
correctly formatted.
-Formats $MGSTCMN and $MGSTCCT were updated with new
values for 2000MB and 4000MB cartridges, and for
ANSI Label Mounts, respectively.
Thanks to Davide Marone, SGS S.p.a. ITALY
Thanks to Carlo Gavinelli, SGS S.p.a. ITALY
Thanks to Gianvittorio Negri, SAS Institute, ITALY.
Change 27.071 -Major enhancement: all MXG-provided VMXGSUM-using summary
ANAL88 programs (e.g. ASUMs, ANALs, TRNDs) will NOT fail if your
ANALAVAI input data has DROPed variables, if you simply specify
ANALCACH %LET KEEPALL=NO;
ANALCISH in your //SYSIN. KEEPALL=NO causes VMXGSUM to determine
ANALCNCR what output variables are needed, and thereby prevents
ANALHTML the VARIABLE NOT FOUND condition when you have DROPed
ANALPKGS variables to reduce the size of your PDB dataset, which
ANALPROG is what happens with the default of KEEPALL=YES.
ANALSTC
ANALUSS The default is KEEPALL=YES, because the KEEPALL=NO logic
ASUM23 would be expensive if applied to the hundreds of VMXGSUM
ASUM42DS invocations that are internal to MXG processing, but its
ASUM94 cost is insignificant for a single execution, and it is
ASUMCACH ONLY needed when you know you have DROPed variables.
ASUMCICS
ASUMCICT -All of the summary programs listed in this change now
ASUMCICX specify KEEPALL=&KEEPALL, in their %VMXGSUM invocation.
ASUMCIMS -And where needed, a KEEPIN= was added, but KEEPIN does
ASUMDB2A not get used unless KEEPALL=NO is in effect, so there is
ASUMDB2B no adverse effect of the KEEPIN= protection.
ASUMDB2G -VMXGINIT sets KEEPALL=YES as the GLOBALed default value.
ASUMDB2P The old default NO was used only in TRNDRMFI, which now
ASUMFRYE has KEEPALL=NO explicitly in its %VMXSGUM statement.
ASUMJOBS -VMXGSUM now has KEEPALL=&MXGKEEP in its definition, in
ASUMMIPS place of a hard-coded KEEPALL=YES, and MXGKEEP=YES is set
ASUMNTIN in VMXGINIT. This value is only used when the %VMXGSUM
ASUMSMFI invocation did not specify a KEEPALL value, and this is a
ASUMTMNT "just in case" option, to use MXGKEEP, that I doubt will
ASUMV11 be needed, but is nice to have for testing.
ASUMV14
ASUMVMON So, how expensive is KEEPALL=NO for my QA stream?
ASUMVTVM
ASUMVMNT The QA tests with all INFILEs reading zero length files
BLDNTPDB invokes VMXGSUM 442 times with these comparisons
BUIL3005
BUILD005 KEEPALL YES NO
BUILD006 DATA Steps 3567 4924
CICSSTAT PROC Steps 11564 13454
DAILYDSR Elapsed mmss 11:44 30:14
DALYTAPE CPU mmss 6:28 20:31
GRAFWLM
MNTHDB2S However, the CPU increase of 900 seconds with KEEPALL=NO,
SPUNJOBS for a total of 442 invocations, is only 2 seconds for a
TRNDDB2P single execution, well worth that cost to permit you to
TRND23 use the summary program with reduced input.
TRND70
TRND70SH
TRND94
TRNDCACH
TRNDCEC
TRNDDB2A
TRNDDB2B
TRNDDB2G
TRNDDB2S
TRNDDB2X
TRNDNTIN
TRNDNTLD
TRNDRMFI
TRNDTALO
USMFRATE
UTILCONT
UTILRMFI
VMXGCAPT
VMXGCICI
VMXGINIT
VMXGRESP
VMXGRMFI
VMXGSUM
VMXGTPFI
WEEKCEC
Apr 20, 2009
Change 27.070 Variable DESCR existed in 4 different XAM datasets, with
VMACXAM 3 different lengths, with only the first 12 bytes in
Apr 16, 2009 XMHSTMEM dataset, where the field is split into 2 pieces.
Variable DESCR is now $16 in both XMTIFTB and XMHSTMEM
datasets, the extra four bytes are appended in XMHSTMEM,
it is renamed DESCRDSK with length $40 in XMHSTDSK, and
it is renamed DESCRTCP with length $128 in XMTCPSYS.
Thanks to Roger Stock, Boston University, USA.
Change 27.069 Serena's Ultimizer user SMF record moved subtype 2 and 3
VMACULTM into the left byte of the two-byte subtype field, and in
Apr 15, 2009 the right byte for subtype 1 records, which was not the
expected location of subtype, but now is supported. The
DSECT for R310 does not document this design. And the
READTIME field is always missing (hex zeros) in the 2/3
records but is populated in the subtype 1 VSAM record.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 27.068 Optional CICSTRAN USERCHAR field was limited to 200 bytes
IMACICDU due to that ancient SAS V6 limit on character variables.
Apr 15, 2009 That field can now be up to 32000 bytes. The IMACICDU
member is an internal member that would not normally have
been tailored by users.
Thanks to Henrik Lange, Nordic Processor, NORWAY.
Change 27.067 Support for LDAP Auditing ID=83 Subtype=3 SMF record.:
EXTY83LD New dataset created:
FORMATS
IMAC83 dddddd Dataset Description
VMAC83 TY83LD TYPE83LD TY83LD: LDAP AUDITING
VMXGINIT
Apr 13, 2009
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
====== Changes thru 27.066 were in MXG 27.02 dated Apr 13, 2009=========
Change 27.066 The "owner" variables in TYPE77 were labeled as "CURRENT"
VMAC77 but they are actually the owners/system/etc at the time
Apr 13, 2009 of maximum contention. The revised labels now are:
CURROWN ='NUMBER OF*OWNERS*WHEN AT*MAX CONTENTION'
CURRWAIT='NUMBER OF*WAITERS*WHEN AT*MAX CONTENTION'
JOBOWN1 ='NAME OF*OWNER#1*WHEN AT*MAX CONTENTION'
JOBOWN2 ='NAME OF*OWNER#2*WHEN AT*MAX CONTENTION'
JOBWANT1='NAME OF*WANTER#1*WHEN AT*MAX CONTENTION'
JOBWANT2='NAME OF*WANTER#2*WHEN AT*MAX CONTENTION'
SYSOWN1 ='SYSTEM OF*OWNER#1*WHEN AT*MAX CONTENTION'
SYSOWN2 ='SYSTEM OF*OWNER#2*WHEN AT*MAX CONTENTION'
SYSWANT1='SYSTEM OF*WANTER#1*WHEN*MAX CONTENTION'
SYSWANT2='SYSTEM OF*WANTER#2*WHEN*MAX CONTENTION'
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 27.065 Cosmetic, to eliminate MXGWARN messages from VMXGOPTR.
BUILD001 Change 27.051 corrected VMXGOPTR so the current value of
BUILD005 an option would be used, but invocations of VMXGSUM could
BUIL3001 unexpectedly modify the option; this change pairs each of
BUIL3005 the VMXGOPTR to reset (VALUE=ORIGINAL) prior to VMXGSUMs.
SPUNJOBS Without this change, the (usually) harmless message
Apr 12, 2009 MXGWARN: STORED VALUE OF DKROCOND IS MXG;
could have been printed on the SAS log.
Change 27.064 SYSLDSN from the IEC501I message could be a number rather
VMACTMNT than a DSNAME; the WORDS array did not parse correctly if
Apr 11, 2009 there were adjacent commas for un-populated fields in the
SYSLOG message text. The TRANWRD(x,',,',', ,') function
was used to insert a blank between adjacent commas, once
I found that TRANWRD and TRANSLATE functions are quite
inconsistent, with their syntax reversed:
TRANSLATE(argument,to,from);
TRANWRD (argument,from,to);
Thanks to MP Welch, SPRINT, USA.
Change 27.063 Decoding SYSLOG MSGID=IEC205I in TMNT Subtype 8 record
VMACTMNT adds variables STEPNAME SYSLBLKS SYSLENCR to TYPESYMT
Apr 11, 2009 dataset to identify Encrypted Tapes; SYSENCR will have
the text KL1CD:L,LK2CD:L for encrypted tapes (where
H:='HASH' or L:LABEL'). The ASMTAPEE monitor program
will be updated later to write IEC205I in TMNT Subtype 8
record, and a later update to ASUMTAPE will be needed to
complete this enhancement.
Thanks to Bruce Gillespie, First American Reinsurance, USA.
Change 27.062 -TYPE42 Updates for VSAM RLS "ABOVE THE BAR" statistics,
EXTY42D3 added by IBM long ago but overlooked by MXG, adds six new
EXTY42D4 datasets and re-labels the six existing "BELOW THE BAR":
EXTY42S3 TY42S1 TYPE42S1 VSAMRLS SPLEX SC BELOW THE BAR
EXTY42S4 TY42S2 TYPE42S2 VSAMRLS SC CF SYS BELOW THE BAR
EXTY42X3 TY42S3 TYPE42S3 VSAMRLS SPLEX SC ABOVE THE BAR
EXTY42X4 TY42S4 TYPE42S4 VSAMRLS SC CF SYS ABOVE THE BAR
IMAC42 TY42D1 TYPE42D1 VSAMRLS SPLEX DATASET BELOW BAR
VMAC42 TY42D2 TYPE42D2 VSAMRLS DATASET CF SYS BELOW BAR
VMXGINIT TY42D3 TYPE42D3 VSAMRLS SPLEX DATASET ABOVE BAR
Apr 9, 2009 TY42D4 TYPE42D4 VSAMRLS DATASET CF SYS ABOVE BAR
TY42X1 TYPE42X1 VSAMRLS BUFF MGR TOTALS BELOW BAR
TY42X2 TYPE42X2 VSAMRLS BUFF MGR DETAILS BELOW BAR
TY42X3 TYPE42X3 VSAMRLS BUFF MGR TOTALS ABOVE BAR
TY42X4 TYPE42X4 VSAMRLS BUFF MGR DETAILS ABOVE BAR
Dostları ilə paylaş: |