MXG - Simplified (MXG for Dummies) Chuck Hopf Merrill Consultants.

MXG - Simplified(MXG for Dummies)

Chuck Hopf

Merrill Consultants

Copyrights

Lots of companies own copyrights on products and tools mentioned herein. All of the copyrights are acknowledged.

Agenda

Primarily focused on MVS/ Zos / OS/390 use of MXG

Setting up SMF and RMF Installing and tailoring MXG Using some MXG tools

Ask questions when you feel the need and know that I try to not take all this very seriously

Tech Note

Code samples assume a minimum level of MXG of 22.10.

This is a living document with frequent updates. The current version will always be on the MXG download page at www.mxg.com

Who is this Bozo talking?

Started working with MXG prior to first GA in 1983 Installed MXG and SAS in many data centers (lost count around

50) Number 1 ‘Code Shark’ - 283 changes as of October 2004 Past chair SWCMG Past VP of CMG Past President of CMG Past General Chair of CMG Now a resident CMG curmudgeon

Getting Ready - Part 1

Deciding what you need SMF Parameters RMF Parameters Collecting SMF data Managing Growth Deciding what to keep Deciding how long to keep it

Deciding What You Need

What will be the purpose of the MXG installation?– Charge-back?– Capacity planning?– Problem solving?

Charge-back?

Will need job information– type 6 26 30

May need CICS data– type 110

May need DB2 data– type 101

Other?– DASD space?– TAPE Usage?

Capacity Planning?

RMF Probably same data as chargeback DASD space? Tape Usage? Network?

Problem Solving

Jobs data RMF data CICS DB2 DCOLLECT datasets (14 15 64 61 65 66 42) ????????????????

Why Care? It’s Just SMF Data

Volume can go up quickly– x*number of LPARs*intervals per day for type 74

(where x is the number of online UCBs) can be huge in a hurry. Consider 20000 online 3390-3 across 9 LPARs on 15 minute intervals - 20000*9*96/day

The capacity of the SMF subsystem is not unlimited - it is limited by the speed of the devices on which the MAN datasets reside (among other things.)

Why Care?

If a 3390-3 holds 2.7GB of data and the speed is 10MB/second then at full speed it could be filled in 270 seconds (6.5 minutes). Then you have to dump and clear which would take 13.

We fill a 3390-3 every 10 minutes. If ANYTHING slows down the SMF

writer - the buffers fill and we lose data.

Why Care?

It takes 10-15 minutes to DUMP/CLEAR If we fill in 10 but it takes 10-15 to

DUMP, then there is a 5 minute period where 2 datasets are being dumped and 1 is active

Must have at least 4 datasets in that instance

Why Care?

So what can slow it down?– IO to some other device on the RAID group– Channel contention– Some moron reading the live MANx

dataset with MXG– All of the things that can cause IO to

degrade

Usual Case

You need all of these things - charge-back, capacity planning, and problem solving.

And then there are your auditors with their own set of requirements for data and data retention.

So why bother?

Why not just keep it all?

Due diligence and to make conscious versus unconscious choices

Crazy Chuck Axiom #1

When capacity planning becomes a capacity planning issue, something is wrong.

Crazy Chuck Corollaries to Murphy’s Law

The piece of data you threw away or did not enable will be the piece you need to solve a problem.

Murphy was an optimist.

Setting up SMF

MAN datasets SMF parameters Processing Managing Growth

MANx Datasets

A long time ago in a galaxy far far away…– datasets had to be named SYS1.MANx– datasets had to be catalogued in the

MASTER catalog

MANx Datasets

In today’s brave new world– Datasets can have any name– Datasets can live in a user catalog

MANx Datasets

Let the names conform to some convention that identifies them

May or may not be advantageous to place them in a USER catalog– Plus side, they can be used by any LPAR– Negative side, they must be cleared on the

system where they are in use

MANx Datasets

For each LPAR:– Two full volume MAN datasets (minimum -

higher volumes could require more)– Third smaller dataset as a backup – Use different control units/paths just like

you would with PAGE datasets

MANx Datasets

Full Volumes?– Minimizes switching– Minimizes impacts from other workloads

hitting the same volumes– Does not eliminate self-inflicted wounds

(reading of a live SMF dataset with MXG.)

MANx Datasets

What CISIZE?– Let the data drive the decision. Member

ANALSMF will do an analysis of your SMF data and tell you what the optimal CISIZE will be. But… if you have lots of CICS, the optimal size will be 16384.

MANx Datasets – CISIZE

SMF Parameters ACTIVE /* ACTIVE SMF RECORDING */ DSNAME(SYS1.MANx,SYS1.MANy,SYS1.MANz) LISTDSN /* LIST DSN AT IPL */ SID(xxxx) /* SYSTEM ID */ REC(PERM) /* TYPE 17 PERM RECORDS */ MAXDORM(0500) /* WRITE IDLE AFTER 05M */ STATUS(SMF,SYNC) /* WRITE STATS EVERY 15M */ JWT(0014) /* 522 AFTER 14 MINUTES */ SYNCVAL(59) /* SYNC TO MINUTE 59 */ INTVAL(15) /* 15 MINUTE INTERVALS */ DDCONS(NO) /* DON'T CONSOL T30 EXCP */ NOPROMPT /* DONT PROMPT OPERATOR */ DUMPABND(NORETRY) /* DEFAULT RETRY */ NOBUFFS(MSG) /* DEFAULT TO MESSAGE */ LASTDS(MSG) /* DEFAULT TO MESSAGE */ SYS(NOTYPE(4,5,16,19,34,35,40,69), EXITS(IEFU83,IEFU84,IEFACTRT,IEFUJV,IEFUSI,IEFUJI,IEFUTL, IEFU29,IEFUJP), NOINTERVAL, NODETAIL) SUBSYS(STC,EXITS(IEFU29,IEFU83,IEFU84,IEFACTRT,IEFUJP,IEFUSO), INTERVAL(SMF,SYNC)) SUBSYS(BP01,INTERVAL(001500)) SUBSYS(BT01,INTERVAL(001500)) SUBSYS(OMVS,EXITS(IEFU29,IEFU83,IEFU84,IEFACTRT,IEFUJP,IEFUSO), INTERVAL(SMF,SYNC)) SUBSYS(HSC0,INTERVAL(SMF,SYNC),TYPE(235)) SUBPARM(HSC0(SUBTYPE(1,2,3,4,5,6,7,8,10-29)))

SMF Parameters

Mostly self-explanatory However...

SMF Parameters

SYS(NOTYPE(4,5,16,19,34,35,40,69), EXITS(IEFU83,IEFU84,IEFACTRT,IEFUJV,IEFUSI,IEFUJI,IEFUTL, IEFU29,IEFUJP), NOINTERVAL, NODETAIL)

Says suppress the 4 5 16 19 34 35 40 and 69 SMF record types

Use all of the exits Do not create detail This applies to all subsystems unless

otherwise noted

SMF Parameters

Type 4 5 34 35 are obsolete job and TSO user records

Type 16 Old DFSORT records Type 19 DASD Volume info (there are

better sources) Type 40 - dynamic de-allocation Type 69 - VSAM catalog records

SMF Parameters

STATUS(SMF,SYNC) /* WRITE STATS EVERY 15M */ JWT(0014) /* 522 AFTER 14 MINUTES */ SYNCVAL(59) /* SYNC TO MINUTE 59 */ INTVAL(15) /* 15 MINUTE INTERVALS */

Write SMF 23 every 15 minutes (buffer status)

Kill jobs after 14 minutes of waiting Synchronize SMF intervals to minute 59 Write interval records every 15 minutes

SMF Parameters

DDCONS(NO) /* DON'T CONSOLIDATE T30 EXCP */

From Chapter 3 of MXG:

Number of DDs CPU Before CPU After DDCONS(YES) DDCONS(NO)

70,000 4 hr 5 min 8 min 35,000 1 hr 3 min 3 min 10,000 6 min 1 min

SMF Parameters

OTOH…– We have seen instances where long

running tasks with 10s of thousands of DD segments write type 30 records so huge that they cause SMF buffer shortages. This problem was solved by detecting in an exit that this was happening and imposing a 10 second delay between type 30 segments.

SMF Parameters

SUBSYS(STC,EXITS(IEFU29,IEFU83,IEFU84,IEFACTRT,IEFUJP,IEFUSO), INTERVAL(SMF,SYNC))

For the STC subsystem, use these exits AND write interval records synchronized with the SYNCVAL

