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

is returned by SAS in &SASSWORK depends on the platform

on which MXG is executing. For PC SAS, $SASSWORK also

contains a pathname, but since PC pathnames use reverse

slashes, so SAS had no problems in compiling under UNIX.

Although the underlying logic will never be satisfied as

written for PC or UNIX SAS, adding the %QUOTE() function

around the &SASSWORK string tells SAS to ignore those

strange characters, so this change:

IF %QUOTE(&SASSWORK) NE WORK %THEN ....

allows VMXGSUM to execute anywhere!

I did test most of MXG in 1995 under UNIX, but that was

with an earlier VMXGSUM. I do not run MXG QA stream on

UNIX, as I do not have nor intend to have a UNIX system,

and believe that testing under PC SAS, plus many happy

users running MXG under UNIX with no errors, is enough.

This is the first and hopefully the last incompatibility

between ASCII SAS platforms that has had any impact on

MXG, and it's because no one had used the VMXGSUM utility

under UNIX yet.
Chris detected, diagnosed, and provided this solution.
July 9, 1998: See MXG Change 16.146.

Thanks to Chris Weston, SAS Institute ITSV, USA.

Change 16.130 -Type 70 RMF records contain an unexpected segment for

VMAC7072 CPUs that were varied offline. The segment does have

Jun 22, 1998 CAI=0 (SMF70CNF) that flags that this CPU was neither

online at the end of the interval nor reconfigured, and

has invalid VOLSER ('E00000'x). The unexpected segment

populated variables CPUSERn, CPUWAITn, IORATEn, where n

is the CPUID that the offline processor had when it was

last online. Now, MXG protects for this segment by only

populating the n-th variables when CAI is non-zero. The

PCTTPIn value was also wrong for the nth segment, but the

cause was a missing ELSE PCTTPI=.; clause to protect its

value when the IOINT denominator is zero, as was found in

these segments. Fortunately, this segment had little

impact on important type 70 measurements, because all of

the CPU-busy variables were already missing or zero. I

intend to suggest that IBM not write this unexpected and

wrong segment in type 70 records.

Thanks to Martyn A. Jones, Chase Manhattan Bank, ENGLAND.

Change 16.129 -A major revision to TMS/CA-1 processing was precipitated

ADOCTMS5 by the discovery that the DSN in the VOL records is not

TYPETMS5 always the true dataset name on that VOLSER: for multi-

VMACTMS5 volume, multi-file sets, the DSN in the VOL record of the

Jun 23, 1998 second and subsequent volumes is the dsname of the first

Aug 11, 1998 dataset in the set of multiple files. This meant there

were observations in TMS.DSNBRECD with the wrong DSN for

some VOLSERS. If you tried to select all VOLSERs for a

specific DSN, you would miss all of the interior VOLSERs

as well as the final VOLSER that contained that dataset.

Fortunately, this past error probably had little, if any,

impact on tape chargeback using TMS.DSNBRECD, for at

least two reasons. First, these sets are usually backups

of groups of common files for an application, so all of

the DSNs are usually owned by the same department that

you billed. Second, since the BLKCNT in these bad VOL

records is always zero, calculated FEET or BYTES would be

zero, so you probably zero billed the wrong DSN anyhow!

The Block Count must be zero in these VOL records (i.e.,

for datasets that start with a DSNB) because the total

block count for the entire dataset across all of its

volumes is recorded in the BLKCNT in the DSNB record.

Unless CA-1 is redesigned to break the total dataset

Block Count into the count per VOLSER, we will never know

how much of one volume is occupied by each piece of these

datasets, but at least now you have the correct DSN for

each VOLSER which contains any part of that DSN.
The final SORT order of TMS.DSNBRECD is

BY ZDATE OVOLSER VOLSEQ FILSEQ CURR;

where OVOLSER is the "Original, or first VOLSER of a set"

and is blank for single-volume tapes, where VOLSEQ and

FILESEQ have been propagated/created by the new logic,

and where CURR is the (current) DSNB number for the

DSNBRECD observations created from DSNB records. CURR

has a missing value in DSNBRECD obs created from VOL

records, and is used as a discriminate in MXG logic.
Additionally, the size of each dataset in TMS.DSNBRECD in

bytes, calculated as Block Size times Block Count, (as

was TAPEFEET) is now created in variable DSNBYTES, and

the total size of each VOLSER in TMS.TMS is now created

in variable TAPEBYTE; both are formatted MGBYTES.
This is a major revision of the logic for TMS processing,

and the gory details of the problem and its solution,

