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

label, and TTSTIME was not coverted from GMT to local.

Thanks to Victor Chacon, Verizon Wireless, USA.

Thanks to Alan Klein, Verizon Wireless, USA

Change 23.052 -z/VM MONWRITE POSSIBLE BAD CONTROL RECORD were because

EOAPLSL0 the 1.17 record test should be SKIP=SKIP-16; instead of

EOAPLSLM SKIP-52. This caused many of the domain 1 records to be

EOAPLSLN skipped and were not output. Fortunately, these are the

EOAPLSLP seldom-needed startup information for MONWRITE, and the

EOdddddd 1.17 record is after all of the critical-to-MXG records.

VMACVMXA -The 1.19 record would have been skipped, as its test for

Mar 25, 2005 MRHDRRC should have been for 19 instead of 17.

-MXG architecture enhancement creates new EOdddddd members

and for "second Output" of a dataset, and defines new

macro tokens named _Odddddd for instream override of the

exit. This "second Output" exit is needed when raw data

is accumulated, so filtering of observations can't be

done during the "first Output" in the DATA step, but only

after the deaccumulation is available for creation of an

interval "usage" variable, USdddddd that is tested in the

new second Output EOdddddd exit member, so only intervals

with activity are output during the final pass of data:

-The EOdddddd member now tests to not output "nulls":

USdddddd=SUM(resources);

IF USdddddd GT 0 THEN DO;

OUTPUT _Ldddddd;

END;

-The MACRO _Odddddd %%INCLUDE SOURCLIB(EOdddddd); %

is defined in VMACxxxx, adjacent to the _Edddddd.

-The _Sdddddd macro sets contain:

IF DELTATM GT 0 THEN DO;

_Odddddd;

END;

Dataset updated thus far to only output active intervals:

Dataset - USdddddd Usage Activity Variable(s)