This can be important for tracking availability

SMF Parameters

SUBSYS(BP01,INTERVAL(001500)) SUBSYS(BT01,INTERVAL(001500))

Not all subsystems (Batch Pipes in this case) recognize the SYNCVAL

SMF Parameters

SUBSYS(HSC0,INTERVAL(SMF,SYNC),TYPE(235)) SUBPARM(HSC0(SUBTYPE(1,2,3,4,5,6,7,8,10-29)))

Some subsystems (in this case STK HSC for controlling tape subsystems) have their own needs.

SMF Parameters

What about type 99 records?– Refer to Crazy Chuck’s corollaries to

Murphy’s law– As sure as you don’t have it… and it will

be too late to turn it on– Throw them away or redirect them during

the processing cycle

Processing SMF Data

Use the IEFU29 exit to detect a switch and dump/clear the full dataset

On a daily basis, consolidate all dumped data into a single dataset

On a weekly basis, consolidate daily data into a weekly dataset (maybe)

Some sites repeat at the monthly level but...

Processing SMF Data

Timing– Force a switch at chosen time– Dump/clear last dataset of day– Do daily consolidation– Midnight may be ideal but may be

impractical

Processing SMF Data

SMF data is generally a great candidate for extended format striped compressed datasets. Compression ratios of 9 or 10 to 1 are not uncommon. There are lots of binary zeros and blanks in the data.

Processing SMF Data - Simple Case

I SMF IFASMFDP

MANx

Working CopyDaily SMF

ArchivalDaily SMF

Single System that does not fill a full dataset in a day

Processing SMF Data - Less Simple

I SMFSYS1

IFASMFDP

MANx


ArchivalDaily SMF

Multiple Systems that do not fill a full dataset in a day

I SMFSYS2

MANx

IFASMFDP

Daily SMFSYS1

Daily SMFSYS2

IFASMFDP

Repeat as needed for moresystems

At this point does not HAVE to be IFASMFDP

Processing SMF Data -Usual Case

I SMF IFASMFDP

MANx


ArchivalDaily SMF

Multiple Systems that fill multiple datasets in a day

EODSMF

Dumps SMFDumps

IFASMFDP

When datasets fill and at end of day, issue I SMF on each system

SMFDumpsSMF

DumpsSMFDumpsSMF

Dumps

After all dumps are complete

Setting up RMF

RMF Monitor I Parameters RMF Monitor III Parameters Run both? RMF Monitor III Archiving

RMF Monitor I Parameters - Part I/*********************************************************************//* PART 1: MEASUREMENTS *//*********************************************************************/ CHAN /* CHANNEL STATISTICS */ CACHE /* CACHE RMF REPORTER */ CPU /* CPU STATISTICS */ DEVICE(DASD) /* DIRECT ACCESS DEVICES MEASURED */ DEVICE(TAPE) /* MEASURE TAPE DEVICES */ DEVICE(NOCHRDR) /* NO CHARACTER READER DEVICES MEASURED */ DEVICE(NOUNITR) /* NO UNIT RECORD DEVICES MEASURED */ DEVICE(COMM) /* COMMUNICATION DEVICES MEASURED */ DEVICE(NOGRAPH) /* NO GRAPHICS DEVICES MEASURED */ DEVICE(NOSG) /* NO SELECTION BY STORAGE GROUPS */ ENQ(DETAIL) /* DETAILED ENQUEUE REPORT */ IOQ(DASD) /* DASD I/O QUEUEING MEASURED */ IOQ(TAPE) /* TAPE I/O QUEUEING MEASURED */ IOQ(NOCHRDR) /* NO CHARACTER READER I/O QUEUEING */ IOQ(NOUNITR) /* NO UNIT RECORD DEVICE I/O QUEUEING */ IOQ(COMM) /* COMMUNICATION I/O QUEUEING */ IOQ(NOGRAPH) /* NO GRAPHICS DEVICE I/O QUEUEING */ PAGESP /* PAGE/SWAP DATASET STATISTICS */ PAGING /* PAGING DATA */ TRACE(MCVSTCRI,ALL) /* HIGH UIC */ TRACE(MCVMGAGE,ALL) /* MIGRATION AGE */ TRACE(MCVTWSS,ALL) /* TARGET WORKING SET SIZE */ TRACE(MCVFRCNT,ALL) /* FORCE STEAL FRAME COUNT */ TRACE(RCENWSF,ALL) /* NON-WSS MOVE TO AUX */ TRACE(RCEWSDNE,ALL) /* WORKING SET MOVE TO AUX */ TRACE(RCVAFQA,ALL) /* AVERAGE AVAILABLE FRAME COUNT */ TRACE(RCVUICA,ALL) /* AVERAGE UNREF. INTERVAL COUNT */ TRACE(RMCARSSC,ALL) /* CENTRAL STORAGE SHORTAGE SWAPS */ VSTOR(S) /* VIRTUAL STORAGE SUMMARY DATA */ WKLD(PERIOD,SYSTEM) /* WORKLOAD MANAGER DATA BY PERIOD */

RMF Monitor I Parameters - Part II

/*********************************************************************//* PART 2: TIMING *//*********************************************************************/ CYCLE(0500) /* SAMPLE TWICE PER SECOND */ NOSTOP /* ACTIVE UNTIL OPERATOR ISSUES STOP */ SYNC(SMF) /* SYNC INTERVAL */

RMF Monitor I Parameters - Part III

/*********************************************************************//* PART 3: REPORTING / RECORDING OF DATA *//*********************************************************************/ NOOPTIONS /* OPTIONS NOT DISPLAYED, NO REPLY */ RECORD /* WRITE SMF RECORDS EVERY INTERVAL */ NOREPORT /* NO WRITTEN REPORTS TO SYSOUT */ SYSOUT(U) /* REPORTS TO CLASS U, IF REPORT */

RMF Monitor I Parameters - Part IV

/*********************************************************************//* PART 4: USER EXITS (ALSO USED BY CACHE REPORTER OFFERING) *//*********************************************************************/ NOEXITS /* DO NOT TAKE USER EXITS */

RMF Monitor I Parameters

Stored in SYS1.PARMLIB as ERBRMF00

Can be modified while active– F RMF,MODIFY ZZ,xxxxxxxx

RMF Monitor III Parameters

CYCLE(1000) /* SAMPLE EVERY SECOND (1000 MSEC) */ DATASET(ADD(SYS3V.&SYSNAME..RMFMON3A)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3B)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3C)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3D)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3E),SWITCH) DATASET(START) /* DATASET SUPPORT */ DATASET(WHOLD(7)) /* CONTROLS BUFFER PAGES IN STORAGE */ MINTIME(60) /* LENGTH OF MINTIME */NOOPTIONS /* DO NOT DISPLAY OPTIONS */ RESOURCE(*JES2,JES2) /* SPECIFIES JES STARTED TASK NAME */NOSTOP /* RUN UNTIL OPERATOR ISSUES STOP */ SYNC(00) /* MINTIME SYNCHRONIZATION */ SYSOUT(7) /* MESSAGES TO SYSOUT CLASS A */ WSTOR(32) /* SIZE OF INSTORAGE BUFFER (IN MB) */ IOSUB /* I/O SUBSYSTEM GATHERING ACTIVE */NOCACHE /* TURN OFF CACH RMF REPORTER */


DATASET(ADD(SYS3V.&SYSNAME..RMFMON3A)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3B)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3C)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3D)) DATASET(ADD(SYS3V.&SYSNAME..RMFMON3E),SWITCH)

Uses SYSNAME symbolic to assign that portion of the monitor 3 data store Stored as ERBMF04 in SYS1.PARMLIB 1 data store can hold up to 18 hours of data or less depending on activity and

volume regardless of size Turning on CACHE gets very expensive - we have seen 20% of a CPU


Can be modified on the fly– F RMF,MODIFY III,xxxxxxxxxxxxx

RMF - Should I Run Both I and III?

They serve different purposes– Monitor I feeds MXG with SMF data– Monitor III provides real-time problem

solving capabilities - in some cases superior to other monitoring tools

Both provide data that can be post-processed

RMF - Monitor III Archiving

It may be wise to archive monitor III data against the possible need for problem diagnosis

No tools provided but it is not difficult to do

RMF Monitor III Archival

IDCAMSREPRO

RMF III Switch detected

RMF IIIDATA STORE

RMF IIIARCHIVE

ERB813I indicating a new RMF III dataset is active


Work expands to exceed any available capacity

Managing Growth

