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

MXG Dataset TYP120CI.
And IBM APAR OW44456 requires the following doc changes:

Periodically, IBM refreshes documentation on our Web

site, so the changes might have been made before you

read this text. To access the latest on-line

documentation, go to the product library page at:

www.ibm.com/software/webservers/appserv/library_390.html

And support provides a new edition:

Document Name: WebSphere Application Server Enterprise

Edition for OS/390 Operations and Administration

Document Number: GA22-7328-01

The new edition contains a chapter (Chapter 9) that

explains how to set up and use the new SMF recording

support and an appendix (Appendix A) that describes

the new SMF record type 120.

To get the new edition, go to our Web site at:

www.ibm.com/software/webservers/appserv/library_390.html

IBM support also requires changes to existing doc:

Document Name: WebSphere Application Server Enterprise

Edition for OS/390 Component Broker Planning and

Installation Guide

Document Number: GA22-7325-00

See revisions in the APAR OW44456 text.

This support has not been tested with 120 SMF records.
Change 18.298 Support for the z/OS License Manager's new LPAR capacity

VMXGRMFI measurement: "Four-Hour Running Average MSU", with MSU in

TRNDRMFI "Million Service Units per Hour", based on the raw SU_SEC

Dec 12, 2000 of the physical platform. New MXG variable MSU4HRAV is

Dec 18, 2000 now created in the PDB.RMFINTRV dataset, and it is that

Feb 10, 2001 value that z/OS will pass to the License Manager, which

is compared with the licensed MSU for that LPAR (which

you chose in your software License Certificate for that

LPAR). WLM measures the MSU consumed by the LPAR every

five (may be changed) minutes, and if the licensed MSU is

exceeded, WLM will cap the LPAR to that licensed MSU for

the next interval.

So this new License Manager can save you lots on software

license costs, if you don't need an entire machine for an

LPAR; you can even license only part of an engine.
BUT to save that money, you will need to know your peak

MSU4HRAV for the month, in advance, so you can purchase a

correct size license, and you will need to track when

that peak MSU4HRAV consumption occurs, perhaps so you can

time-shift work to reduce that peak MSU consumed. Since

each month's charge is likely to be based on the maximum

peak running average during each calendar month, tracking

closely at near-month-end may be needed!

When WLM capping is invoked (because the LPAR exceeded

its licensed MSU4HRAV), response times may be elongated,

and it remains to be seen what feedback will be available

to alert you that dynamic capping was applied, but with

this new variable now, you can at least estimate the size

of each of your Systems to see how you will be able to

take advantage of License Manager product pricing.
The MSU4HRAV variable is created in PDB.RMFINTRV when

you run BUILDPDB/BUILDPD3, or if you run RMFINTRV or

invoke %VMXGRMFI in your own program. The algorithm

also creates the new SPIN.SPINRMFI dataset, which holds

the last four hours of the previous day, and is read by

the next day's BUILDPDB so that continuous four-hour

means are calculated. Variable CECSUSEC, the SU_SEC of

the physical CEC, is also created in PDB.RMFINTRV.

New variable MSU4HRMX in TRNDRMFI is the maximum value

of the MSU4HRAV during each trended interval.

You can add the new variables MSU4HRAV and CECSUSEC to

existing PDB.RMFINTRV datasets (without re-reading the

SMF data), by using the PDB=ADDMSU option in %VMXGRMFI to

read each existing PDB.RMFINTRV dataset and write back a

replacement, enhanced PDB.RMFINTRV dataset, as shown:

//PDB DD DSN=YOUR.EXISTING.PDB,DISP=OLD

//SYSIN DD *

%VMXGRMFI(PDB=ADDMSU);

If you add a //SPIN DD to that example, and start your

re-creation from the oldest to the newest, MSU4HRAV

will exist in all observations (except for the first

four hours of the oldest PDB):

//WEEKOLD EXEC MXGSAS

//PDB DD DSN=YOUR.WEEKOLD.PDB,DISP=OLD

//SPIN DD DSN=YOUR.SPIN,DISP=OLD

//SYSIN DD *

%VMXGRMFI(PDB=ADDMSU);

... one step per week ...

//WEEKNEW EXEC MXGSAS

