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

Thanks to Tim Dockter, CA, USA.

Thanks to Fred Duminy, CA, USA.

Change 16.214 Support for DF/SMS 1.4 changes to HSM records added new

FORMATS values for $MGHSMFU format to decode FSRTYPE:

Sep 22, 1998 Value Formatted value

6 USER requested Delete of a Migrated Data Set

17 HSM Expired/Deleted a Data Set

(FSRFLG3 then indicates where the dataset

existed when HSM expired/deleted it)

18 Partial Release

19='19:EXPIRE OR ROLL OFF INCREMENTAL BACKUP'

20='20:(H)BDELETE INCREMENTAL BACKUP'

Also it was noted that for a full volume restore (FSRTYPE

= 14), FSRFVOL is actually the target volume name, not

the source volume name.

Thanks to Michael E. Friske, Fidelity Investments, USA.

Change 16.213 The type 79 subtype 15 (IMS Long Lock record) fields were

VMAC79 not documented completely accurately, but will be in the

Sep 22, 1998 next SMF manual. New variable F79FTRNM is now INPUT, and

new format $MG079RT decodes F79FRGTY values. R79FPSTN is

either a PST number as 4 hex digits, or the character

string 'ID', which is 'C9C4'x. R79FLHTI is 8-bytes long,

but only the first four are used, as seconds after

midnight. R79FRSNA is now only INPUT if R79FETYP='W'.

Thanks to John Keenan, Boeing, USA.
Change 16.212 MXG did not input seven fields in the System record from

VMACTMV2 Landmark's The Monitor for MVS Version 2, causing dataset

Sep 22, 1998 TMVSSYS to have incorrect values. To circumvent, you can

insert a line with +28 between the INPUT lines for

SYSRESV4 and SYSUIC. The seven new variables in TMVSSYS:

SYSUASID,-AASID,-NASID,-SASID,-RASID,-OSASI,and SYSORASI.

are counters of ASIDs in USE/Available/etc.

Thanks to Jeff Justice, Integon, USA.

Change 16.211 Support for TCP/IP 3.4 Type 118 Subtype 5 SMF record.

EXTYTCPS The new TCP Statistics subtype causes MXG CRITICAL ERROR

FORMATS message and a delete of the new subtype, but the other

IMACTCP datasets are correctly built from the other records.

VMACTCP This support created new dataset TYPETCPS with TCP

Sep 21, 1998 Statistics counters.

Thanks to Huug Tempelmans-Plat, Hoogovens Staal BV, THE NETHERLANDS.

Thanks to Xiaobo Zhang, Insurance Service Office, USA.

Change 16.210 INVALID DATA FOR HH/MM/SS/INBUFFSZ/OUBUFFSZ from Super

VMACSUIN IND$FILE SMF records because some EBCDIC numeric fields

Sep 19, 1998 contain nulls instead of valid EBCDIC zeroes. Knowing

this now, each of the INPUTs that use &NUM. informat are

now preceded with ?? to suppress the warning messages.

The records with nulls also contain UNAVAIL for both the

TERMINAL name and the Logmode Entry Name, and the other

counters are zeroes, so I suspect these null records are

otherwise valid, and so their uninitialized fields are

now protected.

Change 16.209 SAS 6.12 for Windows, Maintenance TS045 changed what is

CONFIG printed on the SAS log when option STIMER is enabled.

Sep 18, 1998 Now, sixteen lines of Stack, Heap, Memory, and Images

stats are preceded by "HOST STATS FOR: xxxxxx" and are

printed for every data or proc step by the STIMER option.

MXG's CONFIG member has always enabled STIMER/FULLSTATS,

as they were useful in diagnosing memory problems back in

early V6, but the new output flooded my QA stream log, so

I have removed the overrides from MXG's CONFIG member, so

the SAS defaults (NOSTIMER,NOFULLSTATS) will be used. If

ever needed, they can easily be enabled in your CONFIG

file, thru the OPTIONS= in MVS JCL, or by using an

OPTIONS STIMER FULLSTATS; statement at the beginning

of your SAS program.

