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

TYPE117 117TRM S117TERM TERMINAL

TYPS117 Data for FLOW, THREAD, and NODE have been validated.

VMAC117

VMXGINIT

Mar 8, 2004

Thanks to Victoria LePak, AETNA, USA.

Thanks to Jeff Martens, AETNA, USA.

Change 22.028 The BY-list-macro _BCICRDQ for new CICSRDQU had TSQNAME,

VMAC110 but that should have been TSQUEUE. This misspelling was

Mar 5, 2004 missed because CICSRDQU is not sorted by default.

Thanks to Chris Weston, SAS ITRM, USA.

Change 22.027 -Variable SM120WIP is a count, not a duration; it is input

VMAC120 now as &PIB.4. instead of &PIB.4.3, and is no longer in

Mar 5, 2004 the TIME13.3 format list.

Mar 10, 2004 -For subtype=7, MXG output only the first server segment

from web application section, causing the counts in the

web activity TYP120WA dataset to be wrong, and much lower

than corresponding web interval counts in TYP120WI. All

server segments are now output.

Thanks to Andre Baltimore, Unigroup Inc, USA.
Change 22.026 Cosmetic. The time-of-day when the read of the SMF file

VMACSMF ended is now printed in the "SUCCESSFULLY READ SMF FILE"

Mar 4, 2004 message on the SAS log.
Change 22.025 The JCL Procedure for MXG and SAS execution for SAS V 9.1

MXGSASV9 is slightly different than the original SAS V9.0 JCL. The

Mar 4, 2004 entry point is SAS, the "BATCH" config member is BATWO,

and the DSNAMES are now .WO.AUTOLIB, .ENW0.SASHELP, and

.ENW0.SASMSG.

Thanks to Ed Finnell, University of Alabama, USA.

Change 22.024 This text just documents all of the names of %MACROs that

doc are currently defined anywhere in MXG source code.

Mar 4, 2004 ACTIVITY ANAL115 ANAL94 ANALAVAI ANALBLSR ANALCISH

ANALCNCR ANALDB2C ANALDB2R ANALDBTR ANALDMON ANALEPMV

ANALHSM ANALMNTS ANALNPMR ANALRMFR ANALTCP ANALUOW

ARGS BITCHECK BLDNTPDB BLDSMPDB CALCPOLC CDE_BCR

CDE_BVR CDE_DCL CDE_DCR CDE_DGN CDE_DSR CDE_DVL

CDE_L2CR CDE_MC1 CDE_MCA CDE_MCB CDE_MCC CDE_MCD

CDE_MCM CDE_MCO CDE_MCP CDE_MCR CDE_MCT CDE_MCU

CDE_MCV CDE_MHCR CDE_TTOC CDE_VAC CDE_VSR CECLEVEL

CHART CHKWORK CICCONSM CICDLIR CICDUMP CICFILE

CICSTOR CONVERT COPYIT CPUGRAF DASDGRPH DB2DBID

DB2RSELA DB2RSORT DBUGDB2C DEVTYPE DISKREPT DMIDET

DMISUM DMONREP1 DMONREP2 DMONREP3 DMONREP4 DOMAIN

DSNUPDT DSNUPDT DSNUPDT DT EMAIL EPIVARS

EXTRACT FACILITY FINALRPT FTPDATA FTPRPTD FTPRPTS

GENFTP GETHEX GETOBS GETSUM GRAFDB2 GRAFHSM

GRAFLPAR GRAFREGR GRAFRMFI GRAFTALO GRAFTAPE GRAFTMNT

GRAFTRND GRAFWORK GRAFWRKX GROUP HEADALL HSMBALL

HSMDELT HSMDELU HSMMALL HSMMMIG HSMMTYP HSMPALL

HSM_SUMT HTTPDTL HTTPSRY IMFDLCHA IMFDLSRT IMFDLTRX

INTVREPT IOSTAT IPHOST IPHOSTF LBLCLS LDSKREPT

