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

EXNSPYAD datasets and removes one. The NSPYTELE TELNET dataset

EXNSPYAT introduced in 5.2 has been completely replaced in 5.3,

EXNSPYHP so references to NSPYTELE and EXNSPYTE were deleted.

EXNSPYMA The nine new dataset created are:

EXNSPYMC dddddd Dataset Record Description

EXNSPYMR NSPYAD NSPYAPPD D APPN Directory Services

EXNSPYRT NSPYAT NSPYAPPT E MNPS Application Recovery

EXNSPYTC NSPYHP NSPYHPR N High Performance Routing

EXNSPYTS NSPYMA NSPYMNPA M MNPS Application

IMACNSPY NSPYMC NSPYMNPF F MNPS Coupling Facility Struct

VMACNSPY NSPYMR NSPYMNPR E MNPS Application Recovery

Apr 7, 2000 NSPYRT NSPYVRTP R VTAM RTP

NSPYTC NSPYTCP I TCP/IP Connections

NSPYTS NSPYTCPS J TCP/IP Stack

These datasets have been added but only syntax tested, as

no test records are yet available for validation.

Thanks to Roger Zimmerman, Scudder Kemper Investments, USA.

Change 18.068 DB2ACCT variables ACCOUNT1-ACCOUNT9 were not populated

VMACDB2 for DBAAS nor for non-Local-DB2-ACCOUNTING records. The

Apr 6, 2000 logic for Local-DB2 was replicated for the other two DB2

record types. Note if you put your own accounting values

in your DB2 records, you must use a 'FF'x delimiter if

you want those accounting fields separated into separate

account variables; only DB2 takes MVS accounting fields

and inserts a 'FF'x delimiter in its 101 records, so that

is what MXG's VMACDB2 logic expects. If there is only

on field with no 'FF' delimiter, then it will be stored

into variable ACCOUNT1 (and member IMACACCT sets the

stored length of each of the ACCOUNTn variables).

Thanks to Ian McKay, Royal Bank of Scotland, SCOTLAND.
Change 18.067 Negative DD counts for OPEN/USED DB2 Dataset calculation:

ANALDB2R -IBM APAR PQ21969 (see NEWSLTRS for APAR details) corrupts

Apr 5, 2000 QTSLWDD, "Slow DDs", which is subtracted from QTDSOPN.

-MXG logic error if there were more than one interval in

the summary. The statement QTDSOPN=QTDSOPN/INTRVLS;

was moved to follow DSUNUSED=(QTDSOPN-QTSLWDD)/INTRVLS;

so total-total instead of average-total is subtracted!

Thanks to John McCray, Huntington National Bank, USA.

Change 18.066 The PDB.ASUMCEC dataset requires that all SYSTEM's clocks

ASUM70PR are on the same timezone, since the merge is by STARTIME.

EXCECTIM This change adds new exit member EXCECTIM to allow you to

Apr 5, 2000 insert your own logic to change the time zone of STARTIME

to a common time zone. You could use logic like this:

IF SYSTEM='CST ' THEN STARTIME=STARTIME+HMS(-5,0,0);

ELSE IF SYSTEM='EUR ' THEN STARTIME=STARTIME+HMS(1,0,0);

to change STARTIME from local to GMT.

Thanks to Richard S. Ralston, Whirlpool, USA.
Change 18.065 The KEEPALL=NO default of VMXGSUM can cost CPU time with

ANALCISH minimal benefit, especially when VMXGSUM is used multiple

ASUMCICS times, as in ANALCISH which invokes 45 executions of the

ASUMCICX VMXGSUM macro if all CICS shutdown reports are requested!

ASUMDBDS MXG enhancements to support all possible syntax in that

ASUMHPAI KEEPALL=NO logic (constructs KEEP= statements with only

ASUMHPSU needed variables, but parsing must be in macro language

MNTHDB2S that is more expensive that data step logic) cost too:

TESTOTHR 16.16 17.17 17.17

TYPEMON8 KEEPALL= NO NO YES

TYPEMONI CPUTM 62 sec 93 sec 43 sec

VMACMON8 ELAPSTM 15 min 19 min 10 min