Change 16.208 Internal support for the NTSMF DTS 0.1 configuration data

VMACNTSM record created three new variables in NTCONFIG dataset:

Sep 17, 1998 PRFSENVR='PERFORMANCE*SENTRY*VERSION*THAT WROTE'

DCSLOCN ='LOCATION*OF DCS: REGISTRY/PRIDCS/DCSFILE/ETC'

DCSINTRN='INTERNAL*NAME*OF THE*DCS'
Change 16.207 PROC GPLOT has never worked right when its input dataset

ANALVARY has zero observations; in various SAS releases there have

ANALRRTM been Notes or Error messages, but _ERROR_ was never set.

Sep 17, 1998 But under SAS Version 7 Beta, these notes were created:

Sep 25, 1998 NOTE: No Observations in Data Set xxxxxxxx.

NOTE: The SAS System Stopped Processing due to errors.

NOTE: SAS Set Options OBS=0.

That false error message, and the setting of OBS=0, has

been accepted by SAS as a defect. However, SAS Tech

Support found that by relocating the SYMBOL statement to

precede the PROC GPLOT statement, the OBS=0 was not set,

so now the MXG 16.04 QA Stream has successfully executed

all steps under SAS Version 7 Beta!!!

Thanks to Chris Noto, SAS Institute Technical Support, USA.

Change 16.206 If you use the COUNT= option in ANALCNCR, and it has more

ANALCNCR than one variable, the BY list was wrong and it contained

Sep 17, 1998 repeated variable names. The MXG logic error is fixed by

changing &&COUNT&NUMCNT to read &&COUNT&I. Fortunately,

the important uses of %ANALCNCR in MXG don't use COUNT=.

In fact, this error was discovered by the new feature in

SAS Version 7 (ERROR: Duplicate variables in a BY list)

when the archaic example ANALTAPE that has %ANALCNCR with

COUNT=TAPEDRVS TAPE3420 TAPE3480 TAPE3490 TAPE3590,

was tested in the MXG QA stream.

Change 16.205 New format MG099TC decodes the Trace Action Codes in the

FORMATS Type 99 Goal Mode Workload Manager trace data, using the

VMAC99 Table 76 in Appendix A of OS/390 V2R5.0 MVS Workload

Sep 16, 1998 Management Services, mapping number to Trace Code Name.

The codes describe WLM decisions, and their full meaning

from that table is also in ADOC99.

Thanks to Chuck Hopf, MBNA, USA.
Change 16.204 The externalization of tailoring for IMACACCT, IMACSHFT,

IMACACCT IMACWORK, and IMACUCB can now use the "MACKEEP" design of

IMACSHFT Change 16.134, with new MACACCT, MACSHFT, MACWORK, and

IMACWORK MACUCB macros defined and nulled in VMXGINIT and invoked

IMACUCB at the end of each of those IMACs. The BUILxxxx members

BUILDPDB/3 were updated also to invoke new EPDBINC macro variable to

BUILD001 permit tailoring of the EXPDBxxx members as well.

BUIL3001

VMXGINIT

Sep 16, 1998

Thanks to Chuck Hopf, MBNA, USA.
Change 16.203 The statement LENGTH=LEN; was changed to LENGTH=LENGTH;

UTILDUMP to eliminate the Warning "Unitialized Variable LEN". The

Sep 16, 1998 new SENDDUMP is probably better documented to get dumps.

Thanks to Hertwig Rainer, Lufthansa Systems GmbH, GERMANY.

Change 16.202 Finally, the logic to create SASSWORK and USERWORK macro

VMXGDEL variables (so we know where your WORK= and USER= point)

VMXGSUM works under both SAS V6 and SAS V7 and under OS/390 as

VMXGOPTR well as Windows and Unix. All this is for housecleaning

Sep 16, 1998 (delete work datasets when we can), but we needed to not

delete WORK.X after SORTing into USER.X if you had set

SAS options WORK= and USER= to the same data library.

Our logic executes PROC SQL on VTABLE to get the WORK=

and USER= current values. We expected DDNAMES, and the

code worked on OS/390, but under Unix and Windows you get

the full file specification name, with forward and back