LOOP LPARSUM MIGSGRPH MMRYREPT MNMXTIME MONTH

MONTHMTD MQMBUF MQMCFS MQMDB2 MQMLOG MRPDBCMD

MXGCAH MXGCF MXGCHAN MXGCOMM MXGCPU MXGDAY1

MXGDEVC MXGDOMI MXGENQU MXGHTTP MXGIOQU MXGPAGE

MXGPGDS MXGSDV MXGSMRY MXGVDAIL MXGVHOUR MXGVSTOR

MXGVUSAG MXGWKLD MXGWLMG MXGXCF NETWREPT NODATA

NPMSMR01 NPMSMR02 NPMSMR03 NUMTYPE OBSCHEK OBSCHEK1

OPTIONS OUT_BCR OUT_BVR OUT_DCL OUT_DCR OUT_DGN

OUT_DSR OUT_DVL OUT_L2CR OUT_MC1 OUT_MCA OUT_MCB

OUT_MCC OUT_MCD OUT_MCM OUT_MCO OUT_MCP OUT_MCR

OUT_MCT OUT_MCU OUT_MCV OUT_MHCR OUT_TTOC OUT_VAC

OUT_VSR PCSRREPT PERIOD PMACC01 PMACC02 PMAUD01

PMAUD02 PMAUD03 PMIOS01 PMIOS02 PMIOS03 PMIOS04

PMIOS05 PMLOK01 PMLOK02 PMLOK03 PMLOK04 PMSPR01

PMSQL01 PMSQL02 PMSQL03 PMSQL04 PMSTA01 PMSTA02

PMTRC01 PMTRC02 PMTRN01 POLICY PRINTIT PRINTNL

PROCESS PROFILE PRT_BCR PRT_BVR PRT_DCL PRT_DCR

PRT_DGN PRT_DSR PRT_DVL PRT_L2CR PRT_MC1 PRT_MCA

PRT_MCB PRT_MCC PRT_MCD PRT_MCM PRT_MCO PRT_MCP

PRT_MCR PRT_MCT PRT_MCU PRT_MCV PRT_MHCR PRT_TTOC

PRT_VAC PRT_VSR PSSTAT RCLASS RDCAT READDB2

READMAP READMXG READREC READSAR REAL REG

REPDATE REPLAY REPORT REPORTS RESP RPTAUSS

RPTCONSM RPTDLIR RPTDUMP RPTFILE RPTJCR RPTLDG

RPTLDR RPTLGR RPTLGS RPTLSRFR RPTLSRR RPTNQG

RPTRMG RPTTCR RPTTSR RPTXMR SCLASS SCPER

SELECT SELTM SMBVTOC SMBVVDS SORTPDB SORTPDB

SPLITCHK SPMAP SRIF SRVPOLCY STM SUMRIZE

SUMTAB TEMP TEMPDB2 TESTLONG TESTN TESTSITE

TIMEBILD TMP70PR TNDATA TNRPTD TNRPTS TRENDIT

TRNDDB2A TRNDDB2B TYP30DD TYP_HDR TYP_HDR2 UDUMPEBC

UNIXTOP USERID USERS UTILBLDP UTILCONT UTILCVRT

UTILPRIN UTILRMFI UTILXRF1 V6COMPCL V6COMPEN VAR_BCR

VAR_BVR VAR_DCL VAR_DCR VAR_DGN VAR_DSR VAR_DVL

VAR_L2CR VAR_MC1 VAR_MCA VAR_MCB VAR_MCC VAR_MCD

VAR_MCM VAR_MCO VAR_MCP VAR_MCR VAR_MCT VAR_MCU

VAR_MCV VAR_MHCR VAR_TTOC VAR_VAC VAR_VSR VAXLOOP

VAXNUM VGETDDS VGETDSN VGETENG VGETOBS VGETSORT

VMACFRYE VMSTAT VMXG2DTE VMXG344 VMXG70PR VMXGCC

