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

aligned, so I've removed the recently-added %TRIM() from

VMXGOPTR in this change.

Note: Change 27.278 also documents that %TRIM macro will

not be found if you have chanced MXG's S2=0 option to any

other non-zero value.
CHANGE 27.123 -ASUMCEC dataset with an IFL still had missing values in

VMXG70PR CPCFNAME CPCMSU NRPHYCPS PARTNCPU PCTCPUBY PCTOVHD PCTPOV

Jun 7, 2009 variables, and wrong values in these variables:

Jun 9, 2009 IFACPUS IFAUPTM ZIPCPUS ZIPUPTM

even after Change 27.102 claimed to correct that error.

The problem only occurs if you have an IFL LPARs that is

also the highest numbered LPARNUM.

Change 27.076 added the support for IFL LPARs to ASUM70PR

output datasets; new observations are created for each

IFL LPARNAME in the two LPAR-specific datasets ASUM70LP

and ASUMCELP, but these new obs only populate only these

IFL resource variables

IFLACTTM IFLCPUS IFLUPTM IFLWSTTM PCTIFLBY

populated. All of the resource variables for the other

engine types (CP,ICF,ZIP,IFA) will have missing values in

the IFL observations. Those missing values were then

inadvertently propagated into the CEC-interval ASUMCEC

dataset. Several data step's sort order and logic were

revised to correct the error.

Thanks to Clayton Buck, UniGroup, USA.

CHANGE 27.122 -Support for APAR OA26832 (increased Service Units field

VMAC30 from 4 to 8 bytes), is needed now, thanks to IBM, because

Jun 7, 2009 z/OS SYSTEMS NEVER FAIL: we now have long-running-tasks

Text revised where long is measured in months, and whose 4-byte fields

Jun 30, 2009 can fill and wrap, truncating those service unit values.

But Service Units are NOT used to calculate any normal

MXG CPU Time variables in TYPE30 data; those CPU times

are read directly from the SMF 30 record, except for the

MXG-only variable SRVTCBTM, the TCB CPU time calculated

from CPUUNITS, added so CPUTCBTM and SRVTCBTM could be

compared to see if using Service-Unit-Based CPU time had

more resolution than the recorded CPU time. Except for

wrapping, I saw VERY little difference between the

CPUTCBTM and the SRVTCBTM when SRVTCBTM was added in MXG.

-Variable SMF30INV has bits for each of the six fields set

if the 4-byte service unit field had wrapped.

-These IBM named fields are cited in the APAR:

SMF30SRV SMF30CSU SMF30SRB SMF30IO SMF30MSO SMF30ESU

and their corresponding MXG variables are these:

SERVUNIT CPUUNITS SRBUNITS IOUNITS MSOUNITS ENCLCPSU

in all of the TYPE30 datasets.
CHANGE 27.121 In Change 27.078 I caused assembly errors

ASMIMSL6 ASMA034E Operand WTOAREA beyond active USING by 61 bytes

Jun 6, 2009 when I added messages for the new log record, proving I

am NOT an ASM programmer; shortening the message text did

circumvent the error, but this correction has been made

by "[e-mail]" who speaks that language for me.

Thanks to Mark Van Der Eynden, HP, AUSTRALIA.
CHANGE 27.120 Support for RMF III z/OS 1.10 new ASI fields (INCOMPAT).

VMACRMFV These variables are now INPUT/KEPT, but as they were

Jun 5, 2009 inserted (rather than appended) to the ASI record, other

ASI variables will be trashed without this change.

ASILVNMO='PRIVATE*MEMOBJ*ALLOCATED'

ASIHVCOM='64-BIT*COMMON*MEMOBJ*ALLOCATED'

ASILVSHR='SHARED*MEMOBJ*ALLOCATED'

ASILVABY='PRIVATE*MEMOBJ*BYTES*ALLOCATED'

ASIHVCBY='COMMON*STORAGE*BYTES*ALLOCATED'

ASILVSBY='SHARED*MEMOBJ*BYTES*ALLOCATED'

ASIHVVBY='HWM*64-BIT*COMMON*BYTES*ALLOCATED'

ASILVMEM='ADDRESS*SPACE*LIMIT*IN MB'