What do you do as the data starts to grow?– Put it on tape

Single user - still cannot share tapes

– Break it into pieces Divide and conquer Break into as many pieces as needed on DASD Put archive copy on tape

Managing Growth

CICS and DB2 are likely the first problems - split them out early in the process.

Replicate the SMF process in miniature for these components.

Managing Growth

I SMF IFASMFDP

MANx


ArchivalDaily SMF

EODSMF

NOTYPE 99 101 110

SMFDumps

IFASMFDP


SMFDumpsSMF

DumpsSMFDumpsSMF

Dumps

After all dumps are completeDuplicate process for CICS and DB2but eliminate disk copy

SMFTYPE 110

SMFTYPE 101

CICS

DB2Do the CLEAR in a secondstep

SMFTYPE 99

WLM

Managing Growth

Assume that the input DD is INDD, the primary output is OUTSMF, the CICS data should go to OUTCICS, and the DB2 type 101 to OUTDB2, type 99 to OUTWLM:– IFASMFDP Control cards are:

INDD(INDD,OPTIONS(DUMP)) OUTDD(OUTSMF,NOTYPE(99,101,110)) OUTDD(OUTCICS,TYPE(110)) OUTDD(OUTDB2,TYPE(101)) OUTDD(OUTWLM,TYPE(99))

Managing Growth

Eventually, you have to go deeper. CICS/DB2 may each grow to the point where they have to be broken up

This requires using some exit points in IFASMFDP to read enough of the data to determine APPLID or some other identifying information to drive the split

Managing Growth

I SMF IFASMFDP

MANx

SMFTYPE

99


CICS1TYPE 110

SMFTYPE 101

CICS2TYPE 110

CICS3TYPE 110

CICS APPL 1

CICS APPL 2

CICS APPL 3

DB2

SMFNOTYPE 101 110

WLM

Managing Growth

Requires some assembler programming skills

See the SMF manual for details on exits There are three IFASMFDP exits:

– Exit 1 is called when records are read– Exit 2 is called when records are selected for

output– Exit 3 is called when output datasets are closed

Managing Growth

– IFASMFDP Control cards are: INDD(INDD,OPTIONS(DUMP)) OUTDD(OUTSMF,NOTYPE(99,101,110)) OUTDD(OUTCICS1,TYPE(110))

OUTDD(OUTCICS2,TYPE(110)) OUTDD(OUTCICS3,TYPE(110))

OUTDD(OUTDB2,TYPE(101)) OUTDD(OUTWLM,TYPE(99)) USER3(YOUR3) USER2(YOUR2) USER1(YOUR1)

Managing Growth

CICS allows for some tailoring of the records written. You can drop fields that are obsolete or that you do not use or think that you need.

Managing Growth

Tailored MCT

Rollout

Managing Growth

Tailoring the MCT requires tailoring of MXG as well. UTILEXCL will build the code to read the records based on the CICS dictionary contents but… change control is very very important. If it changes, you must rebuild the code.

Deciding What to Keep

Refer to axiom 1 At least at the daily level, keep

everything After the daily level, it becomes a matter

of cost benefit analysis - what do you get out of keeping the data vs the cost

May also be auditing/security concerns

Deciding What to Keep

It can get very expensive to keep CICS/DB2 and other high volume data

Tapes are not forever Consolidating to the WEEKLY level may

reduce tape volumes used. Beyond weekly, reduction is usually minimal but the resource cost can be high.

Deciding How Long to Keep It

Largely an audit/legal concern– May be legal reasons to keep the data for

many years– Beyond 6 months the likelihood it will be

needed for problem solving is minimal– Beyond 5 years the likelihood of being able

to read the tapes drops quickly

Now That You Have the Data

Installing MXG– Conventions– SOURCLIB – FORMATs

Installing– Tailoring Exits– Tailoring MXG– Weekly/Monthly/TREND Processing– Non-SMF Data Sources– Managing Growth– Using Some MXG Tools

MXG - Conventions

All datasets are controlled by MACRO variables

MACRO variables are set in VMXGINIT Can be overridden INSTREAM For every IMACxxxx there is a macro

variable MACxxxx All tailoring could be done INSTREAM

MXG - Conventions

IMACxxxx - Installation exits VMACxxxx - Code to read data TYPExxxx - Reads data into WORK TYPSxxxx - Reads/sorts data into PDB VMXGxxxx - A macro ANALxxxx - Some sort of analysis GRAFxxxx - Graphical analysis

MXG Conventions

ACHAPxx - Chapters from MXG book ADOCxxxx- documentation CHANGES - current changes CHANGESS - all changes NEWLTRS - News letters JCLxxxxx - JCL examples

MXG - SOURCLIB

Must be a PDS Keep 3 levels:

– USERID.SOURCLIB Your changes/additions to MXG

– CHANGES.SOURCLIB Important changes between releases

– MXG.SOURCLIB Current production release

MXG - SOURCLIB

May also want a NULL PDS as filler:– //STEP1 MXG PROC …..– // TAILORNG=‘MXG.NULL.SOURCLIB’,– …– //SOURCLIB DD DSN=&TAILORNG– // DD DSN=USERID.SOURCLIB– // DD DSN=CHANGES.SOURCLIB– // DD DSN=MXG.SOURCLIB

MXG - FORMATs

FORMATs are used by SAS to provide human intelligible descriptions of data.

Does ‘01’X have meaning or is ‘1: Mount Missed, Too Fast’ more descriptive?

Saves space FORMAT library needs less than 5

cylinders

MXG Installation - 1st Time

Build using ISPF option 3.2– MXG.NULL.SOURCLIB - 1 track– MXG.USERID.SOURCLIB - 15 cylinders– MXG.CHANGES.SOURCLIB - 15 cylinders– All with LRECL=80 BLKSIZE=27920

RECFM=FB DSORG=PO– Directory blocks can be 25


Using JCL:

– //STEP1 EXEC PGM=IEBUPDTE,PARM=NEW– //SYSPRINT DD DUMMY– //SYSIN DD DSN=MXG.IEBUPDTE– //SYSUT2 DD DSN=MXG.PROD.SOURCLIB,– // DISP=(,CATLG,DELETE), RECFM=FB,– // LRECL=80,BLKSIZE=27920,– // DSORG=PO,SPACE=(CYL,(225,25,999))– //STEP2 EXEC SAS– //SOURCLIB DD DSN=MXG.PROD.SOURCLIB,DISP=SHR– //LIBRARY DD DSN=MXG.PROD.FORMATS,DISP=(,CATLG,DELETE),– // SPACE=(CYL,(15,15))– //SYSIN DD *– %INCLUDE SOURCLIB(FORMATS);


Build MXG Proc:

//MXG PROC ENTRY=SASHOST,// CONFIG='MXG.PROD.SOURCLIB(CONFIG08)',// SASNODE='SAS.PROD',// MXGNODE='MXG',// TAILORNG='MXG.NULL.SOURCLIB',// OPTIONS=,// LIST='*',// LOG='*',// SORT=4,// SORTWK=100,// WORKUNIT=CYL,// WORKNUM=1,// WORK='150,30...


//SAS EXEC PGM=&ENTRY,PARM='SORT=&SORT &OPTIONS'//STEPLIB DD DISP=SHR,DSN=&SASNODE..LIBRARY//CTRANS DD DSN=&SASNODE..SASC.TRANSLIB,DISP=SHR//CONFIG DD DISP=SHR,DSN=&SASNODE..CNTL(BATCHXA)// DD DISP=SHR,DSN=&CONFIG//SASHELP DD DISP=SHR,DSN=&SASNODE..SASHELP//SASMSG DD DISP=SHR,DSN=&SASNODE..SASMSG//WORK DD UNIT=(SYSDA,&WORKNUM),SPACE=(&WORKUNIT,(&WORK),RLSE),// DCB=RECFM=FS//SORTWKxx DD UNIT=SYSDA,SPACE=(CYL,&SORTWK)//SASLOG DD SYSOUT=&LOG//SASLIST DD SYSOUT=&LIST//SASPARM DD UNIT=SYSDA,SPACE=(400,(100,300)),// DCB=(RECFM=FB,LRECL=80,BLKSIZE=400,BUFNO=1)//SYSUDUMP DD SYSOUT=*//LIBRARY DD DSN=&MXGNODE..PROD.FORMATS,DISP=SHR//SOURCLIB DD DSN=&TAILORNG,DISP=SHR// DD DSN=&MXGNODE..USERID.SOURCLIB,DISP=SHR// DD DSN=&MXGNODE..CHANGES.SOURCLIB,DISP=SHR// DD DSN=&MXGNODE..PROD.SOURCLIB,DISP=SHR


