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

Change 23.181 -DB2ACCTP, Package Data, was still wrong for new DB2 V8.1

VMACDB2 IFCID=239 record with LENQPAC=0 and more than one package

Jul 17, 2005 segment. The INPUTed LENQPAC at the beginning of each of

Aug 12, 2008 those segments does not include its own length, so a new

LENxxxx=LENxxxx+2; statement had to be added to each of

of the adjustment DO groups invoked when LENxxxx=0. The

text of Change 23.140 was revised to show new statement.

-For DB2 V7.1 and later, variables QBACxxxx and QTXAxxxx

are always missing in DB2ACCTP package data; those

variables only have values in the DB2ACCT dataset.

MXG logic for the IFCID=0003 record prior to V7.1 had

incorrectly input the QBAC and QTXA fields before the

loop across each of the OFFQPAC segments. Re-locating

the QPAC segment to be processed before the other

segments now correctly causes those sets of variables to

be always missing in DB2ACCTP.

Note: the text in this paragraph was completely wrong

prior to Aug, 2008, but the QBACxxxx,QTXAxxxx

variables have ALWAYS been missing values i

the DB2ACCTP dataset, in spite of that text,

now revised.

-It was noted that in the DB2 V8.1 DB2ACCTP IFCID=239 data

that QWACBSC and QWACESC are both missing, making it less

easy to match the DB2ACCTP back to it's DB2ACCT obs.

-Missing value calculation for QGBAXN eliminated, but that

variable is now always missing; instead, use QBGAEX.

Thanks to Victoria Lepack, Aetna, USA.
Change 23.180 DATETIME logic had incorrect word numbers for the SCAN of

VMACPRPR YYYY and SS, now corrected.

Jul 8, 2005

Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.

Change 23.179 Variables VSRNBYTR and VSRNBYTW in dataset HSMVSRFU were

VMACHSM way too small, as their value in the record was in KB but

Jul 8, 2005 their label indicated bytes. They are now multiplied by

Jul 11, 2005 1024 to convert their value to bytes, and are formatted

with MGBYTES format to "print pretty". These variables

FSRBTTR FSRBTTW FSRDBYTR FSRDBYTW FSRTBYBK FSRTBYTR

FSRTBYTW DSRBYTR DSRBYTW

that contain bytes in both their values and labels are

now also formatted with MGBYTES for consistency.

However, these storage-value variables:

DSRNGBR ='GIGABYTES*READ'

DSRNGBW ='GIGABYTES*WRITTEN'

VSRTOTKB='TOTAL*CAPACITY*OF VOLUME (IN KB)'

are NOT converted to bytes, and are NOT formatted MGBYTES

because they agree with their labels, and changing their

internal value to bytes could impact existing reports.

Life is filled with compromises when you don't make the

correct first choice!

Thanks to Robert Chavez, Office Depot, Inc, USA.

Thanks to Chuck Hopf, MBNA, USA.

Change 23.178 Variable PARTISHN was not labeled in dataset TYPE73, so

VMAC73 it was also unlabeled in dataset TYPE73OE.

Jul 8, 2005

Thanks to Chuck Hopf, MBNA, USA.

Change 23.177 ML-34 of ASMTAPEE and the HSC exit are production status!

ASMHSCEX Beta Tests with the new HSC exit uncovered some minor

VMACTMNT errors that are now corrected, but the exit works fine to

Jul 3, 2005 capture all HSC-controlled tape mounts, just like the IBM

Jul 11, 2005 Volume Mount Exit, previously implemented in ML-34, works

to capture all IBM-controlled tape mounts. Sampling is

no longer used to detect tape mounts, so none are missed.

As currently implemented, ASMHSCEX supports only a single

HSC or CSC, but now that we are aware that both products

and even multiple copies of HSC and/or CSC can exist, we

are investigating how to support those environments, and

will have a revised ASMHSCEX for those installations.

-Primary correction was in ASMHSCEX, which populated the

JOB file with the JCTJOBID value instead of JOB name.

-But because JCTJOBID=JOB, the MXG logic to create JESNR

from the JCTJOBID caused JESNR to be missing:

JOB=JCTJOBID is a valid condition for "early ASID" STCs

the don't have a "JESNR".

-And beta tests exposed MXG errors in VMACTMNT that caused