VMACMONI Hi Block Used 1905 1905 1921

VMXGSUM for ANALCISH, with no savings in the work space needed!

Apr 4, 2000

Apr 11, 2000 I had planned to change the default to KEEPALL=YES, but

found that some VMXGSUM invocations require KEEPALL=NO

to prevent VARIABLE NOT FOUND errors:

With KEEPALL=NO, variables can be listed that don't

exist in the input dataset; both IBM and TMON vars are

listed in the dual-input ASUMCICS program, but only

one set will actually exist. With KEEPALL=YES, all

variables must exist. And with KEEPALL=NO, you can

still use ASUMDB2A to summarize DB2ACCT, even if you

have removed variables that you don't need, since the

KEEPALL=NO option tolerates non-existent variables.

By adding an explicit KEEPALL=YES in each VMXGSUM use in

member ANALCISH, and by adding an EXPLICIT KEEPALL=NO in

ASUMCICS/ASUMCICX, and by cleaning up variables in SUM=

lists that didn't belong there, all of MXG members in the

18.03 library have been tested with KEEPALL=YES as the

default, but I decided that it was not worth the exposure

of creating an error perfectly running programs to save a

few seconds of CPU time, so the MXG default remains

KEEPALL=NO.
But because KEEPALL=YES can be very useful in specific

cases, I have instead externalized KEEPALL to a Global

macro variable, so it can be changed from KEEPALL=NO with

%LET KEEPALL=YES;

in your //SYSIN before the program that invokes VMXGSUM,

so you can test the possible savings and any impact.

Note that if your program uses %VMXGSUM(KEEPALL=xxx,...),

i.e., explicitly specifies the KEEPALL= argument in its

invocation, that local xxx value will always override and

replace the Global value set with a %LET statement.

Thanks to Steve Colio, CIGNA, USA.
Change 18.064 MXG 18.01-18.02 only. Changes in the _Bdddddd "BY list"

VMAC6156 macros caused VARIABLE xxxxxxxx NOT FOUND errors:

VMAC64 -VMAC6156: VARIABLE SMF6XFNC NOT FOUND. Macro should be:

VMAC79 MACRO _BTY6156 SYSTEM READTIME JOB FUNCTION CATNAME

VMACGUTS ENTRNAME VOLSER1-VOLSER5 ACTION SMFTIME %

Apr 4, 2000 -VMAC64: VARIABLE SITUATN NOT FOUND. Macro should be:

MACRO _BTY64X SYSTEM READTIME JOB CATNAME ENTRNAME

COMPONT BEGCCHH VOLSER EXTENTNR SMFTIME %

-VMAC79: VARIABLE SYSPLEX NOT FOUND. Here the KEEP= for

dataset TYPE79F was incomplete; variables SYSPLEX

SYSNAME and STARTIME were added to its KEEP list.

-VMACGUTS: VARIABLE JOB NOT FOUND. Here the KEEP= for

datasets GUTSSESS and GUTSINTR was incomplete;

variable JOB was added to their KEEP lists.

Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 18.063 The count of CLASS3WT events typographically included the

ANALDB2R variable QWACAWTW, the wait duration, when it should have

Apr 4, 2000 been QWACARNW, the number of wait events, (three places).

Thanks to Tom Benson, Amdahl U.K., ENGLAND.

Change 18.062 New RMFINTRV parameters KEEPPGN/KEEPRPGN/KEEPSRV/KEEPRSRV

VMXGRMFI can be used to minimize the list of entries when you only

Apr 3, 2000 want to keep/drop a few PERFGRPs/SRVCLASSes.

Thanks to Normand Poitras, ISM, CANADA.

Change 18.061 The statement segment AND %LENGTH(&USERADD) NE 0

UTILBLDP was removed, because it could have caused no USERADD=

Apr 3, 2000 to be created when there should have been one.

Thanks to Dave Gibney, Washington State University, USA.

Change 18.060 Continued IMS quirk removal; Open Transaction Manager

ASMIMSL5 Access, OTMA, and APPC differences in LCODE=31x records

ASMIMSL6 were revised. While OTMA may have been only an IMS 5.1

Apr 3, 2000 facility, I put the code in both members while we await

