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

default SAS JCL and removes the NLSCOMPATMODE option.

Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.

Change 22.128 New BLDIMPDB is "JCL" for ASCII platforms, for STEP03/04

BLDIMPDB of the JCLIMSLx/ASMIMSLx IMS log processing on ASCII SAS

TYPEIMSB platforms; BLDIMPDB provides the filename statements with

Jun 14, 2004 correct DCB attributes that are used after STEP01/STEP02

(which do not require SAS) were executed on "MVS".

-Member TYPEIMSB had to be changed to process character

fields containing hex data as $CHAR rather than $EBCDIC,

logic was added to convert text fields back to EBCDIC.

Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.127 The example in comments to read SMF data (instead of PDB)

ANALFIOE was enhanced to create only the datasets, and keep only

Jun 14, 2004 the variables that are required, reducing run time and

DASD space. This is not needed if you run ANALFIOE with

BUILDPDB, since the PDB has all of the needed datasets

to analyze concurrent FICON Open Exchanges.

Thanks to Neil Ervin, Charles Schwab, Inc, USA.
Change 22.126 The "WO" must be "W0", i.e., w-zero not w-oh in the DSNs

MXGSASV9 and member names in the JCL example.

Jun 11, 2004

Thanks to Robert Chavez, Office Depot, USA.

Change 22.125 Support for Mobius/IPAC subtype 5 IPAC05 dataset duration

VMACIPAC variables were incorrectly input, but nobody had noticed,

Jun 9, 2004 until now. Version 6.2 data has been validated.

Thanks to Marty Wertheim, Bank of America, USA.

Change 22.124 MXG 22.04-MXG 22.05, QWHSSTCK was missing in SMF 102 DB2

VMACDB2H trace records after Change 22.090; the reset for ID=101

Jun 9, 2004 statement should have also have reset ID=102.

Thanks to David M. Forbes, McLeodUSA, USA.

Change 22.123 SAS Version 9 INCOMPATIBILITY, on "MVS" only, CRITICAL:

CONFIGV9 The MXG default value for the SAS system option S2=

UTILS2ER (it sets the line size of source statements that will

MXGSASV9 be read from %INCLUDE and AUTOCALL members),

Jun 8, 2004 which is set in the MXG CONFIGV9 member,

Jun 12, 2004 MUST now be changed for MVS from the MXG default of S2=72

(which was chosen so that SAS only read columns 1-72,

and prevented errors when user-written code had mixed

blank and non-blank lines, or had invalid line numbers

in columns 73-80. Only user-written code members had

the exposure, since all of MXG fits in 72 positions),

to be S2=0, because:

- MVS SASMACRO library was changed from RECFM=FB to VB.

There are no standards for line size of SAS-provided

%macros; previous MVS-used %macros fit in RECFM=FB, but

new V9 macros now have line sizes up to 255 positions.

These new macros were created on ASCII platforms,

where all text files are variable length, with 255

default length (which SAS handled because it treats

variable length input and fixed length differently),

so the coders (with no legacy background) had no

reason to restrict their code to the 72 bytes that

we had found necessary on MVS systems, and they did

all of their testing on ASCII platforms.

If they had known of the restriction, their macros

could easily have been written to fit, this change

wouldn't have been necessary, so you could have

read their source code, to understand and learn,

without line wrapping on green screen terminals!

- So the MVS folks had to change RECFM from FB to VB to

deliver these long-length %macros, and since the real

SAS System default is S2=0, the MVS QA tests did not

see any of the errors that their change causes when the

S2 option is set to S2=72.

- And, unfortunately, while MXG programs do use some of

the SAS-provided %macros (%LOWCASE,%LEFT,%CMPRES,%TRIM)

the utilities that use them (UTILBLDP,BLDSMPDB) weren't

executed with the arguments that happen to invoke them

in our QA, so we missed this V9 problem in our testing.
- The SAS Change to RECFM=VB with the MXG S2=72 default