VMXGCHR VMXGCICI VMXGCOMP VMXGCON VMXGDEL VMXGDKRN

VMXGDOWN VMXGDSNL VMXGDUR VMXGENG VMXGETM VMXGEXP

VMXGFOR VMXGGETM VMXGGMT VMXGGOPT VMXGINIT VMXGINV

VMXGJFCB VMXGLBIN VMXGLRC VMXGLRF VMXGLRI VMXGLRO

VMXGLRV VMXGMLST VMXGOPTR VMXGPPDS VMXGPRAL VMXGPRO

VMXGRFM VMXGRFV VMXGRMFI VMXGSET VMXGSUM VMXGTAPE

VMXGTIME VMXGTPFI VMXGUOTT VMXGUOW VMXGUOWC VMXGUOWL

VMXGUOWT VMXGUSE VMXGVBS VMXGVTOC VMXGVTOF VMXGVTOR

VMXGWORL WEEKBLD WEEKWTD WGPER WGROUP WKLDUPDT

XMINX _MTG01 _MTG02 _NDMMAKE _VRD30
Change 22.023 No Change, doc only. PCHANBY over 100% for SMF73ACR='OSD'

VMAC73 channels occurs but variable VARIED='Y' (bit 6 SMF73FG2)

Mar 4, 2004 is true in those obs. The SMF manual says for bit 6:

"Data Recorded is incorrect because channel path was

reconfigured during the interval". While I could chose

to not calculate fields, it has always been my policy to

give you whatever IBM puts in the record, so you can then

chose to keep or not to keep that observation in reports.

And, hopefully, the larger-than-100% value will cause you

to find this note, understand why, and then take actions

for your installation to delete those observations from

your reports.

Thanks to Frank DeBree, DEXIA, BELGIUM.
Change 22.022 -Variable LOSU_SEC (unweighted service units per second of

BUILD005 the hardware platform where this step executed) is kept

BUIL3005 in PDB.STEPS and PDB.JOBS.

VMAC30 -Two new service-unit-based CPU variables are created in

Mar 4, 2004 TYPE30_x, PDB.SMFINTRV, PDB.STEPS, and PDB.JOBS datasets;

so they can be compared with the SMF-recorded TCB and SRB

fields:

SRVTCBTM='SERVICE*UNIT*BASED*TCB TIME'

SRVSRBTM='SERVICE*UNIT*BASED*SRB TIME'

The CPUUNITS, SRBUNITS & LOSU_SEC are in SMF 30 records,

but the CPUCOEFF/SRBCOEFF coeffs are not. They are only

in RMF 72s, but since they almost never are changed, the

new variables use macro variables which default to ONE,

a very common weighting value. You MUST override default

coefficients, using these %LETs in IMACKEEP or //SYSIN:

%LET CPUCOEFF=10;

%LET SRBCOEFF=10;

if CPUCOEFF and SRBCOEFF in TYPE72/TYPE72GO are not one.

Note: IBM added those coefficients into the SMF 30 record

with APAR OA09118, and they will be used if that

APAR has been installed. See Change 22.341.
Cheryl Watson suggested using SU-based CPU time instead

of SMF CPU time, because SUs have more precision than the

.01-second SMF resolution, and truncation of those extra

decimal places added up to a few hours of CPU per month.

I examined 879 step records (z/OS 1.5), and did find 216

steps with SRV TCB/SRB CPU times greater than their SMF

TCB/SRB CPU times, but the max delta was only 0.0069 secs

and the "extra" SRV time, due only to truncation, was a

total of only 0.62 seconds for those 216 steps.
However, I also found there were 377 other steps that had

SMF TCB/SRB CPU time greater than SRV CPU; 38 steps had

deltas of over 1 second, and the total SMF CPU captured

was 168 seconds more than the SRV captured CPU time, so

replacing the SMF CPU with the SRV CPU seems unwise.
But what does make sense, now that I have the variables,

is to use the maximum TCB/SRB time, so any decimals that

would have been truncated won't be, creating new variable

