* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
PLSDG29C='DIAGNOSE*X29C' PLSDG2A0='DIAGNOSE*X2A0' PLSDG2A4='DIAGNOSE*X2A4' PLSDG2A8='DIAGNOSE*X2A8' PLSDG2AC='DIAGNOSE*X2AC' PLSDG2B0='DIAGNOSE*X2B0' PLSDG2B4='DIAGNOSE*X2B4' PLSDG2B8='DIAGNOSE*X2B8' PLSDG2BC='DIAGNOSE*X2BC' PLSDG2C0='DIAGNOSE*X2C0' PLSDG2C4='DIAGNOSE*X2C4' PLSDG2C8='DIAGNOSE*X2C8' PLSDG2CC='DIAGNOSE*X2CC' PLSDG2D0='DIAGNOSE*X2D0' PLSDG2D4='DIAGNOSE*X2D4' PLSDG2D8='DIAGNOSE*X2D8' PLSDG2DC='DIAGNOSE*X2DC' PLSDG2E0='DIAGNOSE*X2E0' PLSDG2E4='DIAGNOSE*X2E4' PLSDG2E8='DIAGNOSE*X2E8' PLSDG2EC='DIAGNOSE*X2EC' PLSDG2F0='DIAGNOSE*X2F0' PLSDG2F4='DIAGNOSE*X2F4' PLSDG2F8='DIAGNOSE*X2F8' PLSDG2FC='DIAGNOSE*X2FC' PLSDG300='DIAGNOSE*X300' PLSDG304='DIAGNOSE*X304' PLSDG308='DIAGNOSE*X308' PLSDG30C='DIAGNOSE*X30C' PLSDG310='DIAGNOSE*X310' PLSDG314='DIAGNOSE*X314' PLSDG318='DIAGNOSE*X318' PLSDG31C='DIAGNOSE*X31C' PLSDG320='DIAGNOSE*X320' PLSDG324='DIAGNOSE*X324' PLSDG328='DIAGNOSE*X328' PLSDG32C='DIAGNOSE*X32C' PLSDG330='DIAGNOSE*X330' PLSDG334='DIAGNOSE*X334' PLSDG338='DIAGNOSE*X338' PLSDG33C='DIAGNOSE*X33C' PLSDG340='DIAGNOSE*X340' PLSDG344='DIAGNOSE*X344' PLSDG348='DIAGNOSE*X348' PLSDG34C='DIAGNOSE*X34C' PLSDG350='DIAGNOSE*X350' PLSDG354='DIAGNOSE*X354' PLSDG358='DIAGNOSE*X358' PLSDG35C='DIAGNOSE*X35C' PLSDG360='DIAGNOSE*X360' PLSDG364='DIAGNOSE*X364' PLSDG368='DIAGNOSE*X368' PLSDG36C='DIAGNOSE*X36C' PLSDG370='DIAGNOSE*X370' PLSDG374='DIAGNOSE*X374' PLSDG378='DIAGNOSE*X378' PLSDG37C='DIAGNOSE*X37C' PLSDG380='DIAGNOSE*X380' PLSDG384='DIAGNOSE*X384' PLSDG388='DIAGNOSE*X388' PLSDG38C='DIAGNOSE*X38C' PLSDG390='DIAGNOSE*X390' PLSDG394='DIAGNOSE*X394' PLSDG398='DIAGNOSE*X398' PLSDG39C='DIAGNOSE*X39C' PLSDG3A0='DIAGNOSE*X3A0' PLSDG3A4='DIAGNOSE*X3A4' PLSDG3A8='DIAGNOSE*X3A8' PLSDG3AC='DIAGNOSE*X3AC' PLSDG3B0='DIAGNOSE*X3B0' PLSDG3B4='DIAGNOSE*X3B4' PLSDG3B8='DIAGNOSE*X3B8' PLSDG3BC='DIAGNOSE*X3BC' PLSDG3C0='DIAGNOSE*X3C0' PLSDG3C4='DIAGNOSE*X3C4' PLSDG3C8='DIAGNOSE*X3C8' PLSDG3CC='DIAGNOSE*X3CC' PLSDG3D0='DIAGNOSE*X3D0' PLSDG3D4='DIAGNOSE*X3D4' PLSDG3D8='DIAGNOSE*X3D8' PLSDG3DC='DIAGNOSE*X3DC' PLSDG3E0='DIAGNOSE*X3E0' PLSDG3E4='DIAGNOSE*X3E4' PLSDG3E8='DIAGNOSE*X3E8' PLSDG3EC='DIAGNOSE*X3EC' PLSDG3F0='DIAGNOSE*X3F0' PLSDG3F4='DIAGNOSE*X3F4' PLSDG3F8='DIAGNOSE*X3F8' PLSDG3FC='DIAGNOSE*X3FC' PLSDGUCT='ALL*USER*DIAGNOSE*OPERATIONS*/ PLSDGX00='DIAGNOSE*X00' PLSDGX04='DIAGNOSE*X04' PLSDGX08='DIAGNOSE*X08' PLSDGX0C='DIAGNOSE*X0C' PLSDGX10='DIAGNOSE*X10' PLSDGX14='DIAGNOSE*X14' PLSDGX18='DIAGNOSE*X18' PLSDGX1C='DIAGNOSE*X1C' PLSDGX20='DIAGNOSE*X20' PLSDGX24='DIAGNOSE*X24' PLSDGX28='DIAGNOSE*X28' PLSDGX2C='DIAGNOSE*X2C' PLSDGX30='DIAGNOSE*X30' PLSDGX34='DIAGNOSE*X34' PLSDGX38='DIAGNOSE*X38' PLSDGX3C='DIAGNOSE*X3C' PLSDGX40='DIAGNOSE*X40' PLSDGX44='DIAGNOSE*X44' PLSDGX48='DIAGNOSE*X48' PLSDGX4C='DIAGNOSE*X4C' PLSDGX50='DIAGNOSE*X50' PLSDGX54='DIAGNOSE*X54' PLSDGX58='DIAGNOSE*X58' PLSDGX5C='DIAGNOSE*X5C' PLSDGX60='DIAGNOSE*X60' PLSDGX64='DIAGNOSE*X64' PLSDGX68='DIAGNOSE*X68' PLSDGX6C='DIAGNOSE*X6C' PLSDGX70='DIAGNOSE*X70' PLSDGX74='DIAGNOSE*X74' PLSDGX78='DIAGNOSE*X78' PLSDGX7C='DIAGNOSE*X7C' PLSDGX80='DIAGNOSE*X80' PLSDGX84='DIAGNOSE*X84' PLSDGX88='DIAGNOSE*X88' PLSDGX8C='DIAGNOSE*X8C' PLSDGX90='DIAGNOSE*X90' PLSDGX94='DIAGNOSE*X94' PLSDGX98='DIAGNOSE*X98' PLSDGX9C='DIAGNOSE*X9C' PLSDGXA0='DIAGNOSE*XA0' PLSDGXA4='DIAGNOSE*XA4' PLSDGXA8='DIAGNOSE*XA8' PLSDGXAC='DIAGNOSE*XAC' PLSDGXB0='DIAGNOSE*XB0' PLSDGXB4='DIAGNOSE*XB4' PLSDGXB8='DIAGNOSE*XB8' PLSDGXBC='DIAGNOSE*XBC' PLSDGXC0='DIAGNOSE*XC0' PLSDGXC4='DIAGNOSE*XC4' PLSDGXC8='DIAGNOSE*XC8' PLSDGXCC='DIAGNOSE*XCC' PLSDGXD0='DIAGNOSE*XD0' PLSDGXD4='DIAGNOSE*XD4' PLSDGXD8='DIAGNOSE*XD8' PLSDGXDC='DIAGNOSE*XDC' PLSDGXE0='DIAGNOSE*XE0' PLSDGXE4='DIAGNOSE*XE4' PLSDGXE8='DIAGNOSE*XE8' PLSDGXEC='DIAGNOSE*XEC' PLSDGXF0='DIAGNOSE*XF0' PLSDGXF4='DIAGNOSE*XF4' PLSDGXF8='DIAGNOSE*XF8' PLSDGXFC='DIAGNOSE*XFC' PLSTOTDI='ALL Z/VM*DEFINED*DIAGNOSE*OPERATIONS*/ -Dataset VXIODDEV (6.03) new variables added by 5.3: PAVCC3S ='INITIAL*CMR*TIME' -Dataset VXVNDSES (8.01) new variables added by 5.3: MSVCMAC ='VDEV*MAC*ADDRESS' -Dataset VXAPLTC1 (10.01) TCP/IP SUBTYPE '01' added: FORNIPV6='FOREIGN*IP*ADDRESS*IPV6' LOCLIPV6='LOCAL*IP*ADDRESS*IPV6' -Dataset VXAPLTC4 (10.02) TCP/IP SUBTYPE '04' added: FPSPAV2G='FPSP*AVAILABLE*LOCKED PAGES*GT 2G' FPSPALUS='FPSP*ALLOCATED*LOCKED PAGES*GT 2G' -Dataset VXAPLTC9 (10.02) TCP/IP SUBTYPE '09' added: ACBSSC00='PROCESS 00*ACBS SCHEDULED' ELAPSE00='PROCESS 00*ELAPSED TIME ACB' VIRTCP00='PROCESS 00*VIRTUAL CPU TIME ACB' ELAPSM00='PROCESS 00*MAXIMUM ELAPSED TIME ACB' VIMXCP00='PROCESS 00*MAXIMUM VIRTUAL CPU TIME ACB' thru ACBSSC80='PROCESS 80*ACBS SCHEDULED' ELAPSE80='PROCESS 80*ELAPSED TIME ACB' VIRTCP80='PROCESS 80*VIRTUAL CPU TIME ACB' ELAPSM80='PROCESS 80*MAXIMUM ELAPSED TIME ACB' VIMXCP80='PROCESS 80*MAXIMUM VIRTUAL CPU TIME ACB' for all 81 "Process Name Types".
is insufficient. The PRCAPM segment does not contain the CMB Entry Type, which sets the size of the CMB: Entry type 3, 5, 6 are 64 bytes Entry type 4 is 336 bytes Entry type 6 is 80 bytes plus - the length of the variable data depends on the type of AP (determined by the PRCAPM_CT field in the CMB Header, and the number of APs installed, But: neither that PRCAPM_CT fields, nor is the number of APs in the PRCAPM segment in MONWRITE data. Fortunately, the PRCAPM 5.10 segment only exists if there are PCI Crypto Cards installed. -Dataset VXAPLTC9 (10.02) SUBRECORD '09'X, TCP/IP ACB is still not understood sufficiently for complete support. All of the datasets listed above have been tested with data from z/VM 5.4. There are a few other records that have new data fields, but they did not exist in the test files, so they won't be updated until a user request is accompanied by test data with those segments. Change 26.202 Creating RMFINTRV or BUILDPDB with //PDB DD on tape fails VMXGRMFI because both PDB.TYPE78 and PDB.TYPE78IO were opened in a Aug 30, 2008 VMXGSUM invocation, but PDB.TYPE78 has always had zero Oct 15, 2008 observations (with 3090's or later), so it was removed from that step. PDB.TYPE78 is still VMXGSUM'd separately to create these PDB.RMFINTRV variables, always missing values, but there so your old report programs won't fail: NRATTMPS NRSAMPLE SIO78CNT PCTDEFCU PCTDEFDV PCTSUCES PCTALLBY Oct 15: Using PDB=SMF with %VMXGRMFI failed because the _STY78 had been inadvertently removed. Thanks to Jorge Fong, DOITT NYC, USA. Thanks to Atle Mjelde, Ergo Group, NORWAY. Change 26.201 Support for DB2 V9.1 (COMPAT) SMF 100/101 + new V8 data: FORMATS
VMACDB2 WOW: New Z/OS metrics in PDB.DB2STATS are added to both Aug 30, 2008 DB2 V8.1 (APAR PK47659) and DB2 V9.1 (APAR PK56356). Sep 1, 2008 Both DB2 APARs also need RMF APAR PK62116 (which has prereq APARs PK66373 and OA24404), and PK62116 has these installation notes from IBM: Please be aware that there can be situations when the z/OS metrics don't get provided at all or only partially in the DB2 trace. The reason for this is that there are setup problems related to RMF. Please verify that actions 1 to 4 were completed after installation of the PTF for PK62116: 1. Make sure that the PTF for the prereq APAR PK66373 has been applied. 2. Verify that the fix for Resource Measurement Facility (RMF), PTF for APAR OA24404 has been installed. If this step is omitted, an abend will occur in RMF. 3. Set DB2 subsystem parameter ZOSMETRICS to YES. 4. Start Resource Measurement Facility and RMF Monitor 3 sysplex data retrieval service. -Dataset DB2STATS new variables from DB2STAT0 in V8 & V9: New z/OS variables in PDB.DB2STATS with above APARs: QWOSDB2U='DB2*SUBSYSTEM*CPU*UTILIZATION' QWOSDBMU='DB2*DBM1*CPU*UTILIZATION' QWOSDPIR='DB2 SUBSYS*PAGE-IN*RATE' QWOSDRSU='DB2 SUBSYS*USED REAL STORAGE*IN MB' QWOSDVSU='DB2 SUBSYS*USED VIRTUAL*STORAGE*IN MB' QWOSLNCP='CPS*IN*LPAR' QWOSLPIR='LPAR*PAGE-IN*RATE' QWOSLPRU='LPAR*CPU*UTILIZATION' QWOSLRSF='LPAR*FREE REAL*STORAGE*IN MB' QWOSLRST='LPAR*REAL STORAGE*IN MB' QWOSLVSF='LPAR*FREE*VIRTUAL*STORAGE*IN MB' QWOSLVST='LPAR*VIRTUAL*STORAGE*IN MB' QWOSMSTU='DB2*MSTR*CPU*UTILIZATION' NOTE: DB2 Parameter ZOSMETRICS=YES must be specified to populate these variables. APAR PK62116 applies. With the default NO value, fields contain 'FFFFFFFF'x. -Dataset DB2ACCT new variables added by V9: QWACALBW='WAIT TIME*TCP/IP LOB*MATERIALIZATION' QWACALBC='WAITS FOR*TCP/IP LOB*MATERIALIZATIONS' QWACSPC1='SP_CLS1SE*STORED PROC*CLASS 1*ON ZIIP' QWACSPC2='SP_CLS2SE*STORED PROC*CLASS 2*ON ZIIP' QWACSPZC='SPNF_CP*STORED PROC*CPU TIME*ON CP' QWACSPZE='SPNF_ELAP*STORED PROC*ELAPSED*TIME' QWACSPZI='SPNF_ZIIP*STORED PROC*CPU TIME*ON ZIIP' QWACTRSE='TRTE_SE*NESTED*TRIGGER*CPU ON ZIIP' QWACUDC1='UDF_CLS1SE*UDF STORED PROC*CLS 1*ZIIP' QWACUDC2='UDF_CLS2SE*UDF STORED PROC*CLS 2*ZIIP' QWACUDZC='UDFNF_CP*FUTURE*FUNCTION' QWACUDZE='UDFNF_ELAP*FUTURE*FUNCTION' QWACUDZI='UDFNF_ZIIP*FUTURE*FUNCTION' -Dataset DB2ACCTP new variables added by V9: QPACALBC='TCP/IP LOB*WAIT*TRACE*EVENTS' QPACALBW='CPU TIME*ON ZIIP' QPACSWIT='TIMES*PACKAGE WAS*SWITCHED TO' -Datasets DB2ACCT, DB2ACCTP, DB2ACCTB, DB2ACCTG new QWHC (Header) variables added: QWHCOAUD='ORIGINAL*APPLICATION*USERID' QWHCROLE='ROLE*NAME' QWHCTCXT='TRUSTED*CONTEXT*NAME' -Dataset DB2STATS new variables from DB2STAT0 in V9: Q9STCTX5='DISPLAY*DDF*COMMANDS' Q9STCTAD='ACCESS*DATABASE*COMMANDS' Q9STCTSS='START*PROFILE*COMMANDS' Q9STCTST='STOP*PROFILE*COMMANDS' Q9STCTSD='DISPLAY*PROFILE*COMMANDS' -Dataset DB2STATB and DB2STATS changes: These DB2STATB variables are (or have been) reserved QBSTALX QBSTARA QBSTARF QBSTAWA QBSTAWF QBSTDWC QBSTDWX QBSTHBE QBSTHPA QBSTHPL QBSTHRA QBSTHRE QBSTHRF QBSTHWA QBSTHWF QBSTHWR QBSTWEE and all are now set to a missing value in DB2STATB. Additionally, their QB1xxxx-QB4xxxx counterpart variables in DB2STATS are now also missing values. New variables in DB2STATB: QBSTCIO ='PAGES*OF I/O*ON CASTOUT' QBSTPCO ='PAGES*ON*UNLOCK*CASTOUT' New variables in DB2STATS: QB1TCIO ='1ST PAGES*OF I/O*ON CASTOUT' QB1TPCO ='1ST PAGES*ON*UNLOCK*CASTOUT' QB2TCIO ='2nd PAGES*OF I/O*ON CASTOUT' QB2TPCO ='2nd PAGES*ON*UNLOCK*CASTOUT' QB3TCIO ='3rd PAGES*OF I/O*ON CASTOUT' QB3TPCO ='3rd PAGES*ON*UNLOCK*CASTOUT' QB4TCIO ='4th PAGES*OF I/O*ON CASTOUT' QB4TPCO ='4th PAGES*ON*UNLOCK*CASTOUT' -Dataset DB2STATB new variable in V9: QDBPASIZ='AUTOSIZE*ATTRIBUTE' -Dataset DB2STATS new variables from DB2STAT1: QISECTA ='PAGES*USED IN CT*ABOVE BAR' QISEKFAL='FAIL*DUE TO*STMT SKEL*POOL FULL' QISEKFRE='FREE PG*IN SKEL*EDM POOL*FRE CH' QISEKNFA='NOT-FOUND*RECORD*ADDED*TO CACHE' QISEKNFM='CACHED*NOT-FOUND*RECORD*LOCATED' QISEKNFR='NOT-FOUND*RCRD*REMOVED*FRM CACHE' QISEKPGE='PAGES*IN SKEL*EDM POOL' QISEKTA ='PAGES*USED IN PT*ABOVE BAR' QISESFAL='FAIL*DUE TO*STMT ABV*POOL FULL' QISESFRE='FREE PG*IN STMT*ABV EDM*POL FRE' QISESKCT='PAGES*USED*FOR SKCT' QISESKPT='PAGES*USED*FOR SKPT' QISESPGE='PAGES*IN STMT*ABV EDM*POOL' -Dataset DB2STATS new variables from DB2STAT1: QISTW04K='TOT 4KB*TABLESPACE*USED*FRACT MB' QISTW32K='TOT 32KB*TABLESPACE*USED*FRACT MB' QISTWF04='TOT 4KB*TABLESPACE*USED*WHOLE MB' QISTWF32='TOT 32KB*TABLESPACE*USED*WHOLE MB' QISTWFCK='CUR TOTAL*FRACT MB*USED IN*WF IN KB' QISTWFCU='CUR TOTAL*WHOLE MB*USED IN*WF DB' QISTWFMU='MAX TOT*USED IN*WF DB (MB)' QISTWFMX='MAX*ALLOWABLE*USE LIMIT*P/AG MB' QISTWFNE='TIMES MAX*ALLOWABLE*LIMIT*EXCEEDED' QISTWFP1='TIMES 32KB*PAGE TS*USED WHEN*4KB SHOULD' QISTWFP2='TIMES 4KB*PAGE TS*USED WHEN*32K SHOULD' -Dataset DB2STATS new variables from DB2STAT1: QXALTCTX='ALTER*TRUSTED*CONTEXT' QXALTJR ='ALTER*JAR' QXCRCTX ='CREATE*TRUSTED*CONTEXT' QXCRROL ='CREATE*ROLE' QXDRPCTX='DROP*TRUSTED*CONTEXT' QXDRPROL='DROP*ROLE' QXMERGE ='TIMES*MERGE*STATEMENT*WAS EXECUTED' QXRNIX ='RENAME*INDEX' QXSTXMLV='MAX STORAGE*USED FOR*XML VALUES' QXTRTBL ='TIMES*TRUNCATE*TABLE*WAS EXECUTED' -Dataset DB2ACCTP documentation. Variables QPACCAST, QPACCANM, QPACUDST are always missing in both V8 and V9, as they are Account level, not package, metrics. Thanks to Scott Barry, SBBWorks, Inc, USA.
BUILDPDB ERROR:Variable SYSPLEX defined as both char and numeric. Aug 28, 2008 ERROR:Variable SYSTEM defined as both char and numeric. ERROR:Variable SYSNAME defined as both char and numeric. followed by WARNING: The data set WORK.MSU4HRAV may be incomplete. The error is a broken SPIN.SPINRMFI, from an earlier test job that failed; PROC CONTENTS DATA=SPIN.SPINRMFI will show the three variables as NUMERIC instead of CHARACTER. PROC DELETE DATA=SPIN.SPINRMFI and a rerun resolved. Change 26.199 Change 25.228 added protection for invalid 14, 15 records VMAC1415 that had only one NUCB while NUCB=2 in the record, but Aug 28, 2008 the protection failed when the NUCB segment was the last in the record. The protection itself CAUSED message: ERROR: INVALID SMF1415 RECORD. INVALID UCB SEGMENT ERROR which prevented those records from being output, so it really is an ERROR, albeit caused by MXG and not a bad record. Most 14/15s have the extended segments, and the protection worked fine for those records. Thanks to Herbert Sweeney, Verizon Data Services, USA Change 26.198 All Pool 00 variables in BVIR32 are changed to Pool 32, VMACBVIR as all IBM Virtualization Engine TS7700 reporting now Aug 25, 2008 reports pools 1 thru 32 instead of the pool 0 thru 31 in the DSECTS from which I wrote the original MXG code. Variable names and labels are changed. Thanks to Leendert Keesmaat, UBS, SWITZERLAND. ====== Changes thru 26.197 were in MXG 26.07 dated Aug 24, 2008========= Change 26.197 PCTMVSBY in PDB.TYPE70PR is now calculated for all engine VMAC7072 types (CPs,zIIPs,zAAPs), because SMF70PAT parked time is Aug 24, 2008 now recorded for the specialty engines. The existence of SMF70PAT field required heuristic circumvention code when it was discovered that a fully parked engine did not have the SMF70PAT exactly equal to the SMF70ONT Online Time; my first test for ONT-PAT GT .02 seconds was not enough and caused PCTMVSBY greater than 100% when data with ONT of ONT 15.00.01 and PAT of 14:59:97 was found, so that heuristic was raised to 0.10 seconds. CPUWAITM greater than DURATM by 0.01 seconds with SMF70PAT nearly DURATM also required heuristic protection to prevent negative PCTCPU calculations for individual engines in TYPE70PR.
VMACBVIR are only 31 pools. But now see Change 25.198. Aug 24, 2008 Thanks to Jens Mohring, HUK-COBURG, GERMANY. Change 26.195 The Multi-System Enclave Remote System dataset TYPE30MR VMAC30 always had zero observations, because MXG's test for the Aug 22, 2008 13 bytes remaining should have been 12, so the offset was always missing and the segment was never read. This also caused variables CPUMRDTM/CPUMRITM in TYPE30xx, PDB.JOBS, PDB.STEPS, and PDB.SMFINTRV to always be zero. However, fortunately, even IBM doesn't expect many (or any?) sites to actually have these segments, so no one had noticed their absence. Thanks to Stephen Hughes, Excellus, USA. Change 26.194 The MXGWPSV2 JCL procedure example was inconsistent in MXGWPSV2 the example DSNAMEs, and the JCLINSTW example notes were JCLINSTW clarified on the JCL Procedure Name to be used. Aug 24, 2008 Change 26.193 Lots of cosmetic cleanup. Labels added, variables that DOC should not have been kept aren't, formats added, etc., Aug 21, 2008 as a result of SAS ITRM Dictionary Build, MXG QA runs, and user detected inconsistencies. Members touched: IMACCICS IMAC110 VMAC110 VMAC6156 VMACTPMX VMAC116 VMACSMF VMACHSM VMACCMF VMXGCICI VMAC30 VMXGRMFI JCLROCS ASUMTAPE CHANGESS VMACSUSE VMXGINIT IMACQAPM VMAC7072 VMACNTSM VMACTPF Thanks to Nick Johns, Sainsbury Supermarkets Ltd., ENGLAND. Thanks to Chris Weston, SAS ITRM Development, USA. Thanks to Freddie Arie, Merrill Consultants QA Guy, USA.
VMAC7072 HIPERDISPATCH has parked an engine(s), by subtracting the Aug 21, 2008 Parked Time (SMF70PAT) from both the numerator and the denominator: Online Time - (Wait + Parked Time) MVS UTIL(%)=---------------------------------- * 100 Online Time - Parked Time so MXG's calculation of PCTMVSBY is revised to match IBM. This was noted in the MXG Newsletter discussion of Parked time, but was not implemented in code until now. Thanks to Brian Currah, Independent Consultant, CANADA. (In 1972, the first person I ever called with a question about an SMF record's contents was Brian; the late Steve Cullen knew him to be an SMF guru at GUIDE! And, he knew the answer, then and now!) Change 26.191 A new MXGSAS92 JCL Procedure for MXG under z/OS SAS V9.2 MXGSAS92 is provided because SAS changed their DSNAMES for CNTL Aug 22, 2008 and SASMSG datasets: -If you use the SAS Deployment Wizard (SDW) to install the SAS V9.2 for z/OS release, the DSNAME of their CNTL dataset is changed by the addition of a new qualifier with the SAS Version, year, and julian date of install, with this syntax DSN=&SASHLQ..V92DYJJJ.CNTL(BAT&YY.) or a specific DSNAME, for example, of DSN=&SASHLQ..V92D8208.CNTL(BATW0) for an install in 2008 on julian date 208, in the USA. The MXGSAS92 JCL procedure now has //CONFIG DD DISP=SHR,DSN=&SASHLQ..V92DYJJJ.CNTL(BAT&YY.) // DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9) Get that exact YJJJ value from your SAS Installer. -Also the SASMSG DSNAME with .SL. no longer exists, so the SASMSG DD only has these two DDs: //SASMSG DD DISP=SHR,DSN=&SASHLQ..&XX.&YY..SASMSG // DD DISP=SHR,DSN=&SASHLQ..EN&YY..SASMSG Thanks to Tom C. Frohnapfel, AAFES, USA. Thanks to MP Welch, SPRINT, USA. Change 26.190 -Support for IMS Log record 0A (CPI-CI Driven Program) ASMIMSL6 records 0A07x (Terminate) & 0A08x (Start) creates IMS0A78 EXIMS0A7 dataset in both ASMIMSL6/TYPEIMSA and TYPEIMS7 programs. EXIMS0A8 -For ASMIMSL6/TYPEIMSA log processing: EXIMSA78 _IMSVERS defined in IMACIMSA now default is IMS 10.0. IMACIMS Comments in IMACIMSA document how to change DDNAMES and IMACIMS7 which %LET Wdddddd= or %LET Pdddddd you use for IMACIMSA each of the six output IMS datasets. TYPEIMS7 ASMIMSL6 was modified to pass the 0A records and report TYPEIMSA the total count of those records written. VMACIMS -For TYPEIMS7 processing: Aug 23, 2008 _IMSVERS defined in IMACIMS7 now default is IMS 10.0. Member IMACIMS is NO LONGER USED. In _IMSUMRY macro CTR array was increased from 55 to 67. These DDname Macros were previously defined in IMACIMS7: _IMSTRAN, _IMSBMP, and _IMSWORK but they are no longer used in IMS processing, as the simpler Pdddddd and Wdddddd macro variables are now fully implemented in the MXG IMS processing. They are still defined, in case they exist in your user code. All TYPEIMS7 output datasets are written to //WORK, but comments in TYPEIMS7 show how to send its output to other DDNAMES. Thanks to Cornelia Dorr, Lufthansa Systems Infratec GmbH, GERMANY. Thanks to Gero Wohlsperger, Lufthansa Systems, Infratec GmbH, GERMANY
VMXGINIT enable the (non-existent, as of now) VARLENCHK option, so Aug 20, 2008 it was removed. See MXG Newsletter FIFTY-TWO, SAS Note 7 which discusses the Hot Fix for SAS V9.2. Thanks to MP Welch, SPRINT, USA.
DOC the ASUM70PR member currently do NOT subtract SMF70PAT, Aug 19, 2008 Parked Time, from the SMF70ONT, Online Time, so the count of LPnNRPRC (CP Engines) is not the average online count. It might not be possible, easily, to modify ASUM70PR to account for Parked Time in the two System-Level datasets ASUM70PR and ASUM70LP, because the SMF70PAT only exists in the per-MVS-system observations in TYPE70PR from the parked MVS system records. However, the two CEC-Level datasets, ASUMCEC and ASUMCELP already use only the per-MVS-system observations, so it appears that you could use the below example to create two new PARKCEC and PARKCELP datasets in your PDB library with the SMF70PAT parked time removed from SMF70ONT time, which then causes the calculation of LPnNRPRC and related related variables to account for the parked time of each LPAR: //REALPDB DD DSN=YOUR.REAL.PDB.DATASET,DISP=SHR //PDB DD UNIT=SYSDA,SPACE=(CYL,(50,50)) //SYSIN DD * DATA PDB.TYPE70PR; SET REALPDB.TYPE70PR; IF SMF70PAT GT 0 THEN SMF70ONT=SMF70ONT-SMF70PAT; %INCLUDE SOURCLIB(ASUM70PR); DATA REALPDB.PARKCEC; SET PDB.ASUMCEC; DATA REALPDB.PARKCELP; SET PDB.ASUMCELP;
Yüklə 28,67 Mb. Dostları ilə paylaş:
|