has caused real errors, and has the potential for more:

- With VB and S2=72, real errors occurred:

A site that had always put their own local %macros

in the SASMACRO FB library in previous SAS versions

got "macro not found" errors when they copied their

%macros into the VB file, and executed with S2=72,

because SAS started reading in column 73, and never

saw their %macro definition. SAS Technical Support

recommended they change S2=0, SAS Note SN-011929,

which did correct this error.

An alternative to putting user %macros in the

SAS-supplied library is to put them in the MXG

"USERID" tailoring source library, because MXG

uses MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS)

precisely so that %macros will be found.

- But with VB and S2=0, potential errors may be worse:

Since MXG has always set S2=72, any text in your own

source code in columns 73-80 was ignored, but now,

if you have a member with invalid line numbers in

columns 73-80 (mixed numbers and characters; some

vendors use 73-76 for a line number and put version

characters in 77-80), or if you have a member with

unnumbered first line and numbers in later lines,

your perfectly running job now will fail under V9

(with a 180 syntax error, at the non-blank line),

and the defective numbering will not be identified.

That member must be either all unnumbered or all

lines must be numbered to eliminate this error.

MXG set S2=72 to protect users from the very common

human error we found in MVS systems, when a user

EDITed a new line with blank number into a member

that was already numbered, but now, you must detect

and correct those members so that S2=0 can be used.

- But since CONFIGV9 must now specify S2=0 to prevent the

real errors encountered, those potential errors due to

"bad" line numbers MUST be detected and corrected prior

to migration to V9. The new UTILS2ER program MUST be

run against each of your Source PDS libraries that have

SAS code; it will identify all members with "bad" line

numbers, so that you can EDIT those members and avoid

the potential errors caused by changing S2=72 to S2=0,

prior to migrating to SAS Version 9 on "MVS".
- Tutorial on S2 option values:

- The S2=72 option has completely different meanings for

RECFM=VB than for RECFM=FB:

-For FB, S2=72 says to only read the first 72 positions

-For VB, S2=72 says to skip the first 72 positions and

start reading in column 73!

- The S2=0 option is also different, for the two RECFMs:

-For FB, the last 8 columns of the first line of each

member is read; if that first line does not have a

valid sequence number, SAS reads the full LRECL of the

source line. If that first line has a valid sequence

number, SAS reads all but the last 8 columns of that

member's lines.

-For VB, columns 1-8 of the first line of each member

is read, and if a valid line number is found, SAS then

internally uses S2=8 to start reading in column 9.

If there is no line number in columns 1-8, SAS then

internally uses S2=0 to read the entire line length.

- Fortunately, SAS separately opens each member, so with

S2=0 and either FB or VB, SAS examines each member for

line numbers, so you can have one member without line

numbers, and another member with line numbers, even in

the same PDS, without any error; it is only when you

have invalid line numbers, or have a blank line before

a numbered line, that the 180 syntax error will happen.
Note that MXG did NOT change the S=72 default value:

- S controls SAS action on code read in from //SYSIN

- S2 controls SAS action on code read by %INCLUDE or

by SASAUTOS)

because you want that protection: it is very common to

have mixed numbered and unnumberd lines in your members

that have both the JCL and the SAS code, that you EDIT

and SUBMIT, and using S=72 allows that inconsistency,

so your job will continue to run without errors.

Summary of changes:

-CONFIGV9 now specifies S2=0 instead of S2=72.

-UTILS2ER is a new program to find S2=0 bad lines.

-MXGSASV8/V9 has //INSTREAM with SPACE=(CYL,(1,20))

instead of CYL,(1,1), which could only hold 168,000

lines of source for UTILS2ER. With (1,20) that temp

file has room for 3 million lines from each PDS.

Thanks to Michael L. Kynch, International Paper, USA.
Change 22.122 Cosmetic. Error messages were made consistent, with both

VMAC28 SYSTEM and SMFTIME printed with all errors.

Jun 8, 2004