(which took three full days to figure out and implement),

complete with example, is now in member ADOCTMS5.

The before and after runs with a 194MegaByte TMC show:

TMS.TMS TMS.DSNBRECD Elapsed Duration

obs obs vars (PENTIUM II 350)
BEFORE 510,000 203,772 42 12 minutes

AFTER 510,000 203,765 46 14 minutes

so the added cost of the new sorts and data steps seems

minimal. The smaller number of observations in the new

DSNBRECD is the result of removing the VOL records which

have blanks or " IO ERROR" as their DSN values.

The AFTER run with same data on an Amdahl millennium took

15 minutes elapsed (and 9 minutes CPU) under OS/390!

Thanks to John Rosewarne, Telstra, AUSTRALIA.
Change 16.128 For NTSMF Version 2.1.0 running under NT 3.51, the error

VMACNTSM INPUT STATEMENT EXCEEDED RECORD LENGTH occurs because the

Jun 18, 1998 NTSMF record is missing the CPU Speed field in the 0,0

CONFIG record. This change only inputs the new sections

if both VERSION GE '2.1' AND NTVERSN GT '3.51'.

Thanks to Jim Quigley, Con Ed, USA.

Change 16.127 This member is still in testing, but now at least it has

BLDNTPDB been debugged and corrected and works. More is planned.

Jun 18, 1998

Thanks to J. Wayne Holzbach, Reynolds Metal Company, USA.

Change 16.126 Unused Change Number.
Change 16.125 IMACKEEP was added at the end of the %INCLUDE list, where

TYPEIMS7 it had been overlooked. Member IMACKEEP was part of the

Jun 12, 1998 original MXG architecture, designed to let you override

the _VAR macros to change the contents of MXG datasets,

but that turned out to be the wrong way to tailor MXG,

because your _VAR override died when I had to add a new

dataset for that product, so Change 10.175 introduced the

new way, by defining _L and _K macros in each IMAC for

each product. However, I kept the IMACKEEP INCLUDE in

all members, just in case it might be useful to have a

common exit in the future, and its future is now!
That future is described in Change 16.134, but it was a

conversation with Peter that triggered the realization

that IMACKEEP will again be the right place, and that led

to the &MACKEEP architecture.

Thanks to Peter Enrico, Watson and Walker, USA.
Change 16.124 Variables SELAPSTM, the step elapsed time, and JOBCLASS

ANALDSET are now kept in both DSETOPNS and DSETSUMS datasets, so

Jun 12, 1998 the OPENTM can be compared to SELAPSTM, for candidate

analysis for HiperBatch and BatchPipes, and so JOBCLASS

can be used to filter unwanted job observations.

Thanks to Lawrence Jermyn, Fidelity Investments, USA.

Change 16.123 ROSCOE code revised to execute under ASCII SAS; several

VMACROSC $EBCDIC1. fields were changed to $CHAR1. and formatted to

Jun 12, 1998 $HEX2. Fields used in binary tests, for example,

IF ROSREC EQ '60'X THEN ... failed when TYPEROSC was run

under ASCII sas with $EBCDIC informat, because SAS change

the '60'X to '2D'x with that informat. Using the correct

$CHAR informat for these binary values fixed the error.

Thanks to Martha Wearen, Department of Agriculture & Food, IRELAND.

Change 16.122 -Variables SYSID, APPLID, and SYSPLEX were blank in most

VMACTMO2 datasets. Change TMSYSID to SYSID, TMENAPLD to APPLID,

Jun 12, 1998 TMSMFSID to SYSTEM, and TMMVSID to SYSPLEX.

Jun 17, 1998 -The GMT offset variables TMENGMTO and TDENGMTO are now

input as &IB.8. rather than &PIB.8., like TAENGMTO, but

while the TAENGMTO value is almost correct, the other

two GMT offsets are wrong in Landmark's records:
Record Hex Value In Record Input as &IB8.6 value

TA FFFFFFFB CF100000 -5:00:00.90

TI FFFFBCF1 DCC00000 -20480:00:00:00.00

TD FFFFBCF1 DCC00000 -20480:00:00:00.00

Note that the TI and TD values are clearly shifted left

three nybbles, causing their invalid value, but also note

that the TA value is truncated on the right, so it is not

exactly five hours. The correct 8-byte value should be:

FFFFFFFB CF1DCC00 -5:00:00.00

Landmark has opened Activity 111176 to correct the GMT

offset; until a fix is available, the GMT offsets are not

usable.

Thanks to Brian Sanger, Eagle Star, ENGLAND.

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