Thanks to Rodger Foreman, Acxiom, USA.
CHANGE 27.119 Documentation. A BUILDPDB SPIN library created on z/OS

BUILDPDB can be PROC CIMPORT copied to an ASCII system, but you

SPIN then must sort SPIN datasets (to change the z/OS EBCDIC

Jun 4, 2009 sort order to match the ASCII sort order) before you can

use that SPIN library with BUILDPDB.

The required SORT statements are:

PROC SORT DATA=SPIN.SPIN30_1;

BY READTIME JOB JESNR JINTIME;

PROC SORT DATA=SPIN.SPIN30_4;

BY READTIME JOB JESNR TERMTIME;

PROC SORT DATA=SPIN.SPIN30_5;

BY READTIME JOB JESNR DESCENDING JTRMTIME;

PROC SORT DATA=SPIN.SPIN26;

BY READTIME JOB JESNR JPURTIME;

CHANGE 27.118 -Cosmetic. DDs with DEVx now have DEVICE='00X'

VMACUCB instead of DEVICE='OTHER'. These values occur for SYSIN,

VMAC30 SYSOUT and other JES-owned DDs that don't have actual

Jun 3, 2009 allocations. Now, 'OTHER' really is "other".

-Dataset TYPE30_D now has DEVCLASS and DEVTYPE kept, just

in case you get "other" values and need to know them.

Thanks to Kim Westcott, New York State OFT, USA.
CHANGE 27.117 MXG 27.03-27.04. Change 27.071 introduced an extraneous

TRNDDB2A %; in line 44 that is now removed.

Jun 3, 2009

Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.

CHANGE 27.116 Type 14/15 records with a non-zero BLKSIZE (from JFCB, in

VMAC1415 record bytes 167-168), but with a Subtype=5 "Additional

Jun 3, 2009 Data Set Characteristics Section" with SMF14BFG='C0'X,

(indicates that the SMF14LBS blocksize field is valid),

have SMF14LBS=0, and MXG logic replaced BLKSIZE with the

newer SMF14LBS with SMF14BFG='1.......'B. The MXG logic

is revised to use MAX(BLKSIZE,SMF14LBS) if the SMF14BFG

bit is on, but this seems to be an APARable IBM problem.

Originally, 23173 obs had BLKSIZE=0, but after the change

there were only 1186 TYPE1415 obs with BLKSIZE=0.

Thanks to David Shaw, M&T Bank, USA.
CHANGE 27.115 Using TIMETABL to SYNC59 individual systems with a value

VMXGTIME in column 71 also required you to %LET MXGTIM59=YES, but

Jun 3, 2009 that is redundant and is now removed; the value found in

71-72 is always used (0, blank, 1, or other minutes).

====== Changes thru 27.114 were in MXG 27.04A dated Jun 2, 2009========
CHANGE 27.114 MXG programs that are "TAPE-aware" test the "PDB" DD for

ANALDB2R its device type of tape to avoid multiple mount/rewinds,

VMXGTAPE but they only were tested with JCL allocation. If the

Jun 5, 2009 the tape "PDB" is allocated by a LIBNAME statement it may

fail with "ERROR: NO LOGICAL ASSIGN FOR filename ddname".

MXG's algorithm to identify a LIBNAME as a tape device

CLEARs the LIBNAME and re-opens it as a FILENAME; a CLEAR

is required to change libref from a LIBNAME to FILENAME,

but a CLEAR unallocates the libref from the library, and

a subsequent reference (to read it) caused the ERROR.

But by moving %VGETENG to first test the "ddname" for its

device type, if we get the device type back, then that

ddname was OPENed, either by a prior use, or because it

was allocated by a LIBNAME statement, and we're done,

since we have the device type. But if %VGETENG returns

"UNKNOWN" for device type, then we know that library was

JCL-allocated and was not OPEN, so we could safely CLEAR

the LIBNAME and open as FILENAME open with a FILENAME and

still get back to the LIBNAME. But, because the LIBNAME

has NOT been OPENed, we really don't need to CLEAR it

before opening it as a FILENAME, so FILENAME ... CLEAR is

now removed from these members.

The CLEAR is still required to switch the other way, from

a FILENAME to a LIBNAME, so a DD name allocation rather