slashes, etc, which required more logic revisions. Now,

we find that only under OS/390 can WORK= and USER= point

to the same library, so the logic was simplified. But

then, under Version 7, we found that PROC SQL no longer

reads the VTABLE when OBS=0 is specified, which caused

macro variables SASSWORK/USERWORK to be blank. (That

PROC SQL in Version 6 did not honor OBS=0 was accepted as

a bug and fixed in Version 7; that we got output under V6

was an unintended design feature, now corrected!). But

by inserting VMXGOPTR invocations before and after each

PROC SQL to momentarily override the OBS=0 to OBS=MAX and

then reset OBS to whatever it was, solves that problem.

And VMXGOPTR itself had to be revised for first time run

so it too will work properly when OBS=0 is specified.

Now, MXG has been executed under the SAS Version 7 Beta

on both MVS (OS/390) and Windows (98 and NT) platforms.
Change 16.201 Type 74 Cache data, variable R745CSC was not kept in data

VMAC74 set TYPE74CA, and variables CSDPIDAT and DEVPIDAT were

Sep 15, 1998 misspelled as CSDPIPID and DEVPIPID, and are now correct.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 16.200 The created variable STARTIME in contained only the date

VMAC94 and hour of the calculated Start time; now the equation

Sep 15, 1998 is STARTIME=SMFTIME-DURATM; but DURATM=3600; is set in

MXG because there is (as yet) no actual duration in the

VTS record, and no way to change IBM's default of hourly.

Thanks to Pat Hansen, Automated Data Processing, USA.

Change 16.199 NTSMF OBJECT='WidetoMBErr' created dataset WIDE2MBE, but

EXNTWIDE that was an April Fool's day trick. I found that object

VMACNTSM name in Discovery records last April, assumed it was a

Sep 15, 1998 new thing, and created the new dataset in Change 16.048.

Today, I discover that THAT string is the error code that

is returned by the translate function API when a Unicode

to ASCII translation fails (like when the Microsoft field

documented as Unicode actually contains ASCII values!),

and there really was no WIDE2MBE dataset to be built, so

its exit member EXNTWIDE and the code in VMACNTSM were

removed by this Change. Demand Technology discovered the

record was really for the SNA Adapter Object, and revised

their code to deal with its idiosyncrasies! So now, when

WidetoMBErr shows up, its time to call Demand Technology

so they can look inside PERFMON to find the actual name

for these aberrant objects, but also please run Discovery

and send the data file, so that I can circumvent it.

For example, the Beta of Microsoft Terminal Server 1.0

now has a counter object named 'WidetoMBErr' inserted in

the middle of the Process object, INCOMPATIBLY causing

an INPUT STATEMENT EXCEEDED RECORD LENGTH error ABEND.

While Demand Technology gets the data to investigate

their end and tell me what's really there, this change

creates variable WIDE2MBE in the PROCESS dataset to get

the field and support the new record. Later, when we

know the field name, this text will be revised to rename

and label and possibly format the variable.

Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.

Change 16.198 -MXG 16.03 only. MACRO _LIMSUNM UNMATCHED % was spelled

IMACIMSA wrong, and must be MACRO _LIMSUNM UNMATCHD % instead.

TYPEIMSA -PROC SORT DATA=IMSMERGE %VMXGFOR ; worked as long as you

Sep 10, 1998 didn't tailor the _LIMSMRG macro in your IMACIMS, but it

is now PROC SORT DATA=_LIMSMRG OUT=ZZIMSMRG %VMXGFOR;

The MERGE PRG (IN=INPRG) IMSMERGE (IN=INIO); is now

MERGE PRG (IN=INPRG) ZZIMSMRG (IN=INIO); and the DELETE

of IMSMERGE now deletes ZZIMSMRG, to make this work. The

macros will change once more when the 16.134 architecture

is applied to the IMS processing shortly.

Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Change 16.197 The extra include of member IMACCICS in member TYPE110

TYPE110 prevented the &MAC110 or &MACKEEP logic from working to

Sep 10, 1998 redefine the _L macros. Member IMACCICS was removed from