CPUTOTTM='TOTAL CPU*MAX TCB,SRB*FROM SMF OR SU'

with this equation in SMF 30 processing:

SUM(MAX(SRVTCBTM,CPUTCBTM),MAX(SRVSRBTM,CPUSRBTM),

CPITCBTM,CPISRBTM,CPURCTTM,CPUHPTTM,CPUIIPTM);
However, remember that CPUTOTTM is COMPLETELY DEPENDENT

on you having %LET correct CPUCOEFF and SRBCOEFF values,

if your coefficients are not the MXG default of one.

-Now, see also the text of Change 22.265.

Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 22.021 -Job delay variables SMF30HQT/JQT/RQT/SQT should not have

VMAC30 been created in TYPE30_V,PDB.SMFINTRV,TYPE30_6 interval

Mar 3, 2004 datasets from subtype 2,3,6 type 30 records, because they

Mar 8, 2004 are job-level, and not interval-level. Their value is

Mar 12, 2004 now always set to a missing value for those records.

-TYPE30_4 dataset, those job-related variables will now be

missing except in the STEPNR=1 observation.

-TYPE30_5 dataset, those job-related variables will now be

missing if TYPETASK IN ('STC','OMVS'), as they are not

"jobs that are initiated".

-No changes were made to BUILDPDB code; those variables

are summed from their TYPE30_5 observation(s) into the

PDB.JOBS dataset, so they will be non-zero if variable

INBITS contains a "J" in the third character, indicating

that a 30-5 job termination was found for this job.

-Variable SMF30PF2, flag byte 2 is now kept.

-Jobs run under CA's JobTrack control have zeros for these

variables in their type 30-5 record, even though they are

non-zero in step records, but it is not JobTrack's error.

We now find that ANY job that has a flushed last step has

zero values for SMF30HQT/JQT/RQT/SQT in the job's SMF 30

subtype 5, even when the step records have non-zero

values; JobTrack showed up because it adds a non-executed

step at the end of every job under its control for

tracking information! The zero values, I believe, are an

IBM error in failing to propagate the values when the

last step is flushed, and a problem report will be opened

with IBM; this note will be updated when IBM replies.

Thanks to Bret Hoesly, TDS, USA.
Change 22.020 The example to create only DB2ACCT.DB2ACCT & PDB.DB2STATS

ADOCDB2 fails with ERROR: FILE WORK.SUMSTATB DOES NOT EXIST. The

Mar 2, 2004 redesign in Change 21.140 moved the interval statistics

for buffers into DB2STATB, which is now required as input

to create the desired PDB.DB2STATS summary dataset. The

example now creates DB2STATB, DB2STAT0, and DB2STAT1 so

PDB.DB2STATS can be created, but they are written to the

//WORK file, so only the two desired datasets are kept.

//SYSIN DD *

%LET PDB2ACC=DB2ACCT;

%LET PDB2ST0=WORK;

%LET PDB2ST1=WORK;

%LET PDB2STB=WORK;

%LET MACKEEP=

%QUOTE(

_NDB2

MACRO _WDB2ACC _LDB2ACC %

MACRO _WDB2ST0 DB2STAT0 %

MACRO _WDB2ST1 DB2STAT1 %

MACRO _WDB2STB DB2STATB %

MACRO _SDB2 _SDB2STB _SDB2STS %

MACRO _SDB2ACP %

MACRO _SDB2ACB %

MACRO _SDB2ACG %

MACRO _SDB2PAT %

MACRO _SDB2ST2 %

MACRO _SDB2STR %

MACRO _SDB2PST % );

%INCLUDE SOURCLIB(TYPSDB2);

RUN;

Thanks to John Croasdale, Abbey National, ENGLAND.
Change 22.019 -Variables STARTIME and DURATM are now created in each of

VMAC119 the 119 interval statistic datasets, TYP11905, TYP11906,

Mar 3, 2004 TYP119A7, and TYP119B7. There are four duration variables

in TYP11905, but all have identical values in test data,

