CMG 2006 - PowerPoint PPT Presentation

About This Presentation

Title:

CMG 2006

Description:

CMG 2006 – PowerPoint PPT presentation

Number of Views:242

Avg rating:3.0/5.0

Slides: 25

Provided by: barrym9

Category:

Tags: cmg | pav

more less

Transcript and Presenter's Notes

Title: CMG 2006

1
(No Transcript)
2
(No Transcript)
3
CMG 2006

zIIP ZIP engines and their new data.
ASMTAPEE/ASUMTAPE enhancements.
3. PDSE Caching statistics in TYPE1415.
4. ASUM70PR/ASUMCEC major revisions.
5. RMF Monitor III INDXUSED
6. Detecting CRYPTO usage.
7. SAS ftp access faster than ftp download.
8. DB2TCBTM in DB2ACCT larger than TASCPUTM in
CICSTRAN.
9. Static versus dynamic allocation of SORTWKnn
DDs.
10. Support for HyperPaV
H. W. "Barry" Merrill, PhD
Merrill Consultants
Dallas, TEXAS
www.mxg.com
Tuesday, December 4, 2006
Reno, NV

1. zIIP ZIP engines and their new
variables.
The metrics and variables for the new zIIP
engines are very much like the metrics for
IFA/zAAP engines. Unlike IFAs, which typically
offload very little current CPU time (due to
lack of Java?), the ZIPs in the field are
showing many hours of CPU time per day
offloaded. -TYPE30 New Variables
CPUZIPTM'TOTALEQUIVALENTCPU TIMEON_ZIP'
CPUEZITM'INDEPENDENTENCLAVECPU TIMEON ZIP'
CPUDZITM'DEPENDENTENCLAVECPU TIMEON ZIP'
CPUZIETM'ZIP-ELIGIBLECPU TIMEON CP'
CPUEZETM'ZIP-ELIGIBLEIND ENCLAVECPU TIMEON
CP' CPUDZETM'ZIP-ELIGIBLEDEP ENCLAVECPU
TIMEON CP' CPUEZQTM'ZIP-QUALIFIEDIND
ENCLAVECPU TIME' CPUDZQTM'ZIP-QUALIFIEDDEP
ENCLAVECPU TIME' ZIPUNITS'ZIP-EQUIVALENTCPU
SERVICEUNITS' ZIEUNITS'ZIP-ELIGIBLECPUSER
VICEUNITS'
5

-TYPE70 New Variables NRZIPS 'NUMBER
OFZIPENGINESAVAILABLE' SMF70SUP'ZIP
PROCESSORSONLINEAT END OFINTERVAL'
PCTZIPBY'ALL ZIPSPERCENTBUSY (DISPATCHED)'
ZIPAVAIL'ZIPPROCESSORAVAILABLE?'
ZIPACTTM'ZIP ENGINEEXECUTING(ACTIVE) CPU
TIME' ZIPUPTM 'ZIP ENGINEAVAILABLE(UP)
TIME' ZIPWAITM'TOTALZIP WAITDURATION'
ZIPWAIT0'ZIP WAITDURATIONZIP 0'
ZIPWAIT1'ZIP WAITDURATIONZIP 1'
ZIPWAIT2'ZIP WAITDURATIONZIP 2' ...
engines 3 thru 30 ... ZIPWAITW'ZIP
WAITDURATIONZIP 31' ZIPWAITX'ZIP
WAITDURATIONZIP 32' PCTZIBY0'ZIP
0PERCENTCPU BUSY TIME' PCTZIBY1'ZIP
1PERCENTCPU BUSY TIME' PCTZIBY2'ZIP
2PERCENTCPU BUSY TIME' ... engines 3
thru 30 ... PCTZIBYW'ZIP 31PERCENTCPU BUSY
TIME' PCTZIBYX'ZIP 32PERCENTCPU BUSY TIME'
6

-TYPE72GO New Variables CPUZIETM'ZIPELIGIB
LECPUTIME' CPUZIPTM'ZIPCPUTIME'
R723CIFA'IFASERVICEUNIT'
R723CIFC'IFA-ELIGIBLESERVICEUNITS'
R723CSUC'ZIP-ELIGIBLESERVICEUNITS'
R723CSUP'ZIPSERVICEUNITS'
R723SUCU'ZIP-ELIGIBLEON CPUSING SAMP'
R723SUPD'ZIPDELAYSAMPLES'
R723SUPU'ZIPUSINGSAMPLES'
ZIEUNITS'ZIPELIGIBLEUNITS'
ZIPUNITS'ZIPSERVICEUNITS' -DB2 CPU Time
fields QWACZIxx added to DB2ACCT
QWACZIEL'CPU TIMEZIP ELIGIBLEON CPENGINE'
QWACZIS1'CPU TIMEEXECUTINGON ZIIP'
QWACZIS2'CPU TIMEIN DB2EXECUTINGON ZIIP'
QWACZITR'CPU TIMEIN TRIGGERSEXECUTINGON
ZIIP' -DB2 CPU Time field QPACZITM for Package
ZIP execution QPACZITM'CPU TIMETHIS
PACKAGE/DBRMON ZIP
7