than a LIBNAME allocation may be required. For example,

this ERROR will also occur with the WEEK/MONTH builds if

you use the TAPETEMP option, and if you try to allocate

TAPETEMP with a LIBNAME statement. There is no possible

circumvention, as we must, by design, issue the CLEAR, so

you must use a DD statement rather than a LIBNAME.

Thanks to Brian A. Harvey, HCL America, USA.
CHANGE 27.113 OMCI INTR Subtype 200 RECSUBTY 4 segments are 58 bytes in

VMACOMCI length; MXG code guessed 53 bytes (and noted "UNTESTED").

Jun 1, 2009 The guess caused INPUT STATEMENT EXCEEDED error.

Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.

CHANGE 27.112 VMXGALOC only correctly allocated weekly PDBs datasets if

VMXGALOC you were using Week-To-Date logic, and if FIRSTRUN=YES,

BLDSMPDB the TREND datasets were not correctly allocated.

May 31, 2009

Jun 11, 2009 BLDSMPDB did not protect for no datasets in the PDB for

WEEKLY processing, and did not end a loop after all of

the datasets were processed, causing in a failed SUBSTR

function ERROR. The loop logic now runs only if datasets

exist in the input, and then only for the number of them.

Thanks to Gary Havlatka, Creative Automation, USA.

Change 27.111 Support for multiple TMS/CA-1 catalogs creates IHDRTMS5

IHDRTMS5 exit, adds &TMSJFCB FILENAME=INFILENM &TMSEOV options to

TYPETMS5 the INFILE TMC statement, creates new TMSLIB and TMSDATE

TYPSTMS5 variables, now inserted into the sort BY list used:

VMACTMS5 BY ZDATE TMSLIB TMSDATE VOLSER ....

VMXGINIT and, in the example code in IHDRTMS5, show how you can

May 31, 2009 populate TMSLIB by parsing the DSNAME of each TMC infile,

and how to populate TMSDATE with the Create Date from the

JFCB of each infile.

-The location of the INFILE, IMACZDAT, and IHDRTMS5 was

moved into the MACRO _CDETMS macro definition in VMACTMS,

to match the expected sequence of those exits.

-New macro variable MACTMSH is created for "instream" code

alternative for the IHDRTMS5 header exit.

-New macro variable TMSJFCB=JFCB=TMSJFCB ; is set ONLY if

if MXG is executing under z/OS, where JFCB= exists.

-New macro variable TMSEOV=EOV=TMSEOV ; is now set ONLY

if MXG is executing under SAS, as WPS JFCB= exists.

Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.110 -I. MXG 27.05 execution tests with WPS 2.3.5 under ASCII:

DOC Summary: Most MXG programs execute under WPS error-free.

Jun 5, 2009

AUTOEXEW This program that creates MXG datasets cannot be used:

MXGWPSV2 TYPESVC - DS8000 Disk SAN Volume Controller XML record;

READDB2 WPS does not support NAMED INPUT.

UTILXRF1

TYPELSAR This program that creates MXG datasets bypasses a new MXG

VMACNMON feature when executed under WPS:

VMXGINIT TYPETMS5 - CA-1/TMS Catalog support for multiple TMC's:

Jul 4, 2009 Added in Change 27.111, the INFILE EOV option

(that allowed concatenation recognition so

multiple catalogs could be concatenated) is

not supported, so &MXGEOV is blank with WPS.

These report example programs use features not in WPS:

ANALCISH - ALL report - PROC SQL run time.

ANAL80A - PROC REPORT.

ANALAVAL - PROC CALENDAR.

ANALPATH - OVERPRINT option PUT statement.

UTILXRF1 - TRANSCODE attribute in DICTIONARY.COLUMNS

UTILXRF1 - VALIDVARNAME=UPCASE.

-The below were previously listed here as not usable, but

the inhibiting feature is now supported:

ANALMPL - PROC PLOT VREVERSE,VPOS options not there.

ANALTAPE - PROC PLOT VREVERSE,VPOS options not there.

SASAUTOS - Warning not assigned, macros empty

-The HBAR option of PROC CHART is now supported, so these

members are now reinstated in the WPS QA tests:

ANALCICS ANALMONI ANALPRNT ANALSMF