Change 16.121 New NTSMF objects "Caching Manager" creates CACHEMGR and

EXNTCAMG "Packet Filtering" creates PACKTFLT datasets, and revised

EXNTPKFL object "Web Proxy Server Service" increased the data from

IMACNTSM 37 to 56 fields, which are now supported.

VMACNTSM

Jun 11, 1998

Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
======Changes thru 16.120 were in MXG 16.02 dated Jun 8, 1998======
Change 16.120 New ERASEOUT parameter was added so that the output data

VMXGSUM set can be erased before creation. For the TREND system

Jun 8, 1998 this will reduce the size of the TREND library, since the

old design created the new TREND dataset while the old

TREND dataset still existed, so the library needed to be

exactly twice the size of the TREND dataset. Making the

change in VMXGSUM will not change the TREND dataset sizes

until a later change adds the ERASEOUT parameter to the

TRND members. The options are NO, YES, or DDNAME, and if

DDNAME is specified, a copy of the old TREND library is

made in that DDNAME before replacement by the new data.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 16.119 Preliminary support for IMS 6.1 Log Records has tested

IMACIMS the 07 and 08 records, so that member TYPEIMS7 is now

IMACIMS7 supported (it counts transactions and total resources,

VMACIMS without response time, for resource accounting of IMS).

Jun 8, 1998 There were massive changes in all IMS log records, with

new information as well, and more work will be done in

the next few weeks to the other parts of MXG IMS code,

notably there will be an ASMIMSL6 for the JCLIMSLG code.

This change includes the 01, 03, 31x and 35x log records,

but none of the new variables have been added and there

is still much validation needed.

Thanks to Dario Franceschi, Nordbanken, NORWAY.

Change 16.118 Tandem variables C0BLKS, C1BLKS, C2BLKS, and C3BLKS are

VMACTAND the cache blocks of 512/1024/2048/4096 bytes allocated,

Jun 4, 1998 and should not have been divided by DURATM. Variable

C1BLKSAV, average entried in the dirty queue should have

been divided by DURATM (like the other three measures).

Thanks to David Foster, Norwest Services, Inc.

Change 16.117 CODEPCT=150 is now the default, replacing CODEPCT=134.

CONFIG This is a compiler option that controls how much virtual

Jun 4, 1998 storage is set aside for the generated program in a DATA

step. If SAS's original guess is too small, it prints a

message suggesting a larger value of CODEPCT (usually one

unit higher!). By setting MXG's default to 150, that SAS

message and user questions about it are eliminated, and

you may save a couple of CPU seconds during the compile

phase of BUILDPDB's SMF processing step. You can also

eliminate the message (which is seen only if you have

modified your BUILDPDB to process additional SMF record

types) by passing CODEPCT as an option in your JCL:

// EXEC SAS,OPTIONS='CODEPCT=150'

Thanks to Thierry Van Moer, COMPAREX, BELGIUM.

Change 16.116 Support for Candle Omegamon for CICS V400 SMF record 255

VMACOMCI subtype 203 sub-subtypes 1 and 2 (INCOMPATIBLE) added no

Jun 4, 1998 new information but inserted blanks and FFFFs. Other

sub-subtypes are probably affected, but only these two

were available at this time for validation.

Thanks to Steve Smith, BMC Systems, USA.

Change 16.115 The support for Landmark DB2 Version 3.1 (Change 16.097)

VMACTMDB worked fine with 3.1, but failed with 3.0 'DA' record,

Jun 4, 1998 INPUT STATEMENT EXCEEDED, because MXG read in a number of

fields in the 3.0 logic that are not in the 3.0 records!

This change deleted those fields and their INPUTs.

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

Change 16.114 Processing ICEBERG and XCOM SMF records together cause an

VMACXCOM error because variable REQTYPE is numeric in ICEBERG but

Jun 4, 1998 was Character in XCOM. Hoping that changing XCOM has

less impact than changing ICEBERG, I have change the name

in the XCOM datasets from REQTYPE to REQTYPEX.

Thanks to Sharon Hindle, EDS Australia, AUSTRALIA.

Change 16.113 Landmark DB2 Version 3.1 INVALID DATA FOR HSRN is printed

VMACTMDB on the log for record 'DE', but the output datasets built

Jun 2, 1998 are not affected. MXG incorrectly tried to read the

"standard header" but the 'DE' record doesn't have one!

To eliminate the message and hex dump, change the line

IF LMRKREC NOT IN ('DC','DD','DF','DW') THEN DO;

to read