an answer from IBM. We think OTMA is very rare in any

event, so this change should have no negative impacts!

Thanks to Pete Gain, SAS Institute, ENGLAND.

Thanks to Carl Meredith, SAS Institute ITSV, USA.

Change 18.059 -TPF support did not work with SAS USER= or WORK= options,

IMACTPF causing ERROR DATASET WORK.TPFTD NOT FOUND because the

TYPSTPF PROC COPY at the end of member TYPSTPF should have been

VMXGINIT removed when the _STPFxx PROC SORT macros were added.

VMXGTPFI -Hardcode "PDB." references were replaced with _Ldddddd

TESTUSER macro references in VMXGTPFI.

Apr 3, 2000 -VMXGINIT now defines WTPFINT and PTPFINT macro variable

for dataset TPFINTRV for consistency in naming.

-IMACTPF now documents the many TPF datasets/dddddd.

-VMACTPF had data set labels that were repeated/unclear.

-These were found by running TESTOTHR with their options.

-TESTUSER was also revised, with its one PROC COPY with

INDD=WORK being replaced with three separate PROC COPYs

each with INDD=&Wdddddd for the specific dataset to copy.

Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.

Thanks to Harmuth Beckmann, Karstat AG, GERMANY

Change 18.058 Zero observations were processed if you did not use the

PRINTNL MXGSAS procedure (or used the SAS procedure without the

Apr 1, 2000 CONFIG=MXG.SOURCLIB(CONFIG) parameter specified) because

the MXG macro variable OPSYS was tested instead of the

original SAS macro variable SYSSCP. Since nothing else

in CONFIG is required for PRINTNL, changing to use the

SAS macro variable SYSSCP eliminates the exposure so that

PRINTNL will work with the plane vanilla SAS JCL proc.

Thanks to Glenn Harper, Memorial Hermann Hospital System, USA.
Change 18.057 Variable PROCSTEP should not have been kept in TYPE30_1

VMAC30 or TYPE30_5, as it is a step-level variable, and it was

Apr 1, 2000 added to the KEEP= list for all TYPE30 datasets that