member TYPE110's include, as it is already included by

the VMAC110 member, and there it include is followed by

the MAC110 and MACKEEP macros, so it can be overridden.

Thanks to Jerry Layne, Virigina Power, USA.
======Changes thru 16.196 were in MXG 16.03B5 dated Sep 9, 1998======
Change 16.196 Variables ELAPSTM, INPREQTM, and QUEUETM were calculated

VMAC33 before the variables used had been input. Now, the three

Sep 7, 1998 statements are inside the DO group, after TPNDTIME.

Variable TPUSRTYP was input and formatted, but not kept;

now it is in both TYPE33_1 and TYPE33_2 datasets.

Thanks to John Strumila, IBM Global Services Australia, AUSTRALIA.

Thanks to Lindsay Oxenham, IBM Global Services Australia, AUSTRALIA.
Change 16.195 The Printer Throughput analysis now created PDB.ASUMPRTR

ANALPRTR instead of PDB.PRINTER, to be consistent with current MXG

ASUMPRTR naming conventions. Scan your MXG Tailoring library and

Sep 6, 1998 change PDB.PRINTER to PDB.ASUMPRTR if it exists, but very

few sites regularly use this detailed analysis.
Change 16.194 -IBM now calculates the TYPE72GO Using/Delay Percentages

VMAC7072 using R723CTSA instead of CTOU+CTOT+CUNK+CIDL samples as

Sep 6, 1998 the denominator. R723CTSA adds CIOU+CIOD samples, and is

Sep 22, 1998 used even if I/O Delays are NOT being included in your

Oct 20, 1998 Velocity definition! Since R723CTSA is now larger, the

percentages will be smaller. So that MXG calculations

match the RMF reports, the correction in VMAC7072 is to

insert:

IF R723CTSA GT 0 THEN VALDSAMP=R723CTSA;

before:

IF VALDSAMP GT 0 THEN ....

-Variable PCTEXTSA is now set to missing value, as it is

a total sample count, now in R723CTSA, and not a percent.

-The I/O Velocity calculation when I/O Delay is NOT turned

on was changed to match IBM reports. MXG's old equation

VELOCITY=(CTOU+CIOU)/(CTOU+CIOU+CTOT) is changed to read

VELOCITY=(CTOU+CIOU)/(CTOU+CIOU+CTOT+CTDQ+CIOD) and the

code relocated until after CTDQ had actually been input!

OS/390 R2.4 added CTDQ in an extension of the SMR

record, but MXG's equation was back in the block of

code for the R1.3 extension. Now, 1.3 calculates

without CTDQ while 2.4 and later includes CTDQ.

When I/O Delay IS turned on, MXG sets R723VELI='Y' so the

velocity and I/O velocity are calculated the same way:

VELOCITY=VELOCIOD=CTOU/(CTOU+CTOT);

These changes now match the IBM RMF 2.4 Report values.

Oct 20, 1998 revision:

I/O Velocity enablement is system wide, and when enabled,

all of the Service Classes have R723MSCF='...1....'B, but

that bit is not on in the Reporting Class records. IBM

RMF has acknowledged their error and will fix it in a

future version of RMF, but MXG now stores R723MSCF from

the Service Class record (written first) into retained

variable SERVMSCF, which is now used instead of R723MSCF

to set R723VELI='Y' when I/O is enabled, so the correct

velocity equation will be used in spite of their error.

Thanks to Leonard Ponich, AT&T, USA.
Change 16.193 New reporting variables were added to MEMOACCT dataset:

VMACMEMO MEMDIST MEM3270 NEWMEM RETMEM SENMEM SESSION

Sep 6, 1998 TRXTOT USERPRF for direct reports from MEMOACCT.

Thanks to Harald Seifert, Huk-Coburg, GERMANY.

Change 16.192 Variable A08DURAT=A08BKDTD-A08BKCTD is now created in

VMAC110 CICS statistics dataset CICSLSRR to report how long the

Sep 6, 1998 pool existed. However, the base times are time-of-day

rather than datetimes, so if the pool exists for more

than 24 hours, the duration will not be accurate.