May not need SASC transients but it is simpler to have them there than to go back and add them.

SORTWKxx is the number of SORTWK datasets you think you may need. It can always be overridden and more added as needed. I start with 6.

MXG Installation - After the 1st

Simpler //STEP1 EXEC PGM=IEBUPDTE,PARM=NEW//SYSPRINT DD DUMMY//SYSIN DD DSN=MXG.IEBUPDTE//SYSUT2 DD DSN=MXG.Vrelease.SOURCLIB,// DISP=(,CATLG,DELETE), RECFM=FB,// LRECL=80,BLKSIZE=27920,// DSORG=PO,SPACE=(CYL,(225,25,999))//STEP2 EXEC SAS//SOURCLIB DD DSN=MXG.Vrelease.SOURCLIB,DISP=SHR//LIBRARY DD DSN=MXG.Vrelease.FORMATS,DISP=(,CATLG,DELETE),// SPACE=(CYL,(15,15))//SYSIN DD * %INCLUDE SOURCLIB(FORMATS);

release is the MXG release number


Do testing:

//STEP1 EXEC MXG//LIBRARY DD DSN=MXG/Vrelease.FORMATS,DISP=SHR//SOURCLIB DD // DD// DD DSN=MXG.Vrelease.SOURCLIB,DISP=SHR


I test all production jobs (there are more than 20) with production inputs

Output compared using VMXGCOMP to drive a PROC COMPARE of all datasets


When testing is finished and you are ready to install

– Delete all members from MXG.CHANGES.SOURCLIB– Copy MXG.Vrelease.SOURCLIB to MXG.PROD.SOURCLIB– Copy MXG.Vrelease.FORMATS to MXG.PROD.SOURCLIB (use PROC

COPY)

MXG Exits

Was originally much more complex There were many exit points to be

touched Now down to only a few

MXG Exits

IMACINIT IMACSHFT IMACKEEP IMACUCB RMFINTRV Others

MXG Exits - IMACINIT

IMACINIT is a place to put things you ALWAYS want to have invoked whenever MXG is invoked

Some examples of usage will follow:


You have LPARs in multiple time zones but want all times to be uniform. Add to IMACINIT:– %TIMEBILD(TIMEBILD=YES);– to use VMXGTIME and TIMETABL to

adjust the timestamps of SMF data to a common time zone.


You have site specific global macro variables you want to initialize. Add to IMACINIT:– %GLOBAL MYVAR;– %LET MYVAR=XYZ;

MXG Exits - IMACSHFT

Classic SHIFT definitions may not have the same meaning they once did

There is still usually a big difference in daytime versus nighttime processing

It is useful to assign a FORMAT to the SHIFT variable that describes the SHIFT


You can lead a manager to the documentation but you cannot make him/her read it or remember it from day to day.

Dilbert Principle Summarized:– “A retarded chimpanzee can drink a case

of beer and still perform most management functions.” Scott Adams - Dilbert and the Way of the Weasels


Standard IMACSHFT Defines Shifts as:– 8:00-17:00 Monday-Friday = P– 17:00-08:00 Monday-Friday = N– 08:00 Saturday - 08:00 Monday = W


Are holidays important? They can make a significant difference

in data at the weekly level It is a management decision. If they

want it reported separately - separate it.



Never argue with managers about how they want data reported. You cant win (unless you are a consultant.) Being right is not enough.

They say it is possible to teach a pig to sing but the process annoys the pig and is very frustrating.


Assume that all you want to change is to apply the format you built called $SHIFT to the SHIFT variable.– Place the following in IMACINIT in your

USERID.SOURCLIB %LET MACSHFT=%QUOTE( FORMAT SHIFT $SHIFT.; );


Building the $SHIFT format:– Place the following in IMACFMTS:

PROC FORMAT LIBRARY=LIBRARY; VALUE $SHIFT ‘P’=‘8:00-17:00 Monday-Friday’ ‘N’=‘17:00-08:00 Monday-Friday’ ‘W’=‘Weekends’;


Could also use the FMTSEARCH option and place user formats in a separate library.

In IMACINIT:– OPTION FMTSEARCH=MYFORMAT LIBRARY;

MXG Exits - IMACKEEP

Only thing that needs to be here is the identity of all user SMF records.

Could be done INSTREAM Could be done in IMACINIT


General Syntax:– MACRO _IDxxxx yyyy %– where xxxx is the NAME of the record type

and yyyy is the record number

– Assume STK silos use record number 218– MACRO _IDSTC 218 %


Using IMACKEEP– MACRO _IDSTC 218 %– MACRO _SYNCID 208 %– MACRO _IDHSMDS 219 %– etc etc– Last statement must be:

&MACKEEP ;


Doing it INSTREAM:– %LET MACKEEP=%QUOTE(

MACRO _IDSTC 218 %

– );– %INCLUDE SOURCLIB(TYPSSTC);


Using IMACINIT– MACRO _IDSTC 218 %– MACRO _SYNCID 208 %– MACRO _IDHSMDS 219 %– etc etc


So which is best?– I use IMACKEEP but from time to time may

override using the INSTREAM approach when testing new releases

– Using IMACKEEP in USERID.SOURCLIB ensures that all users get the right answers

MXG Exits -IMACUCB

Suppose you have:– Real 3480 drives– Real 3490 drives– Virtual tape drives– Robotic 3490 drives– Autoloader 3490 drives– Manual 3490 drives– SHARKs– HDS 9900– HDS 7700– etc

MXG Exits - IMACUCB

Device variable for tape drives will be:– 3480– 3490– 3590

Device variable for DASD devices will be:– 3390 (maybe 3380 but not very likely)

MXG Exits - IMACUCB

It may be important to know:– Was it real tape or virtual?– Was it robotic/autoloader/manual?– Which VTS was it?– Was it a 3390-3 or a 3390-9?– Which RAID box is it in?

MXG Exits - IMACUCB

IMACUCB can answer the questions by hammering the DEVICE variable into something more meaningful based on DEVNR.

Makes summaries by DEVICE more meaningful

Allows for reporting by the real DEVICE type

MXG Exits - IMACUCB

MXG Exits - IMACUCB

Can be done as hard-coded IF-THEN-ELSE logic

Can be done as a user FORMAT

MXG Exits - IMACUCB

IF 400X LE DEVNR LE 43FX THEN DEVICE=‘VT01 ‘;ELSE IF 440X LE DEVNR LE 47FX THEN DEVICE=‘VT02 ‘;ELSE IF DEVICE=:’3490’ THEN DO; IF 210X LE DEVNR LE 28FX THEN DEVICE=‘ROBOTIC’; ELSE IF 2B0X LE DEVNR LE 2BFX THEN DEVICE=‘AUTOLOAD’;END;ELSE IF DEVICE=:’3390’ THEN DO; IF 1200X LE DEVNR LE12FFX THEN DEVICE=‘7700-1’; ELSE IF 0A000X LE DEVNR LE 0A7FFX THEN DEVICE=‘9900-1’; ELSE IF 0B000X LE DEVNR LE 0B5FFX THEN DEVICE=‘SHARK 1’;END;

MXG Exits - IMACUCB

Using FORMAT - IMACUCB is:

DEVICE=PUT(DEVNR,MYDEVS.);

Building the FORMAT:

PROC FORMAT LIB=MYFMTS; VALUE MYDEVS 400X-47FX=‘VT01’ 440X-47FX=‘VT02’ 210X-28FX=‘ROBOTIC’ 2B0X-2BFX=‘AUTOLOAD’ 1200X-12FFX=‘7700-1’ 0A000X-0A7FFX=‘9900-1’ 0B000X-0B5FFX=‘SHARK 1’;

MXG Exits - RMFINTRV

Was originally done in IMACWORK Moved here to allow for more workloads

to be defined Can still be done in IMACWORK but

this is a more flexible way to do it


RMFINTRV is the call to VMXGRMFI which builds the RMFINTRV dataset during the BUILDPDB process.

Lots of parameters and options Primary focus here is defining

workloads


Should I use report classes or service classes? Report performance groups or control performance groups?

It Depends!


All questions can be answered with one of the following:

– 42– It Depends– Green– huh?– A withering stare– What is the air speed velocity of a fully laden swallow?

European or African?


If you are in compatibility mode unless you are very careful with report performance groups it is easy to double dip the CPU time