INITTIME and PROCSTEP to be missing/blank.

-With this Change, ML-34 is now ready for production use.

Thanks to Steve Martin, Fidelity Systems, USA.

====== Changes thru 23.176 were in MXG 23.06 dated Jun 29, 2005=========
Change 23.176 -Support for SMF 6 ESS GEPARMKY='04D'x with more than one

IMAC6ESS segment creates ESSMAIL3 and ESSMAIL4 variables. Caused

VMAC6 INPUT STATEMENT EXCEEDED error.

Jun 29, 2005 -Support for SMF 6 ESS GEPARMKY='04B'x creates ESSMFILE.

-Support for SMF 6 ESS GEPARMKY='04E'x creates ESSRPLY2.

Thanks to Engelbert Smets, Provinzial, GERMANY

Thanks to Cornelia Opel, Provinzial, GERMANY
Change 23.175 Support for SMF 22 Subtype 11 I/O Configuration Change

EXTY22UA creates new dataset:

IMAC22 dddddd Dataset Description

VMAC22 TY22UA TYPE22_A I/O Configuration Change

VMXGINIT

Jun 28, 2005

Thanks to Shane Dowling, DEWR, AUSTRALIA.
Change 23.174 Change 18.338 created the _Vdddddd macro definitions, but

VMACMVCI not all MXG code members have been revised to create that

Jun 27, 2005 token. This change creates _VMVCICS and _VMVCICF in the

VMACMVCI member.

Thanks to David Edge, Thomson BETA Systems, USA.
Change 23.173 Using TYPEHSM, datasets HSMWWFSR and HSMWWVSR were not

DIFFHSM sorted into the //PDB library, because TYPEHSM included

Jun 24, 2005 the DIFFHSM member, which had separate _Sdddddd sorts

for each dataset, but DIFFHSM had not been updated to add

sorts for those two datasets. Using TYPSHSM, those data

were sorted into the //PDB, because it invoked the _SHSM

product sort macro, which does list all HSM datasets.

The DIFFHSM member is revised to use the _SHSM member.

Normally, TYPExxxx members leave all of their datasets

in the //WORK file, while the TYPSxxxx members sort all

of the xxxx products datasets into the //PDB library.

But when there are accumulated data in the product, the

TYPExxxx member always will invoke the sort into //PDB

to de-accumulate that dataset, and HSM writes SMF data

with accumulated values, so both TYPEHSM and TYPSHSM

now produce identical results.

Thanks to Ian Arnett, TD Canada Trust, CANADA.

Thanks to Luc Audet, TD Canada Trust, CANADA

Change 23.172 -SAMS POOLS record was INCOMPATIBLY CHANGED in 002053V4 by

VMACSAMS increasing NRVOLS field from 4 to 6 bytes, causing all of

Jun 24, 2005 the variables to the right to have wrong values. With the

Jul 20, 2005 help of CA Technical Support to provide the DSECTS of the

Jul 30, 2005 SMF record, MXG code for POOLS was corrected and revised:

-The SAMS Version is used, rather than the circumvention

to test LRECL, to detect the longer NRVOLS field.

-Data in SAMSFBYX/TBYX/VBYX/LBYX were wrong because those

four fields are packed decimal, not binary values, and

MXG was using the incorrect informat for them.

-New in 002053V4 variables SAMSPALL & SAMSBALL are input.

-New in 002053V5 variables SAMSESA/ESB/ESC describe the

storage group in three lines of text.

-Support for 002053V6 was revised and valided Jul 30; the

V6 record's POOLS record was completely restructured.

-Variable SAMSJOBN was removed from the KEEP= and LABEL

statements, as there is no "JOB" name field in SAMS SMF.

Thanks to Abily Christelle, GICM, FRANCE.

Thanks to Patrick Notteghem, CA, FRANCE.
Change 23.171 -Variable LOCLINFO is INPUT $EBCDIC8, which works fine if

VMAC30 SMF30UID contains text or hex characters on z/OS, but if

Jun 24, 2005 executed on ASCII, that INPUT statement changes any hex

characters. The only solution for ASCII execution is to

create a second variable, LOCLINCH, INPUT as $CHAR8 and

FORMATed $HEX16. so any non-text characters in that field

are preserved, and available in the EXTY30Un exits.