VXAPLSLP - TICKS (sum of all clock's ticks)

VXAPLSL0 - TICKS (sum of all clock's ticks)

VXAPLSLM - PGALLOC

VXAPLSLN - SUM(PKTSRCVD,PKTSSEND)

-Example in IHDRVMXA shows how you can skip domains and/or

records from being output, when you want to select which

datasets are created from MONWRITE data.

Some DATA step times reading 1024MB MONWRITE:

Elapsed CPU WORK MB Description

641 87 1382 Output ALL

589 61 902 Skip Domain 7 (SEEK)

413 20 20 Only Domain 10 (APPL SERVER)

321 18 0 No Output, READ ALL,DDecode Hdr

Change 23.051 Support for z/VM Linux Application Server data creates

EXAPLSLM four new datasets:

EXAPLSLN APLSLM VXAPLSLM LINUX MEMORY

EXAPLSLP APLSLP VXAPLSLP LINUX PROCESSOR SUMMARY

EXAPLSL0 APLSL0 VXAPLSL0 LINUX EACH CPU DETAIL

VMACVMXA APLSLN VXAPLSLN LINUX NETWORKING

VMXGINIT This support is preliminary, and is in process of being

Mar 16, 2005 validated - the clock tick duration value for Linux times

Mar 24, 2005 is not provided, so actual CPU time is not yet measured

in the VXAPLSLP/SL0 Processor records, and the Linux time

stamp is 18 to 20 seconds earlier than the start of the

MONWRITE interval; both issues are to be opened with IBM.

Thanks to Mike Reeves, Fidelity Systems, USA.

Thanks to Warren Cravey, Fidelity Systems, USA.

Thanks to Rachel Holt, Fidelity Systems, USA.
====== Changes thru 23.050 were in MXG 23.01 dated Mar 15, 2005=========
Change 23.050 z/VM MONWRITE dataset VXBYUSR didn't accurately recognize

VMACVMXA a new LOGON after the same VMDUSER had logged of, causing

Mar 11, 2005 incorrect DELTATM and CPU times for the first interval of

each LOGON in the MONWRITE file. The logic now tests for

a change in CALTODON to recognize each LOGON interval.

Thanks to Mike Salyer, CitiGroup, USA.

Change 23.049 MQ-Series Variable QWHCCV is renamed to QWHCCVMQ because

VMAC116 it conflicted with DB2 variable QWHCCV, and when MQ was

Mar 10, 2005 added to BUILDPDB, the MQ $HEX24. format on QWHCCV made

the DB2 QWHCCV jibberish.

You can make the DB2 QWHCCV print correctly simply

by adding FORMAT QWHCCV $12.; to your DB2 reports.

At the same time, variable QWHSSSID in MQ-Series is now

renamed to QWHSIDMQ and labeled 'MQ*SUBSYSTEM*NAME' so

that it wont override the DB2 QWHSSSID label.

Yes, I know that changing variable names may cause your

MQ Reports to fail, but since only bleeding-edge sites

have begun to use the MQ data, changing now is better

than changing later.

Thanks to Mike Gebbia, Eddie Bauer, USA.

Change 23.048 Amdahl CPUTYPE='2000'X does not populate SMF70ONT, z/OS

VMAC7072 up time of each engine, so for intervals when engines are

Mar 10, 2005 varied on or off line, MXG cannot accurately calculate

the true capacity, since it doesn't know how much of the

interval that varied engine was available. The result is

that NRCPUS counted 2 engines, but part of a third engine

was available, and the CPU time in RMF 72 Service Class

records slightly exceeded the CPUACTTM of those two CPUs.

This was detected ONLY by a NEGATIVE CPU UNCAPTURED TIME

warning from RMFINTRV, which compares the 70 and 72 CPU

times, and there is no cure for the Amdahl deficiency,

so this part of this change is only documentation of the

expected existence of that message with this processor.

(In TYPE70 for this interval, variable CAI3='03'x shows

the third engine was varied, so you can confirm the cause

of the warning message, but I can't use that information

to delete the interval without creating more questions!).

-In addition, this same interval record also caused error

DIVIDE BY ZERO; the unexpected SMF70ONT=0 value caused

PCTCPUBY to be zero when the new SHORTCPS variable was

created (the PCTCPUBY for this record is recalculated

later), but the real cause of the DIVIDE BY ZERO ERROR

was, as always, a programmer's error in not correctly

testing the divisor. IF PCTCPUBY GT . AND PCTMVSBY GT .

is now revised to test both variables for GT zero.

Historic Note: When I was using Netscape years ago,

and had reported erratic Divide by Zero errors and

had stated that this was clearly a programmer error,

their Senior Technician replied "a divide by zero

error is not a programming error - it is a normal

event that happens with Windows". B.S.: A DIVIDE

BY ZERO ERROR IS ALWAYS A PROGRAMMING ERROR.

I later found Netscape's problem; I had printed and

the printer was there, but when I had turned off the

printer, Netscape failed to test that the printer

was still alive, and failed with the DIVIDE error.

Thanks to Robert Blackburn, Dominion Resources Services, Inc, USA.
Change 23.047 The date part of READTIME, JHRRDOD, was changed from PD4

VMACESPH 0101303F for 30Oct2001 to 2005066F for 07Mar2005, causing

Mar 10, 2005 INVALID ARGUMENT TO FUNCTION DATEJUL when MXG read the

changed data format. MXG now tests for the new format.

Thanks to Larry Riggen, Cinergy, USA.
Change 23.046 -DB2ACCT vars QXCRESEQ,QXALTSEQ,QXDROSEQ,QXPRRESI,QXALTVW

VMACDB2 were incorrectly INPUT in DB2 V7 records; those fields

Mar 10, 2005 only exist in DB2 V8. The test IF LENQXST GE 440 for

that INPUT should have been GE 460.

-Those five QX variables were not INPUT at all in the STAT

records, but now are kept and deaccumulated in DB2STATS,

for DB2 Version 8.

-Variable QBGAWS was incorrectly INPUT in DB2 V7 records,

but it only exists in V8; logic was corrected.

Thanks to Allan Winston, MBNA, USA.

Change 23.045 Support for TMS Release 11 is already in place in MXG, as

TYPETMS5 the Appendix A for the TMC Volume and DSNB records shows

Mar 9, 2005 no changes to those records.

Thanks to Norm Hollander, CA, USA.

Change 23.044 Two new variables were added to ASUMCACH, and new member

ASUMCACH TRNDCACH was created:

TRNDCACH NREXPOSR - Maximum number of exposures during interval

Mar 9, 2005 INTCHGEX - Number of intervals in which exposure count

changed.

Also, labels for IORATE, IORATEC, and DURATM now exist.

Thanks to Diane Eppestine, SBC, USA.
Change 23.043 Global Macro Variables EPDBVAR,EPDBCDE,EPDBOUT are now

VMXGINIT defined in VMXGINIT, and referenced in their counterpart

EXPDBVAR EXPDBVAR,EXPDBCDE, and EXPDBOUT members, so that UTILBLDP

EXPDBCDE can use those macro variables for "instream" tailoring.

EXPDBOUT

Mar 9, 2005

Change 23.042 New SAS options DMSLOGSIZE=999999 and DMSOUTSIZE=999999

CONFIGV9 with those maximum values that increase the number of

Mar 9, 2005 lines that can be sent to the log or list windows; the

old limit was 99,999. Unfortunately, these options must

be set at SAS initialization, and cannot be set in the

autoexec.sas file under ASCII. For ASCII execution, you

must either update your sas.cfg file, or you can add

-dmslogsize 999999 to the options in your SAS icon.

Thanks to Kevin Hobbs, SAS Institute Cary, USA.
Change 23.041 This new analysis member calculates the DELTATM between

ANAL30V the end of one SMF 30 interval to the start of the next

Mar 8, 2005 interval for each job, and it also calculates SWAPEDTM,

the duration when the job was swapped out after the true

INTETIME end-of-interval. The true "resource duration"

of each type 30 interval record (subtype 2, 3, and 6) is

from INTBTIME to INTETIME, but if a task is swapped out

at the end of the interval, the SMF record is not written

until the task is swapped back in, which can be minutes

or hours later, and since no resources were consumed

while the task was swapped out, SMF resets the INTBTIME

of the next interval to the SMFTIME of the prior record.

So if you look at just the time between INTETIME and the

next INTBTIME, you can see very large values, because it

is the sum of SWAPEDTM plus DELTATM, but in a test with

70,000 interval records, I found a maximum DELTATM value

of only 0.37 seconds. I did discover that the "normal"

sort sequence of READTIME JOB JESNR INITTIME was not

sufficient for some started tasks (notably OPSOSF) that

have multiple instances per system and that start before

SMF initialization - those STCs have missing JESNR, but

had identical values for those variables for what were

separate instances, so SYSTEM ALOCTIME LOADTIME were

inserted in the sort sequence to separate them; if that

heuristic fails, the DELTATM can be a negative value.

Thanks to Dave Thorn, SUNGARD, USA.

Change 23.040 Condition Code/Return Code 0004 is set in ANALPRTR due to

ANALPRTR WARNING:APPARENT SYMBOLIC REFERENCE xxx NOT RESOLVED

Mar 8, 2005 when there were no observations in PDB.ASUMPRTR; those

two macro variables are normally created by CALL SYMPUT

in a DATA step, but when there are no observations, that

data step is not executed. To resolve the reference, the

%LET EARLIEST=; and %LET LATEST=; statements are inserted

at the beginning of the member, so there is no unresolved

macro even when there are no observations.

In this open code, the choice was either to use the

pair of %LETs, or to put both macro variables in a

%GLOBAL statement. Both choices effectively "GLOBAL"

the macro variable, since its value will exist for any

later program that references that same name. One big

difference is that using %GLOBAL does not change the

value if the macro variable was already %GLOBALed, so

you could (accidentally?) pick up a prior value, while

the %LET will set the always reset the macro variable

value. Finally, while not documented in Change 19.230,

using %GLOBAL to initialize macro variables to null

saved measurable CPU time, compared with using the

several hundred %LET statements, so the VMXGINIT

member now only uses %LETs where a non-null initial

value is required. If ANALPRTR were pervasively used,

I'd have put these two macro variables in VMXGINIT,

but it is very old analysis, and the CPU times that it

estimates are way out of date, and new printer devices

may not be amenable to its thruput measurements, so

using the two %LETs was the simple choice.

Thanks to Scott Barry, SBBWorks, Inc, USA.

Change 23.039 Archaic variable QTXASUS is now set missing; long ago it

VMACDB2 was replaced by QTXASLOC, and while it was documented as

Mar 7, 2005 archaic in ADOCDB2, it caused confusion because it had a

value, when it should no longer be used. Instead, the

three variables QTXASLOC, QTXASLAT and QTXASOTH break out

the suspends for Lock, Latch, and Other conflicts.

Thanks to Marty Pruden, Nestle Purina PetCare Co., USA.
Change 23.038 Code was revised to eliminate MISSING VALUE messages by

VMAC30 either relocating calculations or by testing prior to

Mar 7, 2005 the calculation.
Change 23.037 -TYPE30MU and TYPE89 variable MULCURD is now forced to be

VMAC30 a missing value when the MULCUDF/MULCURT is zero, so that

VMAC89 a value is not carried forward when there are multiple

Mar 7, 2005 segments.

-The TYPE30MU decoding now expects MULCUDF=2 to be &PIB.8.

and MULCUDF=3 to be &RB.8., which is consistent both with

IBM documentation and the SMF 89 record descriptions.

All of my 30 test data has MULCUDF=2 with MULCURD=0, or

has MULCUDF=0, so this correction has not been confirmed

with real data; I do have 89 test data with MULCURT=2 and

binary values for MULCURD, so it makes sense to align the

MXG calculations in 30s with those in the 89 records.

Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.036 Using %UTILBLDP with BUILDPDB=NO and INCLAFTER=RMFINTRV,

UTILBLDP Condition Code 4 was set with SAS V9, because RMFINTRV

VMXGRMFI was not protected with OPTIONS DKROCOND=NOWARN when it

Mar 9, 2005 was executed outside of BUILDPDB code. Now, RMFINTRV

is internally protected, and, in addition, when %UTILBLDP

is used with BUILDPDB=NO, it generates DKROCOND=NOWARN

at the top and resets to DKROCOND=WARN at the bottom.

OPTION DKROCOND=NOWARN is extremely useful for MXG;

it lets me have variables in the KEEP= list that are

optional (e.g.: CICSTRAN has a lot of optional vars

that won't exist unless you open the comments in the

appropriate IMACICxxx tailoring member; using NOWARN

suppresses the normal warning that those variables were

not referenced). But prior to SAS V9, NOWARN was just

my convention to keep unneeded messages from your log;

in V9, SAS now sets Condition Code 4 with WARN, so it

is now necessary to protect all known instances in MXG.

Thanks to Scott Barry, SBBWorks, Inc, USA.

Change 23.035 The incorrect references to _LTY30TD were replaced with

UTILBLDP _WTY30TD.

Mar 7, 2005

Thanks to Scott Barry, SBBWorks, Inc, USA.

Change 23.034 The addition of a new dataset (TYPE30TD) to VMAC30 caused

ANALJOBE the old ANALJOBE program to fail, because I failed to add

Mar 7, 2005 the needed override for that new dataset into ANALJOBE.

Adding overrides for that dataset would have worked, but

Scott very nicely revised the logic to use the _Vdddddd

macro tokens so that new datasets could be added to any

of the VMACxxxx members used in ANALJOBE, transparently,

and I don't have to remember to revise ANALJOBE to keep

up with future new datasets in the VMACx it uses!

He also removed the hardcoded MACJBCK= statement which

prevented the use of an instream MACKEEP=.

Thanks to Scott Barry, SBBWorks, Inc, USA.

Thanks to Sam Bass, McLane Co., USA.
Change 23.033 Example in comment should have been UTILS2ER instead of

UTILS2ER FINDS2ER, which was the earlier iteration; the member

Mar 7, 2005 FINDS2ER should not have been kept and is now deleted.

Thanks to Tom White, SPRINT, USA.

Change 23.032 Variables ASID and TARCASID were not formatted $HEX4. but

VMACTMNT now they are. ASID was only $HEX2. and TARCASID had no

Mar 6, 2005 format, so it printed a decimal value.

Thanks to Scott Chapman, American Electric Power,USA.

Change 23.031 Variables SRCDSN and TRGDSN do not exist in ICEBR8SN data

VMACICE set, but were accidentally in the KEEP= list, causing

Mar 6, 2005 confusion. They are now removed.

Thanks to Doug Medland, IBM Global Services, CANADA.

Change 23.030 -ML-33 of MXGTMNT corrects zero values in these variables

ASMTAPEE in the TYPETARC Tape Allocation Recover Event records:

Mar 2, 2005 DEVNR and UCBTYPE were all 0s.

DEVNRCHR was blank

TARCSTRT and TARCEND had the same timestamps.

TARCELAP was 0

TYPESCRN was always 0.

-ML-33 Mount records now have the Mount Time stamp from

the mount message. Hardware errors caused a 20 minute

delay between allocation reserving the drive and the

issuance of the mount message. Allocation handed off to

OAM the request for the mount, but before issuing the

mount, OAM first made a call to the library to get

eligible device pools. Because of the VTS harware

problems, it was late in responding to the request,

causing the mount message to be delayed.

-Mar 11: Mount Records Mount Time is still not correct;

under investigation.

Thanks to Scott Chapman, American Electric Power,USA.

Thanks to Patricia J. Jones, DST Systems, USA.

Change 23.029 The display format for the average service times, which

VMAC74 are in milliseconds, are now printed by default to show

Mar 1, 2005 three decimal places:

AVGCONMS AVGDISMS AVGIOQMS AVGENQMS 6.3

AVGPNCHA AVGPNCUB AVGPNDEV AVGPNDMS AVGRSPMS 6.3

The need for this higher resolution is because the z990

changed the measurement resolution from 128 microsecond

units to one-half microsecond; Pat showed that with a

real value of 192 microseconds, the old resolution with

truncation was reported as .1 millisecond, but with the

new resolution and rounding, the disk service time was

reported as .2 milliseconds per SSCH, causing concern

that service time had increased, when, in fact, there

was not change in the actual service time, but a great

improvement in the measurement of disk service times.

His full paper on this subject, "Understanding the

Differences between z900 and z990 Service Time

Measurements" is available at http://www.perfassoc.com.

Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 23.028 DB2STATS variables QDSTCIN2 and QDSTNADS had very large

VMACDB2 values. MXG deaccumulated them, because IBM documentation

VMACDB2H did not indicate otherwise, and early test data had all

Mar 1, 2005 zeroes, but data now shows they should not have been DIFd

and both are no longer deaccumulated.

-Record with only header 1 and header 2 created false

error message that header was invalid.

Thanks to Peter Farrell, Commerce Bank, USA.

Change 23.027 Support for IMPLEX Versions 3.1 and 3.3.

VMACMPLX

Feb 28, 2005

Thanks to Bob Gauthier, Albertsons, Inc, USA.

Change 23.026 -Byte-containing fields were carried as characters; they

VMACWWW are now numeric with MGBYTE format to "print pretty".

Feb 28, 2005 -IIS Web Logs printed INVALID THIRD ARGUMENT FOR SUBSTR

Mar 2, 2005 because MXG did not expect a zero length URIQVALU.

Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 23.025 %UTILCONT(PDB=PDB); failed if //PDB was DISP=NEW, with

UTILCONT ERROR: LIBRARY DATA SET xxx.PDB CANNOT BE OPENED BECAUSE

Feb 28, 2005 IT IS EXTERNALLY ALLOCATED DISP=NEW OR DISP=MOD,

Mar 7, 2005 AND IT RESIDES ON MULTIPLE VOLUMES

The cause is our choice to not issue PROC CONTENTS if the

DDNAME points to a sequential library, unless you told us

to by removing SEQUENTIAL from the EXCLUDE= opearand.

(The CONTENTS against a sequential library has to read

the entire library, including all datasets, because there

is no directory in sequential librarys). The problem is

that we cannot detect the engine unless the library:

a) has had activity, or

b) a LIBNAME statement has been issued.

