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

UTILCICS CICS 3.1 dictonary, but failed to sort the data before

May 27, 1991 the PROC PRINT DATA=CICSDI31, causing "INPUT DATASET NOT

IN PROPER SORT SEQUENCE." Insert before the PROC PRINT,

PROC SORT DATA=CICSDI31 ;

BY SMFPSRVR APPLID NREC MNSEGCL MCTSSDID;

Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 09.018 This significant user contribution supports SMF user

EXTYTAO records created by Fischer International's TAO (Totally

IMACTAO Automated Office) Electronic Mail System Release 3.2.1

TYPETAO at product maintenance level #82 and up. Earlier

VMACTAO releases are not supported as the vendor had previously

May 15, 1991 used a non-SMF type of recording for statistics from the

EMC2 Electronic Mail System which predates TAO.

Although not as widely used as some EMAIL systems, TAO

is a stand-alone MVS/VTAM application. AMDAHL uses the

TAO system extensively for electronic mail worldwide.

Some problems were encountered processing release 3.2.1

records due to errors in the vendors distribution

packaging. It seems that the documentation which

describes the dsects had been updated along with the

source dsects, however, the load modules were assembled

using earlier versions of the dsects. Assembly was a

problem due to user defined macros which the vendor had

not distributed in source form. These problems were

easily cleared up with a phone call to the vendor, but

some shops may encounter similar difficulties in

attempting to read the TAO generated SMF records using

this code. Several fields have been included in the MXG

code which are not yet supported (or populated) by the

vendor, although they are contained in the dsect areas

and the vendors comments supply documentation of the

future contents of these fields (at least in part).

This is NOT a complete subsystem for processing TAO SMF

records, retaining and summarizing detail data, and

producing reports. It IS a start for people (like me)

who hate using ALC dsects in SAS code.

Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.
Change 09.017 The use of IMACKEEP to drop variables in MXG datasets is

IMACKEEP vulnerable to error. If a new dataset is created by the

May 15, 1991 new version of MXG (for example, new TYPE74.. datasets to

Jul 23, 1991 support MVS/ESA 4.1), and if you don't retrofit your

changes in IMACKEEP, you will fail with a SAS Error 311,

because your redefinition in IMACKEEP won't contain the

name of the new datasets. It appears there is a better

way to drop unwanted variables from MXG datasets without

using IMACKEEP. You can simply use a DROP statement in

the EXTY.... member to drop unwanted variables. Even

those variable names are still in the KEEP= option of the

DATA statement in the _VAR macro definition, the DROP

statement overrides the KEEP= option and the unwanted

variables will be dropped. Using the EXit member to drop

variables should be less vulnerable to change, and will

eliminate the use of IMACKEEP except in cases where you

want to ADD a new variable to an MXG dataset. A caution;

you cannot drop a variable which is later used in a BY

statement.the DATA step, as one user found when he tried

to drop MVS/370 variable LCHAN using EXTY74. The drop

statement removed LCHAN from not only TYPE74 but also the

TYPE73P dataset, which is later sorted from work to the

PDB with LCHAN in its BY statement. This cause an error!

However, ain't nothin' straightforward. If you should

use a DROP statement in the EXIT member, and if that

variable should ever disappear from MXG, you will THEN

fail with a "Variable in drop list never referenced"

error! Normally this won't happen in MXG code, but

(for example), if you had used the XMAC7... members to

circumvent of the SAS (Version 5 only) 344 compiler

error, MVS/370-only variables do not exist in the XMACx

and your DROP statement in EXTY74 would fail.

But you can be even smarter than SAS. If you add a

"MXG Compiler Faker" statement for each variable to

be dropped ahead of your DROP statement, the compiler

will be faked out whether the variable exists or not,

the variable will be dropped, and you code will be

invulnerable to future MXG changes! What is this MXG

"Faker" statement? Simply for numeric variables it's:

IF N=. THEN N=.;

and for a character variable C, you must have as many

blanks between the quotes as is the length of the

character variable:

IF C=' ' THEN C=' ';

Change 09.016 Support for Computer Associates CA-1 (TMS) Release 5 has

TYPETMS completely changed the format of the TMC records, but as

TYPETMS5 there is no product release number in the TMC, MXG had to

create completely separate, but parallel members to read

VMACTMS5 the new TMC to create MXG data set TMS.TMS. A few new

May 15, 1991 variables do exist (see DOCVER09), but all of the prior

