1 / 24

CMG 2006

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.

smithl
Télécharger la présentation

CMG 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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='TOTAL*EQUIVALENT*CPU TIME*ON_ZIP' CPUEZITM='INDEPENDENT*ENCLAVE*CPU TIME*ON ZIP' CPUDZITM='DEPENDENT*ENCLAVE*CPU TIME*ON ZIP' CPUZIETM='ZIP-ELIGIBLE*CPU TIME*ON CP' CPUEZETM='ZIP-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP' CPUDZETM='ZIP-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP' CPUEZQTM='ZIP-QUALIFIED*IND ENCLAVE*CPU TIME' CPUDZQTM='ZIP-QUALIFIED*DEP ENCLAVE*CPU TIME' ZIPUNITS='ZIP-EQUIVALENT*CPU*SERVICE*UNITS' ZIEUNITS='ZIP-ELIGIBLE*CPU*SERVICE*UNITS'

  3. -TYPE70 New Variables NRZIPS ='NUMBER OF*ZIP*ENGINES*AVAILABLE' SMF70SUP='ZIP PROCESSORS*ONLINE*AT END OF*INTERVAL' PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)' ZIPAVAIL='ZIP*PROCESSOR*AVAILABLE?' ZIPACTTM='ZIP ENGINE*EXECUTING*(ACTIVE) CPU TIME' ZIPUPTM ='ZIP ENGINE*AVAILABLE*(UP) TIME' ZIPWAITM='TOTAL*ZIP WAIT*DURATION' ZIPWAIT0='ZIP WAIT*DURATION*ZIP 0' ZIPWAIT1='ZIP WAIT*DURATION*ZIP 1' ZIPWAIT2='ZIP WAIT*DURATION*ZIP 2' ... engines 3 thru 30 ... ZIPWAITW='ZIP WAIT*DURATION*ZIP 31' ZIPWAITX='ZIP WAIT*DURATION*ZIP 32' PCTZIBY0='ZIP 0*PERCENT*CPU BUSY TIME' PCTZIBY1='ZIP 1*PERCENT*CPU BUSY TIME' PCTZIBY2='ZIP 2*PERCENT*CPU BUSY TIME' ... engines 3 thru 30 ... PCTZIBYW='ZIP 31*PERCENT*CPU BUSY TIME' PCTZIBYX='ZIP 32*PERCENT*CPU BUSY TIME'

  4. -TYPE72GO New Variables CPUZIETM='ZIP*ELIGIBLE*CPU*TIME' CPUZIPTM='ZIP*CPU*TIME' R723CIFA='IFA*SERVICE*UNIT' R723CIFC='IFA-ELIGIBLE*SERVICE*UNITS' R723CSUC='ZIP-ELIGIBLE*SERVICE*UNITS' R723CSUP='ZIP*SERVICE*UNITS' R723SUCU='ZIP-ELIGIBLE*ON CP*USING SAMP' R723SUPD='ZIP*DELAY*SAMPLES' R723SUPU='ZIP*USING*SAMPLES' ZIEUNITS='ZIP*ELIGIBLE*UNITS' ZIPUNITS='ZIP*SERVICE*UNITS' -DB2 CPU Time fields QWACZIxx added to DB2ACCT: QWACZIEL='CPU TIME*ZIP ELIGIBLE*ON CP*ENGINE' QWACZIS1='CPU TIME*EXECUTING*ON ZIIP' QWACZIS2='CPU TIME*IN DB2*EXECUTING*ON ZIIP' QWACZITR='CPU TIME*IN TRIGGERS*EXECUTING*ON ZIIP' -DB2 CPU Time field QPACZITM for Package ZIP execution: QPACZITM='CPU TIME*THIS PACKAGE/DBRM*ON ZIP’

  5. -RMF Monitor III fields added to CPUG3 segment for zips: CPUITSUP='LOGICAL CPU*TIME ON*ZIP*PROCESSORS' CPUPRSUP='ONLINE*TIME ON ZIP*PROCESSORS' CPUSTSUP='PHYSICAL CPU*TIME ON*ZIP*PROCESSORS' CPUSUCOL='AVERAGE*ZIPS*ONLINE*DURING*INTERVAL' CPUSUCON='ZIP ENGINES*ONLINE*AT END' -ASUMCEC new ZIP and IFA utilizations PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)' PCTZIPBY='ALL ZIPS*PERCENT*BUSY (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.

  6. 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 • IFAHONORPRIORITY=YES. • 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.

  7. 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 ML=37 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. TOTMNTTM=ENDTMNT-BEGTMNT, the mount delay to the job.

  8. -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.

  9. 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 ='PDSE*DIRECTORY*READ*REQUEST*COUNT' SMF14DRDH='PDSE*DIRECTORY*READ*HIT*COUNT' SMF14MCE ='PDSE*MEMBER*CACHE*ELIGIBLE*COUNT' SMF14MCF ='PDSE*MEMBER*ELIGIBLE*CACHE FULL*COUNT' SMF14MNC ='PDSE*MEMBER*ELIGIBLE*NOT CACHED*COUNT' SMF14MRD ='PDSE*MEMBER*READ*REQUEST*COUNT' SMF14MRDH='PDSE*MEMBER*READ*HIT*COUNT' SMF14MST ='PDSE*MEMBER*CACHE*STOLEN*COUNT‘ Note: MXG 24.08 Required – processing these 14/15s will cause INPUT STATEMENT EXCEEDED ABEND with prior versions.

  10. 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 LPAR’s data after LPAR changes, can’t be trended. - Use PDB.ASUMCEC for hardware total reports, PDB.ASUMCELP for LPAR-level utilization reports.

  11. "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, SYNC59’d" 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.

  12. - 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

  13. -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.

  14. 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 (mm:ss.th) • CECONE 14:58.99-15:53.26 • CECTWO 14:59.62-15:00.50 • 29:59.88-30:00.11 • CECTHREE 09:59:54-10:00.74 • 14:59.24-15:23.17 • CECFOUR 14:59.75-15:00.23 • 28:54.08-30:00.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 • of any LPAR, but may need to be larger; it must • be the Least Common Denominator of DURATMs. • 10 and 15 minute DURATMs require CECINTRV=HALFHOUR.

  15. -Inexactness of DURATM across LPARs in a CEC caused the • STARTIME=SMF70GIE-DURATM; to be replaced with: • to be replaced in PDB.ASUM70PR/PDB.ASUM70LP with • STARTIME=SMF70GIE-INTERVAL; • or to be replaced in PDB.ASUMCEC/PDB.ASUMCELP with • STARTIME=SMF70GIE-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.

  16. 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.

  17. - 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-256*DATA*BYTES*HASH' R702NH2C='SHA-256*CALLS*TO*HASH' R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH‘ -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.

  18. 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.

  19. 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 you’ll need a new • MXG Version to read their new-format 110 records!.

  20. 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 didn’t 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 • stats printed on the SAS log, including FILSZ, for each sort.

  21. 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 step’s 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....".

  22. 10. HyperPav Support APAR OA12865: • TYPE74 New Variables: • HYPERPAV=‘HYPERPAV*BASE*DEVICE?’ • SMF74HPC=‘HYPERPAV*ALIASES*CONFIGURED*THIS LSS’ • SMF74PSM=‘SUCCESSFUL*PAV*SAMPLE*COUNTS’ • TYPE78CU New Variables: • R783HCU =‘HYPERPAV*CU*IDENTIFIER’ • R783HNAI=‘TIMES I/O NO START*NO HYPERPAV*AVAIL’ • R783HTIO=‘HYPERPAV I/O*REQUESTS*FOR THE LSS’ • R783HAIU=‘HWM*IN-USE*HYPERPAV*ALIASES’ • R783HCAD=‘HWM*ALIASES*IN USE*ONE BASE’ • R783HIOQ=‘HWM*OF IO-S*QUEUED’

More Related