so DURATM is set to the MAX of the four variables. Some

labels were revised and misspellings corrected. All other

TYP119xx datasets are events, rather than intervals, so

they don't contain the STARTIME/DURATM pair.

-Variable TCDURTM and UDDURTM are now divided by 4096 vice

by 496.

-Protective double question mark modifiers were inserted

before the two &NUM.3. inputs for FCLREPLY and FSLREPLY.

Thanks to Chris Weston, SAS ITRM, USA.
Change 22.018 All references to the "SPIN" DDNAME/LIBNAME have been

ASUMTALO replaced with macro variables &SPININ or &SPINOUT, so

ASUMTAPE that input and output can be separate MVS datasets. As

BUIL3005 both macro variables default to "SPIN", this should be a

BUILD005 transparent change. This enhancement is needed by sites

JCLUOWP that run their MXG jobstream under CA's Job Scheduler,

JCLUOWV which requires separate datasets for its recoverability.

SPINSORT To use this enhancement, you would change your JCL to

VMACFRYE // EXEC MXGSASV9

VMXGINIT //SPININ DD DSN=OLDSPIN,DISP=SHR

VMXGRMFI //SPINOUT DD DSN=NEWSPIN,DISP=(,CATLG),...

VMXGUOTT and put your %LETs either in //SYSIN or in IMACKEEP:

VMXGUOW %LET SPININ=SPININ;

VMXGUOWT %LET SPINOUT=SPINOUT;

Mar 2, 2004 -These VMXGRMFI temporary datasets that should have been

deleted, now are:

MERGERMF SORINTRV MSU4HRAV SPUNRMFI MSU4HRMR

MERGEMSU MERGESOR SPUNRMFI

-Typo'd member named VMAGUOTT was discovered and deleted.
Change 22.017 FLASH: BUILDPDB (only-under"MVS") runtime elongation can

VGETENG be significant IF any output libraries (like CICSTRAN or

VMXGRMFI DB2ACCT) are on tape or in sequential format on DASD.

VMXGSUM This problem does NOT affect ITRM's normal job, because

VMXGSUME %CPPROCES/CMPROCES puts everything in //WORK, and ITRM

Mar 2, 2004 doesn't use tape libraries during its "BUILD".

Mar 12, 2004 This problem was introduced in MXG 19.19, when %VGETENG

was added in VMXGRMFI, to test if a //SPIN DD existed.

VMXGRMFI is called by RMFINTRV, which is automatically

included in MXG's BUILDPDB. If you do NOT use tapes for

output in your BUILDPDB job, you don't have this problem.
The PROC SQL with FROM DICTIONARY.MEMBERS in VGETENG gets

the ENGINE of //SPIN, but no WHERE LIBNAME=SPIN clause

was used, so the PROC SQL had to read all LIBNAMEs to

populate the DICTIONARY.MEMBERS table. If your CICSTRAN

and DB2ACCT are both multi-vol on tape, you would have

these mount messages on the BUILDPDB's job log:

hh:mm-hh:mm

SMF Opened, read started 14:25

CICSTRAN Mount-Dismount 5 vols 14:24-16:06

DB2ACCT Mount-Dismount 2 vols 14:24-15:25

SMF Closed, read completed 16:12

VGETENG-remount/read 2 DB2ACCT vols 16:17-16:30

VGETENG-remount/read 5 CICSTRAN vols 16:40-17:09

Total Elapsed time: 164 minutes with re-read.

VGETENG wasted 52 minutes, mounting and reading the seven

tapes! For DASD data libraries, PROC SQL only has to

read the directory of SAS datasets in that library, but

for sequential format libraries, PROC SQL has to read the

entire sequential file, because tape format libraries do

not have a directory of datasets.

And PROC SQL doesn't print any message on the SAS log to

tell you it was the cause of the extra CICSTRAN & DB2ACCT

mounts. The only clue to the elongation are those extra,

and unexpected, tape mount messages on the job's SYSOUT!