To solve that old problem, we used a LIBNAME xxx DISP=SHR

in UTILCONT so we could always know the engine of the

library, but that is what caused this error!

In this redesign, for z/OS only, when PDB= is a list of

one or more DDNAMEs, the LIBNAME is issued only when the

DD is not allocated, then a %VGETENG determines the

engine, the MXGENG dataset is deleted, and %VGETENG is

reinvoked to get to get the full list of all datasets in

that library.

Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.

Thanks to Paul Naddeo, FISERV Phildelphia, USA.

Change 23.024 CONTROL-D SF2 records were INCOMPATIBLY changed; fields

VMACCSF2 for SF2PAGE and SF2DPAGE were increased in place from 6

Feb 25, 2005 to 8 bytes.

Thanks to Brian Crow, British Telecom, ENGLAND.

Change 23.023 ABEND 878-10 with REGION=180M got thru seven systems data

ASMRMFV before the failure. REGION=200M processed the data from

Feb 25, 2005 all ten systems at one time.

Thanks to Chuck Hopf, MBNA, USA.

Change 23.022 -Support for VSM subtype 30.

VMACSTC -HSC V6 made changes to subtype 4, STCVMU dataset, but the

VMXGINIT SMF record does not agree with the documentation, and the

IMACSTC result is large and invalid values. No MXG change has