variables still exist (except for the obscure variables

READERR, WRITERR, which were replaced by 8 separate error

values). The value of variable DEVTYPE was changed so it

doesn't waste so much space; the "EIGHTEEN-TRACK" and the

"NINE-TRACK" values were replaced by "9TRK", "18TRK", and

new value "36TRK" (for the 3490-E Serpentine technology)

was added for DEVTYPE. For 3480s ("18TRK"), the IDRC

compaction status is decoded into MXG variable DEN, which

will have the value 38000 for non-IDRC 3480 tapes, and

which is set to 76000 by MXG to indicate IDRC compacted

3480 tapes. Members TYPETMS/VMACTMS must be used for

CA-1 Releases earlier than Release 5, and MXG members

TYPETMS5/VMACTMS5 must be used for Release 5.

Thanks to Debora Reinert, Nordstrom, USA.

Change 09.015 Landmark TMON/CICS Version 8 history file contains a data

TYPEMON8 dictionary record with TMMDREC='DD' which causes MXG to

May 14, 1991 fail because this record was not expected, and should be

deleted. Change lines 065900 to 0660 to now read:

TMMDREC $CHAR2. 065900

@; 065910

IF TMMDREC='DD' THEN DELETE; 065920

INPUT TMMDFLG1 $CHAR1. 066000

Thanks to David A. Faught, FCC National Bank, USA.
Change 09.014 The DROP=_FREQ statement in IMACPDB was supposed to have

IMACPDB been DROP=_FREQ_ (with underscore on both sides), so that

May 13, 1991 the _FREQ_ variable created (only in SAS 6.06+, when PROC

MEANS was replaced by PROC SUMMARY) would be dropped. The

"misspelling" caused _FREQ_ to exist in both PDB.JOBS and

PDB.SPUNJOBS.

Thanks to Raymond Zieverink, Belk Stores Services, USA.

Thanks to Freddie Arie, Lone Star Gas, TEXAS.

Change 09.013 New PDB.SPUNJOBS dataset variables INITTIME/JINITIME were

SPUNJOBS not kept as 8-bytes (which caused their value to be

May 13, 1991 truncated by up to 255 seconds) and were not formatted.

Both are now explicitly in the LENGTH statement and a new

FORMAT statement was added.

Thanks to Freddie Arie, Lone Star Gas, TEXAS.

Change 09.012 Trending of TMON/CICS dataset MONIDBDS built from TMON

ASUMDBDS Release 7 data (i.e., using MXG member TYPEMONI) will

TESTOTHR cause ASUMDBDS to fail with variable APPLID not found, as

May 13, 1991 APPLID did not exist in TMON Release 7. Adding after the

INCODE= operand:

IF APPLID=' THEN APPLID=' ';

will protect ASUMDBDS for either TMON Release 7 or 8.

(This error was not detected because MXG's TESTOTHR step

of JCLTEST had member TYPEMON8 included after TYPEMONI

and then ASUMDBDS was included, masking the error. Now,

ASUMDBDS (and ASUMCICS) are invoked after TYPEMONI, and

then again invoked after TYPEMON8. Note that there is

no way to actually test TMON/CICS with step TESTOTHR and

actual data records; the single MONICICS DDNAME is used

for both TYPEMONI and TYPEMON8, and thus with real data,

one or the other will fail in step TESTOTHR. To really

test TMON/CICS data with MXG, use a separate job with

only the appropriate TYPEMONx member.)

Thanks to William Padilla, Farmers Insurance Group, USA.
Change 09.011 Landmark's TMON/CICS Release 9.0 records will have to be

TYPEMON8 converted to Release 8.1 format for processing by MXG's

May 13, 1991 TYPEMON8 member; Landmark does not intend to make the 9.0

formats available. But TMON/CICS 9.1 will be available

late 1991 or early 1992, and will have significant change

in its records that will be made available and thus 9.1

records will be supported by MXG natively late this year.
Change 09.010 TYPE57 data produced MXG message "INVALID ESS SECTION'

VMAC57 and the record was skipped because IBM documented the LEN

May 13, 1991 and NR of ESS sections as 4 bytes when in fact they are

only two bytes. Lines 010100 and 010200 (where LENESS &

NRESS are INPUTed) should be PIB2. instead of PIB4.

Thanks to David A. Faught, FCC National Bank, USA.

Change 09.009 Processing HSM MCD, etc. data sets may cause STOPOVER,

VMXGHSM may print INVALID DATA messages if HSM dates are nulls,

May 13, 1991 may print INVALID ARGUMENT messages because DATEJUL()