contained STEPNAME (except for TYPE30_D, because that is

a DD-level dataset, and adding PROCSTEP doesn't see to

be needed there and would only waste space (and you can

always use the MACRO _KTY30UD to add PROCSTEP if you

really decided you needed it at the DD-level dataset.

Thanks to Michael Oujesky, MBNA, USA.
Change 18.056 Support for CMA Release 1.11 (COMPATIBLE) added two new

VMACCMA variables, SMFT05PL and SMFT06PC to the subtype 5 and 6

Apr 1, 2000 SMF records.

Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.

Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.055 OAM Release 1.5.0 changed the type 85 subtypes 74-77 and

VMAC85 subtypes 78-79 and 88 INCOMPATIBLY by inserting 32 bytes

Mar 31, 2000 (R85ORMN,R85OTMN) at the front of the segment, and by

Apr 10, 2000 inserting R85LXQT in the middle of the segment. Jobname,

stepname/procname were added to the OAM product segment

and those are now kept in all OAM data sets.

Apr 10: corrected tests for 1.4.0 to 150.

Subtypes 80-86 are not supported yet because I have no

test data, but MXG now prints a note if one of those

unsupported records are found, and I'll add support if

you'll send me your type 85s with those subtypes!

Thanks to Jeff Schuster, American Century, USA.

Change 18.054 The two PROC SORTs should have had _WTMSTMS and _WTMSDSN

TYPETMS5 instead of TMSRECS and DSNBREC, so that you could change

Mar 31, 2000 the location of the WORK copy. If you changed the ddname

you will get "TMS MERGE ERROR" message because MXG did

not use your changed destination.

Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.

Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.053 The macro token _K102TX5 did not follow the _W102TX5

VMAC102 segment in the DATA statement; an oversight, but no

Mar 30, 2000 impact unless you wanted to change the variables kept.

Thanks to Jim Kovarik, AEGON USA, USA.

======Changes thru 18.052 were in MXG 18.02 dated Mar 29, 2000======
Change 18.052 IMS log record 01s are now deleted if MSGFLAGS '10'x bit

ASMIMSL5 is set (MSGFNRQU, the non-recoverable bit). Pete found

ASMIMSL6 duplicate IMSTRAN observations for some transactions that

Mar 29, 2000 were being submitted to the IMS input queue via the IMS

OTMA facility from an MQ series box. The non-recoverable

transaction exists merely to enter the message onto the

queue so that it can be requeued for execution. That

original (non-recoverable) 01 lacks critical identifiers

anyway, cannot be analyzed, and its processing is not

recorded in a type 7 record as a processed message, so

there is no loss by discarding that record.
The non-OTMA log records sequence all had the same DRRN:

01/35/08/56/31/03/35/37/7/33/56/07; the OTMA sequence was

01/35/08/56/31/03/31/33/56/37/33/56/07 records, but the

03/35/31/33 had one DRRN value, while the 01/31/33 had a

second DRRN generated by OTMA's processing, and it was

the second DRRN that created the "duplicate" transaction.

This change removed nine redundant XC USERKEY,USERKEY

statements in ASMIMSL5/ASMIMSL6 to make room for the four

new statements added to drop the unwanted records.

Thanks to Pete Gain, SAS Institute, ENGLAND.

Thanks to Carl Meredith, SAS Institute ITSV, USA.

Thanks to Pete Sadler, IBM, ENGLAND.

Change 18.051 IMF Fast Past records contain INPQUETM as a PD instead of

VMACCIMS the documented PIB format, affecting both INPQUETM and

Mar 28, 2000 ARRVTIME. CICS transactions with ARRVTEST='0000000C'x

are now included in the fast path calculation for the

ARRVTIME, although they are not strictly queueing.

Thanks to Stephen Hoar, Lloyds TSB Bank, ENGLAND.

Change 18.050 -IMS transactions with non-zero value for SUBQ6 time had

ASMIMSL6 the divide by NMSGPROC incorrectly located, causing the

JCLIMSL6 averaged resources (CPUTM, DLI, etc) to be incorrect.

IMACIMSA Fortunately, only one site has observed the problem. The

TYPEIMSA moved code had been added by Change 17.315 to cover the

TYPEIMSB rare case when FIRST.DTOKEN also has INIO and MTYPE='7 '

VMACIMSA because then, the averaging needed for Quick reschedule

Mar 28, 2000 transactions must be bypassed. (That change also added

Jun 5, 2001 IMSACCQ6, IMSSQ6TM and DLRUSSN to the list of variables

to be averaged.)

-Alan's changes that accommodate the 10-byte timestamps in

IMS 6.1 were incorporated in this change, and cosmetic

changes (colons to long vertical bars) were cleaned up.

-Note: error WORK.IMSMERGE.DATA DOES NOT EXIST occurs if

you try to copy an archaic IMACIMS member into your new

IMACIMSA member in your USERID.SOURCLIB. In general,

no tailoring of the IMACIMSA member is required for most

sites, and it is delivered with only comments.

-1Jun01: This change also changed the default in IMACIMSA

to IMSVERS 6.1 instead of 5.1, but that was not noted

in the original change text.

Thanks to Alan Green, Zurich, ENGLAND.

Thanks to Daniel Cannon, The Hartford, USA.

Thanks to John Pierce, Liberty Mutual, USA.

Thanks to Carl Meredith, SAS ITSV Cary, USA.

Thanks to Yves Terweduwe, CIPAL, BELGIUM.

Change 18.049 TYPE 74 subtype 4 "Broken RMF Record" Change 18.045 was

VMAC74 over-protective, falsely throwing away each last segment

Mar 26, 2000 with that error message. The test CDSILOC+SMF744CL GT

should have been CDSILOC+SMF744CL-1 GT LENGTH THEN DO;

Change 18.048 Cosmetic cleanup of MXG members. Sample PROC Prints in

CREATEBC ADOCxxxx members had non-text hex-values (like '00'x)

IMACEAGL that are now blanks, and the hex values in IMACEAGL and

VMACEAGL are replaced by hex literals. Some members had

DOC a small circle or a tiny "3" instead of the long vertical

Mar 25, 2000 bar for flow chart documentation inside comments (members

had been emailed from ASCII to EBCDIC with non-standard

conversion tables, particularly RHUMBA and/or European

ASCII to EBCDIC tables). The creation of MXG EBCDIC text

from ASCII text has not been documented previously, but

it uses the SAS ASCII to EBCDIC conversion, except that

two changes are required to the SAS ASCII to EBCDIC table

to match OS/390 TSO ISPF EDIT's characters:

Left Bracket - ASCII '5B'x EBCDIC 'BA'x

Right Bracket - ASCII '5D'x EBCDIC 'BB'x

Split Vertical - ASCII none EBCDIC '6A'x

New member CREATEBC is a ASCII SAS program that reads the

ASCII IEBUPDTE file to creates the MXG EBCDIC IEBUPDTE

file. The Variable length ASCII IEBUPDTE file is about

half the size of the fixed length EBCDIC 80-byte file.

The output of CREATEBC is a binary file that can be

written directly to a 3480 tape drive under ASCII, or the

EBCDIC file can be ftp'd into an RECFM=FB,LRECL=80 MVS

file which can then be directly read by PGM=IEBUPDTE to

create the MXG PDS Source Library under OS/390.
Change 18.047 Change 18.044 was still incomplete; variable STARTIME was

VMXGRMFI not reset after %VMXGDUR, so changes to _DURSET were

Mar 19, 2000 still not being applied until this (final!) revision.
======Changes thru 18.046 were in MXG 18.02 dated Mar 16, 2000======
Change 18.046 Variable RESPSTD was not created in this member, so it

TRNDCICX was inconsistent with TRNDCICS.

Mar 16, 2000

Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.

Change 18.045 TYPE 74 subtype 4 "Broken Record" protection added in MXG

VMAC74 Change 17.378 did not protect when the number of segments

Mar 16, 2000 exceeded the count in the record, but now it does.

Thanks to Steve Lottich, University of Iowa Hospitals, USA.

Change 18.044 MXG 18.01-First 18.02. If you changed _DURSET, either

VMXGRMFI in IMACKEEP or with %LET MACKEEP= , it caused CPU TIMES

Mar 16, 2000 DO NOT MATCH ERROR. Relocate the IF &INTERVAL EQ DURSET

and following eight lines so they are after &INCODE72.

======Changes thru 18.043 were in MXG 18.02 dated Mar 15, 2000======
Change 18.043 Lotus Domino Server SMF type 108 variable DOMTMXSZ, the

VMAC108 Maximum Size of NSF Bufferpool, needs to be multiplied by

Mar 15, 2000 4096, as it is the number of 4096 byte frames.

Thanks to B. Brewer, Humana, USA.

Change 18.042 -This report fails under SAS V8 under OS/390 (but not with

ANAL30DD Windows) with APPARENT SYMBOLIC MAXRUN error because the

Mar 15, 2000 statement %LET MAXRUN=%EVAL(&MAXRUN); is invalid in open

SAS code, and should have caused a syntax error under V6

and under V8 under Windows, but didn't. If there was no

syntax error, the report ran fine, because MAXRUN is set

in the following statement, but the line is now deleted.

-The report example had 'B3'x instead of '7C'x in seven

places, causing a little 3 instead of a vertical bar to

be printed on these example reports.

Thanks to Edward J. Finnell, III, University of Alabama, USA
Change 18.041 ITSV 2.1 and 2.2 failed with CA1-TMS records, due to

VMACTMS5 hardcode TMS.TMS and TMS.DSNBRECD references, that are

TYPETMS5 now replaced with _LTMSTMS and _LTMSDSN tokens, which are

Mar 15, 2000 themselves redefined in VMACTMS5 now (they were not used

Apr 13, 2000 until now, so there is no compatibility issue) to be:

MACRO _LTMSTMS &PTMSTMS..TMS %

MACRO _LTMSDSN &PTMSTMS..DSNBRECD %

and in member VMXGINIT, the default value of PTMSTMS and

PTMSDSN was changed to "TMS" for both macro variables.

This change makes TMS processing consistent with the MXG

16.04 architecture. TMS records are initially written to

their two _Wdddddd tokens, and then sorted and combined

and output to the _Ldddddd tokens.

There was an additional ITSV fix required on top of this

MXG change for ITSV Release 2.2 and earlier (see ITSV

defect number S0079863), but the problem is corrected

in ITSV Release 2.3.

Thanks to Harald Seifert, HUK=COBURG, GERMANY.

Change 18.040 Support for GUTS, Gutenberg Time Sharing, user SMF

EXTYGUTI records. Two records are created, so two _ID macros are

EXTYGUTS defined, and either or both datasets will be populated.

IMACGUTS dddddd dataset description

TYPEGUTS TYGUTI GUTSINTR GUTS Interactive Execution Session

TYPSGUTS TYGUTS GUTSSESS GUTS Session

VMACGUTS

VMXGINIT

Mar 14, 2000

Thanks to Jeffrey Ball, Information Resources Inc, USA.

Change 18.039 Variable LOSU_SEC is now decoded from SMF30SUS, which

VMAC30 was added in OS/390 R2.6, and provides the Service Units

Mar 13, 2000 per second of CPU value for the SYSTEM on which his step

Mar 28, 2000 locally executed. Variable LOSU_SEC was added to dataset

TYPE30_V, TYPE30_4, TYPE30_5, and TYPE30_6.

Additionally, variables SMF30MSI and SMF30WMI were added;

those variables, new in OS/390 2.9, were documented in

MXG Change 17.385, but were not created until now.

March 28, 2000:

Variable SMF30SUS replaced SMF30TET, but SMF30TET has not

had any value so nothing is lost by its removal.

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

Change 18.038 Further enhancements now permit USECNTRL/USEREPRT to use

VMXGRMFI YES NO COMPAT GOAL SYS1 SYS1... to select control

UTILRMFI or report groups or classes for your workload definition.

Mar 15, 2000 All RPRTCLAS='N' were replaced with RPRTCLAS NE 'Y'

because RPRTCLAS is either Y or blank, and defaults work.

Thanks to Michael L. Kynch, International Paper, USA.

Change 18.037 %INCLUDE SOURCLIB(IMACJBCK) was added to VMACTMNT

VMACTMNT in case that job selection member is used for TYPETMNT

Mar 13, 2000 or TYPETALO selection.

Thanks to Chuck Hopf, MBNA, USA.

Change 18.036 Support for optional CICS RMI counters is added as an

IMACICUS example in using IMACICUS to decode user segments, and

Mar 13, 2000 the comments on how to use IMACICUS were updated.

Thanks to Bernie McGinnis, Charles Schwab, USA.

Thanks to Neil Ervin, Charles Schwab, USA.
Change 18.035 Invalid datetime values in VTCS 2.2 VTV Timestamp in VSM

VMACSTC subtypes 13,14,18,19 STCxxTIM variables. New 2.2 version

Mar 14, 2000 records have start/end variables in TODSTAMP8 format

Mar 16, 2000 ('B3B5488A226EE1C1'x) but have '38A8D15E000580C0'x for

VTV timestamp. Old 2.1 version records have all three as

valid seconds-since-1970 values '0000000038CD028F'x, so

the VTV timestamp was shifted left by four bytes, with

new flag variables in the low four bytes.

Because there is no version number in the STK records,

MXG's heuristic to detect VTCS Version 2.2 versus 2.1

did not expect this shifted value, causing STCxxTIM to

have a date in 1931 (or 1970 if value was zero). MXG's

algorithm to decode VTV STK timestamps is expanded to

Value greater than corresponds to input with

4294967295 FFFFFFFFF missing value

'B000------00'x 11Feb1998 TODSTAMP8.

'3800------00'x 10Oct1999 Left 4 PIB+DEL6070

'0000000038--'x All 8 PIB+DEL6070

I first tried IF X GT 0B000000000000000X syntax, but

doesn't work, and SAS Institute has accepted a bug in

both V6 and V8: you cannot use a 16-digit hexadecimal

constant literal value that starts with A or higher,

because the leading zero that is required (so that SAS

doesn't think it is a variable name) makes the string a

rejected 17 positions. SAS promises a fix in a future

release, but here I just used the decimal value for the

test:

X GT 4E18 for TODSTAMP, or