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

NUMR 02535C4D22000FB2005F18F19989090909090909

and some records seem to have trashed the second quote:

280 result="200 Docume05/18/1998.0.0.0.0.0.0. 320

ZONE 76776732333246676633233233330303030303030

NUMR 2535C4D220004F35D505F18F19989090909090909

MXG has additional logic to handle these anomalies.

These values for RESULT have been found in data. Note

the real joy of UNIX programmers who have five different

case sensitive spellings for RESULT 304 and conflicting

meanings for RESULT 200 and other RESULT values!

RESULT value Count

blank or incomplete double-quote 124

"200 Document follows" 36

"200 File data follows" 2

"200 OK" 881

"204 No content" 28

"302 Found" 4

"302 Moved Temporarily" 12

"302 Object Moved" 3

"302 Object moved" 5

"302 Redirection, oh yay" 1

"304 File Has Not Been Modifed" 8

"304 NM" 40

"304 Not Modified" 183

"304 Not modified" 2

"304 Use local copy" 186

"403 Forbidden" 3

"404 File not found" 3

"404 Hostname lookup failure" 5

"404 Not Found" 2

"404 Not found" 3

"404 Object Not Found" 6

"500 Internal Server Error" 2

"500 Unable to connect to remote 6

"Not HTTP/1.0 response" 113

Thanks to Brian Harvey, Navistar International, USA.

Change 16.101 Support for TME 10 NetView for OS/390 V1 R1 SMF type 38

EXTY3801 record creates these new datasets:

EXTY3802 TYPE3801 Command Authorization Table subtype 1

EXTY3803 TYPE3802 Task Resource Utilization Data subtype 2

IMAC38 TYPE3803 Span Authorization Table subtype 3

VMAC38 but only the TYPE3802 has been tested with data. The

Jun 1, 1998 NAME column is missing in tables 45-50 for subtype 3 in

Jul 16, 1998 IBM's "Application Programmers Guide" SC31-8223-01, but

IBM provided the DSECT so MXG variable names match!
In addition, this product is NOT Year 2000 Compliant,

as the date fields in the subtype 1 and 3 are in the

MM/DD/YY HH:MM:SS format! As usual, however, MXG will

protect the YY using the 1959 windowing technique.

Note that many of the raw data fields contained units of

KB per minute, but they have been converted to bytes per

second and formatted with MGBYTES format so they will

print rates in bytes, KB, MB, etc, per second, to be more

consistent with the rest of MXG than this narrow world

that measures per minute. Also, I/O rates were converted

to rates per second versus per minute, and all rates have

"per sec" in the label to make it clear.

Thanks to Leo Meyer, Humana, Inc, USA.
Change 16.100 The NON-FATAL STRUCTURE MISMATCH message that I thought

VMAC74 I had eliminated in Change 16.032 can still show up. The

May 27, 1998 tests R744SFLG EQ '00......'B and R744SFLG NE '00......'B

was added because that value was observed in data, but

those tests must be changed to

R744SFLG EQ '0.......'B and R744SFLG NE '0.......'B

because when the structure is not online (EQ 0) there

never will be a match, so there is no message to print.

Only if there is a mismatch AND the structure was online

at the end of interval, will the message now print.

Thanks to Gary L. Beers, Boeing Information & Support Services, USA.
Change 16.099 Support for MQ Series Version 1 Release 2 (INCOMPATIBLE,

VMAC115 but only for dataset MQMLOG, Log Manager Statistics,

May 26, 1998 which will have missing values for all of the QJSTxxxx

variables without this change). New variable QJSTLLCP

was added to dataset MQMLOG by the new version.

There were no changes to the type 116 SMF record in 1.2.

Note that previous MQM Version numbers were 1.2 and 1.4,

but those were really 1.1.2 and 1.1.4 and this new one,

Version 1 Release 2, is really MQ Series 1.2.0.

Thanks to ???, ???, ???.