-WPS 2.3.5 does not support SAS "NAMED INPUT" syntax, used

in TYPESVC Open Systems DS8000 Disk SAN Volume Controller

support. The NAMED INPUT syntax has always been in SAS:

INPUT FIELD1= FIELD2= ;

and is used to read data records that have

field1=value1 field2=value2

but it wasn't needed in MXG until this pseudo-XML data

file was supported last November.

-WPS 2.3.5 does not support the EOV= option on the INFILE

statement, newly needed for Change 27.111 to support read

of multiple TMC libraries in TYPETMS5.

-WPS 2.3.5, like 2.2, doesn't support OPTION VALIDVARNAME.

Change 25.025 removed VALIDVARNAME=V7 from WPS CONFIGW2,

because the V7 function, to permit long variable names,

was the default in WPS. But now, in MXG's UTILXRF1, used

to create the DOCVER documentation, I needed to set SAS

option VALIDVARNAME=UPCASE so the variable names out of

the PROC CONTENTS were upper case, which causes WPS 2.3.5

to fail with

ERROR: System option "VALIDVARNAME" is not known.

-WPS 2.3.5 doesn't support TRANSCODE attribute in the

DICTIONARY.COLUMNS dataset, used only in UTILXRF1 to

create the DOCVER documentation. The TRANSCODE attribute

is new in MXG and only exists in SAS v9, so MXG did not

execute the &MXGNOTRA when under WPS due to the SASVER=8

that is set when MXG executes under WPS, but this usage

is now also circumvented so the rest of the UTILXRF1 can

be tested under WPS.

-WPS 2.3.5 SASAUTOS library has no members, which caused a

minor WARNING: SASAUTOS IS NOT ASSIGNED. VMXGINIT issues

LIBNAME SASAUTOS LIST; to list the concatenates, but that

statement is now conditionally not-executed with WPS to

eliminate that harmless WARNING message on the log.

With SAS, the SASAUTOS library is required because %TRIM

is delivered as a source-code %MACRO in the SASAUTOS PDS,

but WPS implemented %TRIM internally, so MXG doesn't need

to point to SASAUTOS FILENAME under WPS.

NOTE: While FILENAME SASAUTOS is NOT required with WPS,

MXG under WPS still requires the

OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;

executed in VMXGINIT, so that WPS will look in

//SOURCLIB to resolve all %MACRO references.

So all references to SASAUTOS FILENAME in the MXGWPSV2

JCL Procedure example and in the AUTOEXEW ASCII autoexec

file were removed. Just for documentation, the WPS .CFG

file has the default -SASAUTOS \&wpsroot\macros.

-The COUNTW() function, added to TYPENMON in Change 27.080

only exists with SAS V9, so TYPENMON failed with either

SAS V8.2 or WPS 2.3.5. NMON code was modified to only

use COUNTW() if under V9; a DO LOOP to count the commas

is used when not under SAS V9; same change in TYPELSAR.

-New dataset names "WORK._temp1559410888854220" structure

are created internally by PROC TRANSPOSE.

-Circumvented in READDB2. WPS %Macro Compiler does not

resolve triple-percent-signs the same way that SAS does,

which caused WPS to die with a compiler error in READDB2.

but, all READDB2 %%% and %% tokens are end-delimiters for

old-style-macro-definitions, and, most fortunately, they

are no longer required (the problem they circumvented was

fixed in SAS long ago), so they could be replaced with a

single percent sign in READDB2. (There are still cases

when %%% is required in other MXG members, often before

an embedded %INCLUDE statement, but WPS handles those

without error.)

-Fixed in WPS Build 12169:

WPS 2.3.5 failed when a FILENAME with concatenated input

files was read; the RECFM/LRECL on the FILENAME statement

was not honored and a STOPOVER resulted when the system

default of V/256 was used for F/340 data. This WPS error

when files are concatenated is fixed in WPS Build 12169.
-Run Time Comparisons on Windows, zero observations input:
MXG QA's first 36 "steps" create all 4700 MXG datasets in

the LIBNAME VERSvvrr, and run times were comparable, with

SAS V9.2 taking 10 min and WPS 2.3.5 taking 13 minutes.
But Step 47 TESTANAL, took over 80 Minutes (vs 2 for SAS)