If you are in Goal Mode, that is not an issue (no task can be in more than a single report class) but you can still double dip if you mix report classes and service classes


My opinion (Goal Mode): Use one or the other but don’t try to use

both. It almost invariably causes problems. If you use report classes, EVERY task must be assigned to a report class. No exceptions. I have a strong tendency towards report classes since there can be many more.


My opinion - compat mode Use performance groups exclusively. It

is safer and simpler.


Coding RMFINTRV:

%VMXGRMFI( PDB=PDB, OUTDATA=PDB.RMFINTRV,

INTERVAL=QTRHOUR, SYNC59=1.1, IMACWORK=NO, USECNTRL=COMPAT, USEREPRT=GOAL,

WORKxx=zzzz/yyyyyyyy/pgns/srvclass/system/sysplex/workload ….. );


WORKxx=– xx is number from 1 to 99– zzzz - first four characters of variable names– yyyyyyy - first line of label– pgns - performance group(s) in this workload– srvclass - service class(s) in this workload– system - system(s) participating– sysplex - sysplex(s) participating

– workload - workload(s) participating


Workloads that are not categorized (they fall thru the workload definitions) will be lumped into ‘OTHR’ variables.


WORK1=BAT/Test Batch/1/BATCH

– Says there will be variables in RMF starting with BAT that have labels starting with ‘Test Batch’ where the data was derived from type72 records with a performance group of 1 or a service class of ‘BATCH’.


What if….– System A has report class TSO which is really test– System B (different plex) has same report class which is not

and has TSOTEST which is

Solution:– WORKx=TSO/TSO Test//TSO/SYSA//2,– WORKy=TSO/TSO Test//TSOTEST/SYSB//2– WORKz=TSOP/TSO//TSO/SYSB//3– ...


What if you want to have different summary levels?

Invoke RMFINTRV twice!


Add an RMF interval dataset by workload

%VMXGRMFI( PDB=PDB, OUTDATA=PDB.RMFWORK, INTERVAL=QTRHOUR, SYNC59=1.1, IMACWORK=NO, USECNTRL=GOAL, WORK1=TSO/TSO//////TSO, WORK2=BATCH/BATCH/////BATCH, WORK3=CICS/CICS/////CICS, WORK4=STC/STC/////STC, WORK5=DB2/DB2/////DB2, WORK6=DDF/DDF/////DDF);

MXG Exits - Others

EXTY30UD - controls the existence of type 30 DD segments

IMACINTV - controls the existence of SMF interval records

IMACACCT- allows you to limit the number of accounting fields kept and their size

Defining Kept Variables

Can be done using the ‘MACKEEP’ macro variable to redefine the _Vdddddd macro for a dataset or by using the _Kdddddd macro for the dataset.


Using MACKEEP - drop ZDATE UNITADR UCBTYPE

%LET MACKEEP=%QUOTE(MACRO _VTY21 _WTY21 /* TYPE21 */ (LABEL='TY21: TYPE 21 SMF - TAPE ERROR STATS' KEEP=BLKSIZE BYTEREAD BYTEWRIT CLEAN DCBOFLG DENSITY DEVICE DEVNR ERASE ERRORS LCU NOISE OPEN PERMREAD PERMWRIT SIOCOUNT SMFTIME SYSTEM TAPCUSER TEMPREAD TEMPRBER TEMPRFER TEMPWRER TEMPWRIT VOLSER )%);


Using _Kdddddd - drop ZDATE UNITADR UCBTYPE

%LET MACKEEP=%QUOTE(MACRO _KTY21 DROP=ZDATE UNITADR UCBTYPE%);


Using MACKEEP - ADD variable DRIVE %LET MACKEEP=%QUOTE(MACRO _VTY21 _WTY21 /* TYPE21 */ (LABEL='TY21: TYPE 21 SMF - TAPE ERROR STATS' KEEP=BLKSIZE BYTEREAD BYTEWRIT CLEAN DCBOFLG DENSITY DEVICE DEVNR ERASE ERRORS LCU NOISE OPEN PERMREAD PERMWRIT SIOCOUNT SMFTIME SYSTEM TAPCUSER TEMPREAD TEMPRBER TEMPRFER TEMPWRER TEMPWRIT UCBTYPE UNITADR VOLSER ZDATE DRIVE )%);


Using _Kdddddd - add variable DRIVE

%LET MACKEEP=%QUOTE(MACRO _KTY21 DRIVE%);


Using MACKEEP - ADD variable DRIVE %LET MACKEEP=%QUOTE(MACRO _VTY21 _WTY21 /* TYPE21 */ (LABEL='TY21: TYPE 21 SMF - TAPE ERROR STATS' KEEP=BLKSIZE BYTEREAD BYTEWRIT CLEAN DCBOFLG DENSITY DEVICE DEVNR ERASE ERRORS LCU NOISE OPEN PERMREAD PERMWRIT SIOCOUNT SMFTIME SYSTEM TAPCUSER TEMPREAD TEMPRBER TEMPRFER TEMPWRER TEMPWRIT UNITADR VOLSER ZDATE DRIVE )%);


Using _Kdddddd - add variable DRIVE and drop variable UCBTYPE

%LET MACKEEP=%QUOTE(MACRO _KTY21 DRIVE DROP=UCBTYPE%);

Which Technique is Correct?

Both– First listing all variables makes it more

clear– Second is a lot less typing

Hardware Compression

Applies only to tape format SAS datasets on disk

May be striped May be compressed May be striped and compressed Only a single SAS dataset per DD can be

open at any point in time Useful for things like CICSTRAN DB2ACCT

MXG Installation - BUILDPDB

If you want nothing but the standard PDB, you are ready to rock and roll but… if you want to add records or tailor things you have more work to do.

MXG Installation - BUILDPDB

Originally, if you wanted to add records, you had to use several exits: EXPDBINC EXPDBCDE EXPDBVAR EXPDBOUT. This technique will still work but there is a simpler way.

MXG Installation - UTILBLDP

Say you wanted to add HSM records to the PDB being built. UTILBLDP (a macro utility) can construct the exits as part of MACKEEP in your SYSIN.

For example - to add HSM to the PDB:


%UTILBLDP( OUTFILE=MYSYSIN, BUILDPDB=YES, USERADD=HSM/204);

Tells UTILBLDP that you want to run BUILDPDB, include HSM data on SMF type 204 records in the PDB, and write the SYSIN out to a DD/FILENAME of MYSYSIN.

The SYSIN constructed would be:

MXG Installation - UTILBLDP%LET MACKEEP=%QUOTE( MACRO _SPINCNT 0 % MACRO _SPINUOW 0 % MACRO _TIMEDIF 0 % MACRO _IDHSMDS 204 % MACRO _VARUSER _VARHSM % MACRO _CDEUSER _CDEHSM % MACRO _EPDBOUT _SHSM %);%LET EPDBINC %QUOTE( VMACHSM);%INCLUDE SOURCLIB(BUILDPDB);...


%INCLUDE SOURCLIB(ASUMUOW);%INCLUDE SOURCLIB(ASUMCICX);%INCLUDE SOURCLIB(ASUM70PR);%INCLUDE SOURCLIB(ASUMCACH);%INCLUDE SOURCLIB(ASUMTAPE);%INCLUDE SOURCLIB(ASUMTMNT);%INCLUDE SOURCLIB(ASUMTALO);%INCLUDE SOURCLIB(ASUMDB2A);%INCLUDE SOURCLIB(ASUMDB2B);

Defaults included after BUILDPDB - unless the inputdata is suppressed.


As many user SMF record types as desired can be added (region size may have to be increased):– USERADD=HSM/208 SYNC/214

TSOM/220 ….

– Separated by spaces terminated with a comma or );


What if you want to suppress some records? Say CICS DB2 and the type 74 RMF records

%UTILBLDP( BUILDPBD=YES, OUTFILE=SOURCLIB(MYPDB), SUPPRESS=110 DB2 74);

%UTILBLDP( BUILDPBD=YES, OUTFILE=SOURCLIB(MYPDB), SUPPRESS=74.1);


What if you want to suppress just the 74 subtype 1?

%UTILBLDP( BUILDPBD=YES, MYFILE=INSTREAM, SUPPRESS=110 DB2 74);%INCLUDE INSTREAM;


It is not required that you store the output of UTILBLDP. You can run and execute the code as your SYSIN.

Retaining Data

Weekly/Monthly Processing vs WTD/MTD processing

TREND processing How long?

Processing Cycle