IF LMRKREC NOT IN ('DC','DD','DE','DF','DW') THEN DO;

Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
======Changes thru 16.112 were in MXG 16.02 dated Jun 2, 1998======
Change 16.112 Cosmetic. If you drop variables from DB2ACCT and use the

ASUMDB2A ASUMDB2A to summarize, UNINITIALIZED VARIABLE messages

Jun 2, 1998 are printed on the log during the ASUMDB2A execution of

VMXGSUM. These have no impact on the end results, and

are printed for those variables that are used in INCODE=

logic, but cannot be eliminated because VMXGSUM cannot

parse the INCODE or OUTCODE arguments for variable names.

However, additional UNINIT messages that were printed due

to the LABEL statement in the OUTCODE= argument are now

eliminated, by moving that LABEL statement into INCODE.

Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.111 -MQ Series SMF 115 MQMBUFER dataset misspelled QPSTDWT as

VMAC115 as QPSTDTW, so now (for a while) both variables exist,

VMAC116 but the DTW spelling will go away in a future version.

Jun 2, 1998 Variables QPSTID, QPSTLL and QPSTEYEC are dropped, as

they are always constant and should not have been kept.

-MQ Series SMF 116 MQMACCT dataset variable QWHCXTYP is

named ATYPE in MQ SMF documentation, but the values that

MQ chose for their ATYP are not at all the same as the

DB2 values for ATYP, and so MXG had to spell ATYP XTYP

in the MQMACCT dataset so that it could be formatted

for its values instead of the DB2 ATYP values. This is

not a code change, but rather explanation as to why the

ATYP variable is spelled XTYP in MQMACCT.

Thanks to Richard Tsujimoto, Chase Manhattan, USA.

Change 16.110 Cosmetic. The input data can only be the _LIDMTAS data

ASUMIDMS from the IDMS Perfmon SMF data, and this eliminates

Jun 1, 1998 UNINITIALIZED errors in my QA stream. Previously, there

were MXG-created SMF records for IDMS, and this report

would use either, but the old MXG monitor only ran under

IDMS Version 10 and earlier, and those records no longer

exist.
Change 16.109 IBM has trashed the IODF Creation Date field in RMF type

VMAC73 73-1, 74-1, and 78-3 records at least in OS/390 R1.3.

VMAC74 All three records have two separate IODF Creation Date

VMAC78 fields, and both have exactly the same character strings:

Jun 1, 1998 Field Names format data value

SMF73TDT, SMF74TDT, R783TDT mm/dd/yy 19/98/04

SMF73TDY, SMF74TDY, R783TDY mm/dd/yyyy 19/98/2004

This OS/390 R1.3 production system had never been tested

with a year 2000 IPL - I think the 2004 is an accidental

value. Several APARs document the IODF format starting in

back in 1993 (OY64585) and in 1996/1997 (OW15406/OW27552)

but there is currently no open APAR about bad values.

This error was seen in an RMF record, but CMF could have

the same problem, if IODF is creating a bad value and both

RMF and CMF are simply copying that bad value.
The nasty symptom of these bad date fields are two SAS

"INVALID ARGUMENT TO FUNCTION MDY AT LINE nnnn COL mmm"

messages, hex dumps of the several thousand bytes of the

bad record, the PUT _ALL_ lists of VARIABLE=VALUE for

about 30-40 pages of printed output.
While we research the problem with IBM, I have changed

each IF YY GT 0 THEN IODFDATE=MDY(MO,DD,YY) to now read:

IF 1 LE MO LE 12 AND 1 LE DD LE 31 AND YY GT ) THEN ....

(or YYYY for the TDY fields) to validate the arguments of

the MDY() function to prevent print of the hex dump/list.

Either way, with or without this print-prevention, the end

result is the same: variable IODFTIME will be missing

until IBM corrects their records, but everything else in

the MXG-built datasets is just fine and dandy!

Thanks to Jean Murphy, Capital Group, USA.

Change 16.108 This "NTSMF PDB Build" example is still not in its final

BLDNTPDB state, but it is getting there. This change removed the

Jun 1, 1998 PROC COPY INDD=WORK OUTDD=PDB that was left from testing

(it copied unsorted datasets over top of sorted datasets

and caused DATASET NOT SORTED errors).

Thanks to Carl Kyonka, Consumers Gas, USA.

Change 16.107 The PDB now PROC SORT's the other six TYPE74xx datasets

BUILDPDB into the daily PDB library. Four XCF datasets (TYPE74CO,

BUILDPDB TYPE74ME,TYPE74PA, and TYPE74SY), the OMVS Kernel dataset