//PDB DD DSN=YOUR.WEEKNEW.PDB,DISP=OLD

//SPIN DD DSN=YOUR.SPIN,DISP=OLD

//SYSIN DD *

%VMXGRMFI(PDB=ADDMSU);

If you use the first example, without SPIN, the first

four hour's observations in each output PDB.RMFINTRV

dataset will have missing value for the new variables.

Definitions and description of the algorithm:
"MSU" is Millions of Service Units per Hour, and it is

calculated from the raw (un-weighted) Service Unit Per

Second value (MXG's SU_SEC variable from TYPE72). The

equation to calculate the hourly MSU capacity is:

MSU= 3600*SU_SEC*NRCPUS/1000000 = 336 MSU (per hr)
(e.g.: 10 engine, SU_SEC=9334.8828, a z900 2064-110)
- But SU_SEC value in PDB.RMFINTRV and TYPE72 data is an

LPAR value, and is based on the number of CPU engines

that you gave to that LPAR for this system; increasing

the number of engines decreases the SU_SEC value, due

to the Multi-Processor effect that causes the recorded

CPU time to increase with the number of engines:

Spin loops for access to serialized storage is seen

as CPU time, and the recorded CPU time increases as

the number of engines increases, so to get constant

Service Units, we must multiply by a smaller factor.

An example of the 9021-711 family's MP Factors

CPUs 1 2 3 4 5 6 7 8 9 10

Pct: 100 95 92 88 85 81 79 77 75 72

So instead of using the SU_SEC value for each LPAR,

which varies with the number of engines in each LPAR,

the MSU capacity measurement in z/OS is based on the

new CECSUSEC variable, which is the SU_SEC for all

engines, the "SU_SEC" of the physical "box" or "CEC"

CEC, was Central Electronics Complex,

CPC, now Central Processing Complex,

and CECSUSEC is constant from LPAR to LPAR in a box.
CECSUSEC did not exist in the RMF records, and it has now

been added in z/OS as SMF70CPA, but MXG creates it now so

we can calculate MSU capacity even before you're at z/OS.
a. The original (18.11) algorithm to calculate CECSUSEC

and MSU from pre-z/OS records (replaced, below):

In OS/390 RMF TYPE72 records, we only have the SU_SEC

of this LPAR, but we could calculate the CECSUSEC from

the LPAR SU_SEC and the "table of MP factors",

above, given the engines in the LPAR and in the box:

CECSUSEC=SU_SEC*MP(PARTNCPU)/MP(NRCPUS);
where

MP(n) is the MP factor for n engines, above, and

PARTNCPU=engines in the physical CEC, and

NRCPUS =engines in this LPAR.

A numerical example:

An LPAR with an SU_SEC = 1000

with NRCPU = 2 (2 engines for this LPAR), and

on a 6-way CEC (PARTNCPU=6) would have a

CECSUSEC = 1000 *(81)/(95) = CECSUSEC = 852

At 100% busy that 2-CPU LPAR has MSU capacity of:

MSU = 3600sec*852SU_sec*2engines/1000000=6.1 MSU
b. The present (18.18) algorithm to get IBM MSU capacity

(pre-z/OS) using table lookup of IBM published values:

The original code worked fine for that one set of MP

factors, but the factors vary with CPU families, and

IBM does not publish a table of MP factors; instead

IBM publishs the MSU capacity of each CPU, and with

the help of Alan Sherkow, the new $MG070CP format is

created as a look-up table that returns the capacity

in MSU and the CECSUSEC, given the CPUTYPE, CPUVERSN,

and (for 2064's) the CPCMODEL.

Alan also noted that the MSU capacity calculated from

CECSUSEC does not exactly match IBM's MSU table value,

even though we thought it should; differences of up to

10% were observed on some particular machines.

c. When you're running under z/OS with License Manager,

the needed fields are added by IBM to the type 70 RMF

record and are kept in PDB.RMFINTRV dataset:

MXG Variable z/OS Variable Description

CECSUSEC SMF70CPA SU_SEC of n-way CPC

MSU4HRAV SMF70LAC 4-hour Average MSU

MSUINTRV n/a Interval MSU count

temp SMF70WLA Defined MSU Capacity

While IBM will provide the SMF70LAC field in z/OS, MXG

now calculates MSU4HRAV from RMF Interval records, going

back four hours, and uses the actual interval durations

so it supports different interval sizes. The last four

hours of each system is written out to SPIN.SPINRMFI so

they can be re-introduced tomorrow so that the four-hour

is continuous in RMFINTRV. (If you're using ADDMSU with

a large PDB.RMFINTRV, default array sizes of 9999 permit

three month's worth of 15 minute intervals.)
This is new territory, and we'll know a lot more about

MSU4HRAV when the License Manager product is released,

but at least now you can begin to measure your LPARs in

these IBM units that will certainly be important in the

future of capacity measurement.
Please do not confuse the License Manager measurements

with Usage Based Pricing, because they are not related.

Under the License Manager, it will be the size of the

LPAR that you define that sets the price you pay for

Software that runs in that LPAR, and it is the total

work in that LPAR (and not the usage of any software

product) that is measured and compared with the LPARs

defined capacity in MSU. There is no measurement of

product's software usage under License Manager, and it

is all work in the LPAR that will be capped if the

MSU4HRAV/SMF70LAC exceeds the SMF70WLA capacity.
Change 18.297 Cosmetic. The test IF NUMTRANS GT 0 for the calculation

ASUMCICX of SQRTARG is redundant so it was removed.

Dec 8, 2000

Thanks to Ian Mackay, Royal Bank of Scotland, SCOTLAND.

Change 18.296 Variable SYSTEM and CPUTM are kept/summed respectively

ASUMCICS from input CICSTRAN/MONITASK data into the PDB.CICS

Dec 8, 2000 summary dataset. CPUTM=TASCPUTM+CPURLSTM in CICSTRAN.

Thanks to Aubrey Tang, Westpac Banking Corporation, AUSTRALIA.

Change 18.295 Support for APAR OWxxxxx which adds a flag bit to type 79

VMAC79 subtype 2.

Dec 8, 2000
Change 18.294 QBGLGG now decoded and kept, although the counters in the

VMACDB2 QBGL section are suspect and under investigation.

Dec 7, 2000

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Change 18.293 SPINCNT=SPINCNT+1; changed to SPINCNT=SUM(SPINCNT,1); so

IMACUOW that SPINCNT would actually be retained and incremented

Dec 7, 2000 and the SPIN library actually used.
Change 18.292A Support for MQ Series V5.2 SMF 115/116.

EXTY1152 -INCOMPATIBLE because subtype is now a two-byte binary at

EXTY1161 @19, having been corrected by IBM from the non-standard

EXTY116Q one-byte @19 (and that VMACSMF had catered for, and now

FORMATS had to be revised to cover both old and new 115/116 SMF).

VMAC115 -Reading new records with old MXG versions will create

VMAC116 zero observations from the new records.

VMACSMF -Type 115 Subtype 1, dataset MQMLOG has 7 new variables:

VMXGINIT QJSTBPAG QJSTCIWR QJSTLLCP QJSTLOGW QJSTLSUS QJSTSERW

Dec 8, 2000 QJSTTHRW

Dec 18, 2000 -Type 115 Subtype 2, new Q5ST DB2 manager statistics adds

70 new variables to existing dataset MQMMSGDM:

ABNDCNT ACTTASK CONNCNT DEADCNT DELECNT DELESCUW

DELESMXW DELETCUW DELETMXW DHIGMAX DISCCNT LISTCNT

LISTSCUW LISTSMXW LISTTCUW LISTTMXW NUMTASK READCNT

READSCUW READSMXW READTCUW READTMXW REQUCNT SCSBFTS

SCSDEL SCSDSCUW SCSDSMXW SCSDTCUW SCSDTMXW SCSINS

SCSISCUW SCSISMXW SCSITCUW SCSITMXW SCSMAXR SCSSEL

SCSSSCUW SCSSSMXW SCSSTCUW SCSSTMXW SCSUPD SCSUSCUW

SCSUSMXW SCSUTCUW SCSUTMXW SSKDEL SSKDSCUW SSKDSMXW

SSKDTCUW SSKDTMXW SSKINS SSKISCUW SSKISMXW SSKITCUW

SSKITMXW SSKSEL SSKSSCUW SSKSSMXW SSKSTCUW SSKSTMXW

UPDTCNT UPDTSCUW UPDTSMXW UPDTTCUW UPDTTMXW WRITCNT

WRITSCUW WRITSMXW WRITTCUW WRITTMXW

-Type 115 Subtype 2, new QEST Coupling Facility statistics

segment, MXG creates new MQMCFMGR dataset, one obs for

each structure (if QESTSTR structure name is non-blank:

IBM writes an array of 64 possible structures but MXG

outputs only the entries with data). MXG also calculates

the average duration of IXLLSTE and IXLLSTM calls in new

new variables QESTAVGE and QESTAVBM.

Updates to elements in the CF can be made one at a

time with IXLLSTE, or requests to update multiple

elements, a group of changes that have to be made

together, are done with IXLLSTM.

The other IBM variables created in MQMCFMGR dataset:

QESTCMEC QESTCSEC QESTMLUS QESTMNUS QESTMSTC QESTRMEC

QESTRSEC QESTSFUL QESTSSTC QESTSTR QESTSTRN

-Type 116: FORMAT MG116TY updated for '7:RRS BATCH' type

of attachment type.

-Type 116 subtype 0 creates old MQMACCT Message Manager

accounting; this was the only data set created from SMF

116 record prior to Version 5.2.

-Type 116 subtype 1 creates new MQMACCTQ Queue Level

Accounting dataset with WTIDxxxx and WTASxxxx variables.

This is the important, task-level, dataset, with elapsed

and CPU times per verb for commit and back out requests,

and has task identification, including Job, User ID,

Transaction Name if applicable, and Channel Name (TCP/IP

address or APPC LU).

-Type 116 subtype 1 or subtype 2 creates new MQMQUEUE

Queue Detail with WTIDxxxx and WQxxxx variables. This

data set has an observation for each QUEUE used by the

task, including number/elapsed/CPU times for MQOPEN,

MQCLOSE,MQPUT,MQPUT1,MQGET,MQINP and MQSET calls, and

the WTIDxxxx task identifiers.

Change 18.292 Cosmetic. Comment corrected and labels for Mount Wait

ASUMTMNT bucket variables MNTBKTn changed from 'PCT JOBS' to

Dec 6, 2000 the more accurate 'PCT MOUNTS*MOUNT WAIT*LESS THAN....'.

Thanks to Chuck Hopf, MBNA, USA.

Change 18.291 Cosmetic. Labels added for DOMTRESP/DOMTWAIT/DOMTRTYP/

VMAC103 DOMTRNUM variables in VMAC108, and dataset labels in the

VMAC108 VMAC103 are now "HTTP Web Sphere Server" instead of the

Dec 6, 2000 Lotus Domino no-longer-used name.

Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.290 TMON for MVS 2.0 NQ records were not correct; Landmark

VMACTMV2 inserted data between 1.3 and 2.0, but no one noticed!

Dec 5, 2000 Both record formats are now supported, and new variables

are now created in dataset TMONNQ.

Thanks to Lindsay Robertson, GMAC Insurance, USA.
Change 18.289 Using IMACJBCK exit for DB2ACCT selection saves CPU time!

IMACJBCK The IMACJBCK exit (or MACJBCK= macro) is invoked in every

VMACDB2H SMF record that contains JOB name. For the DB2 SMF 101

Dec 5, 2000 Account records, using it instead of the EXDB2ACC/ACB/ACP

exit member to delete unwanted records can save lots of

CPU time, because it is invoked earlier in the processing

code, after the QWHS (Standard) and QWHC (Correlation)

Headers have been input, and before INPUTing all of the

other variables in all of the segments in the rest of the

accounting record, and then invoking the EXDB2ACx exit.

These QWHSxxxx and QWHCxxxx variables exist when IMACJBCK

exit is taken, and can be used to delete SMF 101 records

early, fully decoding only the selected records and then

taking EXDB2ACx exit before output into DB2ACCT/ACCTB/P:

SMFTIME ='TIME WHEN*SMF RECORD*WAS WRITTEN'

QWHSSTCK='STORE CLOCK*VALUE FOR*HEADER'

QWHSSSID='SUBSYSTEM NAME'

QWHCAID ='AUTHORIZATION ID '

QWHCCV ='CORRELATION ID '

QWHCCN ='CONNECTION NAME '

QWHCPLAN='PLAN NAME '

QWHCOPID='ORIGINAL OPERATOR ID'

QWHSRELN='RELEASE INDICATOR'

JOB ='JOB NAME*OR*TSO USER'

QWHSLUNM='LUNAME'

NETSNAME='ORIGINATING*SYSTEM*NET-NAME'

QWHCEUTX='END USERS*TRANSACTION*NAME'

QWHCEUID='END USERS*USERID*AT WORKSTATION'

QWHCEUWN='END USERS*WORKSTATION*NAME'

QWHCATYP='CONNECTING*SYSTEM TYPE*CODE'

Numeric values and their meaning:

0='0:UTILITY'

1='1:TSO'

2='2:DB2 CALL ATTACH'

3='3:DL/I BATCH'

4='4:CICS ATTACH'

5='5:IMS ATTACH BMP'

6='6:IMS ATTACH MPP'

7='7:DISTRIBUTED UOW'

8='8:REMOTE UOW'

9='9:IMS CONTROL REGION'

0AX='AX:IMS TRANSACTION BMP'

0BX='BX:UTILITY JOBS'

In your logic in IMACJBCK, you must DELETE unwanted SMF

records, so you must use NOT logic to select wanted:

//SYSIN DD *

%LET MACJBCK= %QUOTE(

IF ID=101 THEN DO;

IF QWHSSIID NE 'DB2SYS1' THEN DELETE;

IF NOT (JOB='MINE' AND QWHCPLAN='PLAN1') THEN DELETE;

END;

);

%ANALDB2R(PDB=SMF);

This change is minor: it moved the %INCLUDE of IMACJBCK

in member VMACDB2H to the end of the Correlation Header,

so all QWHCxxxx variables exist when at IMACJBCK. Added

are QWHCATYP/NETSNAME and new-in-6.1 QWHCEUID/EUTX/EUWN.

(There was no change to IMACJBCK; it just listed here so

you'll find this change when searching for that string!).

Savings: Reading 4.3GB of SMF 101 records to create all

these obs on an SU_SEC=2700 engine took 1426 CPU seconds.

Data Set Observations MegaBytes

DB2ACCT 1,842,166 1500

DB2ACCTG 1,289,146 800

DB2ACCTB 3,915,350 1430

DB2ACCTP 2,700,571 920

Total Output 4650

Deleting all obs in the _EDB2ACx exit took 1257 secs. The

delta of 1426-1257 = 169 seconds is the CPU cost for SAS

write out the 4.5 GB of output, about 27 MB/CPU second.
Using MACJBCK to delete all obs took 318 CPU seconds, so

the delta of 1257-318 = 939 seconds (deleting in _E exit)

is the CPU cost for SAS to execute the INPUT statements

for the 4.3 GB of SMF or about 4.6MB/CPU second.

The 318 seconds is the CPU cost just to read in all 4.3GB

of SMF, because the Headers are actually at the physical

end of each SMF record, so SAS reads SMF records at about

13.8 MB/CPU second.

Case Study:

Read 4.3GB Execute Write 4.5GB

SMF Data Input SAS Output Total
Output all: 318 secs 939 secs 169 secs 1426 secs

Output half:

_EDB1ACx 318 939 85 1342

IMACJBCK 318 470 85 873

Using IMACJBCK to select half of the obs saves 470 secs.
With this much possible saving, we will enhance ANALDB2R

in the near future so that any selection we can do in the

IMACJBCK exit will be done there if you use PDB=SMF for

your DB2PM-like reports, but you can exploit this exit

right now using the above example.

Thanks to Ron Alterman, Charles Schwab & Co., Inc, USA.

Change 18.288 The JCL in the TESTOTHR step of JCLTEST8 did not have the

JCLTEST8 //TMDCIN DD DUMMY and //TMDVTIN // DD DUMMY statements.

Dec 4, 2000 Member TESTOTHR had been updated to test the new support

and JCLTEST6 was updated, but JCLTEST8 was overlooked.

Thanks to Peter Herden, TUI (Touristik Union) Hannover, GERMANY
Change 18.287 Assembly error IEC293I FIRST DCB IN CLOSE NOT ACCESSIBLE

ASMIMSL6 because CLOSE (R3) must be CLOSE ((R3)) in line 1333.

Dec 1, 2000 Many MXG users have seen this error when they assembled

that program, but being ASM experts, they fixed it and

never told me about it! Since R3 is an address in reg 3

the parens tell the ASM that R3 is not a ddname!

Thanks to Alan Green, Zurich Financial Services, ENGLAND.

Thanks to Trevor Ede, EDS, NEW ZEALAND.

Change 18.286 The four new duration variables for initiator delays:

VMAC30 SMF30JQT /*JOB*PREPARATION*TIME*/

Nov 30, 2000 SMF30RQT /*INELIGIBLE*FOR*EXECUTION*TIME*/

SMF30HQT /*JOB*HOLD*TIME*/

SMF30SQT /*ELIGIBLE*FOR*EXECUTION*TIME*/

were multiplied by 1.024, but should have been multiplied

by 1024, as they are in 1024-microsecond units.

May 22, 2004: APAR OA07041 corrected SMF30SQT.

Thanks to Steve Simon, ALLTEL, USA.
Change 18.285 Cosmetic. Label for QWACARNG was corrected to be

VMACDB2 QWACARNG='WAITS FOR*SEND MSGS*DATA SHARING'.

Nov 30, 2000

Thanks to Allan J. Winston, MBNA, USA.

Change 18.284 JES 3 only. The WEEKBLD/WEEKBLDT/MONTHBLD members all

WEEKBL3 referenced dataset NJEPURGE which is JES2 only. These

WEEKBL3T three members can be used for JES3 sites; the only change

MONTHBL3 is that DJEPURGE instead of NJEPURGE is processed, and

Nov 29, 2000 the TYPE25 (also JES3-only) processing is added.

Thanks to Robert Sample, Atlanta Journal-Constitution, USA.

Change 18.283 IMS 6.1 only; variable MSGSZOUT is a constant and wrong

TYPEIMSB value in IMSTRAN dataset; the PUT "SUBQ6 $EBCDIC12." was

Nov 29, 2000 corrected to "SUBQ6 $EBCDIC4." to prevent the overlay.

My apologies to Pete Gain who's correct fix I typoed!

Thanks to Alan Green, Zurich Financial Services, ENGLAND.
Change 18.282 Invalid length ILKA record subtype 20 is protected now,

VMACILKA but the record is still invalid. The length of data in

Nov 29, 2000 SMFACDLN is 11,640, but the record is only 4092 bytes,

and the number of subpools expected is 256, but there is

room only for the first 98 subpool segments. This change

detects the bad record, prints a message on the log, and

outputs only the found subpool segments, while awaiting

a correction from the vendor. Only ILKAST20 dataset is

affected by this error.

Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM

Change 18.281 Three logic errors in VMXGUOW were corrected:

VMXGUOW -IRESPTM was being summed from all MRO transactions, due

Nov 24, 2000 to the mis-location of the code that sets IRESPTM to the

single internal response time of the "TOR" transaction

(i.e.: now, IRESPTM is the response of the transaction

used for TRANNAME and TERMID).

-Counters were being summed as: HOLDX=HOLDX+X; but that

results in a missing value in the PDB.ASUMUOW output data

set if any counter was missing for any observation in the

input. Instead, the more robust HOLDX=SUM(HOLDX,X);

statement is used in VMXGUOW, so that only if all values

of a variable is missing in all input observations will

that variable have missing value in PDB.ASUMUOW output.

-The INCODE= segments (intended to allow tailoring things

like normalize CPU times across different processors, or

to add new variables) was mis-located after the code that

added the new variables, so new variables were missing.

Thanks to Chuck Hopf, MBNA, USA.

Change 18.280 Cosmetic, only affected MXG processing under ASCII SAS.

VMAC110 The variables RTYPE and RRTYPE should have been INPUT as

Nov 24, 2000 $EBCDIC1. instead of $CHAR1., so that they were converted

into ASCII characters for printing and MG110RT format.