Original Implementation Circa 1983 Worked when SMF volume was small Breaks down as volumes increase

without major changes– primarily a space issue - how large is the

largest dataset when you try to create it at a monthly level

Processing Cycle

BUILDPDB Monday? WEEKBLD1st

Month?MONTHBLD

YES

NO

YES

STOP

NO

DailySMF

7 DAILYPDBs

5Weekly

PDB

MonthlyPDB

Weekly Processing

Uses previous 7 daily PDBs Builds the datasets in sequence May be to tape or to disk Volume can quickly become a problem

WTD Processing

Same logic as weekly but run each day At end of week, the same datasets are

created but the resource consumption is spread out

A key is to reduce the number of variables kept

Monthly Processing

Use last 5 weekly and last 7 daily PDBs to construct the previous calendar month.

Logic MUST run on 1st day of month Can be extraordinarily resource intensive Uses tape format datasets on disk to

avoid multiple mounts

MTD Processing

Like the WTD processing, runs each day with a job at the end of the month to create the next MTD PDB.

Reduce the variables even further than the WTD process

Reduce the datasets retained

WTD/MTD Processing

Both rely on a new macro VMXG2DTE– You specify input and output Ddnames,

dataset name, by list if appropriate, whether or not to use PROC APPEND, what cycle and when to start the cycle, and a list of variables to keep or drop (whichever is shorter).

WTD/MTD Processing

%VMXG2DTE( DDIN=MTDPDB, DDOUT=MTDPDB, APPEND=YES, PDB=PDB, DATASET=JOBS, INITIT=M1, DROPPER=var1 var2);

Month-to date starting on 1st of month using PROC APPEND

WTD/MTD Processing

%VMXG2DTE( DDIN=WTDPDB, DDOUT=WTDPDB, PDB=PDB, DATASET=RMFINTRV, BYLIST=SYSPLEX SYSTEM STARTIME, INITIT=W2, KEEPER=VAR1 var2 …);

WTD starting on Monday (day 2 of week) NOT using PROC APPEND

WTD/MTD Processing

To append or not to append - that is the question– Appending destroys sort order but uses

many fewer resources– Not appending preserves sort order

Personally, in most cases if I am doing reporting I have to sort anyway

WTD/MTD Processing

OTOH, if there is an ABEND, PROC APPEND makes recovery much harder.

Using data steps preserves sort order, allows for recovery by using GDG as input and output.

TRENDing

Most of the important data has a TREND component (member TRNDxxxx)

Utilizes VMXGSUM to do summarization

Radical reduction in space for highly summarized data (6 years history in just under 1000 cylinders)

TRENDing

Designed to run weekly but can be done daily by changing the WEEK.xxxxxxxx to PDB.xxxxxxxx in the member

%VMXGSUM(INVOKEBY=TRNDTMNT, INDATA= WEEK.TAPEMNTS (IN=INWEEK) TREND.TAPEMNTS,…..);

TRENDing

At the same time, change the DD on the input and output TREND datasets so that the TREND database can be a GDG.

%VMXGSUM(INVOKEBY=TRNDRMFI, INDATA= PDB.RMFINTRV (IN=INWEEK)

TRENDIN.TRNDRMFI,OUTDATA=TRENDOUT.TRNDRMFI,

…..);

TRENDing

Or by changing the WEEK.xxxxxxxx to PDB.xxxxxxxx using overrides

%LET TRENDINP=PDB;%INCLUDE SOURCLIB(TRNDTMNT);%INCLUDE SOURCLIB(TRNDTALO);...

TRENDing

TREND database can be made a GDG by using the TRENDNEW TRENDOLD macro variables.

%LET TRENDINP=PDB;%LET TRENDOLD=TRENDOLD;%LET TRENDNEW=TRENDNEW;%INCLUDE SOURCLIB(TRNDTMNT);%INCLUDE SOURCLIB(TRNDTALO);...

What Cycles Should You Run?

‘It depends…’– Volume is the key. If volume is small, the canned

structures work fine. As volume grows, these structures become untenable. The run time becomes longer than can be tolerated. The disk space required for temporary datasets that are pseudo-tape may be unattainable. A daily job that runs for a day is not practical. A weekly job that cannot be completed between IPL’s is impractical.

Retention - One Man’s View

Daily PDB is a GDG with 255 generations Weekly PDB is a GDG with 255 generations with a

reduced set of variables and datasets Monthly PDB is a GDG with 255 generations but a

drastically reduced set of variables and datasets TREND dataset(s) are GDG with 30 generations SPIN dataset(s) are GDG with 30 generations WTDPDB/MTDPDB are GDG with 30 generations

Use of GDGs makes all jobs recoverable by CA11 (which means automatically)

So??? What do you do?

No WEEKLY process No MONTHLY process TREND updated daily (which means the

current week is incomplete) Reduced variable counts No detail at the WEEKLY/MONTHLY

level

Processing Cycle

DailyBUILD

MTD Build

WTD Build

DailyPDB

TREND

MTDPDB

!st ofWeek?

!st ofMonth?

Copyto Month

Copyto Week

STOP

Last Week

LastMonth

TRENDBuild

WTDPDB

DailySMF

SPIN

Where to run - Mainframe vs PC

If you are the only SAS user on the mainframe, the cost of SAS may be onerous. Even if you have a ‘penalty box’ it can be very expensive.

If you are not the only mainframe SAS user, the data management facilities and IO capabilities are generally better on the mainframe.

PC Data Management

VMXGALOC– Allocates directory yourbase\wddmmmyy

on first day of week – Allocates directory yourbase\mddmmmyy

on first day of month– Allows for normal or wtd/mtd processing

and long term data retention without a lot of manual manipulation

PC Data Management

VMXGALOC will soon be built into BLDNTPDB and BLDSMPDB

Where to run?

So, the answer one more time is:

It depends.

Running on a PC

It has been found that using the FTP method built into SAS is more efficient than converting the data to RECFM=U and then downloading. It not only saves a step on the mainframe, it eliminates a write of the data on the PC and jobs have been found to run in 1/3 the time of the FTP and SAS step combined.

Running on a PC

BLDSMPDB automates the MVS/OS 390/zOS BUILDPDB process. It is parameter driven and will handle weekly monthly and trend processing.

With the soon to be addition of VMXGALOC it will be (almost) self sustaining.

Running on a PC

BLDNTPDB is the NT SMF equivalent of BUILDPDB and the base on which BLDSMPDB was constructed.

Using FTP Access

filename smf ftp "’your.smf.dsn'" host=’your.ftp.site’ S370VS rcmd='site rdw' lrecl=32760 prompt;%include sourclib(buildpdb);run;

Note the quoting pattern on the dataset name and the rcmd option.

NOT Using FTP Access

Data must be converted to RECFM=U to preserve the BDW/RDW and downloaded BINARY to preserve the EBCDIC bit patterns.

MXG Installation - Non-SMF

Most common sources– TMS - tape library – DCOLLECT - grazing the DASD farm

Less common– NTSMF– SYSLOG– AIX/other platforms


TMS/DCOLLECT may need to be timed to coordinate with a disaster recovery SYNCHPOINT– Run DCOLLECT at SYNCHPOINT time– Run TYPETMS5 after daily TMS runs– Bring output together to run DAILYDSN


TMC

DASDFARM

TYPETMS5

DCOLLECT

TMCData

DCOLLECTDATA RAW

TYPEDCOL DCOL****datasets

DAILYDSN DATASETS

Every dataset in theshop is representedhere.

My Jobs Run Too Long!!!

IO connect time (data transfer) is the largest single component of the run-time of MXG.

Connect time can be reduced by– reducing kept variables– eliminating unneeded datasets– passing only the SMF records of interest– eliminating sorts

My Jobs Run Too Long!!!

Most likely causes of volume problems– CICSTRAN – DB2ACCT– DB2ACCTP– DB2ACCTB– TYPE74– TYPE74CA– TYPE42DS - if you add TYPE42 data

SMF Volumes

SMF Volumes

Tailored

MCT Rollout

My Jobs Run Too Long!!!!!!

It is after all, just an application not unlike any other application

Apply all of the tricks and techniques you use on applications

Parallelism may be the answer - if it won’t run serially, run it in parallel

Parallel Streams

Stream 1 - MYBLDPDB– Processes normal BUILDPDB but excludes

all CICS, DB2, and IO related data is the average response time to DASD across

20,000+ volumes a significant metric in RMFINTRV? Probably not.

Parallel Streams - Stream 1