Thanks to Harald Seifert, Huk-Coburg, GERMANY.

Change 16.191 TMS revisions were still not complete, as FILSEQ was

TYPETMS5 missing in second and subsequent VOLSEQs. Before the

Sep 5, 1998 END; statement for the ELSE IF FILSEQ=. THEN DO; insert

MAXFLSEQ=FILSEQ;

LSTFLSEQ=FILSEQ;

and after IF MAXFLSEQ LT 999999 THEN FILSEQ=MAXFLSEQ;

insert IF FILSEQ=. THEN FILSEQ=1;

to always populate FILSEQ variable correctly.

Thanks to John Rosewarne, Telstra, AUSTRALIA.
Change 16.190 Variable PCTDLNDI is now set missing, as it was not a

ADOC7072 valid percent of anything. Instead, the raw count of

VMAC7072 samples, R723CNDI, from which PCTDLNDI was erroneously

Sep 5, 1998 calculated, is now kept. See the detail description in

member ADOC7072 for new variable R723CNDI.

Thanks to Don Deese, (CPExpert), Computer Measurement Sciences, USA.

Change 16.189 Support for Thruput Manager, TPM, was supported earlier

EXTYTPMX by member TYPETPM, but that program INPUT only the data

FORMATS fields it knew about. This new TYPETPMX was written by

IMACTPMX Susan, and it creates temporary FORMAT $MXTPMTK to token

TESTUSR1 each possible TPM field, and then VMACTPMX uses that in

TYPETPMX its TPM record processing. The output dataset contains

TYPSTPMX all possible variables, but will likely be very sparce as

VMACTPMX most TPM sites don't enable all fields, so COMPRESS=YES

VMXGINIT is specified, since sparce datasets compress so well that

Sep 5, 1998 dropping the nonexistent variables is unwarranted. As an

example, 1000 obs uncompressed required 1005 pages, but

compressed by SAS, the TYPETPMX dataset needed only 40!

Thanks to Susan Marshall, SAS Institute ITSV Cary, USA.
Change 16.188 Variable R742PSIG is now documented in ADOC74 that its

ADOC74 contents, inbound or outbound request counts, are in or

FORMATS out depending on variable R742PDIR, path direction, which

VMAC74 is now FORMATed ('80'X=Inbound, '40'X=Outbound). Also,

Sep 5, 1998 variable R742PTYP, path type, is now FORMATed ('1=CTC,

3='List Structure') by $MG074PD and $MG074PT formats.

Thanks to Leonard Ponich, AT &T, USA.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Change 16.187 Support for XCOM Release 3.0 (COMPATIBLE) adds variables

VMACXCOM TCPIPNAM, TCPIPADR, and XCOMMICR to TYPEXCOM dataset. But

Sep 1, 1998 I discovered that variables FLDSNNME REPTDEST REPTFORM

REPTFCB REPTNAME COPYCNT HOLDFLAG CONTFLAG SPOOFLAG

DISPFLAG and REMFLENM were input from wrong locations. I

have confirmed the two important variables, FLDSNNME and

REMFLENM (input/output dataset names) are properly input,

and I think the others are also now properly aligned, but

they are all blank in my test data.

The test data also XCOMVERS=300 when the connection is

from Unix to MVS, and XCOMVERS=3 when the connection

is from MVS to Unix (actually, the value is 'F30000'X

but it prints as 3). But there's no real problem, as

XCOMVERS is not used in any MXG logic.

Thanks to Aubrey Tang, GIO Australia, AUSTRALIA.
Change 16.186 The PROC SORT %VMXGFOR DATA=_WCICDL2 OUT=SRTDLIR; should

CICINTRV be PROC SORT %VMXGFOR DATA=_WCICDL1 OUT=SRTDLIR; as the

Sep 1, 1998 CICDLIR dataset is _WCICDL1 instead of _WCICDL2 (which is

CICDLIT, but that dataset always has zero observations).

Without this change, the A18xxxx variables were missing.

Thanks to Fiona Crane, Royal and Sun Alliance, ENGLAND.

Change 16.185 MXG Support for IMS 6.1 (Change 16.171) is now validated!