-RMF Monitor III fields added to CPUG3 segment
for zips CPUITSUP'LOGICAL CPUTIME
ONZIPPROCESSORS' CPUPRSUP'ONLINETIME ON
ZIPPROCESSORS' CPUSTSUP'PHYSICAL CPUTIME
ONZIPPROCESSORS' CPUSUCOL'AVERAGEZIPSONLI
NEDURINGINTERVAL' CPUSUCON'ZIP
ENGINESONLINEAT END' -ASUMCEC new ZIP and IFA
utilizations PCTIFABY'ALL IFASPERCENTBUSY
(DISPATCHED)' PCTZIPBY'ALL ZIPSPERCENTBUSY
(DISPATCHED)' -And now that IFA/ZIP text is in
all MXG variable labels, the APAR documents that
IBM has changed RMF reports to now print 'AAP'
for IFA/zAAPs and 'IIP' for zIIPs, but I am not
going to change either those existing labels nor
the variable names that already exist.
8

IFAHONORPRIORTY options in SRM IEAOPTxx option
changed.
APAR OA14131 changes the SRM IEAOPTxx option
See WSC FLASH10432 for additional information.
The IFACROSSOVER option is no longer needed to
use
IFAHONORPRIORITYYES.
If both IFACROSSOVER and IFAHONORPRIORITY are
specified
both specified YES, they operate independent
of each other.
The intent of the APAR is to allow more zAAP
eligible work to run on zAAP processors,
while still remaining responsive to the zAAP
demand.

2. ASMTAPEE ML-39 and ASUMTAPE 24.04
enhancement/validation. -ASMTAPEE/MXGTMNT is
Exit Driven for Mount events, no samples, no
cross memory service calls For STK HSC Exit,
Sun/STK techies installed MXGTMNT and
ASMHSCEX and in STK tests we saw 100 of all
mounts. For IBM Exit, we miss second volume
of multi-volume and mounts from HSM, DMS,
and OPC. Capture of SYSLOG events added in
ML37 is outstanding. Now, ML-39 captures even
suppressed SYSLOG messages (suppressed
messages caused zero obs in TYPESYMT) -ASUMTAPE
in MXG 24.04 enhancements new variables
BEGTMNT is SYLMTIME (SYSLOG Mount Start),
fractions earlier than TMNTTIME (when
MXGTMNT saw mount start). TMNTTIME used
if SYLMTIME is missing. ENDTMNT is SYL5TIME
(SYSLOG IEC705I Label Written at mount)
fractions later than TENDTIME (MXGTMNT saw mount
end). TENDTIME is used if SYL5TIME is
missing. TOTMNTTMENDTMNT-BEGTMNT, the mount
delay to the job.
10

-ASUMTAPE propagates job-level variables from
1st mount ASID INITTIME JOBCLASS
LOCLINFO PGMRNAME RACFTERM RACFUSER READTIME
STEPNAME STEPNR TMNTEXIT into the
multi-volume mounts that IBM exit misses.
TAPMNTTM will still be missing in second volume
mount But TOTMNTTM is captured for these
mounts and should be used. -The SORT order of
PDB.ASUMTAPE is changed from BY DEVNR
DESCENDING EVENTIME to BY DEVNR
EVENTIME but as the expected SORT order in
WEEKBLD/MONTHBLD is just BY DEVNR
the change from DESCENDING to ASCENDING should
have no adverse impact.
11

3. Support for APAR OA12857 which adds PDSE
Caching stats in z/OS 1.7, APAR is already in
z/OS 1.8, to type 14, 15 SMF records, with
these new variables SMF14DRD
'PDSEDIRECTORYREADREQUESTCOUNT'
SMF14DRDH'PDSEDIRECTORYREADHITCOUNT'
SMF14MCE 'PDSEMEMBERCACHEELIGIBLECOUNT'
SMF14MCF 'PDSEMEMBERELIGIBLECACHE
FULLCOUNT' SMF14MNC 'PDSEMEMBERELIGIBLENOT
CACHEDCOUNT' SMF14MRD 'PDSEMEMBERREADREQU
ESTCOUNT' SMF14MRDH'PDSEMEMBERREADHITCOUN
T' SMF14MST 'PDSEMEMBERCACHESTOLENCOUNT
Note MXG 24.08 Required processing these
14/15s will cause INPUT STATEMENT
EXCEEDED ABEND with prior versions.
12

4. Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP
creation. Major changes, perhaps
incompatible - STARTIME, SMF70GIE forced to
"pretty" start/end times. - ASUMCEC/ASUMCELP
have CECINTRV default of HOURLY. -
ASUM70PR/ASUM70LP interval no longer set by
IMACRMFI you may have to set INTERVAL in
your ASUM70PR. - LPARNUM cannot be used to
identify anything uniquely. Add/remove an
LPAR changes LPARNUM of later LPARs
LPARNUM is assigned based on alphabetic order of
the LPARNAME. The LPn summary
variables will have different LPARs data
after LPAR changes, cant be trended. - Use
PDB.ASUMCEC for hardware total reports,
PDB.ASUMCELP for LPAR-level utilization reports.

13

"LPAR" - Variables SYSPLEX LPARNUM
LPARNAME are used to uniquely
define each "LPAR", as the same
LPARNUM and/or LPARNAME can be
used in different SYSPLEX on same CECSER.
"STARTIME" - STARTIME and SMF70GIE are shifted to
the "expected, exact, SYNC59d"
time of day for the INTERVAL and
CECINTRV values. "INTERVAL" - Default
summary interval for "per SYSTEM"
PDB.ASUM70PR/PDB.ASUM70LP datasets,
new default is QTRHOUR. "CECINTRV" -
Default summary interval for "per CEC",
PDB.ASUMCEC/ASUMCELP datasets,
new default is HOUR.
14

- BY List variables used to create summary were
changed. Previously, only SYSPLEX
SYSTEM SYSNAME STARTIME was used to identify a
unique "SYSTEM". But now, the BY list
variables used internally are CECSER SYSPLEX
SYSTEM SYSNAME LPARNUM LPARNAME SMF70GIE
which added protection for - Same SYSTEM in
a SYSPLEX will have different SYSNAME - Same
LPARNAME can be in two LPARNUMs during same CEC
summary interval (i.e., when you add a new
LPAR). - SMF70GIE required by the SPLIT70
rewrite. But that BY list is internal to
VMXG70PR. Outputs are ASUM70LP BY
SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER
LPARNAME LPARNUM ASUM70PR BY
SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER
ASUMCELP BY CECSER STARTIME SHIFT
LPARNAME LPARNUM ASUMCEC BY CECSER
STARTIME SHIFT
15

-MXG's SPLIT70 rewrite (Dec 2005-Jun 2006!) to
support IBM
RMF 70 record split with lots of LPARs
required that
SMF70GIE, the projected end-of-interval
datetimestamp,
be used to create these "per SYSTEM" MXG
datasets
TYPE70,RMFINTRV,ASUM70PR,ASUM70LP
But SMF70GIE cannot be used (as-is) to group
"by CECSER",
SMF70GIE is not the same in all LPARs in a
CEC
DURATM is not the same in all LPARs in a CEC
-CECs with LPARs with both SYNC(0) and SYNC(59)
and 15 Minute DURATM have some SMF70GIE values of
00/15/30/45 minutes and some with values of
59/14/29/44 minutes, so it's impossible to
exactly summarize that data to a true CEC
interval.

Interval DURATM values are very "fuzzy",
even for the
"interval pop" observations that you
expected to have
the exact INTERVAL you requested (10, 15,
or 30 min).
Here's some reality from four CECs that
share SYSPLEX
Interval DURATM
Min Max (mmss.th)
CECONE 1458.99-1553.26
CECTWO 1459.62-1500.50
2959.88-3000.11
CECTHREE 095954-1000.74
1459.24-1523.17
CECFOUR 1459.75-1500.23
2854.08-3000.08
And small DURATMs (from first RMF interval)
mean that any
value can occur in SMF records, so the
records themselves
can't be used to determine the INTERVAL of
the data.
Min DURATM for CEC summary must be at least
largest

-Inexactness of DURATM across LPARs in a CEC
caused the
STARTIMESMF70GIE-DURATM to be replaced
with
to be replaced in PDB.ASUM70PR/PDB.ASUM70LP
with
STARTIMESMF70GIE-INTERVAL
or to be replaced in PDB.ASUMCEC/PDB.ASUMCELP
with
STARTIMESMF70GIE-CECINTRV
-Caution
Even with the revision, the "SYSTEM" and
"SYSTEM-LPAR"
datasets PDB.ASUM70PR and PDB.ASUM70LP have
observations for
each interval from every SYSTEM in each SYSPLEX,
so they have
duplicate and replicated data, and you must
always select
which "SYSTEM" to use.

