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

Jun 19, 1991 although SAS option NOCHARCODE could probably been used.

Thanks to Willie Antman, Federal Deposit Insurance Corporation, USA.
Change 09.051 Shared Medical System's CICS application creates its own

IMACEXCL header segment with an unexpected MNSEGCL value, which

VMAC110 caused MXG to fail. These segments were detected and

Jun 19, 1991 skipped over with the first part of this change, but MXG

Jun 27, 1991 still failed with SMS CICS records, because they use the

CICS EXCLUDE option to exclude some fields from their

transaction record.

You can tell a region has EXCLUDEd fields if the value

of MCTSSDRN in the MXG error message is 60 or less;

a minimum of 61 fields are in non-EXCLUDEd CICS data.

The previous "support" in MXG for EXCLUDE/INCLUDE was

marginal at best, was not externalized, and actually

required you to create a modified copy of VMAC110!

Because MXG promised to fix every Error condition, the

second part of this change completely redesigned the MXG

support for CICS EXCLUDEd fields, and now provides an

externalized tailoring member, IMACEXCL, that permits

processing a multiplicity of different CICS regions that

can even have different EXCLUDEs. IMACEXCL not only is

the documentation for this MXG support, it also contains

the code to read the SMS transaction records and shows

how changing only one line in your IMACEXCL will enable

SMS record processing for two specific APPLIDs.

Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.

Thanks to Tim Cartwright, University of Wisconsin - Madison, USA.
Change 09.050 WEEKBLD job failed when automatically submitted by a job

Submitting but ran without error when submitted from TSO. Adding

Jun 19, 1991 DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000) to the DDNAME in

the submitting job that points to the INTRDR solved the

problem. Without that DCB, the SYSIN dataset that SAS

tried to read had VBA or VS attributes, and SAS failed

with "Undetermined I/O Failure". By the way, that I/O

error from SAS always means the error is in a "flat"

file (SYSIN, or INCLUDEd, or FILE/INFILE), and is not

related to I/O to/from a SAS data library.

Change 09.049 Execution of MXG 8.8 under SAS 6.06 under MVS/370 (i.e.,

SAS 6.06 pre-MVS/XA) is possible for BUILDPDB, but testing and

Jun 19, 1991 validation is still on-going. This note identifies the

current recommendations for SAS 6.06 under MVS/370.

-Use maximum REGION size you can possibly get.

-Specify OPTIONS BLKSIZE=1024 BUFNO=1; to minimize the

virtual storage (but at the cost of additional I/O and

CPU time).

-Change CONFIG member to specify MEMSIZE=6M (because SAS

will try to get more, even when it doesn't exist on your

370 system).

-Add SAS option MINSTG to the CONFIG member (to free up

storage after each PROC/DATA step).

-Let me know if it works. Last site testing got through

to building the SPUNJOBS before memory failure, and has

not yet reported if MINSTG solved their problem.

Thanks to Moji Varian, Congressional Information Services, USA.
Change 09.048 The MXG circumvention for IBM's DFP type 42 records in

VMAC42 Change 9.024 protected the STOPOVER condition, but the

Jun 19, 1991 MXG test for wrong record length was invoked first, and

the bad records were thrown away instead of processed

(after a message was printed on your log, however).

This enhancement protects the STOPOVER and prevents the

MXG message on the log. In addition, the PIB8. fields

in the subtype 1 (written only if you have PDSE enabled)

are now input as ?? 8. instead of PIB8. There is still

a long series of questions at IBM DFP, because some of

the statistics (but not all) appear to be accumulated

across records, and the "Current" time stamp is several

minutes earlier than the SMF timestamp. Two APARs now

exist for the type 42, OY39393 and OY44995, and when

PTFs exist, they should be installed.

Thanks to Joseph J. Faska, Depository Trust, USA

Change 09.047 TYPE78CU IO Queuing data will be missing if microcode

VMAC78 level CP HH0124 has been installed. The fix to IBM's

Jun 19, 1991 firmware is microcode level CP HH0130.

Thanks to Miller Dixon, Continuum, USA.

Change 09.046 TYPE6156 variable ACTION is not consistent with the type

VMAC6156 of function creating the respective record, according to

Jun 19, 1991 IBM APAR OZ82412 (1985!). MXG variable ACTION decodes

SMF6xSUB into INsert, DElete, or UPdate, but the APAR

says the field is valid only in the type 60 VVDS record

and is invalid in type 61, 65, or 66 records. Sister