BUILDPD3 TYPE74OM, and the IRLM Long Lock dataset TYPE74LK that

BUILD003 should have been put in your daily PDB library now are!

VMXGINIT VMXGINIT was updated to define the &PDB74xx macro name

May 29, 1998 for each PDB dataset. See Change 15.320 for discussion.

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

Change 16.106 Enclave CPU and transaction variables CPUASRTM CPUENCTM

IMACPDB and ENCLTRAN from TYPE30_4 step termination records are

May 29, 1998 now kept in PDB.STEPS and summed into PDB.JOBS datasets

with this enhancement.

Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Change 16.105 Support for the Web Proxy logs in Common Log Extended

TYPEWWW format adds new variables to TYPEWWW:

May 29, 1998 CLHEADER CLRQSIZE CONTLGTH HTTPCLVS HTTPSTAT PRREQHDR

PRRESHDR PRRQSIZE RMRESHDR TOTALTM

The left and right square brackets on UNIX have hex value

of '5B'x and '5D'x, but when FTP'd to MVS, they become

'AD'x and 'BD'x, and if IND$FILE'd to MVS they then are

'4A'x and '4F'x, so MXG now tests for all three values

that have been encountered when these ASCII logs are

sent thru different ASCII to EBCDIC translation tables.

Thanks to Brian J. Farley, Reliastar Life Insurance Co., USA
Change 16.104 -ANALCISH CICFCR report can cause ERROR: MORE THAN 32,767

ANALCISH VARIABLES. The PROC TRANSPOSE and array logic that was

May 29, 1998 used (so that one pass of the CICFCR dataset could

generate four reports) breaks that SAS limit when there

are thousands of CICS files. This redesign eliminates the

array and transpose logic, with one pass of CICFCR for

each report requested. We will enhance the redesign so

that only a single pass will be required, but that change

is more extensive, and this change solves the immediate

problem of getting the reports printed.

-CICJCR report can cause ERROR: MORE THAN 10 LINK

STATEMENTS HAVE BEEN EXECUTED. The LINK HEAD;

logic was eliminated.

Thanks to Eain Aronott, Toronto Dominion Bank, CANADA.

Thanks to Ian Mackay ,Royal Bank of Scotland, SCOTLAND.
Change 16.103 Deleted change.
Change 16.102 Support for Raptor Systems' Eagle V4.0 Log Message 121

EXEAG121 is decoded into dataset EAGLE121 with information on the

IHDREAGL individual connections thru that UNIX firewall product.

IMACEAGL EAGLE121 contains duration, type of service, source and

TYPEEAGL destination IP addresses (with port number), url and the

VMACEAGL filename accessed, and bytes sent and received, etc. The

May 28, 1998 other log messages are output into dataset EAGLEOTH with

the MSGID and LOGTIME and other header variables.

The MXG support reads the Version 4.0 records that were

created by Raptor Systems' FLATTEN program. While those

records are created on UNIX, MXG can read them either as

native ASCII records if you run MXG under ASCII SAS, or

you can ship the records to your MVS system (translating

them to EBCDIC in the process) and run MXG there.

FLATTEN records have a header of fixed fields that are

delimited by '09'x on ASCII (which becomes '05'x on MVS)

and then a series of field1=value1 field2=value2 ...

that are delimited by blanks, and then an undocumented

set of six numeric fields containing one byte of zero

in ASCII/EBCDIC that is delimited by '09'x/'05'x. While

the SAS NAMED INPUT technique is meant to handle data

like the field1=value1 series, it could not be used here

for two reasons: a) one of the data fields (ARG, which is

the full url and filename) can contain equal signs, which

would prematurely terminate its input and truncate its

value, and b) once SAS starts NAMED INPUT in a record,

there can be no following fields. So MXG instead must

parse and test the name field for each field.

These records look useful for tracking firewall accesses

but there are some quirks in the data. First, not all of

the fields in Table 6 in the Eagle Configuration Guide

V4.0 are in each record. In particular, USER and AUTH

appear infrequently (only 98 of 1658 records had them),

and there are some blank values for OP(10), PROTO(59),

RESULT(124), and SRCIF(7).

Most records end with the two fields RESULT and PROTO and

the six numeric fields:

result="200 OK" proto=http.0.0.0.0.0.0.

but some records instead have a date value following the

result= field, and there is no proto= field:

result="200 OK" 05/18/1998.0.0.0.0.0.0. 320

ZONE 2767767323332442233233233330303030303030