Change 16.098 ANALSRVC reports CPU Percentage by Service Class for Goal

ANALSRVC Mode from TYPE72GO (like ANALPGNS for Performance Groups

May 21, 1998 in Compatibility Mode from TYPE72). Two percentages are

calculated:

SVPCTCAP - Pct of total Interval Capacity (NRCPUS*DURATM)

SVPCTUSE - Pct of total CPU Used (CPUACTIV during Intvrl)

For example, a SRVCLASS that recorded 1 hour of CPU time

in a 1 hour interval on a 2-engine CEC that was 75% busy

(TYPE70 was 1.5 hours) would have its SVPCTCAP= 50% and

SVPCTUSE= 66.6%. This report was incomplete in MXG 14.14

so Glen cleaned it up so it actually works!

Thanks to Glenn Bowman, Wakefern Food Corporation, USA

Change 16.097 Support for Landmark's Monitor for DB2 Version 3.1 is

VMACTMDB INCOMPATIBLE (i.e., you must have this update to read

May 21, 1998 the 3.1 records) because fields were inserted in their

Jun 1, 1998 records. New variables were added to these datasets:

TMDBDA2 - 26 TMDBDAB - 18 TMDBDAF - 1

TMDBDB2 - 19 TMDBDBB - 1 TMDBDBR - 1

The headers are now decoded for all records, but there

are additional data in some record segments (notably

the BB-BL family, and the DC, DE, DD, and DF) that are

not decoded until someone wants to use that detail data.

Jun 1: INPUT for DABGLCK comment line was shortened.

Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.

Change 16.096 The Structure Type Identifier, variable R744STYP is now

VMAC74 formatted with $MG074TT format:

May 19, 1998 '01'X='01X:UNSERIALIZED LIST STRUCTURE'

'02'X='02X:SERIALIZED LIST STRUCTURE'

'03'X='03X:LOCK STRUCTURE'

'04'X='04X:CACHE STRUCTURE'

and IBM has agreed to update the SMF manual to document

the values for that field.

Thanks to Yanara Perez, UPS, USA.
Change 16.095 The TYPE74 variable IORATE has been calculated by divide

VMAC74 of SSCHSAMP (SMF74MEC) by DURATM. SSCHSAMP is the number

May 15, 1998 of SSCH instructions for which pending, connect, and

actives were stored, and is returned by the hardware to

RMF. But IBM uses SIO74CNT (SS74SSC), which is the

number of requests to the device and it includes SSCH and

RSSCH instructions, to calculate IORATE in RMF reports.

I have changed to use SIO74CNT in the numerator of IORATE

not only to match IBM, but because this will provide the

IORATE even if SSCHSAMP is zero (which Diane discovered

and is investigating with IBM and her hardware vendor).

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 16.094 The test IF &LOMONTH LE ZDATE LE HIMONTH; must be changed

BLDNTPDB to read IF "&LOMONTH"D LE ZDATE LE "&HIMONTH"D; to avoid

May 15, 1998 a 73-222 error when BLDMNTH=YES (the default) is used.

This member is undergoing revisions and enhancements,

and a new option FIRSTRUN= has been implemented to init

initialize the PDB, daily, weekly, etc., libraries.

but this will not be completed in time for MXG 16.02.

Thanks to Bob Gauthier, American Stores, USA.

Change 16.093 The test IF LENGTH EQ 1464 THEN DO; in the Interval CICS

TYPEMON8 record is now IF LENGTH-COL+1 GE 212, because the fields

May 15, 1998 starting with TIAPREQ are present but were not input (so

they had missing values in dataset MONISYST) in records

of different lengths.

Thanks to ???, ???, GERMANY.

Change 16.092 CICS Statistics (type 110 subtype 2) dataset CICDS has

VMAC110 four divides by 5096 should have been divide by 4096.

May 15, 1998 The four variables for the fifth TCB, DS5TWT, DS5TDD,