EXSTCV30 been made, pending STK corrections to their data or doc.

Feb 24, 2005 -Apr 18: Debugging PUT statement, un-commented in tests of

Apr 18, 2005 this enhancement, is now re-commented, as it printed an

un-needed line of text on the log for each STC record.

Thanks to Michael Creech, Fidelity Information Services, Inc, USA.
Change 23.021 -LP0xxxxx variables were not populated; Change 22.293 was

VMAC7072 not properly migrated from test to my master library.

VMXG70PR Only LP0MGTTM is populated with the CPU time, since all

Feb 23, 2005 PHYSICAL CPU time is really "management" time.

Feb 28, 2005 -Variable SHIFT was added to PDB.ASUM70LP dataset.

Oct 31, 2005: See Change 23.276.

Thanks to Ken Jones, Xwave, CANADA.

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

Change 23.020 Support for CyberFusion user SMF record.

EXCYFUSN

IMACCYFU

TYPECYFU

TYPSCYFU

VMACCYFU

VMXGINIT

Feb 23, 2005

Thanks to Robin Murray, ManuLife, CANADA.
Change 23.019 Although using DCOLLECT (see JCLDAYDS JCL example) is the

ASMVTOC recommended way to "graze" your DASD farm, ASMVTOC can be

Feb 21, 2005 used, but the comments did not give an example of how to

use the //VOLLIST DD to exclude volumes. The comments

now show the explicit syntas.

Thanks to Brian Crow, British Telecom, ENGLAND.

Thanks to Fabio Massimo Ottaviani, DTSITALIA, ITALY.