Thanks to Pascal Maurice-Prestataire, La Poste, FRANCE.

Change 22.121 See the extensive discussion of DB2 Parallel Transactions

VMACDB2 (and the significant loss of DB2TCBTM if you have any)

EXDB2ACC in the "DB2 Technical Notes, Newsletter FORTY-FIVE).

EXDB2ACB -This old code in the MXG exit members EXDB2ACC/ACP/ACB:

EXDB2ACP IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;

Jun 6, 2004 was removed by this change, and should be removed from

your exits. It was added by Change 20.266 to resolve a

problem with duplicate records, but the new DB2PARTY='R'

value is set when QWACPARR='Y', so the DELETE could never

have been executed.

-New value 'R' for the RollUp record, and value 'P' is now

for the Parallel Task (or Utility Subtask):

DB2PARTY Description Set by

'R' Rollup QWACPARR EQ 'Y'

'P' Parallel QWACPACE GT 00000000X

'O' Parent/Orig QWACPCNT GT 0, QXMAXDEG GT 0

'S' Sequential None of the above

-The code to set DBPARTY was relocated, and the test for

'O' is now set IF QWACPCNT GT 0 OR QXMAXDEG GT 0, which

is a stronger test for the Parent/Originating record.

Without this change, DB2PARTY was "S" for the Parent.

-In DB2PARTY='R' Rollup records QWACESC is not a datetime

value, but as noted in IBM APAR PQ41012, it contains the

total elapsed time for all child tasks, a duration. MXG

now detects when QWACESC is smaller than QWACBSC, (or if

QWACESC or QWACBSC are zero) and for those observations:

MXG stores the "QWACESC" time in variable CHIELPTM.

MXG creates QWACESC as datetime, equal to QWHSSTCK.

QWACBSC may be zero

ELAPSTM is set to missing

For all other observations, CHIELPTM will be missing,

and ELAPSTM=QWACESC-QWACBSC.

Thanks to Andy Creet, Department of Defence, AUSTRALIA.

Thanks to Andy Schuermann, Department of Defence, AUSTRALIA.

Change 22.120 MXG 22.05, MVS only, using UTILBLDP, you will get error:

CONFIGV8 APPARENT INVOCATION OF MACRO CMPRES NOT RESOLVED and

CONFIGV9 APPARENT INVOCATION OF MACRO LEFT NOT RESOLVED because

Jun 4, 2004 during tests for Change 22.102, I had mis-understood SAS

techs to say that the %LOWCASE and other %MACROS had been

implemented in base SAS, and that SASAUTOS was no longer

required, so I had changed SASAUTOS=SOURCLIB in testing,

but found it was only the function LOWCASE and not the

%macro %lowcase that had been implemented; unfortunately

I failed to go back and correct the SASAUTOS= statements

in those CONFIGVn members. The correct statement is

SASAUTOS=(SOURCLIB SASAUTOS)

which has always been required in CONFIGxx and AUTOEXEx

to retrieve the SAS-provided %macros that are not defined

in base SAS: %LOWCASE, %CMPRES, %LEFT, and %TRIM.

Thanks to Jim Horne, Lowe's Companies, Inc, USA.

Change 22.119 Cosmetic: Four of the BY statements in the _CHAIN macro

VMACCIMS were replaced by _BIMFTRN, since that "BY" macro had the

Jun 3, 2004 same variables as the replaced BY statements.

Thanks to Joe Babcock, Bank One, USA.

Change 22.118 Cosmetic: Semi-colons at the end of some MACRO _BTY91xx

VMAC91 were removed, to be consistent with other definitions.

Jun 3, 2004

Thanks to Joe Babcock, Bank One, USA.

Change 22.117 Support for optional ESS segment GEPARMKY=003B creates

IMAC6ESS variable ESSFRMLN (FORMLEN) in dataset TYPE6, when the

VMAC6 comment block in member IMAC6ESS is opened.