%UTILBLDP( SUPPRESS=DB2 CICS 73 74 75 78, ZEROOBS=73 74 75 78, USERADD=whatever, OUTFILE=SOURCLIB(MYBLDPDB));

There will be MXGWARN messages in theLOG about datasets not being included thatRMFINTRV is expecting.

Parallel Streams

Stream 2 - BLDIOPDB– Process IO related data

type 42 type 73 type 74 type 75 type 78 etc.

Parallel Streams - Stream 2

%UTILBLDP( BUILDPDB=NO, USERADD=42 73 74 75 78, INCLAFTR=ASUMCACH ASUM42DS, OUTFILE=SOURCLIB(BLDIOPDB));

Parallel Streams

Stream 3 - BLDCISTA– Process CICS Statistics

Stream 4 - DALYDSET– MXG member ANALDSET

Stream 5 - BILDDCOL– Process DCOLLECT data

Parallel Streams

Stream 6 - BUILDTMS– Process TMS Catalog

Stream 7 - BILDDSNS– Combine TMS and DCOLLECT data

Stream 8 - DB2PDB (3 times daily)– Process DB2 data

Parallel Streams

Stream 9 - BLDCISTR (3 times daily)– Process CICS transaction data

Stream 10 - ASUMUOW– Combine CICS/DB2 into Unit of Work

summary

First Do This!!!!!!!

I SMF IFASMFDP

MANx


ArchivalDaily SMF

EODSMF

NOTYPE 99 101 110

SMFDumps

IFASMFDP


SMFDumpsSMF

DumpsSMFDumpsSMF

Dumps

After all dumps are completeDuplicate process for CICS and DB2but eliminate disk copy

SMFTYPE 110

SMFTYPE 101

CICS

DB2Do the CLEAR in a secondstep

SMFTYPE 99

WLM

So?? What do you do?

Parallel Jobs - example

CMFData

DB2SMF Data

TYPE110

TYPEDB2

BUILDPDB

BLDIOPDB

CICSTRAN

DB2PDB

DailyPDB

Daily IO PDB

ASUMUOW ASUMUOW

WTD/MTD

MTDPDB

WTDPDB

DailySMF/RMF

CICS/DB2 Volume Problem

Processing of CICS/DB2 SMF data into ASUMUOW is time consuming

3 times/day 3-4 hours each (was 7-9 hours before latest re-architecture)– CICS volume is 176GB of SMF data 30M observations

(and this was a light day)– DB2 volume is 106GB SMF data 40M obs in DB2ACCT– Other SMF (excluding type 99) was only 35GB in 31M

records– Type 99 is about 20GB

Volume is growing 30-40%/year

CICS/DB2 Volume Problem

CICSTRAN and DB2ACCT must be sorted prior to merge

TAPE IO is bottleneck - CICSTRAN dataset is 5-6 volumes of tape at 10-15 minutes/volume to move data

Data is read/written by data step, by sort then read by data step - 5 full passes

DB2ACCT is even worse. Created in huge volumes (10-12 cartridges 3 times/day) but likely never ever read again!

CICSSMF

DB2SMF

CICSTRANSORTED

CICSTRAN

DB2ACCTSORTED

DB2ACCT

TYPE110

ASUMUOW

SORT

SORTTYPEDB2

ASUMUOW

8-9 Hours

Original Architecture

5-6 tapes 5-6 tapes

5-6 tapes

1-2 tapes

2002

CICSSMF

DB2ACCTSORTED

DB2 SMF

CICSTRANSORTED

ASUMUOW

TYPE110/SORT

TYPEDB2/SORT

ASUMUOW

6-8 Hours

Using VIEW from DATA Step to SORT

2003

Still a Problem

Most of the elapsed time in the DB2 thread is due to the writing of 3 detail datasets that are HUGE– DB2ACCT– DB2ACCTB– DB2ACCTP

CICSSMF

DB2 SMF

CICSTRANSORTED

ASUMUOW

TYPE110/SORT

TYPEDB2/SORT

ASUMUOW

3-4 Hours

Using VIEW from DATA Step to SORT

Today

Only OBS with QWHCATYP=4and only variables needed for ASUMUOW

DB2ACCT

CAPPLANDB2ACCT

All variables only OBSGT 5 second elapsed

All OBS only variables wanted by capacity planning

UOWDB2

DB2PDB

Other DB2 Data

Success!!

Observations reduced by 90-95%!! Run time significantly reduced!

But… remember axiom 2. As current growth rates continue, the run time will expand and when it reaches 6 hours (at 3 times per day that is 18 hours) it will be time to adjust again.

But… what about space?

As volumes grow, getting DASD space can be a problem.

Options– SAS compression– DASD hardware compression– Tape

SAS Compression

Default in MXG Advantages

– simple - it is already there– allows data to flow across many volumes

Disadvantages– CPU cost

DASD Compression

Advantages– Allows for the use of striping and lots of

buffers Disadvantages

– CPU time – Only 1 dataset per DD can be open – Cannot be used for work

Tape Datasets

Advantages– CPU for compression offloaded to control

unit Disadvantages

– Tape mount delays– Overloading of VTS– Channel delays

So which is best?

Guess what? - It depends! SAS compression used on almost

everything Some cases (TYPE74 TYPE74CA)

DASD compression used Some cases (CICSTRAN DB2ACCT)

tape is used

CICS Growth

Fri afterTurkeyDay

Fri AfterTurkey Day

DB2 Growth

HOURS!!!

Growth

“Forecasting: A method invented by weasels to make people stop asking questions.” Dilbert and the Way of the Weasel

CICSSMF

DB2 SMF

ASUMUOW

TYPE110/SORT

TYPEDB2/SORT

ASUMUOW

2.3 Hours

Using VIEW from DATA Step to SORT PIPE from SORT to ASUMUOW

CICSTRANSORTED

DB2ACCTSORTED

fitting

fitting

DB2 Processing

pipe

pipe

Next Step

Using VIEW from DATA Step to SORT PIPE from SORT to ASUMUOW

Requires batch pipes for SAS - that will mean at least V8.2 and maybe V9

DB2 Processing must be in 2 steps – the fitting for DB2ACCT can’t be reopened

for input within the same job step. There may be a way to get around this but I haven’t found it yet.

In the Toolbox

I hate writing and rewriting the same programs so I write tools (macros) that handle the repetitive tasks. Where appropriate they find their way into MXG.

Using Some MXG Tools

VMXGSUM UTILBLDP for Ad-Hoc processing ANALCNCR ANALDB2R VMXGGETM VMXGGMT VMXGCOMP VMXGPRAL

VMXGSUM

Generalized summarization of ANY SAS dataset

– Uses PROC MEANS to do summarization– SORTs data– Allows for changes in input and output data– Optimizes variables kept – Carries labels and formats thru summarization– Allows for long variable names– Allows for normalization of variables and changing time

intervals

VMXGSUM

Common in reporting:– DATA xxxx;– SET yyyy;– PROC SORT DATA=xxxx;– PROC MEANS DATA=XXXX OUT=zzzz;– DATA final;– SET zzzz;

VMXGSUM is a short-hand way of coding a repetitive set of commands.

Used extensively internally in many MXG members but especially common in ASUM**** and TRND**** members.

VMXGSUM

VMXGSUM - SYNTAX