5. RMF Monitor III INDXUSED New INDXUSED and
POLYUSED created from DSIG in ZRBBDSHI Detects
so you can save "dead space" in RMF VSAM files.
RMF Monitor III "indexes" each Sample Set in the
DSH table a sample set is written for each
MINTIME interval index provides the offset
into the data set for a sample But max DSH is
32K long, fixed DSH header is 256 bytes, 32512
bytes for the 28-byte index, max possible 1161
index. Cheryl Watson reported 50 are saved for
Policy Indexes, leaving 1111 for actual sample
data indexes. Old, Cumbersome INDEX
calculations so VSAM files were not too
big, otherwise, those 1111 indexes would be
exhausted. New, INDXUSED found only 80-95
indexes used with 2250 tracks per VSAM, would
exhaust space long before exhausting indexes.
VSAM size could be increased, more data online,
and still not risk creating any "dead space".
Adding new RMF III VSAM datasets has hard limit
of 100 dsets.
19

-
6. Identifying CRYPTO users and usage. TYPE30
variable ICSFSCNT/SMF70CSC may or may not
identify the number of crypto instructions
executed in that ASID. New T-rex machine
instructions with CPACF feature provide clear
key DES/TDES as well as hashing functions,
applications can call these functions directly
bypassing ICSF so those calls would NOT be
included in this count. TYPE70Y2 Crypto
dataset CPACF variables count functions
R702NH2B'SHA-256DATABYTESHASH'
R702NH2C'SHA-256CALLSTOHASH'
R702NH2I'SHA-256PCMF INSTRUSED TOHASH
-There is no SMF CPU time field for encryption
CPU cost. However, since it is the TCP/IP
address space that is doing the instructions
for encryption, its CPU time would be in TYPE30
and TYPE72GO data for that ASID and its Service
Class. -CPU time in the PCIXX engine (the
handshake part) in TYPE70Y2.
20

7. SAS ftp access is faster than ftp
download. Sites executing MXG on ASCII to
process zOS or zVM data Faster to process
with MXG code using SAS ftp access method to
process and create output, than to first ftp
download the file, and then read from local
disk Comparison of 1.93 GB of z/VM MONWRITE
data showed ftp download
7m 50s local disk read TYPEVMXA
7m 38s total
(928 seconds) 15m 28s ftp access
method direct with TYPEVMXA 12m 41s
total (761 seconds) 12m 41s
which is 17 faster. (1.93GB in 7min 50 is
4.2 MB/sec, 247MB/min 22 T1's) Writing to a
LAN disk is often much slower than even 1 MB/sec.
21

DB2TCBTM in DB2ACCT can be larger than TASCPUTM
in CICSTRAN.
The Open Transaction Environment OTE (MXG
NL-42) says
that DB2TCBTM is captured in TASCPUTM in
CICSTRAN.
But APAR PK18669 discusses why the DB2TCBTM CPU
Time
in DB2ACCT can be larger than the TASCPUTM in
CICSTRAN.
Under-reporting of up to 16 microseconds of CPU
time per
CICS transaction occurs with the current CICS
clocks
which use only the middle 4 bytes of STCK.
The APAR is CLOSED as a FUTURE requirement to
use all
8 bytes of STCK.
That FUTURE is CICS/TS 3.2, which (while still
not GA)
was announced to have expanded CICS clocks,
which is
continued job-security for me, since youll
need a new
MXG Version to read their new-format 110
records!.

9. Static versus dynamic allocation of SORTWKnn
DDs.
MXGSASVn JCL procedures always have //SORTWKnn DD
statements
which prevent dynamic allocation by your sort
product.
Partly historic SAS releases decades ago didn't
support dynaloc
and many Sort products didnt support the SAS
FILSZ option.
Now, all sorts support DYNALOC and get the file
size from SAS.
Maybe dynamic allocation should be considered
Allocate only the needed workspace for this
sort.
Free that disk space at the end of this sort.
With static, all work space is allocated for step
lifetime.
And, allocation must be large enough for the
largest sort.
You can use the OPTIONS SORTLIST statement to
get lots of

But static //SORTWKnn DDs may still be better
a critical job that does multiple sequential
sorts in one step
(like a daily BUILDPDB).
With static DDs, you are guaranteed to keep that
work space
for the steps lifetime.
With dynamic DDs, you can get halfway thru the
step, and then
fail if there is not enough work space in your
pool
(other jobs have allocated the space that you
just freed!).
You might blame the ABEND on poor storage
administration, but using static SORTWKDDs will
get you through to EOJ!
Like most technical answers, "it all
depends....".