Transcript MXG - Simplified

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
–

May need CICS data
–

type 110
May need DB2 data
–

type 6 26 30
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 - chargeback, 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)
JWT(0014)
SYNCVAL(59)
INTVAL(15)
/* WRITE STATS EVERY 15M */
/* 522 AFTER 14 MINUTES */
/* SYNC TO MINUTE 59 */
/* 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)

From Chapter 3 of MXG:

Number of DDs




70,000
35,000
10,000
/* DON'T CONSOLIDATE T30 EXCP */
CPU Before
DDCONS(YES)
CPU After
DDCONS(NO)
4 hr 5 min
1 hr 3 min
6 min
8 min
3 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
Single System that does not fill a full dataset in a day
Working Copy
Daily SMF
I SMF
IFASMFDP
Archival
Daily SMF
MANx
Processing SMF Data - Less Simple
Multiple Systems that do not fill a full dataset in a day
I SMF
SYS1
IFASMFDP
Daily SMF
SYS1
MANx
I SMF
SYS2
IFASMFDP
Working Copy
Daily SMF
IFASMFDP
Daily SMF
SYS2
At this point does not HAVE to be
IFASMFDP
Archival
Daily SMF
MANx
Repeat as needed for more
systems
Processing SMF Data -Usual Case
Multiple Systems that fill multiple datasets in a day
When datasets fill and at end of day,
issue I SMF on each system
I SMF
IFASMFDP
MANx
SMF
Dumps
After all dumps are complete
EOD
SMF
SMF
Dumps
SMF
Dumps
SMF
Dumps
SMF
Dumps
Dumps
Working Copy
Daily SMF
IFASMFDP
Archival
Daily SMF
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
*/
RMF Monitor III Parameters









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
RMF Monitor III Parameters

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 postprocessed
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
RMF III
Switch
detected
RMF III
DATA
STORE
IDCAMS
REPRO
ERB813I indicating a new RMF III dataset is active
RMF III
ARCHIVE
Crazy Chuck Axiom #2

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
When datasets fill and at end of day,
issue I SMF on each system
I SMF
IFASMFDP
MANx
Do the CLEAR in a second
step
After all dumps are complete
Duplicate process for CICS and DB2
but eliminate disk copy
SMF
NOTYPE
99 101 110
EOD
SMF
CICS
TYPE 110
SMF
TYPE 101
DB2
SMF
TYPE 99
WLM
SMF
SMF
Dumps
SMF
Dumps
SMF
Dumps
SMF
Dumps
Dumps
Working Copy
Daily SMF
IFASMFDP
Archival
Daily SMF
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
When datasets fill and at end of day,
issue I SMF on each system
I SMF
MANx
SMF
TYPE
99
SMF
NOTYPE
101 110
IFASMFDP
CICS1
TYPE 110
CICS APPL 1
CICS2
TYPE 110
CICS APPL 2
CICS3
TYPE 110
CICS APPL 3
SMF
TYPE 101
DB2
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
MXG Installation - 1st Time

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);
MXG Installation - 1st Time
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
...
MXG Installation - 1st Time
//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
MXG Installation - 1st Time
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
MXG Installation - After the 1st
Do testing:
//STEP1 EXEC MXG
//LIBRARY DD DSN=MXG/Vrelease.FORMATS,DISP=SHR
//SOURCLIB DD
//
DD
//
DD DSN=MXG.Vrelease.SOURCLIB,DISP=SHR
MXG Installation - After the 1st
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

MXG Installation - After the 1st

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:

MXG Exits - IMACINIT

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.
MXG Exits - IMACINIT

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

Crazy Chuck Axiom #3
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
MXG Exits - IMACSHFT

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
MXG Exits - IMACSHFT
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.

MXG Exits - IMACSHFT
Crazy Chuck Axiom #4
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.

MXG Exits - IMACSHFT

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.;
MXG Exits - IMACSHFT

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’;
MXG Exits - IMACSHFT
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

MXG Exits - IMACKEEP

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 %
MXG Exits - IMACKEEP