Jun 3, 2004

Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY
Change 22.116 Variables SMF70NSI SMF70NSA SMF70NSW were incorrectly

VMAC7072 divided by NRSAMPLE, which is ten times greater than the

Jun 3, 2004 SMF70DSA that should have been used.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 22.115 JES3 only. The BUILDPD3 program could use the wrong type

BUIL3005 26 purge record, which caused ABEND='JCL' for jobs that

Jun 2, 2004 had actually executed, especially for jobs that were read

in on one system and sent to a second system via NJE for

execution, because the first TYPE26J3 observation was the

one used. This revision uses the SYSEXEC field, which is

non-blank only in the "execution" purge record; all other

purge records are output in dataset PDB.DJEPURGE prior to

the logic that matches the purge record with the other

job records.

-The READTIME value can be different in the purge record

that was written for the job's output processing which

occurred on the original node. The first two 26 records

(one on the read-in system, one on the execution-system)

but the third 26 record had a READTIME that was after the

purge time of the execution purge record. As this was a

non-execution purge record, it is output in PDB.DJEPURGE,

but searching for it by READTIME would not find the obs.

Thanks to Ray C. Lau, Nav-International, USA.

Thanks to Roger Rush, Nav-International, USA.

Change 22.114 This VTS Library Statistics report replicated the IBM

ANAL94 report, but IBM uses the SMFTIME (end) rather than the

Jun 1, 2004 STARTIME (begin) of the interval, so, to match their

report, SMFTIME is now used, and the REPORT TITLE has

been modified to indicate it the end of the interval.

Thanks to Cheri Sample, Ford Motor Car Company, USA.

Change 22.113 ASCII execution only, using ASMIMSLx/JCLIMSLx steps 3 & 4

TYPEIMSA on PC, variable APPLID was unreadable because it was not

May 27, 2004 converted back to EBCDIC. APPLID=SUBSTR(DTOKEN,1,4); was

replaced by APPLID=INPUT(SUBSTR(DTOKEN,1,4),$EBCDIC4.);

Thanks to Mark Van Der Eynden, Hewlett-Packard Australia, AUSTRALIA.
Change 22.112 INPUT STATEMENT EXCEEDED if MVRECLEV EQ '02'X but you did

VMACEDGS see the circumvention in the comments to change the 58 in

May 26, 2004 _SKPEDGS to 122, because the INPUTs for MVAUTID1-8 were

not compared with their length. However, this error is

now eliminated, as logic now tests MVRECLEV and sets the

value to either +58 or +122 automagically.

Thanks to Chuck Hopf, MBNA, USA.
Change 22.111 Durn unix, and it's case sensitivity: these two members

BLDSMPDB must be all lower case, and all of the %UPCASE functions

BLDNTPDB must be changed to %LOWCASE, and when you type in the

May 26, 2004 %bldsmpdb(....) or %bldntpdb(....) those text lines

must also be typed in lower case.

-References to &SYSSCP were changed to &OPSYS, because

&SYSSCP is a SAS-owned macro variable that cannot be

%LOWCASEd, but &OPSYS is set in VMXGINIT and can be.

Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.110 The label for R744STSA was reversed; it is now

VMAC74 R744SSTA='REQUESTS*CHANGED FROM*SYNC TO ASYNC'

May 25, 2004

Thanks to Thom Kight, Fidelity Systems, USA.

Change 22.109 -DB2 data written to GTF and read with TYPE102G caused

ANALDB2R INVALID DO LOOP CONTROL INFORMATION error.

ANALDBTR because some IFCID 070 and 071 Trace Records contain only

VMAC102 a product section; MXG expected a second section with the

VMACDB2H QW0070 and QW0071 DSECTs, as described in DSNDQW01. The

VMACSMF two IFCIDs now only INPUT the second if QWHSNSDA GE 2.

May 30, 2004 When QWHSNSDA=1, T102S070/T102S071 dataset will have

missing values for the variables from those DSECTS, i.e.,