ASMIMSL6 -ASMIMSL6 had references to MXGIMSLG, but the program name

TYPEIMSA CSECT name, and comments were changed to MXGIMSL6 to be

VMACIMSA consistent with the JCLIMSL6 member, and so that IMS 6.1

Sep 1, 1998 program name is different than earlier releases.

-VMACIMSA inputs of ARRTIM, NQTIM, GUTIM and DQTIM were

changed from &PD.4. to &PK.4., and the algorithm to

convert was changed. These inputs are now separated into

a block for pre-IMS 6 and post-IMS 6, using _IMSVERS to

choose the correct format.

-TYPEIMSA KEEP= list for _IMSTRAN.IMSTRAN has variables

OLTERM and OVTAMNDE added; they were inadvertently

dropped.

-With these changes, MXG support for IMS 6.1 matches the

Transit Log Report from IBM's IMS Performance Analyzer!

-See also Change 16.171.

Thanks to Alan Green, Allied Dunbar, ENGLAND.
Change 16.184 Utility to create MXG source for Formats $MGDDDDD and

UDDDDDD $MGDDDSN to map "dddddd" to "dataset" and vice versa,

FORMATS for internal use in Change 16.134 programs, like the new

Sep 5, 1998 %BLDNTPDB. UDDDDDD reads the MXG source to find all _W

macro definitions and writes out the VALUE statement that

defines each format, and the output is copied in at the

end of member FORMATS.
Change 16.183 Revision of MXG logic for ABEND and CONDCODE in PDB.JOBS.

BUILD005 While I still think using the PDB.STEPS dataset for job

BUIL3005 ABEND analyis is strongly preferred (because steps ABEND,

IMACPDB jobs don't, and because the STEPS data gives you the

SPUNJOBS PROGRAM name so you can identify who wrote the program

Aug 31, 1998 that ABENDed, and because jobs can have multiple step

ABENDs), this revision populates the PDB.JOBS variables

ABEND and CONDCODE with useful values, and creates new

variable ABENDS that counts the abending steps in a job.
Previously in PDB.JOBS, the ABEND value indicated that

one or more steps abended, but the CONDCODE value was

taken from the last executed step. If COND=ONLY or EVEN

was specified in the JCL, you could have had an ABEND

with a wrong or zero CONDCODE. Or if a step had what is

called a pre-execution ABEND that causes the step to be

not-executed (this includes FLUSHed steps, steps with a

SYSTEM 822 ABEND, and steps with SYSTEM 213 ABEND on the

STEPLIB, which are not explicitly identified in the step

records) the ABEND='SYSTEM' but CONDCODE was zero.

With this revision, the values of ABEND and CONDCODE will

be stored from the FIRST step that ABENDed. If there are

no ABENDs, but there were non-zero condition codes in any

step, the highest non-zero condition code will be stored

in CONDCODE and ABEND='RETURN'. And if there were no

ABENDs in the step records, but the 30-5 job termination

record has the ABENDed bit set in SMF30STI bit "6", the

logic sets ABEND='PREEXE' to flag that some step of the

job had a preexecution error. (Steps with pre execution

errors will have ABEND='FLUSH', so if there was only one

step with FLUSH, you could determine which step failed,

but if there were multiple FLUSH steps, you may not be

able to identify which step actually had the ABEND).

The default of FIRST can be overridden with the MXGCOND

macro variable, which can be %LET of the values of LAST,

HIGHEST, or LOWEST to choose which ABEND/CONDCODE pair

will be stored in PDB.JOBS.
Defaults:

One or more ABENDing STEPS

CONDCODE=CONDCODE of first ABENDing step

ABEND='SYSTEM' or 'USER' from first ABENDing step

ABENDS=number of ABENDing steps

However: If the JOB TYPE30_5 record has the ABEND

bit on but CONDCODE=0, which happens if

the last step did NOT ABEND, MXG sets

ABEND='ABEND' in the PDB.JOBS dataset.
No ABENDing STEPS - ABEND flag on in type30_5

CONDCODE=CONDCODE from type30_5

ABEND='PREEXE'

ABENDS=1