DS5TCT and DS5ACT would have been about 20% smaller than

they really were. DS5ACT is a included in CPUTCBTM, so

it too was a little bit low. Fortunately, although there

are now six TCBs in a CICS region, almost all of the CICS

CPU time is still in the first TCB (762 second out of 765

seconds, for example), so the impact of this error in the

fifth TCB is minimal on this CICS statistics dataset.

Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 16.091 Landmark TMON for CICS V2 Converted Records do not set

TYPEMON8 TAFLAG6 bits to "Detail" (because V2 no longer has the

May 14, 1998 History or Summary records - all V2 records are "D"),

but MXG sets MONIRECD=' ' and then tests TAFLAG6 to set

MONIRECD to D,S, or H. But with no bits set in V2,

MONIRECD remained blank. The correction is to initialize

MONIRECD='D' instead of MONIRECD=' ' so that the V2

records will always be "D" and older version's with

TAFLAG6 bits will set the "S" or "H" if appropriate.

Only if you have added logic using MONIRECD that expects

the 'D' will this problem cause you an error (but this

site had IF MONIRECD='D' THEN OUTPUT MONITASK; in their

EXMONTSK exit, to discard the old History/Summary data,

so they had zero observations in MONITASK dataset due to

the blank value in MONIRECD in V2 records!

Thanks to Tim Downs, CSC TMG Warren, USA.

Change 16.090 Four additional fields were added to the type 42 st 14

VMAC42 ADSM SMF record that are now output as MXG variables

May 14, 1998 in dataset TYPE42AD:

SMSBYTCS='SPACE-MANAGED*DB OBJ BYTES*SENT CL-SRV'

SMSBYTRE='SPACE-MANAGED*DB OBJ BYTES*RETRIEVED'

SMSOBJIN='SPACE-MANAGED*DB OBJECTS*INSERTED'

SMSOBJRE='SPACE-MANAGED*DB OBJECTS*RETRIEVED'

and the conversion of kilo-bytes to bytes now uses the

factor of 1024 instead of 1000.

Thanks to David Ehresman, University of Louisville, USA.

Change 16.089 Zero observations occurred, apparently because the INPUT

TYPEVLFC of RESTOFIT $CHAR80. needs to be RESTOFIT $CHAR72.

May 13, 1998 The actual change was more extensive, calculating LENLEFT

in the record and INPUTting with $VARYING72.

Thanks to Martin Lee, Safeway, UK.
Change 16.088 Magstar drives have 0E8x for both DENX and TRTCH, but

VMACTMS5 MXG failed to decode those values, causing variable DEN

May 13, 1998 to be missing, and DEN is used to create observations in

DSNBRECD records, so datasets were not reported, and DEN

is also used to estimate the number of feet of tape).

This fix sets DEN=99000 for MAGSTAR so that observations

will be created, but a better density estimate may be

needed if length of tape is important. However, with

compressed data on tape, the ability to measure the feet

used is non-existent, since CA-1 provides only the

uncompressed size.

Thanks to Trevor Holland, Telstra, AUSTRALIA.

Change 16.087 The &MAC50 statement was misspelled as &MAC40 in MXG

VMAC50 15.15, but has now been corrected to &MAC50.

May 11, 1998

Thanks to Bill Shanks, BRBS Sema Group, UK.

Change 16.086 The UDKSCONT utility reads the output of PC DIR commands

UDSKCONT to measure PC filespace and estimate PC diskspace needed

May 9, 1998 (considering FAT cluster waste per file), but the MXG

algorithms (which assume the space in the last cluster

is lost) are not exact. My C: drive has 1546MB capacity,

129MB free and 1413MB in use, according to Properties.

Issuing these five DIR commands:

DIR *.* /S >> DISKFARM

DIR *.* /S /AH >> DISKFARM

DIR *.* /S /AR >> DISKFARM