Elapsed and CPU time, and EXCPs of your daily job can be

reduced significantly, if you use tape output on MVS in

your BUILDPDB job, with either circumvention:

Immediate circumvention, any of the three fixes:

1. Replace MXG 21.21 with MXG 22.01, now available.

See text of Change 22.017 for lots of details.

2. Change the JCL:
Add ,FREE=CLOSE to the //CICSTRAN and //DB2ACCT and

to any other output DDs that are on tape/seq format.

3. Or, change the MXG source code:
a. EDIT/CREATE member EXPDBOUT in USERID.SOURCLIB

tailoring library, and add a statement:

LIBNAME CICSTRAN CLEAR;

LIBNAME DB2ACCT CLEAR;

for each tape (or sequential format) DDNAME.
b. Or do the same in your //SYSIN stream, using:
//SYSIN DD *

%LET MACKEEP=

%QUOTE( MACRO _EPDBOUT

LIBNAME CICSTRAN CLEAR;

LIBNAME DB2ACCT CLEAR;

%

);

%INCLUDE SOURCLIB(BUILDPDB);

....rest of job....

Discussion of the circumventions:
- Using FREE=CLOSE. This appears to always be safe.

The FREE=CLOSE occurs when CICSTRAN/DB2ACCT/etc are

closed, at the end of reading the SMF file, so PROC SQL

in VMXGRMFI won't see those sequential LIBREFs so they

won't be read. But even if your job does then %INCLUDE

any of the ASUMCICx, ASUMDB2A, or ASUMUOW members that

read those data libraries, SAS is still able to re-open

the LIBREF that was FREE=CLOSEd, without any error.

Like magic!

And using FREE=CLOSE on //SMF DD seems always wise and

courteous, so the device can be available to another.
- Using LIBNAME xxxxxxxx CLEAR; in EXPDBOUT also appears

to be completely safe. EXPDBOUT is a little later than

the close of the SMF file, after a few PROC SORTs, but

the CLEAR closes the LIBNAME so PROC SQL in VMXGRMFI

never sees those LIBNAMES to read, but the allocation

can be re-opened, if, for example, you %INCLUDE any of

the ASUMxxxx's that read DB2ACCT or CICSTRAN.
- With either circumvention, harmless messages are on the

SASLOG for each DDNAME, at deallocation time:

NOTE: DATASET XYZ HAS NOT BEEN DEALLOCATED BECAUSE

IT WAS ALLOCATED EXTERNALLY

NOTE: LIBREF XYZ HAS BEEN DEASSIGNED
- The circumventions do not have to be removed when you

install an MXG Version with this change.

- The choice of changing JCL or MXG source depends only

on whichever is easier to do within your production

change control system for your MXG daily jobs!

Permanent Changes made in this change:

a. VMXGRMFI. The permanent correction in this change:
- %VGETENG(DDNAME=SPIN) and ENGINE logic was removed.

- If you execute VMXGRMFI/RMFINTRV by itself, a //SPIN

DD is now required; you'll get an obvious SAS error

if you don't have one.

The test that caused this problem was added only to

prevent an abend that might happen, only if you used

RMFINTRV in a standalone job. RMFINTRV is normally

created by BUILDPDB, and a //SPIN DD has always been

provided in JCLPDBxx examples, but when the MSU4HRAV

variable was created in PDB.RMFINTRV, the history of

the last four hours was to be "spun" in SPIN.SPINRMFI

if a //SPIN DD was found. But if you ran RMFINTRV in

a standalone job that didn't have a //SPIN DD, the

MSU change would cause your "running just fine" daily

job to fail. So the VGETENG and associated logic was

added in VMXGRMFI in MXG 19.19 to protect no //SPIN.

Unfortunately, even that was also wrong. The PROC SQL

with DICTIONARY.MEMBERS sees only LIBNAMEs that are

OPEN, and BUILDPDB has not OPENed the SPIN library

when RMFINTRV is called, VGETENG set ENGINE=UNKNOWN