-Missing value calculations when SMF30IST was missing were

eliminated; SMF30IST only exists in subtype 2, 3, and 6.

Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.

Change 23.170 Character Variables formatted with $MGdddxx formats that

VMAC102 were NOT in a LENGTH $1 statement were stored in LENGTH

VMAC110 of the maximum text in the $MGdddxx format values, which

VMAC74 wasted disk space. Now, all character variables with $MG

VMAC84 format names have been identified, and added to a LENGTH

VMAC85 statement if needed to reduce their stored length.

VMAC92 VMAC110: DS2TCBMD-DS9TCBMD DSaTCBMD SORSSLFL

VMACAIM6 VMAC74: R744QFLG

VMACBE91 VMAC84: JMFJSJSR

VMACBE97 VMAC85: R85ODT R85OVT R85TVT

VMACCIAO VMAC92: SMF92MFG SMF92UFG

VMACEDGR VMACAIM6: IOCTYPE

VMACFTP VMACBE91: BE91STP

VMACHIOM VMACBE97: B970OBT

VMACHURN VMACCIAO: CIAOETYP

VMACNSPY VMACEDGR: RDVRSTYP RRTYPE2 RSTYPE2

VMACOMDB VMACFTP: DVGSCOMP DVGSRPNT DVGSRTYP

VMACOMSM VMACHIOM: HIOOSTYP

VMACQACS VMACHURN: HU62UMOD HU62UTYP

VMACSAR VMACNSPY: NSPYRTPS

VMACSARX VMACOMDB: QMDAPTYP QPACAAFG QWHSRMID

VMACSPMS VMACOMSM: OMDEVMDL

VMACSYSV VMACQACS: ETLPRCL JBSTYP SCPRCL SHPRCL STPRCL

VMACTIE VMACSAR: SARPMDX

Jun 20, 2005 VMACSARX: GCRPMDX

Jul 21, 2005 VMACSPMS: SPMSRLS

VMACSYSV: TRANTYPE

VMACTIE: TIELOG

Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.169 Support for additional SMF 99 Subtype 2 data segments.

EXTY99Q2 -These variables added to TYPE99_2 dataset:

EXTY99R2 PCADP ='CURR*ACHIEAVABLE*DEMAND*PCT'

EXTY99S2 PESCS ='ASIDS*EXPLICIT*STORAGE*CRITICAL'

EXTY99V2 PGRIN ='GROUP*NAME'

FORMATS PIFAD ='IFA*DELAY*SAMPLES'

IMAC99 PIFAU ='IFA*USING*SAMPLES'

VMAC99 PIFLAG ='FLAGS'

VMXGINIT PSAMHST ='SAMPLE*HISTORY*ROWS*USED'

Jun 22, 2005 PSBCPUD ='SAMPLE*BASED*CPU*DELAYS'

PSBCPUU ='SAMPLE*BASED*CPU*USINGS'

PSBIOD ='SAMPLE*BASED*I/O*DELAYS'

PSBNIOD ='SYSPLEX*WIDE*NON I/O*DELAYS'

PSPMDP ='MINPCT*PROCTIME*DEMANDED'

PSWCPUU ='SYSPLEX*WIDE*CPU USING*SAMPS'

PSWCT ='SHORT*WAIT COUNT*ACCUMULATE'

PSWIDLE ='SYSPLEX*WIDE*WIDE IDLE*SAMPS'

PSWNONI ='SYSPLEX*WIDE*NON-IDLE*SAMPS*

PSWOTHR ='SYSPLEX*WIDE*OTHER*SAMPS'

SMF99SCI='SERVICE*CLASS*INDEX'

-New datasets are created from subtype 2 segments:

dddddd Dataset Description

TY99R2 TYPE99R2 99-2-Q REMOTE QUEUE DATA

TY99Q2 TYPE99Q2 99-2-Q QUEUE SERVER DATA

TY99S2 TYPE99S2 99-2-S SERVER SAMPLE DATA

TY99V2 TYPE99V2 99-2-V SERVER DATA

Thanks to Chuck Hopf, MBNA, USA.
Change 23.168 Cosmetic. Blanks in SMF6TARG (IP Address) are removed.

VMAC6

Jun 21, 2005

Thanks to Thomas Peiper, Tietoenator, SWEDEN.

