* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
with QWACATYP=4 and UOWTIME=. were discarded by ASUMUOW. Thanks to Diane Eppestine, IBM Global Services, USA.
VMXGPARS special characters like ( ) ; ' % in the text, the parser Apr 12, 2008 got sick on macro quoting function idiosyncrasies. Using the %SUPERQ macro function appears to solve the parsing. Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA
VMAC7072 was explicitly named and was not in _N7072, so it could VMXGINIT not be "_NULL_"ed. MACRO _WTY70SP &WTY70SP..TYPE70SP % Apr 12, 2008 is now defined and VMXGINIT updated and _N7072 updated. Since it uses _VTY70 and _KTY70 definitions for content tailoring, no other _xTY70SP macros are not defined. Thanks to Chuck Hopf, Bank of America, USA.
ANALRMFR SAS V9.2 changed some text in SASLOG NOTES, but none have Apr 12, 2008 any impact on MXG execution. They do make comparison of SAS logs of MXG QA runs from both versions a bit messy, but these were noted in validating MXG execution .
step is enhanced with new resource information: NOTE: The SAS System used: real time 28:46.70 user cpu time 3:26.99 system cpu time 3:55.99 Memory 89953k OS Memory 101216k Timestamp 4/11/2008 6:39:31 PM
Real Time - amount of time spent to process the SAS job, also referred to as elapsed time. User CPU - CPU time spent to execute SAS code System CPU - CPU time spent to perform operating system tasks (system overhead tasks) that support the execution of SAS code. Memory - the amount of memory required to run a step. OS Memory - the maximum amount of memory that a step requested from the System. Timestamp - the end date/time of the step. Useful in diagnosis of SAS run time issues, and to correlate log events to time of day. Better than the OPTIONS DTRESET; that prints time to the minute at each new page, but I would have preferred to also see time to the milliseconds; a simple data step with no variables runs in about 5 milliseconds. -A new LIBREF, MAPS, exists with SAS V9.2 on Windows; this caused WORK.LIBNAMES and WORK.MXGENG datasets to have observation count differences when %VGETENG was used to get the engine type of a libname and saw the new libname. This has zero actual other impact. -The PROC CONTENTS output under SAS V9.1.3 printed only 42 lines per page, while SAS V9.2 prints 54 lines when both had the OPTIONS PS=54 default. This caused the location "printed pages 1-105" with 9.1.3 to be "pages 1-79" with SAS V9.2, which, of course, then impacted the location in all subsequent "printed pages n-m" log messages. -Inconsistencies in character text in these NOTEs: NOTE: The DATA step printed page 269. NOTE: The DATASTEP printed page 325. NOTE: No observations in input data set. NOTE: No observations in input dataset. -The SPF compare showed four cases of '0c'x before MXGNOTE with SAS V9.2, and five different instances with V9.1.3. The MXGNOTE text is a %PUT MXGNOTE statement, so having any difference was quite confusing, until I realized that the '0c'x in column 1 of the SAS log file when written to a disk file under Windows, is the top-of-page control, and these MXGNOTEs with '0c'x just happen to start a new page, and with the PROC CONTENTS changing pages, there were different lines at the top of each page, but nothing more nefarious. -COMPRESSION DISABLED for RDHITSP RDHITSNP datasets in 9.2 that was compressed in 9.1 suggest a minor change in the internal when-to-compress algorithm. -ANALRMFR: Harmless note new in V9.2 printed on SAS log: "NOTE: The array IN has the same name as a SAS-supplied or user-defined function. Parentheses following this name are treated as array references and not function references." The array name was changed to ININ to eliminate printing of this new harmless (and useless?) NOTE on the SAS log. I also made all FILE statements parameters consistent, left to right, for ease in reading, before I had realized that '0c'x issue was NOT due to differences in the FILE parameters in the ANALRMFR program itself! -An additional NOTE: WORK.CICSUOW HAS 0 OBSERVATIONS when datasets for ASUMUOW all has zero observations, possibly due to use of VIEWs.
VMACSRDF the numeric Max Percent Cache. New variable SRDMXUSP is Apr 10, 2008 created to avoid an ABEND due to CHAR and NUM conflict if May 5, 2008 the name were reused and you combined differently built PDB datasets. The old variable is left unchanged, and you can create the new numeric variable in old PDB's with SRDMXUSP=INPUT(SRDMXUSE,&PIB.1.)/256; May 5: Flags 3 and 4 decoded into individual variables. Change 26.058 IMF dataset TYPECIMS variable INPUTCLS was increased to VMACCIMS 2 bytes, but the FORMAT INPUTCLS $HEX2. statement seen Apr 10, 2008 before INPUT defined the variable's length to one byte. The $HEX2. was changed to $HEX4. But the INPUT was also now incorrect, as the two-byte value starts @76, instead of @77 for the one-byte value. An input class of ' T' that would have been stored as INPUTCLS='T' in one byte will now be stored as INPUTCLS=' T' in two bytes, so you need to examine any tests for INPUTCLS in your reporting programs. Thanks to Geert De Batselier, KBC, BELGIUM.
VMACDB2 but it falsely said it was also added to DB2STAT4. Now, Apr 8, 2008 it is kept in DB2STAT4. Thanks to Kerry Sommers, Deere & Co., USA. Change 26.056 Replaced by Change 26.264. Change 26.055 SAS V8 only: ERROR: REQVECTOR DATAREP IN DROP, KEEP .... UTILCONT because those two variables only exist with SAS V9. As Apr 4, 2008 they were only referenced in a DROP statement for a temp dataset, they are removed with no other impact. Thanks to George Ellard, Fedex, USA.
VMAC16 variables (BYTESORT ICEMOSIZ ICEFILSZ), and the format Apr 4, 2008 MGKILO is added to these count variables, which can have large values, so they will "print pretty". Thanks to Chuck Hopf, Bank of America, USA.
VMACRMFV ASISMPCT='NUMBER OF*VALID*SAMPLES*THIS ASID', but RMF III Apr 2, 2008 reports use SSHSMPNR='NUMBER*OF VALID*MINTIME*SAMPLES'. So if there are 2 samples for the job in question, in a 100 sample MINTIME interval, and one delay sample, MXG calculated 1/2 = 50% while RMF reports 1/100 = 1%. I could create 50 additional ASIxxxxx variables with the RMF III percentage values, but I personally think the way MXG calculates is more useful, since it reflects delay or using only when the job is actually active. However, if you wish to match the IBM RMF III display, you can use IBMPCT=MXGPCT*ASISMPCT/SSHSMPNR; because I have added SSHSMPNR to the variables kept in ZRBASI dataset. Thanks to Susan Kent, Charles Schwab, USA. Thanks to Jerry Urbaniak, Acxiom, USA. Change 26.052 IBM SMF 110 Subtype 2 Statistics STID=31 segments are not VMAC110 always valid; the segment length of 808 indicates there Mar 31, 2008 are 16 segments, but many segments have a value of one in LDBNRDSN, so MXG now loops to MAX(LDRNRDSN,SKIP/44). Impacts only the CICSDBDS dataset. Thanks to Diane Eppestine, IBM Global Services, USA. Change 26.051 ACF2 changed the format of ACSMFREL from a packed numeric VMACACF2 value ('62'x for Release 6.2) to a hex character ('C0'x Mar 28, 2008 for release 12), causing INVALID DATA FOR ACSMFREL, which cause ACSMFREL to be a missing value, causing additional potential errors. The INPUT was revised and 'C0'x will now be converted to ACSMFREL=12.0; Thanks to Patrick Holloman, Zions Bank Corp, USA.
VMAC74 for tape devices (no volume mounted at end of interval); Mar 28, 2008 MXG now translates to blanks to avoid non-printables.
VMAC102 IF QWHSIID= nnn THEN DO; statements to be the first in Mar 27, 2008 each definition, ahead of the LABEL, FORMAT, LENGTH, etc. This permits the use of the _CDExxxx syntax to construct MXG programs for multiple SMF record processing, using: %INCLUDE SOURCLIB(VMACSMF,VMACID,VMAC110,VMAC26J2, VMAC30,VMAC74,VMACDB2,VMAC102,IMACKEEP); DATA
_VARID _VAR110 _VAR26J2 _VAR30 _VAR74 _VARDB2 _V102022 _V102044 _V102063 _SMF
_CDEID ELSE _CDE26J2 ELSE _CDE30 ELSE _CDE74 ELSE _CDEDB2 ELSE _HDR102 ELSE _C102022 ELSE _C102044 ELSE _C102063 _END102
RUN; Thanks to Harald Seifert, HUK-COBURG, GERMANY. Thanks to Chris Weston, SAS ITRM Development, USA.
VMXGSUM VMXGSUM aborted, saying it had nothing to do, even if Mar 27, 2008 you had asked for other statistics. Now corrected.
VMACMGCR two new variables (INCOMPATIBLY, as they were inserted): Mar 27, 2008 MGCRCOMP='COMPRESS=*PARAMETER*IN MGCPARMS' MGCRTSKI='TCB*ADDRESS' and increased the length of two character fields, MGCRIV from $8 to $16, and MGCRKS from $40 to $64. Thanks to Denise Willers, InfoCrossing, USA.
IMAC6ESS ESSPRTAT='ESSPRTAT*PRINT*ATTRIBUTE*IN ESS' VMAC6 Sample record has a value of "document-codepage=IBM-273". Mar 28, 2008 Thanks to Peter MacCarthy-Morrogh, ATOSORIGIN, GERMANY. Thanks to Alexander Raeder, ATOSORIGIN, GERMANY. Change 26.045 VMACIMS support for '08'x log record for IMS Version 10 VMACIMS was incorrect even after Changes 26.026 and 26.045; the Mar 27, 2008 logic was revised, and enhanced to use the LINTSUB bits to store TRANSACT in LINTPSB (a new field added in V10) and to store LINTSY2 into TRANSACT when appropriate. Labels were added for many variables for IMS08 dataset. Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.
VMACIMSA in IMS 9.0+ two-byte INPUT, so TRANCLAS was still wrong. Mar 26, 2008 Thanks to Steve Hudson, AVNET, USA. Change 26.043 Initial header INPUT of SYSTEM in 1.4 to get SYSZONE was VMACVMXA off by 4 bytes, but actual 1.4 INPUT was correct and the Mar 26, 2008 value is retained from that INPUT.
VMACNMON PID and FULLCOMD populated (and the short record caused Mar 25, 2008 INPUT STATEMENT EXCEEDED error). Thanks to Steven Olmstead, Northwestern Mutual, USA. Change 26.041 The default INTERVAL in ASUM70PR in MXG 26.01 was changed ASUM70PR accidentally to INTERVAL=HOUR, but the intended default Mar 21, 2008 of INTERVAL=QTRHOUR,CECINTRV=HOUR are reinstated. Thanks to Jorge Fong, New York City DOITT, USA. Change 26.040 Variables for zIIP engines are added to TREND.TRND72GO: TRND72GO ZIPUNITS ZIEUNITS CPUZIPTM CPUZIETM Mar 21, 2008 Thanks to Ingegerd Jansson, Volvo, SWEDEN. Change 26.039 -Support for APAR OA24074 adds variable SMF70HHF to TYPE70 VMAC7072 (COMPATIBLY), with more complete HiperDispatch Status Mar 17, 2008 than in the original HiperDispatch Status in SMF70HDM. Mar 28, 2008 The new SMF70HHF is formatted HEX2 with these bit values: Apr 5, 2008 SAS bit IBM Bit Meaning '1.......' 0 HiperDispatch supported '.1......' 1 HiperDispatch is active '..1.....' 2 HiperDispatch status changed -MXG 26.01 SMF70PAT/CPUPATxx, new parked time, was wrong; my guessed INPUT of SMF70PAT/CPUPATxx Parked Time with no test records was incorrect, needing a divide by 4096. So MXG 26.02 is needed for HiperDispatch and Parked time. -See Newsletter FIFTY-TWO for description and schematics of this new "Parked Time" durations in TYPE70/TYPE70PR. -The PCTMVSBY calculation now subtracts SMF70PAT (parked) from SMF70ONT (online) for the denominator. Those three elapsed time durations in SMF70PAT, SMF70ONT and DURATM are gathered separately and small deviations are expected and observed: SMF70PAT was 0.015 seconds (15 millisecs) larger than SMF70ONT, which would have created a negative PCTMVSBY, so MXG's heuristic now calculates the PCTMVSBY only if the ONT-PAT delta is at least +.02 seconds. -SMF70HDM was not initialized to blank and was incorrectly kept in TYPE70 instead of TYPE70PR. -This APAR and Change applies only to z10 and later CPUs.
VMACVMXA MACRO _NVMXA. Mar 17, 2008
FORMATS to a syntax difference between Windows and z/OS SAS that Mar 11, 2008 I added after the last QA test on z/OS. Thanks to Nathan Loewenthal, CITI, USA. ====== Changes thru 26.036 were in MXG 26.01 dated Mar 10, 2008========= Change 26.036 Variable R793CUT was 0.062 when it should have been 62, VMAC79 the Percent MVS Utilization. Variable R793CUU, Percent Mar 10, 2008 LPAR Utilization was correct. The 4.3 input is now 4. Thanks to Dan Almagro, Automobile Club of Southern California, USA. Change 26.035 Dataset TYPE74SY variable R742SDIR is FORMATed with the FORMATS existing $MG074PD format, and that format is updated with VMAC74 new value '20'x:'20X:LOCAL' so it can be used for both Mar 10, 2008 R742SDIR and R742PDIR variables Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
VMACITRF record with LENGTH=251 was not expected; now the code Mar 8, 2008 tests each INPUT statement to verify data is present. Comments added to indicate that MXG has been tested with records from OMEGAMON XE FOR IMS 4.1 with DCR 77/78.
EXTVW011 creates these new datasets with TYPETNG (NSM was TNG): EXTVW012 DATASET DDDDDD DESCRIPTION EXTVW013 VW011 VW011 NSM CA CPU INTERRUPT GRO EXTVW014 VW012 VW012 NSM CA CUBE STORE GROUP EXTVW015 VW013 VW013 NSM CA DISK GROUP EXTVW016 VW014 VW014 NSM CA PROCESS GROUP (PI EXTVW017 VW015 VW015 NSM FILESYSTEM EXTVW018 VW016 VW016 NSM NETWORK EXTVW019 VW017 VW017 NSM PRINTER QUEUE FORMATS VW018 VW018 NSM PROCESS IMACTNG VW019 VW019 NSM USERS VMACTNG and new metrics were added to several existing VMWare VMXGINIT datasets. Mar 8, 2008 Thanks to Xiaobo Zhang, CheckFree, USA. Change 26.032 Debugging PUT _N_= _I_= _J_= LOCCONN=; statement printed VMACRMFV lots of messages on the log if you enable CF data, but Mar 7, 2008 had no other adverse impact, and is now removed. Thanks to Stephen Hoar, Lloyds TSB, ENGLAND. Change 26.031 -Support for Dedicated zAAPs and fix for Dedicated zIIPs. VMAC7072 Change 25.211 only worked for one Dedicated zIIP engine, VMXG70PR because it used total ZIPWAITM vs the ZIPWAIT(LCPUADDR+1) Mar 7, 2008 wait time for each engine, impacting TYPE70 variables ZIPACTTM, PCTZIPBY, and PCTCIBYn. That logic is fixed, and new logic for Dedicated zAAPS is added, impacting the IFAACTTM, PCTIFABY, and PCTCIBYn variables. For Shared zIIPs or zAAPs, the LPAR Dispatch time was always valid, but for Dedicated zAAPs or zIIPS, the dispatch time was always reported as 100% busy. I recommend that you do not use the PDB.TYPE70PR dataset, as it has too much detail and requires lots of logic in your programs to sort out what's what; instead, use the ASUM70PR-created PDB.ASUMCEC and PDB.ASUMCELP CEC-level summary datasets or PDB.ASUM70PR and PDB.ASUM70LP, which already have separate variables for the "CPU" times for your CPs, ZIPs and ZAPs. But, if you still use TYPE70PR: For Dedicated zIIPs and zAAPs, in the PDB.TYPE70PR dataset, the LCPUPDTM and LCPUEDTM dispatch values are not changed, and will still be the "100%" value. But MXG now creates IFAACTTM and ZIPACTTM variables from the ORIGWAIT field for each LCPUADDR that is an IFA or a ZIP engine. -Support for Dedicated zIIPs and zAAPs in ASUM70PR-created summary datasets was also added by this change, so the PDB.ASUM70PR, PDB.ASUM70LP, PDB.ASUMCEC and PDB.ASUMCELP datasets have correct values. Thanks to Mark Cohen, DTS, ITALY. Change 26.030 -Two extraneous debugging PUT statements were removed from VMACNTSM the SQL record processing. Mar 6, 2008 -Datasets SQLDATAB and MSQDATAB have new variable INSTANCE ('SQL' in SQLDATAB, MSQSRVDB in MSQDATAB), and DATABASE is populated, for ease in combining them. Thanks to Roger Zimmerman, Hewitt Associates, USA. Change 26.029 Cosmetic. A slash was missing in the SUCCESSFULLY READ VMACSMF SMF message, causing a linewrap on the SAS log. Mar 6, 2008 Thanks to Peter Krijger, ANZ National, NEW ZEALAND. Change 26.028A Fields added COMPATIBLY to HSM FSR SMF record in z/OS 1.8 FORMATS and z/OS 1.9 are now created in HSMFSRST dataset, and all VMACHSM bit flags are decoded. Mar 6, 2008 New variables added in z/OS 1.8 SMF records: FSRCPYME='REQUESTED*FAST REPLICATION*METHOD' FSRFDASD='DASD*COPY*DELETED?' FSRFDCPY='DUMP CLASS*COPY POOL*DELETED?' FSRFDVER='ENTIRE*DUMP*VERSION*DELETED?' FSRFPIGB='USED*TAPE*ALREADY*MOUNTED?' FSRFRDMP='FAST*REPLICATION*DUMP OR*RESORE?' FSRFREMO='COMPLETED*ON*REMOTE*SYSTEM?' FSRFRHOS='MWE*PROCESSED*BY REMOTE*HOST?' FSRFRTRY='BACKUP*DURING*RETRY*INUSE?' FSRFBKTP='BACKUP*VERSION*DELETED*IS ON TAPE?' FSRFEXBV='BACKUP*VERSION*DELETED BY*EXPIREBV?' FSRFEXDT='DATASET*DELETED BY*EXPDT OR*MGMTCLASS?' FSRFVINI='RECOVERY*SCHEDULED*FROM VOLUME*REQUEST?' FSRFXPL1='DATASET*BEING*EXPIRED*IS FROM ML1?' FSRFXPL2='DATASET*BEING*EXPIRED*IS FROM ML2?' FSRRECON='RECONNECTION*MIGRATION?' FSRFLG4 ='FSRFLG4*FLAGS' FSRFG480='FSRF*FRRECOV*DSNAME*COMMAND?' FSRFG440='FSRF*FRRECOV*FROMDISK*ONLY?' FSRFG420='FSRF*MULTIPLE*DSNAMES*SPECIFIED?' FSRFG410='FSRF*MULTIVOLUME*FRRRECOV*REQUEST?' FSRFG408='FSRF*ALTERPRI*COMMAND?' FSRFG404='FSRF*ALTERPRI*HIGH*KEYWORD? FSRFG402='FSRF*INC*COPY POOL*INCREMENTAL?' FSRORGID='HOST*ID THAT*GENERATED*REQUEST' FSRFREAS='FSR*FR*REAS*RETURN*CODE' FSRCLIP ='TARGET*VOL+FROM MWE*VOL RESTORE' FSRCPNAM='COPY*POOL*NAME' New variables added in z/OS 1.9: FSRECYSO='SOURCE*FOR*RECYCLE*OPERATION' FSRECYCN='RECYCLE*COUNTER' FSRCALTW='RECALL*CAUSED*TAPE*TAKEAWAY?' FSRPSQTY='TRACKS*NEEDED*WHEN ML1*OUT OF SPACE' Bit variables now decoded that should have been decoded: FSRFFSTR='FROM*STRIPED?' FSRFFSTR='TO*STRIPED?' FSRFNONQ='NOT*SERIALIZED*ENQUEU?' FSRFNQN1='ENQUE*FAILED*ONCE?' FSRFNQN2='ENQUE*FAILED*AGAIN?' FSRFVER ='FSRGEN*CONTAINS*VERSON?' FSRFVSDS='VSAM*DATASET?' FSRFT0 ='CONCURRENT*COPY*FUNCTION*USED?' Variables DSRTYPE,VSRTYPE,FSRTYPE,WFSRTYPE are decoded by MGHSMFU format, which is updated with new values of: 21='21:FAST REPLICATION BACKUP FUNCTION' 22='22:FAST REPLICATION RECOVER FUNCTION' 23='23:FAST REPLICATION DELETE FUNCTION' Thanks to Michael Friske, Fidelity Systems, USA. Change 26.028 Protection for a divide by zero when SMF70GMU was zero, VMXG70PR in the new Group Capacity PCTGCUSE creation in ASUM70GC Mar 6, 2008 dataset. Thanks to Alexander Raeder, ATOSORIGIN, GERMANY. Change 26.027 Nigel's Monitor, NMON, writes RECTYPE='ERROR' records, VMACNMON with a text message (ERRORMSG=), and MXG printed the text Mar 6, 2008 on the SAS log, but ERRORMSG= made it look like it was an MXG error. Now, when these records are read, the text on the log is printed with this header information
ENDTIME=25FEB2008:02:37:52.00 MESSAGE: ERROR,T0144,Disk statistics reset detected. This time Read=0 Write=0 and Total So far=0 You'll have to contact your NMON guru over in AIX/LINUX land, to find out if that message is expected or not. Thanks to Steven Olmstead, Northwestern Mutual, USA.
IMACIMS -TYPEIMS7 and TYPEIMSA (used in ASMIMSL6/JCLIMSL6) now IMACIMSA both keep these new variables from 07 and 08 log records VMACIMS in their IMS0708 and IMSTRAN and BMPS datasets: VMACIMSA From IBM IMS 07 log record: TYPEIMS7 DLRABRSN='ABEND*REASON*CODE' TYPEIMSA DLRCPUID='CPU ID*PLACE*HOLDER' Mar 6, 2008 DLRESAF ='ESAF*CALLS' DLRFLD ='FASTPATH*FLD*CALLS' DLRNPGM ='DLRNPGM ' DLRNWID ='NETWORK*IDETIFIER*OF LAST*MESSAGE' DLROSAMR='OSAM*IO*READS' DLROSAMW='OSAM*IO*WRITES' DLRPOS ='FASTPATHP*POS*CALLS' DLRRLSE ='RLSE*CALLS' DLRTOTIO='TOTAL*DL/I*OSAM+VSAM*CALLS' DLRVSAMR='VSAM*IO*READS' DLRVSAMW='VSAM*IO*WRITES' DLRXCOPY='COPY*CALLS*(XQUERY)' DLRXRSTR='RSTR*CALLS*(XQUERY)' DLRXSAVE='SAVE*CALLS*(XQUERY)' From IBM IMS 08 log record: LINTFLG1='FLAG*1' LINTPGM ='PROGRAM*NAME' LINTPSB ='PSB*NAME' LINTSUB ='IMS08*SUBTYPE' LINTSY2 ='TRANCODE OR DBNAME' -The default in _IMSVERS value is now consistently 8.1. Member IMACIMS is used only in archaic TYPEIMS member. Member IMACIMS7 sets _IMSVERS for TYPEIMS7 member. Member IMACIMSD sets _IMSVERS for TYPEIMSD (DBCTL). Member IMACIMSA sets _IMSVERS for TYPEIMSA (ASMIMSL6). Member IMACIMSA sets _IMSVERS for TYPEIMSB (ASMIMSL6). -You can always use the &MACKEEP macro variable to set the value of _IMSVERS instream, with this syntax: %LET MACKEEP= MACRO _IMSVERS 10.0 % ; %INCLUDE SOURLIB(TYPEIMS7); -All datetime stamps are now converted to local time zone Yüklə 28,67 Mb. Dostları ilə paylaş:
|