due to a WPS error in its PROC SQL, BUT, an error that is

ONLY likely to occur in MXG's QA tests. MXG's %VGETOBS is

invoked frequently in ANALxxxx examples, to test if a

dataset exists and if it has observations, and it uses

PROC SQL: SELECT FROM DICTIONARY.TABLES

WHERE LIBNAME= MEMNAME=;

The (internal) DICTIONARY.TABLES dataset has one obs for

each dataset in each LIBNAME. The MXG QA TESTANAL step

allocates the 37 different LIBNAMES (PDB, WEEK1-WEEK5,

MONTH1-MONTH5, etc) that may needed by ANALxxxx programs

to that VERSvvrr directory with its 4700 datasets. So,

there are 37*4,700=173,900 datasets in DICTIONARY.TABLES,

which overwhelms the defective WPS PROC SQL; each execute

takes over 90 SECONDS of CPU and Elapsed time. WPS has

identified their PROC SQL error and it will eventually be

fixed.
In addition to the long run time of the QA job due to the

PROC SQL error, the QAWPSXX job has never completed. It

gets to the TESTANAL code, and then in ANAL115 it just

hangs, continuing to execute, using CPU time, but with no

further log messages, and the last message was a %VGETOBS

PROC SQL execution. Skipping ANAL115 allowed the TESTANAL

to get to ANALDB2R before it again hung, and again that

last message was a PROC SQL execution. But since each of

the ANALxxxx programs execute standalone, this too is an

error unlikely to occur outside the MXG QA test runs.

II. Z/OS Specific Tests, unresolved as of July 4, 2009:
-The Large ARRAY(256,512) problem in VMXGGETM that was