Using IMACKEEP
–
–
–
–
–
MACRO _IDSTC 218 %
MACRO _SYNCID 208 %
MACRO _IDHSMDS 219 %
etc etc
Last statement must be:
 &MACKEEP
;
MXG Exits - IMACKEEP

Doing it INSTREAM:
–
%LET MACKEEP=%QUOTE(
 MACRO
–
–
_IDSTC 218 %
);
%INCLUDE SOURCLIB(TYPSSTC);
MXG Exits - IMACKEEP

Using IMACINIT
–
–
–
–
MACRO _IDSTC 218 %
MACRO _SYNCID 208 %
MACRO _IDHSMDS 219 %
etc etc
MXG Exits - IMACKEEP

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-THENELSE 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

MXG Exits - RMFINTRV
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

MXG Exits - RMFINTRV

Should I use report classes or service
classes? Report performance groups or
control performance groups?

It Depends!
Crazy Chuck Axiom #5

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?
MXG Exits - RMFINTRV
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

MXG Exits - RMFINTRV
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.

MXG Exits - RMFINTRV
My opinion - compat mode
 Use performance groups exclusively. It
is safer and simpler.

MXG Exits - RMFINTRV
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
…..
);
MXG Exits - RMFINTRV

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
–
–
–
–
–
–
MXG Exits - RMFINTRV

Workloads that are not categorized
(they fall thru the workload definitions)
will be lumped into ‘OTHR’ variables.
MXG Exits - RMFINTRV

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’.
MXG Exits - RMFINTRV

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
...
MXG Exits - RMFINTRV

What if you want to have different
summary levels?

Invoke RMFINTRV twice!
MXG Exits - RMFINTRV

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.
Defining Kept Variables

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
)
%
);
Defining Kept Variables

Using _Kdddddd - drop ZDATE UNITADR
UCBTYPE
%LET MACKEEP=%QUOTE(
MACRO _KTY21
DROP=ZDATE UNITADR UCBTYPE
%
);
Defining Kept Variables

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
)
%
);
Defining Kept Variables

Using _Kdddddd - add variable DRIVE
%LET MACKEEP=%QUOTE(
MACRO _KTY21
DRIVE
%
);
Defining Kept Variables

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
)
%
);
Defining Kept Variables

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:
MXG Installation - UTILBLDP
%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);
...
MXG Installation - UTILBLDP
%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 input
data is suppressed.
MXG Installation - UTILBLDP

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 );
MXG Installation - UTILBLDP

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
);
MXG Installation - UTILBLDP

What if you want to suppress just the 74
subtype 1?
%UTILBLDP(
BUILDPBD=YES,
OUTFILE=SOURCLIB(MYPDB),
SUPPRESS=74.1
);
MXG Installation - UTILBLDP

It is not required that you store the
output of UTILBLDP. You can run and
execute the code as your SYSIN.
%UTILBLDP(
BUILDPBD=YES,
MYFILE=INSTREAM,
SUPPRESS=110 DB2 74
);
%INCLUDE INSTREAM;
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
Daily
SMF
STOP
NO
NO
YES
BUILDPDB
Monday?
1st
Month?
WEEKBLD
YES
MONTHBLD
Monthly
PDB
7
DAILY
PDBs
5
Weekly
PDB
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

Month-to date starting on 1st of month
using PROC APPEND
%VMXG2DTE(
DDIN=MTDPDB,
DDOUT=MTDPDB,
APPEND=YES,
PDB=PDB,
DATASET=JOBS,
INITIT=M1,
DROPPER=var1 var2
);
WTD/MTD Processing