DIR *.* /S /AS >> DISKFARM

DIR *.* /S /AA >> DISKFARM

to get Hidden/Read-only/System files/Archive files.
Change 16.085 The new support for Mobius InfoPac RDS View Direct 6.1

VMACIPAC in change 16.052 was validated, and minor changes were

May 8, 1998 made to deal with the changed records: subtype 1 and 2

are same length but 2-byte century field was added at the

beginning and a 2-byte filler at the end was deleted; the

subtype 3 and 4 was increased by 4-bytes, and the revised

code has been tested with both 5.2 and 6.1 releases.

Thanks to Clark Jennings, Reynolds Metals Company, USA.

Change 16.084 The new calculation of RESPSTD should have used RESPAVG

TRND72 instead of AVGELPTM.

May 8, 1998
Change 16.083 The new OS/390 R2.5 Job queueing durations in TYPE72GO

VMAC7072 variables R723CQDT, R723CADT, R723CCVT, and R723CIQT were

May 8, 1998 incorrectly multiplied by 128 when they should have been

multiplied by 1024. They are in 1024 microsecond units,

but I carried down the 128 from R723CIOT, which is in 128

microsecond units. Also, R723CQDT was incorrectly

spelled as R723CDQT, but now matches the DSECT name.

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

Change 16.082 This ABEND report uses PDB.STEPS (because programs ABEND,

ANALABND jobs don't) to produce a report similar to the example in

May 8, 1998 Table 27.5 in the MXG Guide (see member ACHAP27). This

report tabulates ABENDs by Group, where you define the

groupings by EDITing the PROC FORMAT statements. In this

example, the variable JOBCLASS is used to define groups,

but any variable in PDB.STEPS (including ACCOUNT1, JOB,

etc.) could be used to group the tabulation.

This is also a good example of how to build table lookups

with PROC FORMAT and report with PROC TABULATE.

Thanks to Kevin Clark, Amtrak, USA.

Thanks to Chuck Hopf, MBNA, USA.

Change 16.081 The JCL parameter TAILORNG in the MXGSAS JCL Procedure

MXGSAS causes a JCL error with JES 3.1.3, because the symbol is

May 8, 1998 more than seven characters, so it has been changed to

TAILOR to avoid the error. However, one other site had

to remove both references to the TAILOR parameter to

eliminate a strange SAS 180 error, after the SAS

Initialization but before the MXG initialization

messages, that was followed by another SAS message that

the USERID.SOURCLIB was not a PDS when it most definitely

was. TAILOR is an MXG optional JCL parameter that is not

explicitly used anywhere in MXG and can be removed

without causing a problem.

Thanks to Tom Marchant, Wayne State University, USA.
Change 16.080 Multiple purge records can be created for JES3 jobs,

BUILDPD3 but MXG logic in BUILDPD3/BUILD3005 did not expect more

BUIL3005 than one purge record. These JES3 purge records are

May 7, 1998 identical with same READTIME, JOB, and JESNR values, and

only these variables are different in the three records:

JFINTIME JPURTIME ENTERDJ LEFTDJ TYPETASK SPOOLREC

. 04:46:29 Y STC 780

07:53:00 07:53:00 Y JOB 468

07:53:48 07:53:48 Y JOB 468

Most triplets had STC in the first record, JOB in the

second and third record, and came from started tasks that

had run for a week, were taken down, apparently had their

SYSOUT "dumped" and later had it "entered". There were

also pairs of purge records with TYPETASK='TSU' followed

by TYPETASK='JOB', and there were many pairs with both

first and second records containing TYPETASK='JOB'. It

looks like when JES3 "enters" the SYSOUT, it uses the

same JOB and JESNR, but sets TYPETASK='JOB' in those

subsequent purge records, even when the original "job"

was a STC or a TSO USer.

In all cases of multiple JES3 purge records, the first

record had LEFTDJ='Y', indicating the job left the system

by way of DJ (dump job), and the subsequent records have

ENTERDJ='Y', indicating the job entered the system by way

of DJ, so perhaps if you never use JES3 DJ, you never had

a problem. (There were purge records with LEFTDJ='Y'

and/or ENTERDJ='Y' that did not have multiple records,

but I only looked at part of a day's data.)

The problem with these multiple purge records is that

they cause multiple observations to be built in the

PDB.JOBS dataset, so I had to add logic to ensure that

only one purge record, the first one (i.e. earliest

JPURTIME) will be used to create PDB.JOBS, and the other

purge records create a new dataset DJPURGE for further

investigation.
The actual change was

-add DJPURGE to the DATA statement that creates

TYPE26J3 from SETS TYPE26J3 and SPIN26,

-after the END; statement, insert:

IF FIRST.JESNR THEN OUTPUT TYPE26J3;

ELSE OUTPUT DJPURGE;

Thanks to Brian Harvey, Navistar, USA.
Change 16.079 New format MGDECSR had extra quotes which caused a SAS

FORMATS "WARNING: At least one string was over 98 characters long

May 6, 1998 and had special characters and had to be truncated to

98 characters" that was overlooked (perhaps because that

warning did not set a condition code - I am now revising

the MXG QA stream to automatically detect any warnings in

the PROC FORMAT step, even if it set no condition code.

(SAS does not always set a condition code for a WARNING).

Thanks to Scott Wiig, US Bank, USA.
Change 16.078 All variables with format MGBYTES are now stored in 8

DOC bytes rather than 4 bytes. There were 2051 variables

May 6, 1998 in 332 MXG-built SAS datasets with that format, but by

searching all members of MXG for MGBYTES, there were

only about 220 that had to be scanned and only 105 that

were actually changed. Typically, the lines of the

FORMAT statement were copied into the LENGTH statement

and set to length 8. It is the DEFAULT=4 operand in

the LENGTH statement that sets the stored length. Some

report members that had no length statement did not have

to be changed, and code that only used MGBYTES in a PUT

statement in a DATA step were not changed, because all

SAS numeric variables are length 8 during the data step

that creates them; it is only when output to DASD that

the variable is truncated into four floating point bytes.

See MXG Technical Note on this subject.

Change 16.077 -Under SAS V7, when you create an output dataset using

VMXGSUM the PROC CONTENTS OUT= operand, the lengths of some of

May 5, 1998 the created variables are changed. In particular, NAME

Sep 9, 1998 will be 32 bytes long in the V7 output dataset, whereas

NAME was only 8 bytes long in the V6 output dataset. In

VMXGSUM, we create a list of names in your arguments as

length 8, but when we merge that list with the output of

PROC CONTENTS (to verify the variables you listed are

actually there to summarize), SAS V7 raised a warning

message. This change forces the length of NAME to 8 s

bytes, but was not actually made until Sep 9, 1998.
Change 16.076 -Using the new ASUMTALO summarization with a version of

ASUMTALO MXGTMNT/ASMTAPES earlier than MXG 14.01 (ML-10, which

May 5, 1998 was the first version that created the End-of-Interval

allocation records) created zero observations in ASUMTALO

because the new logic did not validate that there were

any interval records to use. Now the logic only uses

interval records when they are found in your SMF records,

so ASUMTALO observations will always be created now.

-The LENGTH of variable DEVICE defaulted to 8 if there was

no SPIN.SPINTALO (i.e., for the initial run of ASUMTALO),

but the length of DEVICE in TYPETALO is 7. Under SAS V7

this raised a WARNING message about unmatched lengths

of character variables when the new and old datasets are

interleaved, so now DEVICE is set to length 7 to avoid

the warning and its associated return code of four.

Thanks to Chuck Hopf, MBNA, USA.

Change 16.075 -DB2 variables CLASS3WT and CLASS3TM (DB2 Class 3 wait

ANALUOW counts and wait durations) are added to ASUMUOW and

ASUMCICS TRNDUOW datasets. These are the sum for all of the

ASUMUOW twenty individual class 3 wait buckets, for a high

TRNDCICS level view of DB2 waits in the ASUMUOW dataset.

TRNDUOW -The new wait variables added by CICS TS 1.2 (see text

May 5, 1998 of change 15.274) are included in the ASUMUOW and the

TRNDUOW datasets.

-CICS variables SSQELAP, RESPSTD and MAXRESP are now

created in TRNDUOW.

-ANALUOW analysis reports now have MAXRESP on report 2 and

both MAXRESP and RESPSTD on report 3 to show how tightly

clustered response times are. New option PLOTIT= sets

the number of minutes between tickmarks on the X axis for

plots of response time versus time of day (and uses the

specified STARTIME= and ENDTIME= values on the x axis).

If PLOTIT is not specified, no plot is produced. If both

PLOTIT= and GRAFOUT are specified and you have SAS/GRAPH,

a graphics catalog named ANALUOW will be built in the DD

pointed to by GRAFOUT.

-Variables SSQELAP and RESPSTD were added to ASUMCICS and

TRNDCICS output datasets.

Thanks to Chuck Hopf, MBNA, USA.
Change 16.074 Change 15.320 replaced hardcoded PDB DDname references

ANALBLSR with &PDBMXG macro variables to externalize the DDname,

VMACFRYE but these members had wrong syntax. In ANALBLSR &PDBMXG

XDB2LOCK was changed back to &PDB because the usage was inside a

XNALCACH %MACRO with a PDB= operand, while VMACFRYE had PDBMXG

ZGRAFRMF changed to &PDBMXG; the other three disused members were

May 5, 1998 corrected for consistency but are not actively used.

Thanks to Chuck Hopf, MBNA, USA.

Change 16.073 INVALID DATA FOR TMMDMODL message is printed because the

TYPEMON8 INPUT TMMDMODL &NUM.2. should be TMMDMODL ?? &NUM.2.

May 5, 1998 Add the ?? modifier to suppress printing of the message

and hex dump when invalid data is attempted to be INPUT.

MXG's logic to detect whether this Landmark record has YY

or YYYY dates knows that TMMDMODL will be invalid (and

hence set to missing value) for the non-Y2K compliant

records, and so it rereads TMMDMODL as &PIB.2. when

TMMDMODL is missing, and so the datasets built by

TYPEMON8 were just fine. I just forgot to add the ??

modifier to eliminate the unnecessary print messages.

Thanks to Diane DePasquale, CSC TMG Warren, USA.

Change 16.072 Old variables FSPCBTRP FSPCBTRT FSPCCOLP and FSPCCOLT in

VMACICE dataset ICEBRGSY are renamed to FSBYxxxx because the FSPC

May 5, 1998 prefix is was intended for percentages, not storage size,

and FSPCCOLP and FSPCCOLT already existed in ICEBRGUT,

and their label and format was overlaying the ICEBRGSY

variables. The FSBYxxxx variables are formatted MGBYTES.

Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 16.071 This new program merges VSAM type 62 and 64 SMF records

ANAL6264 to add OPENTIME to each CLOSE record. Dataset VSAMOPEN

May 4, 1998 has an observation for each open from each job for each

VSAM ENTRNAME.

The ENTRNAME in the OPEN record will end with blanks,

'CLUSTER', 'CL', or 'BASE', but its corresponding CLOSE

records for that open end will end with blanks, 'DATA',

'DT', 'INDEX', or 'IX'. MXG strips the "last" part of the

ENTRNAME, merging on the stripped name, and stores the

"last" part in variable LAST.

For CLOSE (64s) without an OPEN, the OPENTIME is set to

the minimum SMF time of the 62/64s on that system, and

for OPEN (62s) without a matching CLOSE, their SMFTIME is