APAR OZ82414 also claims that SMF6xFNC and SMF6xTYP are

equally invalid (which MXG decodes into FUNCTION and

ENTTYPID respectively). In MVS/ESA 4.2 SMF manual, the

SMF6xFNC is now a reserved field, but both SMF6xSUB and

SMF6xTYP are still documented. Your guess is as good as

mine, but beware!

Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 09.045 NETSPY accounting record offset cause INPUT STATEMENT

VMACNSPY EXCEEDED RECORD LENGTH STOPOVER error. Change the line:

Jun 10, 1991 @OFFNSPY+OFFSMF+169 to read @OFFNSPY+OFFSMF+168

Thanks to Doug Drain, National City Bank, USA.

Change 09.044 An interesting change in Connect Time ("IOTM") measures

IOTM was observed in GTF traces. The instance was 4K I/O, and

Jun 8, 1991 the normal connect of 2ms per I/O was observed most of

the time, but occasionally the connect time was 18ms!

The device was a 3390 DASD behind a Model 2 3990 (i.e.,

non-cached CU). The additional connect time was traced

to a change in IBM's handling of missed RPS reconnects.

Previously, IBM would simply try, and try, and try again

to reconnect, recording 16ms (one revolution) disconnect

time for each miss. IBM has apparently implemented the

same scheme that other vendors use to limit reconnects:

after some number of misses (perhaps 2?), IBM now tries

continually to reconnect, and when it is finally able to

connect to the channel, it now SEARCHes to find the

desired sector and record. SEARCH, of course, records

not disconnect time, but now records connect time, for

the device in type 74 and for the job in type 30. In

principle this is probably good, since it limits how

long your I/O can sit waiting for reconnect, but it

could lead to problems in repeatability of connect time

for I/O measurement and accounting, because now the

connect time is a function of channel and path conflicts

rather than just the amount of I/O transferred. Since

multiple paths are typically available to devices, there

is much less probability of RPS misses now than in the

past, and the variability in connect time will not be a

significant factor in the absence of RPS misses.

Thanks to Bill Fairchild, Landmark, USA.

Change 09.043 The link edit step in ASMVTOC specifies AC=1, but later

ASMVTOC comments in the program state that authorization is NOT

Jun 8, 1991 required. The comments are correct, and the AC=1 has

been removed from the LKED step.

Thanks to David Ehresman, University of Louisville, USA.
Change 09.042 SAS 6.06 and MXG JCLTEST6 will fail in REGION=2048K with

JCLTEST "OPEN ABORTED FOR SOURCLIB, NO MEMORY FOR DATA BUFFERS".

JCLTEST6 The REGION=4096K is required, but MXG JCL comments were

Jun 8, 1991 incorrect and implied 2048K was enough. It isn't.

Thanks to David Ehresman, University of Louisville, USA.
Change 09.041 Sites with TLMS may encounter 713-04 ABENDS when putting

TLMS SAS datasets on tape, if the TLMS installation Option

Jun 8, 1991 named DBLTIME is set to 0! If DBLTIME=0, TLMS does not

Feb 25, 2006 permit "double opens", but when you build your PDB on

tape, SAS opens and closes each SAS dataset, which OS

sees as multiple opens, and TLMS inhibits. You can set

DBLTIME=1 and TLMS will let the same jobname open the

same tape data set multiple times, as long as the time

between is less than one hour (DBLTIME=2 give 2 hours!).

Unfortunately, DBLTIME is an installation-wide option.

Feb 25, 2006: Using DISP=(MOD,CATLG) instead of using

DISP=(NEW,CATLG) eliminated the ABEND!!!

Thanks to Nancy Vance, ???.

Thanks to Terry Poole, SAS Institute Cary, USA.

Thanks to Carol Arnold, BBH, USA.
Change 09.040 Reading VTOC records created by ASMVTOC with VMXGVTOF,

VMXGVTOF even after Change 9.035 (MXG 9.1), was still incorrect.

Jun 7, 1991 The logic of VMXGVTOC was not properly migrated into

VMXGVTOF, and the first extent on each volume was lost.

You might not have noticed the loss, if the first extent

was free space, but if the first extent was a real

dataset, the entire dataset record could have been lost.

The simple fix is to change VMXGVTOF as follows:

was: must be:

SET EXTENTS END=EOF; SET TOTRACKS EXTENTS END=EOF;

Thanks to Roger Edwards, South Carolina Electric & Gas, USA.
Change 09.039 MVS/ESA 4.2 was still not fully validated, even in 9.1.

