* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
-One of the sites will opening a PMR with IBM, after I had extensive discussions with RMF Development, but that will require IBM Support to design a SLIP trap to diagnose the problem, which will take some time and effort by both IBM and the customer. -I had revised MXG code to detect that CNF bit 6 is on, in this original change, so that you could choose to cause those bad values to be instead be set to a missing value, simply by inserting this optional statement: %LET CNFBIT6=1; after your //SYSIN. And this change originally made the MXG default to calculate the bad values, so that you'd know they existed. Fortunately, that bad data only affects variables that are "MVS-specific" and are not the "mainstream" variables you use for CPU calculations; they have been there some time and were not observed until I added the Short CPs variables. HOWEVER: UPDATE JAN, 2006: SPLIT 70 Rewrite eliminated the CNFBIT6 macro variable option, and these data are always presented. See change 23.321. -Several MXG sites without IRD have run the program and none have seen the symptoms, but that's not conclusive. -In conclusion, these MXG variables in PDB.TYPE70 and in PDB.RMFINTRV (where not all are kept) may be negative or incorrect with MXG's default PCTMVSBY MVSWAITn SHORTCPS PLCPRDYQ CPUMVSTM when corresponding CAIx variables have 02x or 03x values. -Additional notes from RMF Development elaborate meanings: MXG Variable LPARCHNR='Y' if Bit 1 of SMF70PFG is on: Bit 1 of PFG (Number of Logical Processors has Changed) does not indicate any online/offline activity; it it indicates whether the number of logical processors changed and does not care whether those processors are online or offline or whether their on/of status changed. MXG Variable LCPUVARY='Y' if Bit 5 of SMF70VPF is on: Bit 5 of VPF (log proc varied online during interval) is only set when the processor turned ONLINE compared to the status at the end of the previous interval (this is more or less a bit from the old days, prior to WLM CPU mgmt). -You can use the below program, to analyze your existing TYPE70 data to see if the problem exists in at your site:
/* DISREGARD THE MESSAGES ON THE LOG THAT STATE: */ /* THERE ARE NO VALID OBSERVATIONS... */ PROC CHART DATA=PDB.TYPE70; BY SYSPLEX SYSTEM MVSLEVEL DURATM NOTSORTED; HBAR CPUWAIT1-CPUWAIT9 IORATE CAI1-CAI9; TITLE MXG INVESTIGATION OF SMF70CNF BIT 6 ERROR; TITLE2 CPUWAIT GT DURATM IS AN ERROR CONDITION; TITLE3 IORATE GT 10000 IS LIKELY AN ERROR CONDITION; TITLE3 ONLINE STATUS OF 02-03 ARE SMF70CNF BIT 6 ON; LABEL SYSPLEX='SYSPLEX' SYSTEM='SYSTEM' MVSLEVEL='MVSLEVEL' DURATM='DURATM'; Thanks to MP Welch, SPRINT, USA. Thanks to Chuck Hopf, MBNA, USA. Thanks to Michael Oujesky, MBNA, USA
Several there still were references in several members to the Jan 12, 2005 original-last-August names of IFACPUTM and IFECPUTM. Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND. Change 22.347 The IMACEXCL member generated for CICS/TS 3.1 data could UTILEXCL fail with 180 abend starting with variable PGTOTCCT. Jan 12, 2005 Thanks to Victoria Lepak, Aetna, USA. Change 22.346 PCTCPUBY for non PR/SM system was wrong; it was either VMAC7072 the busy of the last engine, or missing, if the last CPU Jan 12, 2005 was offline. And the IORATE was way wrong, as it was the IORATE of the last engine, not the total of all engines. Thanks to Mary Kay Pettengill, (i)Structure, USA.
VMAC30 in Change 22.051 was flat out wrong; I was misled by my Jan 12, 2005 own error: my code INPUT the MOF/MLN/MNO triplet at the same location as the ARM triplet offset. The data DOES agree with IBM documentation, and, with this change, the IBM field names are the MXG variable names in TYPE30MR. Note: the SMF30MRD/SMF30MRI CPU times are normalized by MXG back to the system on which this type 30 was created, but both SMF30MRA and LOSU_SEC variables are kept in the TYPE30MR dataset, in case you want to do it differently. The sum of SMF30MRD/SMF30MRI in all MR segments in this SMF 30 record are summed into variables CPUMRDTM/CPUMRITM which already existed in TYPE30_4(PDB.STEPS) and TYPE30_5 and are now also kept in TYPE30_V (PDB.SMFINTRV). However, CPUMRDTM/CPUMRITM are NOT added into CPUTM, at least not yet by this change; since they have never been right, they could not have been used, and it is not clear exactly what use will be made of those CPU times that occurred on other systems. Your feedback is wanted! Especially, since I do not have any type 30 records with the Multi-System segment with which to validate!! -The original MXG variable names RMSU_SEC and MRENSYST are now replaced by SMF30MRA and SMF30MRS respectively. Thanks to Robert Vaupel, IBM RMF Development, GERMANY. Change 22.344 If you have too many LPARs and LCPUADDRs, it is possible VMAC7072 for IBM to split your RMF 70 data into multiple physical Jan 11, 2005 records for each interval, and this is not YET supported in MXG (because no one yet has actually made it happen). At least now, MXG will detect the split records and will alert you with error messages and hex dumps of the first 10 records with SMF70RAN non-zero, and will tell you that your TYPE70, TYPE70PR, ASUM70PR, ASUM70LP, and ASUMCEC data are wrong, and that TYPE70 will have multiple obs for a single RMF interval. Eventually, MXG will support the split records, and this change text will be revised.
JCLMNTH -The existing JCLMONTH and JCLMNTH both assume you want to JCLMNTHD build your MONTH PDB on tape. The original JCLMONTH read JCLMONTH five weekly PDBs and created MONTH as a sequential format MONTHBLD ("tape format") SAS data library, but there are multiple MONTHDSK mounts and rewinds when multiple data steps are used to Jan 9, 2005 write multiple datasets to a seq-format library on tape. So the JCLMONTH was revised (in 1987!) to write each dataset first in sequential format to //TAPETEMP DD on DASD, and MVS's MOD was used to add each dataset to the end of the tape, to eliminate backspace/rewind delays. -But even then, if your weekly PDBs were each on tape, the JCLMONTH required six tape drives, one for each weekly PDB and one for the MONTH output data library. So 1992s JCLMNTH example enhanced the process by requiring only one tape drive, by first PROC COPYing each weekly tape PDB with SELECT of the needed datasets to temporary DASD, (with UNIT=AFF so only one tape drive was needed to read all weekly PDBs), and then the MONTH PDB was created using //TAPETEMP, MOD, and UNIT=AFF on the same drive. -While both JCLMONTH or JCLMNTH were designed to write the //MONTH to tape, you could write MONTH to a DASD DD. However, a data library in sequential (tape) format has no directory, so you must read all N-1 preceding SAS data sets to read the Nth dataset you wanted, wasting CPU and I/O.
-In addition, you may have been wasting a lot of DASD space if you wrote your //MONTH to DASD in sequential format. This entire discussion was precipitated when the reporting site's monthly job failed when it ran out of disk space; they had moved from SAS V8.2 to SAS V9.1.3, but were unaware they were creating their Monthly PDB in sequential format: -Using SAS V8, V8SEQ, and COMPRESS=YES (MXG Default), and writing //MONTH to DASD in sequential format, they needed only 55,830 tracks, because V8SEQ, SAS 8.2 and COMPRESS=YES did compress sequential format libraries, but V9SEQ and SAS V9.1.3 does NOT compress seq format, so its data library was 106,710 (uncompressed) tracks! -So I had Chuck then run these benchmarks to reveal the source of their ABEND:
34305 DASD V8 8.2 --- Yes 106710 V6SEQ 8.2 65 Yes 106725 V9SEQ 9.1.3 26 No 106725 V9SEQ 9.1.3 26 Yes 34380 DASD V9 9.1.3 138 Yes 63705 DASD V9 9.1.3 22 No 106723 V8SEQ 8.2 22 No 55830 V8SEQ 8.2 126 Yes 34305 V8SEQ 8.2 133 Yes 50145 V8SEQ 8.2 20 No 106725 V8SEQ 9.1.3 26 No 106725 V8SEQ 9.1.3 26 Yes 34380 DASD V8 9.1.3 137 Yes 63705 DASD V8 9.1.3 20 No
and versions actually compress sequential format, but that is what I want: if you are writing to tape, the IDRC hardware compress the tape, so you don't want SAS to burn CPU time to also compress the data. Furthermore, you can write a single SAS dataset to an extended-sequential, striped, hardware-compressed DASD device, which also shouldn't be SAS-compressed. -MXG CONFIGV9 still specifies V6SEQ today, because I cannot tell from within SAS if you are at V9.1.3, or if you have the critical Hot Fix for earlier V9s. Originally I recommended V6SEQ, even under SAS V8.2, because it did NOT waste CPU time by compressing. While V9SEQ eliminated that compression, prior to SAS V9.1.3, you MUST use V6SEQ, because there were data corruption errors using V8SEQ or V9SEQ under SAS V9s prior to 9.1.3. If you have installed 9.1.3, it is NOW safe for you to change CONFIGV9 to V9SEQ. -So back to the new JCL examples, and documentation of all of your choices. This change adds example JCLMNTHD and member MONTHDSK, which should be used when yow want your monthly on DASD, and your weekly PDBs are also on DASD. Additionally, once you've built "Last Month's" PDB on DASD, you can archive it to a tape GDG by using: PROC COPY IN=MONTH OUT=MNTHTAPE MT=DATA; to write all of those datasets in a single write to tape when you're finished with this month's reporting and then free up the DASD space. JCL Code Weekly Monthly Select Tape Member include On On Copy Drives JCLMONTH MONTHBLD Tape Tapes No Six JCLMNTH MONTHBLD Tape Tapes Yes One JCLMNTHD MONTHDSK Disk Disk No None JCLMNTHT MONTHDSK Tape Disk Yes One -To be complete, JCL example JCLMNTHT is created, but it is likely to be unneeded - if you can't find space on DASD for your weekly PDBs, then why try to write a month to DASD? (Perhaps, if you only build a small number of datasets monthly, which is really what I personally think best - I only created the JOBS/STEPS/PRINT/RMFINTRV in my monthly, and did all of my other reporting week-to-week. Thanks to Bruce Green, MIB, USA. Change 22.342 INCOMPATIBLE MXG CHANGE TO BUILDPDB, if you have tailored BUILD001 your build to add SMF 115 or SMF 116 records. If so, you BUIL3001 MUST remove the references to 115 and/or 116 in the PDB BUILD004 exit members, EXPDBINC/EXPDBVAR/EXPDBCDE/EXPDBOUT. If BUILDPDB you overlook this revision to your tailoring, your first BUILDPD3 test of the new MXG BUILD will fail, because of duplicate BUILD606 dataset names being built in the first Data Step. Jan 10, 2005 Change 22.341 -If you have IFAs but don't have APAR OA09118 installed VMAC30 (adds CPUCOEFF to SMF 30), MXG-created IFAUNITS/IFEUNITS Jan 7, 2005 variables are missing, causing CPUUNITS to still include the IFAUNITS. Now, if there are RMF 72s from the same SYSTEM in the SMF file that precede the type 30 record, the old MXG logic to calculate EXCPRMF using CPUCOEFF from RMF is used to also populate IFAUNITS and IFEUNITS and to subtracts IFAUNITS from CPUUNITS. If both the IFAUNITS and EXCPRMF are still missing values, then both the APAR is not installed and there was no RMF 72 record from this system before that type 30 record. -The IFA CPU time variables are now formatted TIME12.2. Thanks to Bernie Pierce, IBM, USA.
VMAC7072 100%, and IFAACTTM was equal to the DURATM, because MXG Jan 6, 2005 did not consider offline IFAs. This change restructures MXG code for IFAs, summing IFAs SMF70ONT into IFAUPTM and summing IFAs LCPUPDTM into IFAACTTM to calculate PCTIFABY and also new variable NRIFAONL, the number of IFAs that were online (which, like NRCPUS, the number of CPs that were online) can be a fraction if some are offline. -The MXGCIN variable is also now correctly set to IFA even for offline IFAs. The original NRIFAS variable is now a count of installed IFAs, but is not used in calculations. -The IFAWAITn and PCTIFBYn variables (32 of each!) are no longer created; they are not needed in TYPE70 and they can be determined from TYPE70PR. -If CP engines were varied on/off, PCTMVSBY was wrong, as it was calculated based on DURATM instead of SMF70ONT; this also led to incorrect values of the new SHORTCPS variable, that was added in Change 22.325. -Mar 7, 2005: The MXGCIN 'guess' depends on IRD, because variable SMF70SPN, the LPAR Cluster Name, is only found in systems that are in an LPAR Cluster. Thanks to Dave Cogar, CA, USA. Change 22.339 -Major enhancement to TNG support: EXTNT100- The instance macro variables values and the MAXROW value EXTNT127 are now set dynamically from the input performance cubes, EXTNT127 so you won't get any ARRAY SUBSCRIPT OUT OF RANGE errors! FORMATS The cube's headers are read in a quick pass of the input, IMACTNG and then used to write the %LET PPoooI=nnn; statements TYPETNG (to //INSTREAM) for each object that was found in your TYPSTNG input; the input is then re-read to create the output. VMACTNG This will also minimize the amount of virtual storage VMXGINIT required for the MXG job; a REGION of only 200MB was Jan 6, 2005 used for test data with many objects and many instances Jan 21, 2005 that previously required over 400MB. And since the array size is now based on data, the default instance macro variables in VMXGINIT are now all set to one, and metric macro variables are back in the VMACTNG member, since they are only changed when new metrics are added by CA, and that requires other changes in the VMACTNG code. -Support for 28 new NT objects with over 600 metrics: Dataset dddddd Object Name TNT100 NT100 ASP.NET APPS V1.1.43 TNT101 NT101 ASP.NET V1.1.4322 TNT102 NT102 DOUBLE-TAKE CONNECTI TNT103 NT103 DOUBLE-TAKE KERNEL TNT104 NT104 DOUBLE-TAKE SECURITY TNT105 NT105 DOUBLE-TAKE SOURCE TNT106 NT106 DOUBLE-TAKE TARGET TNT107 NT107 FTP SERVER TNT108 NT108 GOPHER SERVICE TNT109 NT109 GROUPSHIELD FOR MICR TNT110 NT110 HTTP SERVICE TNT111 NT111 INDEXING SERVICE TNT112 NT112 INDEXING SERVICE FIL TNT113 NT113 MSEXCHANGE INTERNET TNT114 NT114 MSEXCHANGECCMC TNT115 NT115 MSEXCHANGEDS TNT116 NT116 MSEXCHANGEES TNT117 NT117 MSEXCHANGEIMC TNT118 NT118 MSEXCHANGEIS TNT119 NT119 MSEXCHANGEIS PRIVATE TNT120 NT120 MSEXCHANGEIS PUBLIC TNT121 NT121 MSEXCHANGEMSMI TNT122 NT122 MSEXCHANGEMTA TNT123 NT123 MSEXCHANGEMTA CONNEC TNT124 NT124 MSEXCHANGEPCMTA TNT125 NT125 SQLSERVER:BACKUP DEV TNT126 NT126 DATABASE TNT127 NT127 RSVP SERVICE -When processing TNG data on ASCII platforms, which have a default LRECL=255, you will need to add LRECL=32000 to your FILENAME statement. -Jan 20: temporary datasets used in _UTNGCNT now deleted. Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND. Change 22.338 The AUTOEXEx and CONFIGVx members now specify the option AUTOEXEC DLDMGACTION=REPAIR for all platforms; the option causes AUTOEXEU SAS to automatically repair and rebuild indexes and the CONFIGV8 integrity constraints, when a damaged SAS dataset is CONFIGV9 detected; the most common reason for a damaged data set Jan 4, 2005 is when it was left open because of a prior abnormal termination (i.e., on z/OS, an x22 timeout ABEND). SAS defaults are inconsistent, with z/OS having REPAIR for batch and PROMPT for interactive, but FAIL for batch and REPAIR for interactive for Windows systems. Thanks to Dan Squillace, SAS Institute Cary, USA.
VMAC80A KW23SPEC and KW23IGNR are only one byte each, but the bit Jan 4, 2005 tests were wrong, and were testing for two bytes. -Variable RACF07DT was increased to 200 bytes. Thanks to Erling Andersen, SMT, DENMARK.
ASUMUOW added to the PDB.ASUMUOW dataset for CICS transactions IMACUOW created by MQ-Series (but you must enable their addition JCLMQMCI in your IMACUOW member or in your input per comments. VMXGUOW IBM does NOT provide the variables NETSNAME/UOWTIME in VMXGINIT MQMACCT/MQMACCTQ datasets that are used to directly match Jan 10, 2005 up to CICSTRAN data. (IBM MQ-series support claimed that the STCK value in QWHCNID in MQMACCT could be used, but its value is NOT the same as the UOWTIME STCK value.) So this heuristic algorithm first matches CICSTRAN with MQMACCT by APPLID TASKNR TRANNAME to get NETSNAME/UOWTIME from CICSTRAN, which is then used to merge MQMACCT and MQMACCTQ (which can have more than one obs per uow if multiple MQ queues are used) with the CICSTRAN (and any DB2ACCT data, although DB2ACCT data is not required). -There is a clear exposure in using the TASKNR within an APPLID to get the NETSNAME/UOWTIME from CICSTRAN, as the IBM maximum for TASKNR is currently 99999, even though the field is a PD4 that could contain 9999999, but there is no other way at the present time. -You MUST have tailored either IMACUOW or ASUMUOW to even create observations in PDB.ASUMUOW in the first place, since the MXG default is to create zero observations. You must re-tailor using the new IMACUOQ or ASUMUOW member from this MXG to add the MQ Series variables. -ASUMUOW will not fail, even if there are no MQ data. -Variable MQTRAN counts the number of MQMACCT/MQMACCTQ records that were included in the Unit of Work. -MXG's BUILDPDB was revised by Change 22.342 to add the processing of SMF 115 and 116 data in the default PDB. -Member JCLMQMCI is a JCL example that uses VMXGUOW for standalone processing of SMF for CICSTRAN, DB2ACCT and SMF 116 data to create PDB.ASUMUOW with all three. -MXG 22.12. Error due to IMACUOW missing an end comment symbol. At the same time, CICSUOW dataset was externalized by MACRO _UOWICIC so that it's destination can be overridden. -VMXGINIT defines macro variable MXGMQADD, default blank. -Cosmetic. Using %INCLUDE SOURCLIB(ASUMUOW); with no DB2 observations caused UNINITIALIZED variable messages that are now eliminated by adding compiler fakers for DB2PARTY QWACFLGS and QWHSSSID variables, and missing value notes have also been almost completely suppressed. Thanks to Ove Dall-Hansen, Codan Insurance, DENMARK. Thanks to Diane Eppestine, SBC, USA.
EXTY748A -Subtype 5 adds these new metrics to TYPE74CA dataset: EXTY748R R7451CT1='BYTES*READ' EXTY748X R7451CT2='BYTES*WRITTEN' FORMATS R7451CT3='READ*RESPONSE*TIME' IMAC74 R7451CT4='WRITE*RESPONSE*TIME' VMAC74 R7451PBR='PHYSICAL*STORAGE*BYTES*READ' VMXGINIT R7451PBW='PHYSICAL*STORAGE*BYTES*WRITTEN' Jan 1, 2005 R7451PRO='PHYSICAL*STORAGE*READ*OPERATIONS' R7451PRT='PHYSICAL*STORAGE*READ*TIME' R7451PWO='PHYSICAL*STORAGE*WRITE*OPERATIONS' R7451PWT='PHYSICAL*STORAGE*WRITE*TIME' R7451XID='EXTENT*POOL*ID' R7451XTY='EXTENT*TYPE' R7452XFL='EXTENT*POOL*FLAGS' "Millisec" values are formatted TIME13.3 (so a value of 99 milliseconds will print as 0:00:00.099). -Subtype 8 creates three new datasets: TYPE78A - ESS RANK ARRAY DATA R748AACP='ARRAY*CAPACITY' R748AAID='RANK*ARRAY*IDENTIFIER' R748AASP='ARRAY*SPEED*IN 1000*RPM' R748AAWD='ARRAY*WIDTH' R748AEBC='ARRAY*TYPE*EBCDIC' R748ARID='RANK*IDENTIFIER' R748ATYP='ARRAY*TYPE*CODED' TYPE78R - ESS RANK STATISTICS DATA R748RAIX='INDEX TO*FIRST ARRAY*SECTION OF*RANK' R748RBYR='BYTES*READ' R748RBYW='BYTES*WRITTEN' R748RCNT='COUNT OF*ARRAYS*IN RANK' R748RKRT='READ*TIME' R748RKWT='WRITE*TIME' R748RPNM='EXTENT*POOL*NUMBER' R748RRID='RANK*IDENTIFIER' R748RROP='RANK*READ*OPERATIONS' R748RWOP='RANK*WRITE*OPERATIONS' TYPE78X - ESS EXTENT POOL STATISTICS R748XPID='EXTENT*POOL*IDENTIFIER' R748XPLT='EXTENT*TYPE' R748XRCP='REAL*EXTENT*POOL*CAPACITY* R748XRNA='ALLOCATED*REAL*EXTENTS*IN POOL' R748XRNS='REAL*EXTENTS*IN EXTENT*POOL' R748XRSC='REAL*EXTENT*CONVERSIONS' R748XSDY='SOURCES OF*DYNAMIC*RELOCATIONS' R748XTDY='TARGETS OF*DYNAMIC*RELOCATIONS' R748XVCP='VIRTUAL*EXTENT*POOL*CAPACITY' R748XVNS='VIRTUAL*EXTENTS*IN EXTENT*POOL' R748XVSC='VIRTUAL*EXTENT*CONVERSIONS'
DOC "housecleaned" with PROC DELETE DATA=_Wdddddd syntax, you Jan 1, 2005 got a non-fatal SAS warning message; replacing the syntax with the preferred %%VMXGDEL(DDDDDD=dddddd); eliminates the messages. (All were oversights where VMXGDEL should have been used.) These members were revised: ANALVVDS ASUMTAPE TYPEDOS TYPETMS5 VMAC103 VMAC108 VMAC29 VMAC30 VMAC50 VMAC79 VMACAIX VMACCIMS VMACCTLL VMACHMF VMACHSM VMACMPLX VMACTCP VMACTIMS VMACTMDB VMACTPF VMACTPX VMACVITA VMACVMON VMACVMXA VMACXXXX Thanks to Joe Babcock, Bank One, USA. Change 22.332 Support for (Optional) ESS segment GEPARMKY field values IMAC6ESS 0036x=ESSRETAS, 0041x=ESSOFSTF, and 0043x=ESSOFSTB, plus VMAC6 correction for '034'x field, which can have time-in-text Dec 30, 2004 formats of 10:00 or 0150:00:00. Jan 2, 2005 Thanks to Dr. Alexander Raeder, Itellium, GERMANY. Thanks to Harmuth Beckmann, Itellium, GERMANY.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|