were not protected, misspelled TTOCTYP with an E, and

did not input TTOCALT, the Alternate VOLSER. The STOPOVER

was corrected by moving the two tests for 'junk" records

(SUBSTR(MCDDSN) containing '99999') to immediately after

the variable MCDDSN was input (by breaking the input

statement at that point with @;). The INVALID DATA was

eliminated by preceding all PDB4. formats with the ??

format modifier, and the INVALID ARGUMENT was eliminated

by replacing all DATEJUL(x) functions with:

IF x GT 0 THEN x=DATEJUL(x);

ELSE x=.;

The occurrence of TTOCTYPE was respelled TTOCTYP, and was

formatted $HEX2. instead of HEX2., and the preceding

TTOCKEY variable was now formatted HEX2. Finally, at the

end of the TTOC section, new variable TTOCALT $CHAR6. is

now input, labeled 'VOLSER OF ALTERNATE VOLUME' and kept.

Thanks to Tim Noone, American United Life Insurance Company, USA.

Thanks to Joe Ellis, Shelby Insurance, USA.
Change 09.008 SAS 5.18 344 Compiler Limit circumvention member VMAC110M

CICINTRV (that was added by Change 8.065 to reduce Iterative DOs)

VMAC110M fails with BUILDPDB because after VMAC110M was tested,

May 9, 1991 member CICINTRV was added to BUILDPDB, but VMAC110M does

not create the datasets required by CICINTRV. Since the

purpose of VMAC110M was to suppress CICS/ESA Statistics

processing, and since CICINTRV processes only CICS/ESA

Statistics data sets, the easiest circumvention that lets

you use VMAC110M (by copying and renaming it to VMAC110

in your USERID.SOURCLIB) is to also create a member named

CICINTRV in your USERID.SOURCLIB that contains a blank

line. This will possibly circumvent the 344 error and

will definitely eliminate the "Data Set Not Found" caused

by VMAC110M. However, just to be really robust, the

member VMAC110M was corrected by this change, and now it

does create the CICS/ESA statistics datasets (with zero

observations, and with only the seven variables needed by

CICINTRV) so if a future user does not see this change,

and uses only VMAC110M, he/she won't be burned!

Thanks to John Hassman, Texas Education Agency, USA.

Change 09.007 Applies only to MXG 8.9. Change 8.304 added retrograde

VMAC79 support for RMF 3.5.1 type 79 records, but I miss-typed

May 9, 1991 two lines. In line 037900, R792ARS should be PIB2. vice

PIB4., and in line 039630, R792TWSS should be PIB2. vice

PIB4. Without this change, RMF 3.5.1 records STOPOVERed.

Thanks to Gordon Keehn, Fidelity Mutual Life Insurance Company, USA.

Change 09.006 Minor documentation. Member IMACAAAA failed to list the