and so SPIN.SPINRMFI has never been created; only the

WORK.SPINRMFI has been output, and then deleted!

Fortunately, the only impact is that MSU4HRAV in

PDB.RMFINTRV has missing values for the first four

hours of each day. But since you have been wisely

using the PDB.ASUM70PR/ASUMCEC/ASUM70LP LPAR data

to measure and report "MSU" capacities, you have

never noticed nor used MSU4HRAV in PDB.RMFINTRV.

It was added for convenience when looking at a

single SYSTEM in RMFINTRV data.

Now, SPIN.SPINRMFI will always be created.
b. VGETENG: Permanent change, but VGETENG is NOT used in

VMXGRMFI with this change. Read carefully.

You can heal VGETENG's missing WHERE clause problem

by copying the member VMXGENG into member VGETENG,

and then CHANGE "VMXGENG" "VGETENG" ALL. The old

VMXGENG member does have the needed WHERE clause.

However, even with a WHERE clause, if the DDNAME is a

sequential format library, PROC SQL still must read

all of that (one) data library. And if it happens to

be a multi-volume, extended format, striped, and DASD

hardware compressed dataset; it will take time and

there won't even be mount messages to account for the

wasted time.
The VMXGENG member worked fine with its WHERE clause,

but when I standardize macro/member names that "GET"

a value to start with VGET instead of VMXG prefix, I

got a VGETENG without the WHERE clause. We would not

be having this pleasant conversation if I had used

%VMXGENG in VMXGRMFI in place of the new %VGETENG.

But since the %VGETENG is not removed from VMXGRMFI,

it really doesn't matter, now.

c. VMXGSUM, VMXGSUME: A very minor exposure to delay.
If you created your own %VMXGSUM execution that uses

TEMP01=, TEMP02=, TEMP03= arguments (DDNAMEs for temp

workspace), a PROC SQL; FROM DIRECTORY.MEMBERS is

used to find the engine, which was then set to VnSEQ,

if the fall-thru case of UNKNOWN engine is found, so

that an extended-format, hardware compressed, striped

file can be used, if that's in the DATACLAS/STORCLAS.

Since this PROC SQL does have the WHERE clause, only

the one TEMPnn DD would be read, but it would be read

once for every %VMXGSUM invocation.

But because the primary reason for TEMPnn= arguments:

to circumvent limitations back in SAS Version 6

for multi-volume temporary disk data libraries

was eliminated by SAS V8 multi-volume support, I have

removed this exposure by removing the PROC SQL and

logic for ENGINE in the VMXGSUM members. If you are

bright enough to use those specialized files that

require a sequential engine, that I believe you are

also bright enough to know that you need to add a

LIBNAME TEMPnn VnSEQ;

in your program before your %VMXGSUM invocation.

Especially since SAS will tell you if is needed!

d. Two other MXG "utility"s use FROM DICTIONARY.MEMBERS:

- VGETDDS, which you would use ahead of VMXGSET to

read multiple SAS libraries for the same dataset.

- VGETDSN, which returns the MVS DSNAME of a SAS data

library.

As both members have WHERE clauses for the LIBNAME,

so only one library would be read in any case, and as

both are optional and unlikely to be used during the

BUILDPDB process, they remain unchanged.

Thanks to Jim Poletti, Edward D. Jones, USA.

Change 22.016 The ANALSRVC report still had BY SYSTEM STARTIME for the

ANALSRVC RMF sort order, and failed with RECORDS OUT OF ORDER;

ANALPGNS BY SYSPLEX SYSTEM STARTIME has been the RMF sort order

ANALSTOR for years, but these examples had not been updated until

ADOCPDB now.

ACHAP35

XPRSMSUM

Mar 1, 2004

Thanks to Dave Crowley, Blue Cross Blue Shield of Florida, USA.
Change 22.015 Cosmetic. White space was inserted after single quotes

ANALDB2R to eliminate the SAS Version 9.1 " 49 " Warning message.