Change 23.167 The Installation Data field, INSTDATA, was inconsistently

VMACRACF input as $200 with +55, or $40 with +215, and variables

Jun 21, 2005 OMVSHOME, OMVSPROG, USRDATA, and APPLDATA did not input

their full $255 byte field. The $200 was the SAS V6

limit for character variables, but I've been reluctant to

change those inputs to $255, because that would cause an

avoidable ABEND with V6, and besides, is there really

anything in those last 55 bytes that is needed? However,

since this RACF Unload utility code didn't exist when SAS

V6 was The Thing for MXG years ago, I've chosen to

increase all these variables to input and be stored as

$255, and hope no V6 sites try to use this support! Some

MXG members are already documented as requiring SAS V8

(like records with UCS data, for example), but the few

sites that I know are still on V6 are not their by their

own choice, so I'll try to protect the really important

SMF records, until a real need arises.

Thanks to Len Rugen, State of Missouri, USA.

Change 23.166 -Fields were added to CMRFILE, probably Version 5.6, but

VMACMVCI there is no length-of-file-segment field in the CMRDETL

Jun 21, 2005 record, so the new fields were overlooked, causing trash

values in the second and subsequent file segments in each

CMRDETL record with more than one file segment.

New variables are created and kept in CMRFILE dataset:

T6EF1='RNU*COUNT' T6EF2='RPU*COUNT'

T6EF3='RWD*COUNT' T6EF4='REDSET*COUNT'

T6EF5='RDUSET*COUNT' T6EF6='RNXSET*COUNT'

T6EF7='RPVSET*COUNT' T6EF8='RNUSET*COUNT'

T6EF9='RPUSET*COUNT' T6ET1='RNU*TIME'

T6ET2='RPU*TIME' T6ET3='RWD*TIME'

T6ET4='REDSET*TIME' T6ET5='RDUSET*TIME'

T6ET6='RNXSET*TIME' T6ET7='RPVSET*TIME'

T6ET8='RNUSET*TIME' T6ET9='RPUSET*TIME'

T6ETA='READ*TIME' T6ETB='RDU*TIME'

T6ETD='WRT*TIME' T6ETE='RWT*TIME'

T6ETG='DEL*TIME' T6ETH='UNK*TIME'

T6ETJ='SBR*TIME' T6ETK='RNX*TIME'

T6ETL='RPV*TIME' T6ETM='EBR*TIME'

T6ETO='RBR*TIME' T6ETP='OTH*TIME'

T6ETQ='FCTOT*COUNT' T6ETR='FCTOT*TIME'

T6ETS='FCWAIT*COUNT' T6ESR='SRECS*COUNT'

-T6EV1,T6EV2,T6EV3 are protected for hex zeros for Volume

Serial Numbers; T6EV3 contains hex values in byte 4 that

are changed to blanks by MXG.

-Variable TFILI was kept as $27, because it was assigned

the $MGMVICT format without also being set to the $1

length in a LENGTH statement. Variables that are assigned

an MXG-built character format will have the length of the

longest value statement, if their length is not fixed in

a LENGTH statement; this was overlooked, but we'll add a

new report to detect any other cases of wasted space.

-Variable SYSTEM was always blank; it was only populated

in Version 5.3 records, but now it is populated from the

T6ESMFID SMF TYPE field.

-These variables are now set to blank if they contained

hex zeros:

T6EBMSN T6ECMP53 T6EOPID T6EPSBN T6ERPTCL T6ETMID

T6EAUTH T6ECORR

-However, when T6EBMSN starts with "CSMI" in EBDCIC4., the

last four bytes are non-printable ('1C796A00'x) which may

be trash left over, or may be actual "data" for the BMS

Map Name. I've chosen to detect these and store only the

"CSMI " back in T6EBMSN, and have stored the last four

hex bytes in new variable T6ECSMI until we have an answer

from the vendor as to why that field has mixed EBCDIC and

HEX when it starts with the mirror transaction name CSMI.

Thanks to David Edge, Thomson BETA Systems, USA.
Change 23.165 New MGFMTVR identifies which MXG Version's FORMATS member

FORMATS was used to create the format library pointed to by the

Jun 21, 2005 //LIBRARY (or LIBRARY LIBREF). Using this program

DATA _NULL_; FMTVERS=.; PUT FMTVERS MGFMTVR. ;