fixed in WPS 2.3.4 (WPS Error #6276, Change 26.258)

has shown up again in WPS 2.3.5. UTILGETM is only used

in the MXG Test Jobs, to create a small SMF file with

a few records of each type and subtype, so this is not a

fatal error for normal execution.

-In the QA job only, after many data steps were run and

many datasteps had been written to the PDB library, the

BUILDPD3 step job failed with "PDB LIBRARY CORRUPTED"

error message. However, since the BUILDPD3 program runs

fine when outside of the QA job, this is most likely an

issue with WPS "PROC SQL".

III. Miscellaneous
-The //LOGCFG DD is no longer used by WPS, so it is now

removed from MXGWPSV2 JCL Procedure example.

Change 27.109 QA COMPALL program found character to numeric conversion

VMACLDMS for not-kept-variable SEGMENT in VMACICE and VMACXPTR and

VMACXPTR for not-kept-variable LDMSTYPE in VMACLDMS, both fixed.

May 29, 2009 The COMPALL program compiles ALL of the MXG code members

that read SMF records, in a single (MASSIVE) DATA step to

create 1907 datasets, all with zero observations because

the INFILE SMF is a zero-length or DD DUMMY file.

So COMPALL is also a good SAS compiler stress test.

Last year, Change 26.217 compared COMPALL with SAS 9.1.3

and WPS 2.2, but the z/OS comparison was wrong.

Now with MXG 27.04, which creates 1907 datasets and more

variables, and now using WPS 2.3.5, SAS 9.2 and SAS 9.1.3

these comparisons are observed:
Compiler Platform Run Time Memory Required
SAS 9.2 Win/XP 96 seconds 1185 MB

SAS 9.1.3 Win/XP 86 seconds 1158 MB

WPS 2.3.5 Win/XP 101 seconds not reported
SAS 9.2 z/OS 7 minutes 1210 MB

SAS 9.1.3 z/OS 12 minutes 1194 MB

WPS 2.3.5 z/OS 17 minutes 1037 MB
Enabling the full diagnostic options to print all source

only increased the SAS V9.2 WIN/XP run time by 6 seconds.

Change 27.108 &NULLPDS, &LOAD, &SASAUTOS JCL Symbolics in MXG JCL Proc

MXGSAS examples are removed. They were never required, rarely

MXGSAS92 used, and then, only in ancient releases of SAS. And now

MXGSASV9 have caused JCL errors when very old and more recent JCL

MXGSASV8 procs are used in the same job. such as this error:

May 27, 2009 IEC143I 213-04,IFG0194D,M577FPA1,SASMXG,STEPLIB

MXGWPSV2 Their only purpose was to override the //STEPLIB or the

JCLQAWPS //SASAUTOS DD statements, which can easily be done in the

Jun 1, 2009 JOB's JCL, with no exposure to the &NULLPDS DISP issues.

(See CHANGESS for the many NULLPDS historical hits!)

-JCLQAWPS moved LIBRARY to be before SOURCLIB so its JCL

overrides matched the order in MXGWPSV2.

Thanks to Stuart Wildey, Morgan Stanley, USA.

Thanks to MP Welch, SPRINT, USA.

====== Changes thru 27.107 were in MXG 27.04 dated May 27, 2009========
Change 27.107 Support for BMC's IMF 4.4 (COMPATIBLE) added some new

VMACCIMS variables and some variables MXG had overlooked.

May 26, 2009 These new variables are now created in IMFTRAN:

Jun 2, 2009 CPUTRNX ='CPU AFTER*TRN STOP SET'

TRNOTCLP='IMS*CONNECT*CLIEN*PORT NUMBER'

TRNMQMID='MQS*MESSAGE*ID'

TRNCVTTZ='TRNCVTTZ*GMT*TIME ZONE*OFFSET'

TRNCAPPL='CICS*APPLID'

TRNFALSC='FALSE*SCHEDULES'

TRNTFLAG='COPY OF*RATTFLAG*DET TRACE'

TRNFALST='FALSE*SCHEDULE*ELAPSED*TIME'

This change has only been tested with 4.3 records.

Jun 2: TRNxxxxx fields wrong; Trace Table +80 vs +72

BMC APAR BAI9444 documents that the IMF Transaction CPU

time can exceed the transaction elapsed time, because the

APAR BAI9312 excluded the "stopped term thread activity"

time from being included in transaction elapsed time, by

setting the transaction stop time upon completion of the

Get Unique, regardless of whether it returned another

message. When it doesn't return another message, the

region goes through term thread, and the CPU used by the

terminate thread can cause the total transaction cpu to

exceed transaction elapsed time, since the transaction

stop time is set before term thread. BAI9444 modified the

IMEUTMR7 timing routine to separately record any CPU time

calculated after transaction stop time, in a new fields

named TRNXCPU, which MXG outputs in new variable CPUTRNX,

so you can identify that is the cause of CPU time greater

than elapsed time in IMS.
Change 27.106 Support for z/OS 1.10 storage metrics in SMF 119 create

VMAC119 these four new subtype=5 variables in TY11905 dataset:

May 25, 2009 TS6CEALO='CURRENT*ECSA*STORAGE*ALLOCATED'

May 28, 2009 TS6CENIU='CURRENT*ECSA*ALOC BUT*NOT INUSE'

TS6CPALO='CURRENT*AUTH PRIVATE*ALLOCATED'

TS6CPNIU='CURRENT*AUTH PRIVATE*NOT IN USE'

May 28: The four INPUT statements are &PIB.8., not 4.

Thanks to Stan Dylnicki, Royal Bank of Canada, CANDADA

Thanks to Aylin Kavas, Royal Bank of Canada, CANDADA
Change 27.105A-PDB.TYP70 variables with "CPU" in their name or label are

DOC supposed to contain only metrics for the "CP" engines.

May 24, 2009 Separate variables, with "ZIP" or "IFA" in their name or

their label, contain the metrics for zIIPs and zAAP/IFAs.

Those three types of engines require separate capacity

analysis (and even have different capture ratios in MXG's

RMFINTRV dataset).

And PDB.TYPE70 variable CPUPATTM contains the Parked Time

for (only) the "CP" engines.

However, the 64 individual-engine Parked Time is stored

in 64 variables named CPUPATM0-9,A,B.... So you could

have zero CPUPATTM in this MVS System, but CPUPATM4 could

be non-zero, if your 4th engine is a zIIP, for example.

-PDB.TYPE70 variable CPUWAInn for nnth engine's LPAR Wait

is variable NEWWAIT in PDB.TYPE70PR for that engine, and

the variable MVSWAInn for the nnth engine's MVS Wait is