WTD starting on Monday (day 2 of
week) NOT using PROC APPEND
%VMXG2DTE(
DDIN=WTDPDB,
DDOUT=WTDPDB,
PDB=PDB,
DATASET=RMFINTRV,
BYLIST=SYSPLEX SYSTEM STARTIME,
INITIT=W2,
KEEPER=VAR1 var2 …
);
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
Daily
SMF
Daily
BUILD
SPIN
WTD
Build
Daily
PDB
WTD
PDB
TREND
Build
TREND
MTD
Build
MTD
PDB
!st of
Week?
Copy
to Week
Last
Week
STOP
!st of
Month?
Copy
to Month
Last
Month
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
MXG Installation - Non-SMF

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
MXG Installation - Non-SMF
TMC
TYPETMS5
TMC
Data
DAILYDSN
DATASETS
Every dataset in the
shop is represented
here.
DASD
FARM
DCOLLECT
DCOLLECT
DATA RAW
TYPEDCOL
DCOL****
datasets
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 the
LOG about datasets not being included that
RMFINTRV 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
–

Stream 4 - DALYDSET
–

Process CICS Statistics
MXG member ANALDSET
Stream 5 - BILDDCOL
–
Process DCOLLECT data
Parallel Streams

Stream 6 - BUILDTMS
–

Stream 7 - BILDDSNS
–

Process TMS Catalog
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!!!!!!!
When datasets fill and at end of day,
issue I SMF on each system
I SMF
IFASMFDP
MANx
Do the CLEAR in a second
step
After all dumps are complete
Duplicate process for CICS and DB2
but eliminate disk copy
SMF
NOTYPE
99 101 110
EOD
SMF
CICS
TYPE 110
SMF
TYPE 101
DB2
SMF
TYPE 99
WLM
SMF
SMF
Dumps
SMF
Dumps
SMF
Dumps
SMF
Dumps
Dumps
Working Copy
Daily SMF
IFASMFDP
Archival
Daily SMF
So?? What do you do?

Parallel Jobs - example
CMF
Data
TYPE110
CICSTRAN
ASUMUOW
DB2
SMF Data
TYPEDB2
DB2PDB
BUILDPDB
Daily
PDB
Daily
SMF/RMF
ASUMUOW
WTD
PDB
WTD/MTD
BLDIOPDB
Daily
IO PDB
MTD
PDB
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!
Original Architecture
2002
CICS
SMF
TYPE110
5-6 tapes
CICSTRAN
SORT
CICSTRAN
SORTED
5-6 tapes
5-6 tapes
ASUMUOW
ASUMUOW
1-2 tapes
DB2
SMF
TYPEDB2
DB2ACCT
SORT
8-9 Hours
DB2ACCT
SORTED
Using VIEW from DATA Step to SORT
2003
CICS
SMF
TYPE110/
SORT
CICSTRAN
SORTED
ASUMUOW
DB2
SMF
TYPEDB2/
SORT
6-8 Hours
DB2ACCT
SORTED
ASUMUOW
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
Using VIEW from DATA Step to SORT
Today
CICS
SMF
TYPE110/
SORT
All OBS only variables
wanted by capacity
planning
All variables only OBS
GT 5 second elapsed
DB2
SMF
CICSTRAN
SORTED
ASUMUOW
ASUMUOW
CAPPLAN
DB2ACCT
Other DB2
Data
DB2PDB
DB2ACCT
TYPEDB2/
SORT
3-4 Hours
UOWDB2
Only OBS with QWHCATYP=4
and only variables needed for
ASUMUOW
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 after
Turkey
Day
Fri After
Turkey Day
DB2 Growth
HOURS!!!
Growth

“Forecasting: A method invented by
weasels to make people stop asking
questions.” Dilbert and the Way of the
Weasel
Using VIEW from DATA Step to SORT
PIPE from SORT to ASUMUOW
Next Step
CICS
SMF
TYPE110/
SORT
fitting
CICSTRAN
SORTED
pipe
ASUMUOW
ASUMUOW
pipe
DB2
SMF
TYPEDB2/
SORT
fitting
2.3 Hours
DB2ACCT
SORTED
DB2
Processing
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
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 - 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 frontend, 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
 List
rate2 rate3…ratex/duration
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
–
–
–
–
–

Old method
–
–
–
–

15 minutes of 1
5 minutes of 2
5 minutes of 3
5 minutes of 2
15 minutes of 1
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;
ANALCNCR - Example 2

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;
ANALCNCR - Example 3

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