will print, on the SAS Log:

MEMBER FORMATS FROM MXG 23.05 CREATED YOUR MXG FORMATS.

Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 23.164 Additions in WAS Version 6.01, support for PQ96114 and

FORMATS MXG errors are corrected:

VMAC120 -MQ Series variable SM120CSO has new values of 5 and 6:

Jun 21, 2005 now decoded by the MG120CO format:

5:HTTP SESSION and

6:HTTP ENCRYPTED SESSION

-MQ Series variable SM120JB3 has overlooked values 4,5 and

a new value of 6 now decoded by MG1203B format:

4='4:BMP ENTITY BEAN'

5='5:CMP ENTITY BEAN'

6='6:MESSAGE DRIVEN BEAN'

-Variables SM120JHF and SM120JHT are now correctly input

as &PIB.8 instead of &PIB.4. JHF was always zero, and

JHT contained the value of JHF when they were wrong.

Thanks to Martyn Jones, Euroclear, BELGIUM.

Thanks to Phil Downes, Euroclear, BELGIUM.

Change 23.163 INVALID ARGUMENT FOR INPUT FUNCTION because SyncSort has

VMACSYNC a new and unexpected value of 'SMS' for ths UCB Address.

Jun 18, 2005 'SMS' is now tested to circumvent the error message.

Thanks to Jim Dammeyer, State Farm Insurance, USA.

Change 23.162 ML-34 of MXG Tape Mount Monitor provides ASMHSCEX member

ASMHSCEX that you assemble to create an HSC SLSUX01 user exit that

ASMTAPEE your HSC guru then installs in HSC, so that all of the

Jun 15, 2005 HSC-controlled mounts (STK VTS or STK Silos) will be

Jun 22, 2005 captured by exit (event-driven), instead of by sampling.

(Sampling, even at .5 seconds missed a lot of the very

fast VTS mounts; using an exit captures 100% of them.)

The STKX option tells MXGTMNT to use the HSC exit, like

the MXIT option in ML-31 used the IBM Volume Mount Exit;

the difference is that you have to install the HSC exit,

while IBM's exit was already there! With MXIT and STKX

enabled, all mounts to real drives, all IBM VTS mounts,

and (finally!) all HSC-controlled mounts are captured!
The SLSUX01 exit, created by assembly of the ASMHSCEX,

itself can be used in one of two ways, depending on your

site's current use of the STK HSC exit, and you control

which way via the SYSPARM input during assembly. If your

site does not currently use the STK HSC exit, SYSPARM(N),

which is the default, results in just the MXG replacement

exit code being assembled. But if your site does use the

HSC exit, specifying SYSPARM(Y) at assembly of ASMHSCEX

will cause MXG code to include your existing exit code

during the link edit step that creates the exit module.

Then, when MXG's exit is subsequently defined to HSC, our

exit will invoke your exit as if we weren't there, then

we'll do our thing to collect the necessary data and pass

that to the TMNT address space. This is well documented

in the ASMHSCEX comments, but please let us know if the

instructions need clarification or improvement.

You can assemble ASMTAPEE member to create the MXGTMNT

program load module before you assemble ASMHSCEX to

create the MXG SLSUX01 HSC exit, or vice versa; there is

no forced order for installation, and enablement of

MXGTMNT can occur in any order.
The implementation of the MXG HSC Exit is quite robust:

- it is essentially a NOP if it detects MXGTMNT is not

enabled or is not running, or, conversely,
- if MXGTMNT is enabled, but the exit is not there, the

environment exists to support the exit, but nothing

will happen until the exit is running.
We believe HSC 5.1 and HSC 6.0 versions are supported,

based on STK documentation; it might also work with 5.0,

but we don't have enought information from STK to confirm

if that is true, and, besides, 5.0 is archaic!

You can only specify STKX=YES at assembly or start-up of

the monitor; you cannot start the monitor and then use

a command to turn on STKX later; that might be added in

the future, but it would have delayed delivery of this

release.
We have Alpha tested this code as thoroughly as we can,

and we have NEVER caused a system outage with any ML of

the monitor, but since we don't have a Silo or VTS on our

test system, we ask that you ONLY test ML-34 on an HSC

test system that can afford to be "crashed", before you

use it on an real system. When we have more feedback