VMAC74 Yet another error slipped thru, causing STOPOVER on type

XMAC74 74 subtype 2 RMF records:

Jun 7, 1991 -Find the following statement and changes as shown:

was must be

R742STCN $CHAR4. R742STCN $CHAR8.

-There are three lines containing SKIP=OFFDDSS that must

be changed as follows:

was must be

SKIP=OFFDDSS-52; SKIP=LENDDSS-56;

SKIP=OFFDDSS-72; SKIP=LEN742PO-72;

SKIP=OFFDDSS-44; SKIP=LEN742MO-44;

Thanks to Tom Elbert, John Alden Life Ins, USA.

Thanks to Dan Barbatti, Southwestern Bell, USA.

----Changes thru 9.038 were included in MXG 9.1 dated June 3, 1991------
Change 09.038 Support for Boole and Babbage's CONTROL-D SMF record

ANALCTLD is added by this user contribution. Release 1.6.4 has

EXTYCTLD been processed with this data, which creates the

IMACCTLD CONTROLD data set. Member ANALCTLD provides examples

TYPECTLD of potential reports.

VMACCTLD

Jun 3, 1991

Thanks to Brian Cobb, Credit General Industriel, FRANCE.

Change 09.037 Variable FCOTHCN was not kept in CICSTRAN dataset, for

VMAC110 no good reason, but now it is!

Jun 3, 1991

Thanks to Herr Weismann, Zurich Versicherung Frankfurt, GERMANY.

Change 09.036 Variable APPLID in NSPYVIRT was not kept, causing later

VMACNSPY report programs to fail. Add APPLID to KEEP= list.

Jun 3, 1991

Thanks to Chris Morgan, Post Office (UK), ENGLAND.

Change 09.035 A SAS 5.18-only problem caused when SYMPUT references an

VMXGVTOF unreferenced variable caused VMXGVTOF to not process all

Jun 3, 1991 extents. The MXG circumvention is to insert the line

LENGTH NOBS 4; ahead of the CALL SYMPUT line,

which satisfies the 5.18 compiler and makes the %DO loop

iterate. In addition, there was a redundant PROC SORT

of the EXTENDS data set preceding the %DO which did no

harm, but did no good, and which has been removed. This

was a combined discovery of several SAS folks:

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.

Thanks to Jan van Lent, SAS Institute, NETHERLANDS.

Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.

Change 09.034 Two exits enhance BUILDPDB tailoring so that changes to

BUILDPDB are externalized for sophisticated users. Exit

BUILDPD3 EXPDB304 is taken so TYPE30_4 step variables can be

EXPDB304 changed/added into PDB.STEPS or summed into PDB.JOBS.

EXPDB6 is taken so TYPE6 print variables can be changed

May 31, 1991 into PDB.PRINT or summed into PDB.JOBS. Comments in the

exit member describe how it can be used. Complete tests

have not been completed; use with caution until this

note is replaced with validation results. At worst, you

may have to modify SPUNJOBS if you use these exits!

Thanks to Jane Graffum, Blue Cross Blue Shield of Massachussets, USA.
Change 09.033 Invalid NETSPY records are now protected from STOPOVER

VMACNSPY by comparing the expected length ENDREC to LENGTH and

May 31, 1991 deleting bad records. LEGENT is investigating the data

(NSPYREC='C' with ENTL=288 and ENTN=216-->62208 bytes

in a record only 21,000 bytes long)!

Thanks to Wilson Wong, Salomon Technology Services, USA.

