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

Thanks to Rick Salazar, City of Long Beach, USA.

Change 16.040 Corrupted type 42 subtype 6 caused INPUT EXCEEDED error.

VMAC42 The record has SMF42PDL=DFSMSV1R and SMFPDN='DF TP' but

Apr 2, 1998 the rest of the product section is trash and the record

is longer than its triplets indicate is should be!

The INPUT EXCEEDED occurs because MXG did not validate

that the offset field in the PRODUCT section was less

than the record length. To detect and delete these

corrupted records, insert this circumvention:

IF OFFJDDS+LENJDDS GT LENGTH+1 THEN DELETE;

after the statement LOOP42:

The actual MXG change was more extensive, and will

produce a diagnostic message on the SAS log that the bad

record is being skipped.

Thanks to Melanie Floyd, United Parcel Service, USA.

Change 16.039 Year 2000 only. READTIME in TYPE6 will be 1900 for a job

VMAC6 read in year 2000. MXG's protection for CA-Dispatch's

Apr 2, 1998 corruption of the first byte of julian date was resetting

May 14, 1998 the century bit to zero. The statement in VMAC6 could

have been changed from

IF SUBSTR(READCADI,5,1) GT '00'X THEN

SUBSTR(READCADI,5,1)='00'X;

/*CA-DISPATCH CORRUPTION FIX*/

to

IF SUBSTR(READCADI,5,1) GT '01'X THEN

so both year 2000 and CA corrupt records can be processed

correctly. Following text revised May 14, 1998.

However, the actual change that I made was to remove the

protection for the CA corruption, since their current

versions must be installed for year 2000 anyhow, and the

MXG heuristic protection is just another opportunity for

a future error! This error would also have affected

BUILDPDB; the print records would not match the READTIME

of the other job records, so they will create separate

obs in PDB.JOBS with the 1900 date and only print

resources, while the real PDB.OBS with 2000 date will

have no print resources counted.

Thanks to Arzina Merali, Alberta Public Works, CANADA.

Thanks to Joe Zelyas, Alberta Public Works, CANADA.

Taught 3-day class in Dallas, Mar 30 - April 1, 1998.
Change 16.038 Cosmetic. Messages about INVALID SUBTYPE VALUES that

VMXGGETM seemed endless are now printed only for the first five

Mar 27, 1998 records in this utility used to create SMFSMALL file.

Thanks to Joe Zubras, Pennsylvania Hospital, USA.

Change 16.037 Cosmetic. Format $MG028ST was created by Change 13.072,

VMAC28 but was supposed to be used for variable LSCDSTYP, but

Mar 27, 1998 that was only accomplished now, with this change.
Change 16.036 Nine instances of "=F" must be changed to "@" in this

ANALMULT example report; different character translation tables

Mar 27, 1998 were used during transmission of this member.
Change 16.035 Year 2000 Support for AS/400 was incorrect. There are 44

VMACQAPM instances of IF YY GT 0 THEN ... that must be changed to

Mar 27, 1998 IF YY GE 0 THEN ....