%VMXGSUM(– INDATA= input dataset(s) name– OUTDATA= output dataset name– SUMBY= list of variables by which data

should be sorted– INCODE= a stub of SAS code executed

during the first data step– OUTCODE= a stub of SAS code executed

during the final data step

VMXGSUM - SYNTAX

– INTERVAL= how to change the time interval. Valid values are:

QTRHOUR HALFHOUR HOUR THREEHR MINUTE WEEK MONTH MYTIME

– DATETIME= the variable name of the variable containing the datetime value on which INTERVAL= will be applied

– SYNC59= if your time is synched to 59 minutes, will add 60 seconds before calculating interval if set to YES

VMXGSUM - SYNTAX

ID= list of variables that will be carried forward as ID values

AUTONAME=YES/NO autoname = yes says to use the autonaming functions of SAS V8 to name the output variables. This allows the specification of the same variable name in multiple lists but changes the output variable name to variable_suffix where suffix is the name of the function performed on the variable.

VMXGSUM - SYNTAX

SUM= list of variables to be summed MAX= list of variables to be maxxed MIN= list of variables to be minned MEAN= list of variables to be meaned P1= list of variables to get percentile 1 P5= 5th percentile variables P10= 10th percentile variables

VMXGSUM - SYNTAX

– P25 P50 P75 P90 P95 P99 - percentile values

– STD - Standard Deviation– VAR - variance– CV - coefficient of variance– STDERR - Standard error– KURTOSIS - Kurtosis– T - T value

VMXGSUM - Syntax

NORM1-NORM99 - normalization of data. Maintaining rates as rates and not averages of averages. On the front-end, the rate has to be multiplied by the duration and on the back end divided again to recalculate the correct rate.

VMXGSUM - SYNTAX

– NORM1-NORM99 - syntax rate1 rate2 rate3…ratex/duration

List the variables to be normalized followed by a / then the variable to be used to do the normalization.

VMXGSUM - SYNTAX

There are other parameters. See the documentation in the member for usage and the member ADOCSUM.

VMXGSUM - Example 1

Summarize the dataset TYPETMNT by DEVICE and TMNTTIME calculating average mount delay and the total number of mounts per quarter hour.

%vmxgsum( indata=pdb.typetmnt, outdata=tapemnts, sumby=device tmnttime, interval=qtrhour, datetime=tmnttime, mean=tapmnttm, freq=mounts);

VMXGSUM - Example 2

Summarize the Goal Mode type 72 records for the TSO service class calculating the average response time, the number of transactions at one hour intervals by period.

VMXGSUM - Example 2

%VMXGSUM( INDATA=PDB.TYPE72GO, OUTDATA=TSOSUM, SUMBY=STARTIME PERIOD, INCODE= IF SRVCLASS=‘TSO’;, SUM=RESPAVG NUMTRAN, NORM1=RESPAVG/NUMTRAN, INTERVAL=HOUR, DATETIME=STARTIME);

VMXGSUM Usage Notes

NORMx operands must be contiguous starting at 1. That is, you cannot have NORM1 and NORM3 without a NORM2.

TEMP01/TEMP02 DDs are recognized for increasing work space but with V8 and compression it is not usually needed and is no longer recommended.

VMXGSUM Usage Notes

The first data step is almost always converted to a VIEW rather than a real data step.

KEEPALL=NO is resource intensive and not really needed except in odd cases. KEEPALL=YES is much preferred. The keep lists on all output datasets are optimized regardless of KEEPALL setting.

Why VMXGSUM?

So why not just use PROC MEANS with CLASS operands?

VMXGSUM in tests is usually much more efficient and in some cases will do the summarization where using PROC MEANS or PROC SUMMARY with CLASS operands runs out of memory.

VMXGSUM - Hysterical Note

The ‘keeping’ logic in VMXGSUM was intended by Barry to reduce the size of the input data and therefore the amount of data moved in the first data step. After years of arguing, he was finally convinced that it did not work that way and KEEPALL=YES became preferred.

UTILBLDP - Ad-Hoc

Say you need to read the 1415 6156 64 and 30 records (ANALDSET?) in a single pass for an ad-hoc report.

%UTILBLDP(BUILDPDB=NO, USERADD=1415 6156 64 30, OUTFILE=INSTREAM, SORTOUT=NO);%INCLUDE INSTREAM;

ANALCNCR

Counts concurrent events. How many of something were happening at the same time.

ANALCNCR - History

Method used in original release of MXG:– DO TIME=BEGIN TO END BY 5;– OUTPUT;– END;– Then add up all the observations with a

given value of TIME. Created a HUGE number of observations and was cumbersome.

ANALCNCR - History

Method used with ANALCNCR:– TIME=BEGIN;COUNT=1;OUTPUT;– TIME=END;COUNT=-1;OUTPUT;

– Now add up the counts by time and you are done (basically.) Many many fewer observations.

ANALCNCR - History

If there are three tape allocations:

– Allocation 1 begins at 08:00 ends at 08:30– Allocation 2 begins at 08:15 ends at 08:25– Allocation 3 begins at 08:20 ends at 08:45

ANALCNCR - History

MAX of 3 concurrent allocations– 15 minutes of 1 – 5 minutes of 2 – 5 minutes of 3 – 5 minutes of 2 – 15 minutes of 1

Old method– Allocation 1 - 1800/5=360 obs– Allocation 2 - 600/5=120 obs– Allocation 3 - 1500/5=300 obs– Total = 780 obs

New Method– Each allocation is 2 OBS– Total = 6

ANALCNCR - Example 1

How many jobs are running concurrently in class A average and max.

%ANALCNCR(INDATA=PDB.JOBS, OUTSUMRY=RUNTIME, SUMBY=JOBCLASS, INCODE=IF TYPETASK=‘JOB’;, INTERVAL=QTRHOUR, STARTIME=JINITIME, ENDTIME=JTRMTIME, OTCODESM= AVGRUN=CONCURNT/DURATM; RENAME MAXCNCR=MAXRUN;);PROC PRINT;ID JOBCLASS TIMESTMP;VAR AVGRUN MAXRUN;


Now suppose you want the INPUT QUEUE time for the same job class.

%ANALCNCR(INDATA=PDB.JOBS, OUTSUMRY=QUETIME, SUMBY=JOBCLASS, INCODE=IF TYPETASK=:’JOB’;, INTERVAL=QTRHOUR, STARTIME=READTIME, ENDTIME=JINITIME, OTCODESM= AVGQUE=CONCURNT/DURATM; RENAME MAXQUE=MAXRUN;);PROC PRINT;ID JOBCLASS TIMESTMP;VAR AVGQUE MAXQUE;


Now put the two outputs together

DATA JOBSTAT;MERGE RUNTIME QUETIME;BY JOBCLASS TIMESTMP;PROC PRINT;ID JOBCLASS TIMESTMP;VAR AVGQUE AVGRUN MAXQUE MAXRUN;

ANALDB2R

ANALDB2R is a reverse engineered semi-clone of IBM’s DB2PM.

Most DB2PM reports can be produced from either a PDB or raw SMF data.

Parameter driven and documented in the member as well as in ADOCDB2R.

VMXGGETM

Get specific types and subtypes of SMF data up to x number. Great for building a test case for processing or extracting samples of data to send to Merrill Consultants for analysis in problem solving.

VMXGGETM

Get the type 30 and type 230 records all subtypes and write to SMFOUT the first 100 OBS of each.

%VMXGGETM( ID=30 230, SUBTYPE=ALL, NRECORD=100, SMFOUT=SMFOUT);

VMXGGMT

Adjust the timestamps of SMF data (or any other time stamp) to a specific offset

Useful if you have multiple LPARs in differing time zones and you want a uniform picture.

VMXGGMT

Three pieces– TIMETABL - A table of SYSTEM/SYSPLEX ID

with datetime ranges and offsets from GMT– TIMEBILD - builds a FORMAT based on the

values in TIMETABL and enables VMXGGMT– VMXGGMT - macro imbedded in all MXG

members that will adjust times based on the values contained in TIMETABLE so that midnight is always midnight.

VMXGGMT - Usage

Build your TIMETABLE In IMACINIT, insert:

– %TIMEBILD(TIMEBILD=YES); VMXGGMT imbedded in MXG will now

be active. Without the %TIMEBILD, the

VMXGGMT invocations are nulled

VMXGCOMP

Compare all of the members of two SAS data libraries– useful in testing new releases to compare

results– identifies common datasets, new datasets,

dropped datasets– compares values in common datasets

VMXGCOMP

Syntax

%VMXGCOMP( NEWDD=PDB, OLDDD=OLDPDB, NOBS=100);

VMXGPRAL

Print the contents of all of the members of a SAS data library, do a PROC MEANS of the numeric variables, and print X number of OBS.

%VMXGPRAL( DDNAME=PDB, NOBS=10);

VMXGPRAL

Or print the contents of all opened allocated SAS data libraries

%VMXGPRAL(DDNAME=_ALL_,NOCONT=);

VMXGPRAL

Or print the contents of the data libraries in which you are interested

%VMXGPRAL(DDNAME=PDB SPIN,NOCONT=,NOSPLIT=NOSPLIT);

MXG Tools

There are lots more. Look for SOURCLIB members that start with ANAL, VMXG, VGET, UTIL.

Documentation is contained within the members and in some cases (ANALDB2R for example) there may also be an ADOC member.

Questions

There are no stupid questions except those you don’t ask.– Prof Hartmann - PSY 101 Purdue

MXG - Simplified (MXG for Dummies) Chuck Hopf Merrill Consultants.

Documents

capacity planning issue

data centers

data retention

gb of data

mxg simplifiedmxg

installed mxg

mxg installation

daythe capacity