QW0070FR/CK or QW0071RT/RS/NI/FR will have missing value.

-Additionally, these two IFCIDs have only the Standard DB2

Header and the CPU Header in their Product Section. the

Correlation Header does not exist, so the QWHCCN QWHCCV

and all QWHC variables are missing in T102S070/T102S071.

-The _GTFDB2 macro in VMACSMF was corrected to run under

ASCII SAS; $EBCDIC was changed to $CHAR and $HEX format

was added.

-The _GTFDB2 macro did not store TODSTAMP into QWHSSTCK,

so the use of GTF data for ANALDBTR to create "PAIRS"

datasets, and/or the use oF PMSQLnn reports in ANALDB2R

did not work, causing blanks for Interval Start, etc.

-ANALDBTR did not include _114PAIR in ALLPAIRS macro,

causing S114S115/S114S116 DATA SET NOT FOUND errors in

ANALDB2R.

-ANALDB2R had misspelling of QW006PG vice QW0006PG, and an

incorrect &TRACEIN..S183S183 that is now just S183183; it

had caused a DATASET PDB.S183S183 not found error.

Thanks to Wayne Montefiore, CSC GIS Engineering Services, AUSTRALIA.
====== Changes thru 22.108 were in MXG 22.05 dated May 22, 2004=========
Change 22.108 CRITICAL for SAS V9.1, if you did NOT install CRITICAL

CONFIGV9 SAS Hot Fix in SN-012437 for V9.1 and for V9.1.2:

VMAC110 Summary: -SAS V9.1, using V7SEQ,V8SEQ,or V9SEQ, creates

VMAC120 corrupted and un-readable datasets, with no

VMAC80A error messages until you try to read the data,

VMACOMDB and the data is NOT recoverable; it's lost!

VMACSMSX See the FLASH posted May 21 to MXG-L/ITSV-L,

VMACTMTC or see FLASH in Newsletters at www.mxg.com.

May 22, 2004 -SAS V9.1, using V6SEQ, creates valid datasets

that have no errors, but if a dataset has any

long-length variables (greater than 200 bytes),

the copy/write caused error messages, and you

could not copy/write that dataset.

-SAS 9.1.3 has corrected all known errors and

V9SEQ can be safely used; however, CONFIGV9

still has V6SEQ, because I cannot tell that you

are running under SAS V9.1.3.

-Under SAS V8.2, V8SEQ creates valid datasets,

and supports "long length" variables; the error

only occurs under SAS V9.1, without hot fix.

This revision shortens all "long-length" variables in

datasets from MVS data, so that SEQENGINE=V6SEQ can be

safely used without errors; and the change reinstates

the SEQENGINE=V6SEQ in the CONFIGV9 member.

There is now another CRITICAL change to CONFIGV9 that is

also required for SAS V9, in Change 22.123.

These SMF variables were reduced to $200 bytes length,

(and it is extremely unlikely that your MVS data has

and text longer than 200 bytes in these fields):
SMF TYPE Dataset Variable Orig length

80 TYPE80EK EKC80FRD 1024

80 TYPE8XEK EKC80FRD 1024

110 CICSJR SJRPRPTH 255

110 CICPGR PGRJVCLS 255

120 TYP120JI SM120JI7 400

120 TYP120WA SM120WAL 400

120 TYP120WA SM120WAQ 400

120 TYP120WI SM120WIQ 400

120 TYP120WI SM120WIW 400

USER SMSX IGDACSSC ACEROJFL 256

USER SMSX IGDACSSC ACEROMFL 256

USER SMSX IGDACSSC ACEROSFL 256

USER TMTC TMTCIS ISCONTCT 256

USER TMTC TMTCIS ISDESCR 256

USER TMTC TMTCIS ISLOC 256

USER TMTC TMTCIS ISNAME 256

USER TMTC TMTCIS ISOBJID 256

These MVS-but-not-SMF variables were reduced to $200,

(and data loss here is also unlikely):