from Beta test sites, this text will be revised to

confirm successful tests at real sites.

a. Jun 22 update:

-First test of the HSC Exit did not succeed but it did no

harm: on the first mount after initializing the monitor

and exit, the user exit ABENDed with S978, and then it

disabled itself; tape mount processing then proceeded as

usual without the exit. [e-mail] examined the dump

and the listing of the assembly of the HSC exit and

corrected a "dumb mistake, bad branch" error in ASMHSCEX,

now dated Jun 22, 2005.

-An IBM-only site raised three question,:

1. Why do I get STKX=NO in the monitor output while I

have 'OPTIONS2 DC AL1(DOARCV+DOMXIT+DOSTKX) in the

assembler code:

asmguy answer ==>

Because I forgot to add code to change the STKX=NO to

STKX=YES if the code is modified to turn this on

instead of using input parms. This is a tough one for

me to remember since it's counter to the way I think

and I always use parms when I test so I don't catch

these things. Anyway, I'll correct it.

2. What does 'MXGC003I MXG STK MOUNT EXIT MONITORING

ENABLED' mean?

asmguy answer ==>

This is a message that indicates the environment

necessary to support the STK exit has been enabled in

MXGTMNT as a result of STKX=YES.

3. Do I need XMem at all?

Barry's answer ==>

XMEM is still needed to get the job-related fields in

the TYPETALO allocation records, at least for now, as

they are independent of the mount records. But I plan

to examine if I need to revise ASUMTAPE to use the new

exit-driven mount records to populate TYPETALO info,

once we've got the monitor working and I've got some

SMF data from a site with both IBM and HSC mounts.

b. Jun 24 update:

-For HSC, you may need to create exit SCSUX01 instead or

in addition to the SLSUX01 exit, depending on the HSC

interface your site uses. SCSUX01 is required if CSC is

used for remote access to the robot and VSMs, which may

be all that's available on your test system. SLSUX01 is

used for local access. Changing all SLSUX01 to SCSUX01

in ASMHSCEX and reassembling worked just fine, but we can

create a new SYSPARM option for ASMHSCEX that will create

both HSC and CSC exits in the same member.

c. Jun 28 update:

No errors have been reported by two sites successfully

using ML-34 and the new HSC exit. I'm awaiting test data

to update the ASUMTAPE program, but that won't happen

until late July, after some vacation time.

Thanks to "[e-mail]".

Thanks to Paul Naddeo, FiServ, USA.

Thanks to Jeff Holst, FiServ, USA.

Thanks to Normand Poitras, IBM Global Services, CANADA.

Change 23.161 Comments said PDB.TYPE73OE dataset would be created, but

ANALFIOE the code created WORK.TYPE73OE; this change creates the

Jun 15, 2005 old style MACRO _LANFIOE PDB.TYPE73OE % so the default

dataset will be PDB.TYPE73OE, but also so that you could

change the DD or Dataset name using MACKEEP/IMACKEEP.

Thanks to Chuck Hopf, MBNA, USA.

Change 23.160 New variables added to T102S106 dataset:

VMAC102 QWO4ADM2='OFF*SYSTEM*ADMIN ID2'

Jun 14, 2005 QWO4DFID='OFF*SYSTEM*DEFAULT*USER ID.'

QWO4OPR1='OFF*MVS*OPERATOR ID'

QWO4OPR2='OFF*MVS*OPERATOR ID2'

QWO4OZUS='OFF*ONLINE*ZPARM*USERID*MONITOR'

QWO4REGA='OFF*DDL REG*ART NAME'

QWO4REGC='OFF*DDL REG*TABLE OWNER'

QWO4REGO='OFF*DDL REG*ORT NAME'

QWO4SADM='OFF*INSTALL*SYSADMIN*USERID'

QWP4CONT='CONTRACT*CT*LONG*STORAGE*POOL?'

QWP4CRVW='DBA CAN*CREATE*VIEW-ALIAS*FOR OTHERS?'

QWP4DCFS='SMS*DATACLASS*FILE(DATA)*TABLESPACE'

QWP4DCIX='SMS*DATACLASS*INDEX*TABLESPACE'

QWP4DSMX='MAXIMUM*NUMBER OF*DATASETS'

QWP4EDBC='EDM*POOL*DBD*CACHE SIZE'