and the four lines preceding GDES1=MDY(MO,DD,.... that

input variables YY MO DD and CC with informat &NUM.n.

need double-questionmarks between the variable and the

informat, eg., YY ?? &NUM.2.

Without this fix, the date variables in the year 2000

(only) will have 1960 dates (Because their value is zero

and the zero SAS date is 1960.

Thanks to Mike Wroot, SAS UK Customer Support, ENGLAND.

Thanks to Paul Hill, Midland Bank, ENGLAND.

Change 16.034 Support for DECnet/SNA DTF SMF records creates nine new

EXDECS01 MXG datasets:

EXDECS03 Subtype Dataset Description

EXDECS04 01x *DECSSTAR DECNET/SNA ADDRESS SPACE START

EXDECS05 03x *DECSBEGN DECNET/SNA SESSION BEGIN

EXDECS06 04x *DECSEND DECNET/SNA SESSION END

EXDECS07 05x DECSDIR DECNET/SNA DIRECTORY REQUEST

EXDECS08 06x *DECSALOC DECNET/SNA FILE ALLOCATION

EXDECS09 07x DECSOPEN DECNET/SNA FILE OPEN

EXDECS0C 08x *DECSCLOS DECNET/SNA FILE CLOSE

EXDECS0d 09x *DECSERAS DECNET/SNA FILE DELETE

EXDECS0f 0Cx DECSREQB DECNET/SNA IBM REQUEST BEGIN

EXDECS10 0Dx DECSREQE DECNET/SNA IBM REQUEST END

FORMATS 0Fx DECSTERM DECNET/SNA ADDRESS SPACE TERMINATE

IMACDECS 10x DECSRCAL DECNET/SNA DATASET RECALL ON DIR

TYPEDECS The six datasets prefixed with '*' above have been

VMACDECS tested with data records.

Mar 26, 1998

Thanks to Brian Harvey, Navistar International Transportation, USA.
Change 16.033 IDMS 10.2 records were not output, so all seven lines

VMACIDMS with IF 'xxxx' LE SMFHVER LT '1400' THEN DO; were

Mar 25, 1998 changed to IF SMFHVER LT '1400' THEN DO;

Thanks to Ron Larue, FDISG Boston, USA.

Change 16.032 The MXG DISCOVERY. NO STRUCTURE MATCH. NON FATAL message

VMAC74 should no longer occur. The message was printed when a

Mar 25, 1998 structure in the Request Data Section was not found in

the Structure Data Section, and the only impact was that

variable R744QSIZ in TYPE74ST would be missing for that

structure name in that observation. But now, having

examined sample mismatches, I find that there is an entry

for the Structure in the Request Data Section, but there

is no corresponding entry in the Structure Data Section,

and the Request Data Section has R744SFLG='00000000'B, so

this structure neither was Online at End of Interval, nor

did it Become Active during the interval, but it had been

connected at the start of the interval, hence the Request

Data Section. But IBM explains that the Structure data

is a snapshot at interval end of all allocated structures

in the coupling facility (returned by IXCQUERY), and as

the structure was not allocated at interval end, there is

no structure data. This accounts for the mismatch, so

now, the mis-match message won't be printed when R744SFLG

is zero.

Thanks to Steve Smith, BGS, USA.
Change 16.031 CICS UNEXPECTED STATISTICS RECORD with STID=0 or = large

VMAC110 was caused by incorrect processing of STID=94 record. The

Mar 25, 1998 +11 after LGSAUTOP was INPUT must be +7. This also caused

zero observations in dataset CICLGS.

Thanks to Steve Smith, BGS, USA.
Change 16.030 Variable ABENDUSR in dataset CIMSPROG has never been

VMACCIMS right. The equation ABENDUSR=MOD(ABENDSYS,16)+ABENDUSR;

Mar 24, 1998 must be replaced with ABENDUSR=MOD(ABENDUSR,4096); and

ABENDUSR must be removed from the HEX4 format statement

as IMS User Abends range from 0 to 4095, not 0 to FFFx,

so they will now print as decimal by default.

Thanks to Karen Sherman, Franklin-Templeton, USA.

Thanks to Wayne Collins, Franklin-Templeton, USA.

Change 16.029 Variable R723CIMP (Importance Level) was in the SUM=

TRND72GO argument, making it meaningless in non-zero CPU Dispatch

Mar 24, 1998 times and non-zero Percent CPU Busy values.
Change 16.028 MXG 15.15-15.07 Only. For PR/SM Deactivated Partitions,

ASUM70PR observations were created that had non-zero CPU Dispatch

VMAC7072 times and non-zero Percent CPU Busy values, which when

Mar 24, 1998 summed into ASUM70PR could record more than 100% CPU Busy

for the CEC. Fortunately, very few sites have Partitions

Deactivated, but if you have this error, there will be

observations in TYPE70PR with LPARCPUS=0, as that is the

Deactivated Partition flag.

If you do have LPARCPUS=0 obs, you can correct the old

PDB.TYPE70PR data simply by deleting TYPE70PR obs with

LPARCPUS=0, and then re-run ASUM70PR (which reads the

corrected TYPE70PR dataset) to re-create the corrected

PDB.ASUM70PR dataset:

DATA PDB.TYPE70PR; SET PDB.TYPE70PR;

IF LPARCPUS=0 THEN DELETE;

%INCLUDE SOURCLIB(ASUM70PR);

You can prevent the creation of LPARCPUS=0 observations

in tomorrow's PDB by adding an IF test before the OUTPUT

statement in member EXTY70PR:

IF LPARCPUS GT 0 THEN OUTPUT ....;

until you install this change or MXG 16.01 or later.
The Permanent Fix. Change 15.299 created observations

for the Deactivated Partitions (for availability

reporting) but it failed to reset the variables from the

previous segment in this record. The permanent fix is to

insert these lines immediately after the existing IF:

IF LPARCPUS=0 THEN DO;

LCPUPDTM=.;

LCPUADDR=.;

LCPUSHAR=.;

LPARVPF =.;

LCPUEDTM=.;

LCPUDED =' ';

LCPUWAIT=' ';

LCPUCHST=' ';

LCPUCHWT=' ';

LCPUCAP =' ';

LCPUCAPC=' ';

ORIGWAIT=.;

NEWWAIT=.;

PCTCPUBY=.;

PCTMVSBY=.;

Thanks to Wayne Lauck, State of South Dakota, USA.

Change 16.027 While Change 15.273 mentioned that JES3 APAR UW41108

VMAC26J3 was required to fix an IBM error in the JES3 type 26

Mar 23, 1998 purge record, it did not protect the absence of that

APAR. By inserting IF LENGTH-COL+1 GE 10 THEN

immediately before the INPUT SMF27LN7 &PIB.2.

statement, even if the APAR is not installed, MXG won't

fail.

Thanks to Pete Gain, SAS Software, ENGLAND.

Change 16.026 New subtype 6 SMF type 99 record caused INVALID SERVER

VMAC99 SECTION TRIPLET because SMF99CPO=SMF99CPO+SMF99CPN;

Mar 22, 1998 should have been SMF99CPO=SMF99CPO+SMF99CPL;

This also caused truncated values for SRVCLASS.

Thanks to Steve Smith, BGS Systems, USA.
Change 16.025 "SHORT ABAR" warning messages about deleted records could

VMACHSM be erroneously created. Insert the INPUT statement below

Mar 22, 1998 between the ELSE DO; and the LENGTH-COL test so it reads:

ELSE DO;

INPUT @15+OFFSMF @;

IF LENGTH-COL+1 LT 274 THEN DO;

The COL value was still @40 as a result of the prior

INPUT, so records that were sufficiently long were

incorrectly deleted, but with the warning message.

Thanks to Don Friesen, B.C. Government, CANADA.

Change 16.024 -Support for new object "Database" creates new MXG dataset

EXNTDATA named DATABASE. This object has 104 fields in the record

IMACNTSM but only 16 are populated with field names and data.

VMACNTSM -Support for EXCHANGE 5.5 (INCOMPATIBLE) inserted data in

Mar 21, 1998 seven MS Exchange objects (IMC, IS Private, IS Public,

IS, Internet Protocols, MTA, and MTA Connections), which

caused INVALID TRIPLET warnings and skipped records until

this change is installed. Scores of variables were added

and some no longer exist in the Exchange records.

-Messages INVALID DATA FOR DURATM for Discovery Records

(Discovery Records have OID=0) occurs with NTSMF 2.1.4

records, but it has no impact on the real datasets that

MXG creates. The format of the Discovery Records was

changed, causing the MXG message.

-In addition, the _UNTDISC utility to print the Discovery

Records no longer worked with Release 2.0.h, which has a

NRNAMES field only in the 0.5 and not in the 0.6 or 0.6,

and there is an extra field at the end of each 0.7 record

that contains a repeat of the penultimate field. Also,

records from NTSMF 2.1.4 have still different Discovery

records, but the NTSMF Version is still 2.0.h, so logic

based on whether DURATM is missing or not (because the

new format has OBJECT name where DURATM was) is used to

decode which Discovery Format is in place, so that

_UNTDISC is now functional.

Thanks to Jim Quigley, Con Edison, USA.

Change 16.023 Change 15.368 added the DURATM=INTERVAL parameter to the

ASUMJOBS VMXGSUM invocations in most ASUM members, but ASUMJOBS

Mar 20, 1998 was overlooked until now.

Thanks to Chris Weston, SAS Institute ITSV, USA.

Change 16.022 Only for those few who use the &DEBUGMXG symbolic during

VMXGSUM testing is this minor fix needed. The three lines

Mar 20, 1998 %IF &MXGDEBUG GE 2 ...; %ELSE %IF &MXGDEBUG GE 3 ...;

May 14, 1998 and %ELSE %IF &MXGDEBUG GE 4 ....; need the %ELSE

removed from the second and third lines.

This Change was not included in MXG 16.01, but was in

MXG 16.02.

Thanks to Graham Bell, Blue Cross Blue Shield of Kansas, USA.

Change 16.021 The TRENDing of TYPE70 dataset had not been updated for

TRND70 more than 8 CPUs. While TYPE70 contained sixteen buckets

Mar 20, 1998 for CPU's (variables suffixes 0-9,A,B,C,D,E,F), but the

TRND70 member was overlooked when variables 9 and above

were added to TYPE70. The lists of these variables were

expanded: CPUWAITn, IORATEn, PCTCPBYn, PCTTPIn, VFAFFTMn,

and logic added for PCTTPIn, PCTCPBYn and PCTRDYWT

calculations.

Thanks to Graham Bell, Blue Cross Blue Shield of Kansas, USA.
Change 16.020 Support for Software Engineering's SpaceManager's two

EXSPMGSP flat files, Space Records and Volume Records create two

EXSPMGVL new datasets:

FORMATS SPMGSPAC - SpaceManager Space Records

IMACSPMG SPMGVOL - SpaceManager Volume Records

TYPESPMG MXG requires both a //SPMGSPAC DD and a //SPMGVOL DD and

VMACSPMG will read both files with member TYPESPMG. If you only

Mar 20, 1998 want to process one file, simply DD DUMMY the unwanted.

Apr 7, 1998 Several new $MGSPMxx formats are created, so you will

need to update your MXG Format library using this new

FORMATS member.

Thanks to Hans Juergen-Beck, DVG, GERMANY.

Change 16.019 -Variables TPXBYTI and TPXBYTO have always been wrong, due

VMACEPIL to an error in CA's documentation. Instead of being two

VMACOMAU 8-byte fields, they are now input as &PIB.4. and a line

VMACOMCI with +4 follows each to skip over the unused 4-bytes.

VMACTPX -It was also noted that all of the internal TPX datetimes:

VMAC39 TPXETIME, TPXSTIME, TPXUTIME were on the GMT clock, while

Mar 20, 1998 the SMFTIME is on the local clock, but there is a GMT

Apr 6, 1998 offset in the record, so now, MXG converts those three

timestamps into local. The CVTTZ field in the record is

the high four-bytes of the GMT offset, which is not an

exact value, so the following algorithm is required to

get the GMT offset in seconds into TPXCVTTZ:

INPUT TPXCVTTC $CHAR4. @;

TPXCVTTZ=INPUT((TPXCVTTC!!'00000000'X),&IB.8.6)/4096;

IF . LT TPXCVTTZ LT 0 THEN TPXCVTTZ=FLOOR(TPXCVTTZ);

ELSE TPXCVTTZ=CEIL(TPXCVTTZ);

For example values, the raw TPXCVTTC is '00000D69'x for

a +1 hour (3600 seconds) European offset, and for a -5

hour (-18000 seconds) USA EST is 'FFFFBCF2'x.

Then to correct timestamps to local, you add TPXCVTTZ:

TPXETIME=TPXETIME+TPXCVTTZ;

-In validating this change, I looked at all of the members

that contain CVTTZ and I discovered that in four members,

VMACEPIL, VMACOMAU, VMACOMCI, and VMAC39, I had reversed

the FLOOR and CEIL functions, which caused a one second

error in value of the GMT offset, so those four members

were also corrected by this change.

Thanks to Harry Olschewski, DeTeCSM, GERMANY.

Change 16.018 Member DOCGRAF is updated with examples of getting graphs

DOCGRAF from the mainframe to your PC. The new examples were

Mar 20, 1998 originally postings on our MXG-L ListServer.

Thanks to Bob Hare, Comerica, INC, USA.

Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 16.017 The three DSORG fields in DCOLLECT (DCDSORG,UMDSORG, and

VMACDCOL UBDSORG) are increased to three bytes long from two, and

Mar 19, 1998 the suffix "U" will be added (e.g., DSORG='PSU') for the

files that "contain location dependent information, the

old "Unmoveable" attribute. I had erroneously set the

DSORT='U' for the Unmoveable attribute.

Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.016 Change 15.356 introduced the &MACxxxx macros, but member

IMACFILE IMACFILE was overlooked. Now, &MACFILE is initialized as

VMXGINIT blank in VMXGINIT and a line with only &MACFILE now ends

Mar 18, 1998 member IMACFILE (which is included after the SMF header

has been input), so that any tailoring of member IMACFILE

(formerly done EDIT and SAVE into your USERID.SOURCLIB)

and now be done inline by setting the &MACFILE variable.

Because this &MACFILE variable will be inserting actual

SAS statements with semi-colons, the always-safe-syntax

to use to insert statements in &MACFILE is:

%LET MACFILE= %QUOTE(

LINE OF CODE TO BE EXECUTED ;

LINE OF CODE TO BE EXECUTED ;

LINE OF CODE TO BE EXECUTED ;

) ;

For a specific example, your //SYSIN program could be:

%LET MACFILE= %QUOTE(

IF ID=110 AND SUBTYPE=2 THEN DELETE;

) ;

%INCLUDE SOURCLIB(TYPE110);

would delete the CICS subtype 2 (Statistics) records so

no //WORK space would be needed by them, but would read

the CICS subtype 1 transaction records to create CICSTRAN

observations. Note that while the references are

&MACFILE, the %LET syntax does not use the ampersand.
If you have an-already-tailored IMACFILE member, you must

either add &MACFILE to the end of your tailored member

(so that any code added inline with &MACFILE will be

executed AFTER the code in member IMACFILE), or you must

remove your tailored IMACFILE member and do all your

tailoring in the %LET MACFILE= statements.

For reasons that are still unclear, it was necessary to

add a semicolon after the &MACFILE statement in the

IMACFILE member to satisfy the SAS compiler under MS

Windows, but not under MVS!

Thanks to Chuck Hopf, MBNA, USA.
Change 16.015 Documentation. Variable JCSPTIME had been INPUT but not

VMAC110 kept, but was re-spelled as JCSPTOD when it was added to

Mar 17, 1998 the KEEP= list for dataset CICSSMED in Change 15.157.

Thanks to Jens Schlatter, Independent Consultant, GERMANY.

Change 16.014 Variables XMGMXT and XMGTNUM were not kept in CICINTRV

CICINTRV dataset (in CICS 4.1 XMGMXT replaced DSGTL's MAXTASK

Mar 16, 1998 limit; DSG fields for AMAXTASK no longer exist in 4.1).

In the last VMXGSUM invocation in member CICINTRV, add

XMGTNUM to the SUM= argument and XMGMXT to the MAX=.

Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.

Change 16.013 Cosmetic. Variable WTSCWTCN was given FORMAT TIME12.2,

VMACTMO2 but the variable that should have been in the FORMAT

Mar 16, 1998 statement was WTSCWTTM.

Thanks to Chris Weston, SAS Institute ITSV, USA.

Change 16.012 IDMS Version 10.2.1 PMHRTYPE=1 records caused error INPUT

VMACIDMS STATEMENT EXCEEDED RECORD LENGTH. Find the FIRST instance

Mar 16, 1998 of the line reading:

ELSE IF '1201' LE SMFHVER LT '1400' THEN DO; and change

it to read: ELSE IF '1021' LE SMFHVER LT '1400' THEN DO;

Thanks to Alan Deepe, SBC Warburg Dillon Read, ENGLAND.

Change 16.011 Variable SRHCRWRT is now SRCHRWRT to be consistent with

VMACNTSM the other spelling of other SRCHxxxx variables in dataset

Mar 15, 1998 FULCRUM built from NTSMF records.

Thanks to Chris Weston, SAS Institute ITSV, USA.

Change 16.010 Member YEAR2000 now warrants that MXG is (in IBM terms)

YEAR2000 "Year 2000 Ready", and the cover letter that is normally

Mar 15, 1998 sent in reply to year 2000 requests is now included at

the beginning of member YEAR2000.

Change 16.009 Variable MXGVERSN in dataset TYPE70 was blank in 15.15.

VMAC7072 Originally MXGVERSN=SYMGET('MXGVERS'); was before the

Mar 13, 1998 IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO; logic, but

Change 15.354's relocation of IF tests (for BUILDPDB's

performance) inadvertently caused the SYMGET to only be

executed for pre-XA RMF records. The simple fix is to

just copy the three lines:

IF MXGVERSN=' ' THEN DO;

MXGVERSN=SYMGET('MXGVERS');

END;

to immediately follow the IF ... AND MVSXA THEN DO;....

statement, so the SYMGET statement is executed once for

either type of record. However, Don Deese showed me that

RETAIN MXGVERSN "&MXGVERS" ;

will initialize a RETAINed character variable to the

value of a macro variable, so the actual change replaced

the existing RETAIN MXGVERSN ' ' statement with the

above syntax, deleted the three-line DO group on MXGVERSN

and added a line with MXGVERSN $6 to the LENGTH statement

to define MXGVERSN's length.

Users of CPExpert will need to install this change or get

a one-line fix from Don Deese to circumvent my error.

The PROC COMPARE that should have caught this error that

was not run for MXG 15.15 has been reinstated in MXG QA!

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

Thanks to Lynn Meyer, Storage Tek, USA.

Thanks to David Ehresman, University of Louisville, USA.
Change 16.008 Duplicate observations in TYPE30_V might not be deleted.

BUILDPDB Change 15.235 discussed the addition of MULTIDD EXTRADD

BUILDPD3 to the BY list for TYPE30_4 and TYPE30_5, but those two

BUILD005 variables were not added to the TYPE30_V sort until this

BUIL3005 change.

Mar 13, 1998

Thanks to Allan Winston, MBNA, USA.
Change 16.007 Cosmetic. Format MGILKAT had repeated 4: for the RETR,

FORMATS APPE, and STOR actions, instead of having 8:RETR, 16:APPE

Mar 13, 1998 and 32:STOR for the format values.

Thanks to Ken Mazer, Internal Revenue Service WVA, USA.

Change 16.006 The ARRAY statement permitted only 10 LCUIDs, causing the

ANALPATH SUBSCRIPT OUT OF RANGE error. The array statement was

Mar 11, 1998 increased to 16, the LCU1-LCU9 instances were change to

LCU1-LCU16 and variables LCU10 thru LUC16 were added to

the initialization logic.

Thanks to Tobias Cafiero, Mercedes Benz of North America, USA.

Change 16.005 Variable PCTDLSSW was added by Change 14.318, but its

VMAC7072 value was incorrect because it was never divided by the

Mar 5, 1998 variable VALDSAMP due the misspelling as PCTLDSSW in the

line in which it should have been divided by VALDSAMP.

Thanks to Chris Weston, SAS Institute CARY, USA.
Change 16.004 Change 15.293 discussed why YEARSECS and YEARDAYS can not

TYPEDMS be used to protect non-Y2K-compliant date fields, but the

TYPEMON8 code in these four non-compliant products was not changed

TYPETMON until this change, which uses smart logic to protect.

VMACNSM

Mar 5, 1998

Change 16.003 IBM's NPM product now creates a "century" value in their

VMAC28 unique date fields, but the new and unexpected format of

YEAR2000 'CYYMMDDF'x is still not documented by IBM. APAR II10481

Mar 4, 1998 does make the following statement:

Mar 9, 1998 "97/04/30 NPM will support the year 2000. User's do

not need to do anything special.

Further details provided by NPM development:

NPM's SMF record header contains the date (SMF28DTE)

in the form 0CYYDDDF, where the '0C' represents the

century. This byte contains '00' in this century