Change 09.032 DB2 Audit Reports (PMAUD01, PMAUD02, or PMAUD03 were not

ANALDB2R produced if PDB=SMF was specified on %ANALDB2R. These

May 31, 1991 reports ARE produced if instead you use TYPEDB2/TYPE102

to build the datasets first, and then invoke ANALDB2R

with the PDB=PDB option to generate the Audit reports.

The PDB=SMF problem can be corrected by inserting:

AND &PMAUD01 EQ NO

AND &PMAUD02 EQ NO

AND &PMAUD03 EQ NO

two lines prior to each of the following lines:

MACRO _DB2AC1 MACRO _DB2AC2

MACRO _DB2AC3 MACRO _DB2AC4

MACRO _DB2AC5 MACRO _DB2AC6

MACRO _DB2AC7 MACRO _DB2AC9

MACRO _DB2TC2 MACRO _DB2TC10

(The omission of these three lines testing if you had

requested an Audit report caused the PDB=SMF option to

generate the above Macro line, thereby causing MXG to

create 0 observations in the datasets needed by the

audit report.

Change 09.031 The example JCLDASD had incorrect DDNAMEs, and ANALVVDS

ANALVVDS had conflicting DDNAMEs.

JCLDASD -In ANALVVDS both occurrences of PERM should be MXGVVDS,

May 31, 1991 and the OPTIONS statement was deleted (it did not cause

a real problem, but it did not belong there, since it

would prevent you from controlling options externally).

-In JCLDASD step VTOC:

Comment preceding step VTOC should state

DDNAMES DISK AND MXGDASD ARE REQUIRED

MXGDASD should replace PERM as the DDNAME for the SAS

data set to be built,

DISK should replace MXGDASD as the DDNAME for the

*.ASMVTOC.VTOCDUMP dataset, and

-In JCLDASD step VVDS:

Comment preceding step VVDS should state

DDNAMES SMF AND MXGVVDS ARE REQUIRED

Change 09.030 DB2 Reports have several values that are incorrect by a

ANALDB2R factor of two. The error only affects these variables:

May 31, 1991 QB1TCBA QB2TCBA QB3TCBA QB4TCBA QISEPAGE QISECT

QISEFREE QISEDBD QISESKCT

The correction (fortunately) is simple. Delete all

15 occurrences of 2* in member ANALDB2R! I am really

embarrassed by this error due to incorrect testing.

Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.

Change 09.029 The MXG PDS Printing utility ALWAYS printed the SOURCLIB

VMXGPPDS PDS because "PROC SOURCE INDD=&PDSIN ..." should have

May 31, 1991 been used instead of INDD=SOURCLIB!
Change 09.028 Preliminary trend data base support for VMXAINTV dataset

TRNDVMXA has been added. Note that the trending supports only a

May 31, 1991 single VM/XA system. If you have multiple VM/XA systems

they must be separately processed and trended; I am open

to suggestions for the creation of a "SYSTEM" variable

that would allow separate VMXAINTV datasets to be added

to a common VM/XA trend data base. The TRNDVMXA member

existed in MXG 8.9, but had warnings not to use, because

of Variable Not Found messages. If you remove variables

PFXIDSER and PFXIDMDL from the SUMBY= statement in 8.9,

you will then have the MXG 9.1 version of TRNDVMXA!
Change 09.027 Complete online documentation of MXG datasets has begun!

ADOCACHE I plan to provide "Chapter FORTY" style documentation of

May 31, 1991 each data source that MXG supports and each dataset that

MXG builds, as members of the MXG library, so that they

can be viewed and searched online with your text editor.

Since most data sources have a VMACxxxx member that is

the actual processing code, I have decided on the naming

convention that VMACxxxx member's data will be described

in member named VDOCxxxx. A completed VDOCxxxx member

will contain these sections:

a. Data source description. Who, what, when, writes

the raw data records, vendor, releases supported

by which version of MXG, etc. How to process this

data source with MXG (members, IMACs, etc.).

b. MXG Data Set Documentation. For each MXG data set

built, there will be these sections:

1. Description of data set itself, usage, etc.

2. Alphabetic description in detail of every MXG

variable, including usage notes, caveats, etc.

3. Clustering of similar variables.

4. PROC PRINT with variable name of sample data.

5. PROC PRINT SPLIT='*' with label of sample data.

6. PROC MEANS of sample data.
The member VDOCACHE is incomplete, but contains CACHE90

sections b.2, b.4, b.5, and b.6 for starters.

This work will extend over time. Initial estimates of

the number of pages for MXG's 900 datasets and 36,000

variables are from 8 to 13 800-page volumes! How much

will actually be printed, in what form, when will it be

completed, etc., are still under consideration. However,

as individual VDOC.... information is completed, it will

be added to the MXG SOURCLIB (even if not finished) so

the information will always be available online.

Change 09.026 Changes in 8.293 to CACHE90 dataset in VMACACHE have now

XMACACHE been implemented in XMACACHE, the SAS 5.18 member used

May 31, 1991 to circumvent the 344 compiler error.
Change 09.025 TPX variable TPXELAP should have been INPUT as PIB4.2

VMACTPX instead of PIB4.

May 31, 1991

Thanks to Seymour J. Metz, EDS, USA.

Change 09.024 Type 42 subtype 2 SMF records (DFP 3990 SMS cache stats)

VMAC42 are invalid until module IGDDCFSR is at OY39393. The

May 30, 1991 APAR OY39393 which fixed the subtype 3 record last year

didn't get on subtype 2! Without OY39393, the CU and VOL

segments are both mis-located by their offset triplets,

and the final VOL segment is actually truncated by two

bytes). This change enhances MXG to detect and process

both corrected and incorrect format records; since the

truncated bytes happen to be reserved it could be done!

You should still install OY39393 in case IBM makes any

other change to the DFP record. But there's more. In

every other relocatable SMF record, the length triplet

value is the length of a single segment, but the DFP

developers decided to be different and store the total

length of all VOL segments in SMF42VLL (and not only do

they claim there is no standard and that the format of

the length field is up to the creator, they haven't even

said they will issue a document APAR telling you!). MXG

corrects the length value in processing. And then there

are the LTM and CTM time stamps that don't contain the

HHMMSSTH that is documented, but instead contain the

seconds since midnight! And finally, the LYY and CYY

year values contain x'005B' = decimal 91 now, but do not

document what will happen in 2000 - is the format really

0cyy where c is the century bit and the 2000 will be the

x'0100', or is the format the number of years since 1900

so that the 2000 year value will be x'0064'? I have put

code in place that assumes the century bit format, but

am checking with IBM for the actual format.

Thanks to Joseph J. Faska, Depository Trust, USA.

Change 09.023 EXD Release 3.0 added EXDRTECD (EXD/SAR Route COde) to

IMACEXD the additional EXD variables in the type 6 record, and

May 30, 1991 now MXG creates that variable if optional EXD support

is enabled in member IMACEXD. I failed to note which

bright MXG user notified me of this omission.
Change 09.022 SAS 6.06 option VERSIONLONG was added to MXG's list of

CONFIG default options, so that SAS will print the date of the

May 30, 1991 maintenance library on your log (6.06.01.01Feb91P).
Change 09.021 Support for CADAM, Inc.'s Statistics Data File, written

TYPECADM to their DDNAME STATSEQ, provides response averages and

VMACCADM counts of function key activity for CADAM end users. The

May 30, 1991 vendor's documentation warns that the data structures

are not supported by CADAM as user-accessible data and

are subject to change without notice (but the document

is dated 1988 and MXG has decoded data from the current

CADAM version 20.12). Function key use is recorded in 32

function key slots (but note that many CADAM products

(AEC, 3D) use multiple function key tables, redefining

the slots each time, and these re-uses are NOT reflected

in the function key slots.) For each function key slot,

CADAM records the number of uses, the total service time

and the sum-of-squares service times; MXG converts the

total service time to the average service time for each

function key slot. Additionally, CADAM captures the

arrival, service, and response time statistics (average,

minimum, maximum, and distributions of these three "wall

clock" durations in 44 buckets from .01 to 120 seconds.

Service is the duration from when CADAM selects an

attention to process to the point that the operating

system has reported that the display has been updated.

Response time adds to the service time the additional

duration that an attention waits to be selected for

processing (i.e., response is from arrival of an

attention to when the display is updated after

processing the attention).

Arrival time is the interval between the arrival of

attentions at the scope. Since attentions may be

"stacked" this value forms a measure of the "human

factor" in scope usage. Arrival times significantly

lower than response times imply that scope operators

are "getting ahead of the system," and that system

performance is poor.

Thanks to Emery Johnson, Allied Automotive Data Center, USA.
Change 09.020 Support for Interlink's products (used to interchange

EXILKA20 data between IBM, DEC, Internet, etc. platforms) has

EXILKA21 been added. The products each create user SMF records

EXILKGAB which are processed into multiple MXG datasets:

EXILKGAC

EXILKGCO Product MXG Acronym Datasets Created

EXILKGDI

EXILKGRE SNS/TCPaccess ILKA ILKAST20

EXILKVCO ILKAST21

EXILKVDI

EXILKVOF SNS/SNA Gateway ILKG ILKGABRT

EXILKVON ILKGACPT

EXILKVSR ILKGCONN

EXILKVST ILKGDISC

IMACAAAA ILKGREJC

IMACILKA

IMACILKG SNS/TCPvt ILKV ILKVCONN

IMACILKV ILKVDISC

TESTUSER ILKVLOGF

TYPEILKA ILKVLOGN

TYPEILKG ILKVSTOP

TYPEILKV ILKVSTRT

VMACILKA

VMACILKG

VMACILKV

May 29, 1991

Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.019 The CICS Dictionary Printing Utility added support for