IMACAAAA IMACCMF member (Boole's CMF SMF Record ID) in its index,

IMACCMF and member IMAC370 was deleted, as it was not referenced

IMAC370 and should have been deleted during testing; it was going

May 8, 1991 to contain MVS/370-only-RMF processing but was discarded

as a bad idea. It serves no purpose.

Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.005 Minor, unless you tried to build your PDB on tape! The

IMACCICS new SPUNJOBS logic added in MXG 8.8 tried to read the

SPUNJOBS PDB.SPIN26 at the same time it was writing PDB.SPUNJOBS

May 8, 1991 which can't be done if your PDB DD points to tape! Note

that if you really want your PDB on tape you must not

only correct this design error in SPUNJOBS, but you must

also change the default PDB values in member IMACCICS to

WORK, and (if you actually have CICS data) use EXPDBOUT

to then PROC COPY IN=WORK OUT=PDB; SELECT CIC:; as is

now described in comments in IMACCICS. To fix SPUNJOBS,

insert: DATA SPJB26; SET PDB.SPIN26; immediately before

the line containing DATA PDB.SPUNJOBS; and in the

following MERGE statement change PDB.SPIN26 to SPJB26 so

that only one PDB dataset is open at a time. Also,

PROC DATASETS NOLIST;

DELETE SPJB30_1 SPJB30_4 SPJB30_5 SPJB26;

was added at the end of the member. It was also realized

that SPIN6 processing is not currently in SPUNJOBS, and

that will be corrected in another change.

Thanks to Tim Hill, Pacific Bell, USA.

Change 09.004 Minor. Lines 011900 and 012000 both contained */ after

DIFFHSM the semicolon, which should have raised a syntax error,

May 8, 1991 but didn't. Instead, variable DSRNTRKW was never DIF()d!

Thanks to Joanne Turpie, New Zealand Dept. of Labour, NEW ZEALAND.

Change 09.003 Minor. The last occurrence of variable OTHRACTV (in the

TRNDRMFI NORM1= list) should have been OTH0ACTV.

May 6, 1991
Change 09.002 This change is cosmetic, but should be noted. The 3490E

VMACUCB cartridge tape (serpentine, bi-directional) device has a

May 6, 1991 DEVTYPE of 81x, which was formerly assigned to the 9348.

MXG will now report 3490E instead of 9348. Note that the

3490 (non-E variety) cannot be differentiated from 3480s.

And of course 3480s with and without IDRC (compression)

are not identified at the device level. And what's going

to be real fun is trying to figure out what kind of tape

you hold in your hand; all three used identical media

cartridges, but are incompatible; 3490E cannot be read

by 3490/3480/3480-IDRC, and 3490/3480IDRC cannot be read

on 3480. Note MXG shipments are 3480-non-IDRC!

Thanks to Jay Arbabha, Principal Mutual Life Insurance Company, USA.
Change 09.001 MVS/ESA 4.2 data records finally arrived and demonstrate

VMAC30 that it is risky to distribute software that has not been

VMAC7072 tested with actual data records. On the other hand, if

VMAC73 I had waited for the data, you would still be waiting for

VMAC74 the software! These errors ONLY happen with MVS/ESA 4.2

XMAC30 data records, and only one causes an actual error.

XMAC7072 a.In VMAC30, find the line containing

XMAC73 @109+OFFSMF SMF30ASO +8 /*RESERVED*/

XMAC74 and change it to read:

May 6, 1991 @109+OFFSMF +8 /*RESERVED-SMF30ASO*/

This was a soft error, only causing your log to be filled

with "INVALID DATA FOR SMF30ASO" messages and a hex dump.

(If it's not clear, SAS was trying to input SMF30ASO as

an EBCDIC numeric field because there was no format item

following the variable name in the input statement. What

was desired was to skip over 8 bytes, and note that this

reserved field was called SMF30ASO by IBM.)

b.VMAC7072 causes "INVALID DATA FOR IOCRFC/CPURFC" messages

because these two fields no longer exist in 4.2, and the

fields now contain hex zeros instead of EBCDIC zeros!

Find the lines containing

@OFFWRKC+14 IOCRFC 3.

@OFFWRKC+17 CPURFC 3.

and add ?? format modifier between the variable and its

format:

@OFFWRKC+14 IOCRFC ?? 3.

@OFFWRKC+17 CPURFC ?? 3.

The ?? format modifier suppresses the hex dump and the

message, and sets the variable's value to missing.

This is a soft error.

c.VMAC73 causes "INVALID DATA FOR IODFDATE" messages.

Find the lines containing

IODFDATE YYMMDD8.

IODFTIME TIME8.

and add ?? format modifier between the variable and its

format:

IODFDATE ?? YYMMDD8.

IODFTIME ?? TIME8.

because not all records contain this new date/time data.

This is a soft error.

d.VMAC74 also causes "INVALID DATA FOR IOFDATE" messages

for the same reason as the VMAC73. Apply the fix above

for IOFDATE (paragraph c) to the VMAC74 member.

e.VMAC74 causes a STOPOVER condition. This is not soft!!!

Find the three lines reading:

DLYDIRTM PIB4.6

@;

SKIP=SKIP-20;

and change them to read:

DLYDIRTM PIB4.6

DEVDYNCH $CHAR1.

+3

@;

SKIP=SKIP-24;

These extra four bytes were added by IBM, and were added

in the SMF manual, and were even vertically barred, but

I simply missed them. Sorry for the inconvenience.

The actual change in MXG VMAC74/XMAC74 9.2 and later is

more extensive that this "quick fix" printed changed.

Thanks to Diane Eppestine, Southwestern Bell, USA.
LASTCHANGE: Version 9

=========================member=CHANGE08================================

/* COPYRIGHT (C) 1984,1991 MERRILL CONSULTANTS DALLAS TEXAS USA */
I. This is the Production Version MXG 8.9, dated May 1, 1991.
All Changes listed in this member have been installed in MXG 8.9.
MXG 8.9 is a replacement for MXG 8.8 (which had been shipped April 8).

The few minor errors that had been found in 8.8 were corrected, and the

support for Fujitsu's FACOM PDL data was enhanced.
This MXG 8.9 library contains 1370 members, 309,959 lines of code,

and builds 903 datasets with 31,868 variables documented in DOCVER!

Member NEWSLTRS contains all newsletters, including NINETEEN which

contains the Installation and Compatibility notes for MXG Version 8.

Changes thru 8.078 were printed in NEWSLETTER SEVENTEEN, Jul 10, 1990.

Changes thru 8.087 were contained in MXG PreRelease 8.2, Jul 20, 1990.

Changes thru 8.119 were contained in MXG PreRelease 8.3, Aug 26, 1990.

Changes thru 8.157 were contained in MXG PreRelease 8.4, Oct 9, 1990.

Changes thru 8.168 were contained in MXG PreRelease 8.5, Oct 27, 1990.

Changes thru 8.169 were contained in MXG PreRelease 8.6, Oct 27, 1990.

Changes thru 8.186 were printed in NEWSLETTER EIGHTEEN, Dec 3, 1990.

Changes thru 8.203 were contained in MXG PreRelease 8.7, Dec 18, 1990.

Changes thru 8.283 were printed in NEWSLETTER NINETEEN, Apr 8, 1991.

Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.

Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
Critical Notes:
MXG Compatibility Exposures in MXG Version 8 for Existing Users:
a. The SAS options required by MXG for execution have changed.

b. Execution under SAS 6.06 is different than under SAS 5.18.

c. To create your PDB directly on tape, IMACCICS must be changed.

d. If you have added additional SMF record processing to BUILDPDB,

and you still execute MXG under SAS 5.18, you may encounter a

SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.

See Change 7.038 in member CHANGE07 for 344 error circumvention.
Please note the new MANDATORY options for SAS 5.18 and 6.06 in the

SAS Notes in Newsletter NINETEEN. Member SASOPTV5 or CONFIG in this

library can be used to specify these options, but if you do not pay

attention to ALWAYS include the appropriate member, you will be

very frustrated by unresolved macro reference or 180 syntax errors!
MXG Newsletter NINETEEN contains Installation Instructions that MUST be

complied with. (Contained in member NEWSLTRS).

SAS 6.06 is repaired, and with the March 1991 or later SAS Usage Notes

tape, it is now MXG's recommendation that you begin your migration

to SAS 6.06. The March tape contains 100% pre-applied SAS ZAPs for

all SAS products, in IEBCOPY format, making SAS maintainance a snap!

Z6062141 is a critical ZAP that MUST be installed if you do not

have the March SAS tape installed.

IV. Documentation MXG Software.
Member CHANGES always contains the version number of MXG Software, and

it lists changes that were installed in that version. Several members

named CHANGEnn are the contents of changes when that "nn" MXG version

was created. Details on enhancements will be found in the text of the

Change description that made the enhancement (in those CHANGES and

CHANGEnn members). The CHANGE members can also be scanned online (with

SPF BROWSE) to search for specific product name references (CICS,

MVS/ESA, etc.). The text of each Change identifies the member(s) that

were altered or added by that change, and documentation (especially for

new product support) is often found in comments at the beginning of

those named members.
Member NEWSLTRS contains the text of all newsletters (up through the

newsletter that accompanied that MXG release). You can search NEWSLTRS

for product name or acronym to find the technical notes, APARs, etc.

from all MXG newsletters. (The Change Log of each Newsletter is not

replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter

FORTY style) of only those variables and datasets that were changed

between successive MXG Versions. There is a DOCVERnn "delta" member in

the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format

that documents all of the 31,868 variables from the 903 MXG data sets

that can be created by that MXG Software Version (alphabetically by data

set name and variable name).

Finally, MXG is a source distributed system, so you can often find your

answer by BROWSE/EDIT of the source member, especially the VMAC...'s

that actually create the data set, or ANAL....'s that analyze the MXG

datasets. In many instance, the MXG Variable is the IBM or Vendor's

documented field name. In other cases, the IBM field name is carried as

a comment beside the MXG variable that contains that information. In

all cases, you should also have the Vendor's documentation of the

particular data record you are using for analysis.

I. MXG SOFTWARE Version status.
1. Production MXG Version is now MXG 8.8, dated April 8, 1991.
MXG Version 8.8 is shipped with NEWSLETTER NINETEEN to all sites, and

should be installed as soon as possible. MXG 8.8 is mandatory for MXG

execution under SAS 6.06 or later, has MANY major enhancements, and has