Product Dataset Variable

Candle OMDB DB0035 QMDAASTR 247

Candle OMDB DB0630 QW0063ST 5000

Candle OMDB DB1920 QW0192DT 250

Candle OMDB DB2060 QW0206MR 256

Candle OMDB DB2060 QW0206MS 256

Candle OMDB DB2080 QW0208MR 256

Candle OMDB DB2080 QW0208MS 256

Candle OMDB DB2360 QW0236MR 256

Candle OMDB DB2360 QW0236MS 256

Candle OMDB DB2571 QW0257MS 256

Candle OMDB DB3120 QW0312PR 250

Candle OMDB DB3140 QW0314PL 256

Candle OMDB DB3190 QW0319D1 256

Candle OMDB DB3240 QW0324CP 254

Candle OMDB DB3270 QW0327MS 256

And what's at least "slick" about this change:

If you need the extra characters in these variables,

once you have installed the Hot Fix, you can increase

them back to their maximum length just by inserting a

LENGTH var1 var2 ... varn $256 ;

statement in one EXdddddd member for each product!

MXG code still INPUTs the original long length, but

this change inserted a LENGTH varx $200; statement

in the VMACxxxx member, but SAS uses the LAST

LENGTH statement, and the EXdddddd member's code

will then change the stored length of the variable.
But not all variables over 200 bytes were changed:

- These variables created by TYPEWWW from Web Logs were

unchanged; that code is normally run on ASCII SAS,

which does not use the SEQENGINE option, and

Dataset Variable LENGTH

WWWIIS BROWSER URISTEM 256

" COMPNAME CSBYTES CSHOST 4096

" CSVERSN PORT SCBYTES 4096

" SITENAME STATUS32 URIQUERY 4096

WWWLOG BROWSER URISTEM 256

WWWLOG URIQUERY 4096

WWWREFER REFERER 4096

WWWURQRY URIQVALU 4096

WWWCOOKE COOKVALU 4096

- These variables are ONLY longer that 100 bytes if the

COMPRESS=YES option is enabled, none of the datasets

are likely to be created in BUILDPDB nor archived,

especially the T102Snnn DB2 trace datasets that are

usually created only for ad hoc analysis. And all of

these variables can be changed by inserting

%LET SASCHRLN=100;

or

OPTIONS COMPRESS=NO;

as your first //SYSIN statement:
Dataset Variable LENGTH

T102S004 QW0004MS 32000

T102S005 QW0005MS 32000

T102S059 QW0059CN 32000

T102S061 QW0061CN 32000

T102S062 QW0062ON 32000

T102S063 QW0063ST 32000

T102S064 QW0064CN 32000

T102S065 QW0065CN 32000

T102S066 QW0066CN 32000

T102S090 QW0090CT 32000

T102S092 QW0092P1 32000

T102S097 QW0097P1 32000

T102S124 QW01242T 32000

T102S140 QW0140TX 32000

T102S141 QW0141TX 32000

T102S145 QW0145TX 32000

T102S168 QW0168ST 32000

T102S180 QW0180DS 32000

T102S194 QW0194DS 32000

T102S203 QW0203PA 32000

T102S204 QW0204TH 32000

T102S206 QW0206MR QW0206MS 32000

T102S207 QW0207HR 32000

T102S208 QW0208MR QW0208MS 32000

T102S236 QW0236MR QW0236MS 32000

T102T124 QW01242T 32000

T102T140 QW0140TX 32000

T102T141 QW0141TX 32000

T102T145 QW0145TX 32000

TMDBBD QW0140TX 32000

TMDBBD0 QW0140TX 32000

SHADOW06 SM06SQSR 32000

Note: Jan 11, 2011. Change 28.325 updated this list.

Thanks to Diane Parker, AmerisourceBergen Corp, USA
Change 22.107 Formats MGTMDRC for ASG/TMON DB2 and MGDB2RC for IBM DB2

FORMATS slightly out of sync, but now match.