* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
variable ORIGWAIT in PDB.TYPE70PR; variable ORIGWAIT and SMF70WST are very close in PDB.TYPE70PR, but SMF70WST is smaller by as much as a half second in 15 minutes.
FORMATS that is formatted by new $MGACFTY format to decode the VMACACF2 combination of the 2nd-4th bytes of ACVMFRES and the HEX May 21, 2009 value of ACVMFLGS NI (LOGICAL AND'ed) with '3E'x. These new values are primarily for DB2 activity identification. Thanks to Jake Phillips, Lowe's Companies, USA. Thanks to Jim Horne, Lowe's Companies, USA. Thanks to David Pflum, CA, USA. Change 27.104 The BVIR TS7700 HYDRA data contains GMT values for all of VMACBVIR its timestamps, SMFTIME, STARTIME, ENDTIME, and VERTIME, May 24, 2009 whether the data is in History File or SMF File format, Jun 1, 2009 but there is no field with the GMT Offset time, so you must tell MXG your GMT Offset value, with this syntax %LET MACKEEP= MACRO _BVIRGMT -18000 % ; if you want those datetimes on your local time zone. For USA sites, the value is negative, -18000 for EST at 5 hours, -14400 for EDT at 4 hours behind GMT, etc. You set that GMT offset value using: - SMF-FORMAT BVIR DATA: // EXEC MXGSASV9 //SMF DD DSN=BVIR.SMF.FORMAT,DISP=SHR //PDB DD DSN=BVIR.PDB.LIBRARY,DISP=(,CATLG),.... %LET MACKEEP= MACRO _BVIRGMT -18000 % ; %INCLUDE SOURCLIB(TYPSBVIR); or - HISTORY-FORMAT BVIR DATA: // EXEC MXGSASV9 //BVIRHIST DD DSN=BVIR.HISTORY.FORMAT,DISP=SHR //PDB DD DSN=BVIR.PDB.LIBRARY,DISP=(,CATLG),.... %LET MACKEEP= MACRO _BVIRGMT -18000 % ; %INCLUDE SOURCLIB(TYPSBVIH); Labels were revised Jun 1. Thanks to Perry Lim, Union Bank, USA.
VMXGDUR and they can be used in any MXG INTERVAL= parameter in May 21, 2009 ALL ANALxxxx/ASUMxxxx/TRNDxxxx/RMFINTRV invocations. Thanks to Jacob Nudel, Thomson Reuters, USA. Change 27.102 PARTNCPU and other variables in PDB.ASUM70PR could be VMXG70PR missing values if the last LPARNAME in this sort order May 20, 2009 BY CECSER SYSPLEX SYSTEM SYSNAME SMF70GIE GMTOFFTM LPARNUM LPARNAME; was for a non-z/OS LPAR, as the "CP-engine" variables are missing values in non-CP-engine LPARS. This could only occur with recent ASUM70PR enhancements in 27.02+ that added non-CP-engine LPARS to PDB.ASUM70PR dataset. This case had a z/VM LPAR with only IFLs as last LPAR. By changing sort order to GMTOFFTM DESCENDING LPARNUM, the LAST LPAR for every interval will be LPARNUM=0, LPARNAME='PHYSICAL' LPAR, which always has the variables. Thanks to Paul Naddeo, FISERV, USA.
VMACPRPR in DATE or TIME character fields, so MXG had two separate May 20, 2009 links for conversion, but four combinations could exist, Jun 2, 2009 causing missing values in STARTIME and ENDTIME. But only Jun 22, 2009 one conversion is needed, by using '.:' in the SCAN() to decode with whichever delimiter is present. -Variable COPY was not kept in PRPR1620 dataset. -Jun 19: JOBNAME increased to $128 as it can contain more text. Fortunately, since PRISMA code is executed standalone, with only the PRISMA log file read, this ONLY impacts the length of JOBNAME in the PRISMA datasets. -Variables COPY, UNKNOWN, PRINTCNT, MEDIANUM, OFFSETS in PRPR1620 are read in that order to correct values. Thanks to Nik Marien, KBC Global Services NV, BELGIUM. Change 27.100 -MXG "trashed" dataset ZRBLCP in RMF III from z/OS 1.10 VMACRMFV because MXG (in a rare case) didn't use the triplet for May 20, 2009 offset/length for the INPUT of the CPC Logical Processor May 25, 2009 Section (DSECT ERBCPCDB). 24 bytes inserted after the NR of LCPUs, and 8 bytes added to each LCPUADDR segment with CPUG3 Version=5 and CPCDB Version=4 are now properly read using the triplet, which will also protect for future IBM changes, transparently, without trashed output data. -IBM RMF III Support provided doc of the new LCPUADDR data fields, in those extra bytes, now these new variables LCPUPRMN='PROC*MIN*WEIGHT' LCPUPRMX='PROC*INI*WEIGHT' LCPUPOLW='POLAR*WEIGHT' in the ZRBLCP dataset. -But in validating this correction, I saw that there were observations for each LCPUADDR, including offline engines and LCPUADDR that were NEVER dispatched during each one minute interval, a waste of disk space, so the logic now only outputs ZRBLCP observations if LCPUPDTM dispatch is non-zero (but that could be overridden in MACRO _EZRBLCP if you really want all the zero dispatch intervals to be created). Thanks to David Lo, Bank of America, USA. Thanks to Betty Wong, Bank of America, USA. Change 27.099 -The optional Omegamon DB2 segment for CICS/TS 3.2 or 4.1 IMACICOB had correct counts but the durations were way too small. May 20, 2009 They were divided by 4096 instead of multiplied by 16 in Change 25.238, when a new block of code for CICS/TS 3.2+, for SMFPSRVR GE 65.0 used the /4096 conversion, expecting a TODSTAMP value, instead of the old *16 conversion for 16 microsecond values. I must have misread the DSECT. The new block with /4096, and the tests for SMFPSRVR are now all removed, and there is a single code block for all CICS versions. -The 100-byte segment always exists when enabled, but its internal length is zero if the transaction did not call DB2, so the MXG logic now only INPUTs those 24 fields if that length is non-zero (so those variables will have a missing value in non-DB2 transactions, instead of all having values of zero). Thanks to Jim Polenti, Edward Jones, USA. Thanks to Jeana M. Bechtel, Edward Jones, USA. Change 27.098 -Typos in BLDSMPDB for WAS were corrected in BLDSMPDB BLDSMPDB the statement weekkeep=&wek2kep. VMXGALOC was changed to weekkeep=&wek2keep, May 19, 2009 and after line 437, this statement was inserted dayskeep=&day2keep, -In VMXGALOC, the %GLOBAL was removed as superfluous; the variables are being set by a SYMPUT which is an implicit GLOBAL. This removed spurious messages on the SAS log, messages that were different when MXG was run in a Window versus run in Batch. Thanks to Gary Havlatka, Creative Automation, USA.
READDB2 DB2 V9 DB2STAT0, DB2STAT1, DB2GBPST, DB2STAT4 (IFCID 225) VGETOBS are merged to create PDB.DB2STATS, and for DB2 V8, the VMACDB2 DB2STAT0, DB2STAT1, T102S225 are merged in PDB.DB2STATS. May 24, 2009 -All variables (QW0225xx) from DB2STATS4 (DB2 V9+) are Jun 25, 2009 automatically merged into the PDB.DB2STATS dataset. -All variables (QW0225xx) from T102S225 (DB2 V8) can be merged into the PDB.DB2STATS dataset, but you may have to make some updates, if you don't use %READDB2, below. -READDB2 always creates DB2STAT4 with IFCIDS=STATISTICS. -READDB2 only creates T102S225 if IFCIDS=225 .... is used. -READDB2 updates PDB.DB2STATS with DB2STAT4 if STATISTICS is specified. If IFCID 225 is also specified, then the T102S225 is also updated into PDB.DB2STATS. -If you use BUILDPDB, TYPEDB2, TYPSDB2 instead of READDB2: -All variables (QW0225xx) from DB2STATS4 (DB2 V9+) are automatically merged into the PDB.DB2STATS dataset. -All variables (QW0225xx) from T102S225 (DB2 V8) can be merged into the PDB.DB2STATS dataset, but you have to tell MXG you have V8 data to be added; see below. -You should use PDB.DB2STATS for all statistics reports, replacing use of DB2STAT0, DB2STAT1, DB2STAT4, DB2GBPST, and T102S225 in your DB2 reports. More details: -DB2 V9 DB2STAT4 (optional IFCID=225, ID=100, subtype=2) and DB2 V9 DB2GBPST (100 subtype 1 QBGL) variables are now merged to expand existing PDB.DB2STATS dataset to contain all variables for each interval for each DB2 Subsystem, i.e., all possible variables from the DB2 ID=100 Subtype 0, 1, or 4 SMF records. DB2STAT4 vars are added by %INCLUDEs of TYPEDB2, TYPSDB2, or BUILDPDB, or by using %READDB2(IFCIDS=STATISTICS) program for V9. -DB2 V8 writes IFCID=225 as an SMF 102 subtype 225 Trace record, and MXG creates the T102S225 dataset for V8, but it has the same variables as the V9 DB2STAT4, so DB2 V8 IFCID=225 variables can also be added into PDB.DB2STATS: -%READDB2(IFCIDS=STATISTICS 225,PDBOUT=PDB) will create both T102S225 and DB2STAT4 and merge each to expand and populate the PDB.DB2STATS dataset with both V8 and V9 IFCID=225 variables. -To add V8 IFCID=225 processing to BUILDPDB, and to add those variables to PDB.DB2STATS, you need to EDIT these statements into these MXG exit members into your "USERID.SOURCLIB" tailoring PDS library/directory: EXPDBINC: %INCLUDE SOURCLIB(VMAC102); EXPDBVAR: MACRO _VARUSER _V102225 % EXPDBCDE: MACRO _CDEUSER _HDR102 _C102225 _END102 % EXPDBOUT: _SDB2STY
-If you instead use these other ways to create T102S225 dataset for DB2 V8, depending on how you created it: if created by old-style macro macro variable TYPE102 _W102225 &W102225 TYPS102 _L102225 &P102225 %READDB2 _W102225 &W102225 %READDB2(PDBOUT) n/a &PDBOUT EXPDBOUT PDB PDB then you have to use %LET to set the DDNAME of your T102S225 dataset's library, and then insert the new _SDB2STY macro token in your source program, after you have created PDB.DB2STATS and PDB.T102S225, e.g.: %LET PDB2STY=PDB; _SDB2STY; RUN; -READDB2 in MXG 27.02-27.03, when ONLY the IFCIDS=225 was requested, caused a 10-fold increase in CPU time if there were lots of other DB2 records, because READDB2 in those versions (incorrectly) created all of the other DB2ACCTx and DB2STATx datasets when only T102S225 was desired. lots of unwanted ID=101 records. Now, only T102S225 is created if only IFCIDS=225 is specified. -All executions of READDB2 should be faster; all non-DB2 SMF records are immediately skipped as soon as the SMF ID is read; previously, all DB2 Product Headers were read before record selection/skipping was done. -PROC COPY IN=WORK OUT=&PDBOUT was incorrectly run (copy each DATASET to the &PDBOUT libname) when &PBOUT=YES, was specified, causing LIBNAME YES NOT FOUND. Now, the PROC COPY is bypassed if PDBOUT=YES. -VGETOBS was enhanced with new NOEXIMSG=NO argument that bypasses printing of the DATASET DOES NOT EXIST message and the DATASET HAS nnn OBSERVATIONS message, useful when VGETOBS is used only to detect that a dataset exists. -These new variables, based on IBM MEMU2 report example: are created in PDB.DB2STATS from the DB2STAT4/T102S225: CUSHION = QW0225SO+QW0225MV+QW0225CR; NDB2STOR= QW0225EH-QW0225GM-QW0225GS-QW0225FX-QW0225VR ALLOWSTR= QW0225RG-CUSHION-NDB2STOR; THRDUSE = QW0225RG-CUSHION-NDB2STOR-QW0225GM -QW0225AS-QW0225FX-QW0225EL; THRDFTPT= (QW0225VR-QW0225AS+QW0225GS) / (QW0225AT+QDSTCNAT); MAXTHRDS= THRDUSE / THRDFTPT; TOTTHRDS= QW0225AT+QDSTCNAT; OVERALLO= MAXTHRDS - TOTTHRDS; CUSHION ='CUSHION*WARNING' NDB2STOR='TOTAL*DBM1*STORAGE' ALLOWSTR='ALLOWABLE*STORAGE' THRDUSE ='THREAD*STORAGE*USED' THRDFTPT='THREAD*STORAGE*PER THREAD' MAXTHRDS='MAXIMUM*THREADS' TOTTHRDS='TOTAL*THREADS' OVERALLO='OVER*ALLOCATED*THREADS' Thanks to Ray Dunn, CIGNA, USA. Thanks to Deborah L. Soricelli, CIGNA, USA. Change 27.096 There is a new "MEM" object with 15 new variables: VMACNMON MEMTOTAL HIGHTOTAL LOWTOTAL SWAPTOTAL MEMFREE May 18, 2009 HIGHFREE LOWFREE SWAPFREE MEMSHARED CACHED BIGFREE BUFFERS SWAPCACHED INACTIVE ACTIVE instead of the non-overlapping 5 memory variables that were in previous NMON MEM Object records. The order of the two LOW/HIGH sets in these new fields is clearly mis-documented in the "MEM" Header record; the LOW value precedes the HIGH value, so MXG's code now matches the actual data rather than the documentation. -Labels for variables REALFREE & VIRTFREE didn't include "PERCENT". Those memory percentages are calculated as REALFREE=100*REMBFREE/REMBTOTL; VIRTFREE=100*VIMBFREE/VIMBTOTL; -Both sets of memory variables are kept in NMONINTV. -"NMON", "Nigel's Monitor", is now delivered as part of TOPAS in AIX 5.3/6.1 or VIRTUAL I/O SERVER VIOS 2.1. Thanks to Tom Draeger, Aurora Health Care, USA. Change 27.095 The TRND23 member had not been updated to use the macro TRND23 variables TRENDOLD TRENDNEW TRENDINP, which optionally May 17, 2009 set the libnames for new, old and input trend libraries, and old macro names expected the week input in the "PDB" libname, when it should have used "WEEK" to match the other TRND Trending members. Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd, AUSTRALIA
IMACACCT error had NRACCT=127 and LENACCT=400, impossible values, May 14, 2009 and there was only trash at the OFFACCT location. MXG only decodes 9 ACCOUNTn fields, printing a message for the 10th, but IMACACCT did not protect for this much of invalidity. Now, it stops reading the ACCT fields when the 10th is encountered, with enhanced diagnostics. Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY. Change 27.093 Variable JESNR in TYPETPMX datasets was only 5-digits but VMACTPMX JESNR can now be up to seven digits. The VMXGJESN member May 13, 2009 is now %INCLUDEd after JCTJOBID has been input, and the Mar 20, 2012 JESNR is now created from JCTJOBID rather than just input of the last five digits. Mar 2012: Maximum JESNR is 999,999 because the first of seven digits is always a zero. Thanks to Paul Volpi, UHC, USA. Thanks to James D. Lieser, UHC, USA.
VMXGOPTR -ONLY under SAS V8.2, MXG 27.03 caused BUILDPDB errors in VMXGSUM the VMXGSUM invocation for SUMSTATB with error messages May 14, 2009 MXGNOTE: VMXGSUM FROM MXG 27.03 INVOKED BY SUMSTATB May 18, 2009 ERROR: OVERFLOW HAS OCCURRED; EVALUATION IS TERMINATED. May 22, 2009 ERROR: THE MACRO VMXGOPTR WILL STOP EXECUTING. This error is ONLY in the SAS V8 %Macro compiler, and is circumventable; the problem is that V8 %Macro compiler is not terminating strings at the equal sign as expected, but by wrapping the strings in double-quotes, to make it a character compare rather than an evaluated comparison circumvented the compiler error. There is also an associated change between V8 and V9 in the limit to the value of a numeric compare in the macro language from 2**32 in V8 to 2**64 in V9, causing the compare to work accidentally in V9 but not in V8. The one statement in VMXGOPTR that caused SAS V8 to fail IF "&STRING"="123456789123456789" %THEN .... was corrected, so this part of MXG continues to execute with SAS V8.2, BUT USING V9 IS MUCH BETTER AND SAFER! -Enroute to isolating the actual error, we investigated VMXGSUM for long-length-macro-text, a known past problem with the SAS Macro Language, and did reduce the length of some macro variables in the updated VMXGSUM, but it was not the cause of the OVERFLOW. This simple test isolated the V8-only compiler error: %MACRO TESTCASE; %LET STRING=12345678912345689; %IF &STRING=12345678912345689 %THEN %PUT TEST FAILED; %MEND TESTCASE; %TESTCASE; When executed on SAS V9, "TEST FAILED" was printed. when run under SAS V8.2, the OVERFLOW occurred.
their time fixing the %Macro compiler error, with what appears to be a complete circumvention. Chuck and I spent a great deal of time chasing this V8-ONLY error, just so those of you that are still limping along on ancient V8, and knowing that you do need V9 (but just can't find time to install it) can still get the full benefits of all of the new features and enhancements in the current MXG. -ONLY user SAS V9.2, just to get even, its macro compiler found invalid syntax of %THEN %THEN in VMXGOPTR, when it was called from deep within READDB2, causing V9.2 error message NO MATCHING %IF FOR %THEN. SAS V9.1.3 didn't burp with that same invalid syntax! Thanks to Francois Chable, DTF/DESI, FRANCE. Thanks to Hai Dang, DTF/DESI, FRANCE. Thanks to Winnie Peng, Hawaii Medical Service Association, USA. Change 27.091 ASG TMON/CICS variables WTSCWTTM and WTSCWTCN were input VMACTMO2 reversed, with the counts in the time field (but divided May 13, 2009 by 1 million!) and the time in the count filed (and NOT divided as it should be), in three separate INPUTs. Thanks to Shantha Hallett, Capgemini UK, ENGLAND
VMAC7072 now described by new variables R723RN01-R723RN15, from May 11, 2009 the Resource Delay Type Names Section added in z/OS 1.10 to the SMF 72 Subtype 3 record. There is a separate Name Section for each of subsystems (DB2,CICS,IMS,SMS,etc.) that capture delay samples, so each can have a different description of each of its fifteen delay counters. -The _BTY72DL "BY list" sort order that removes dupes was revised by adding RPRTCLAS as the penultimate variable, a protection required ONLY if you have (unwisely) used the same name for a Service Class and for a Reporting Class.
thus far, all test files have R723RDNN=0. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
FORMATS -Format $MGBVIDC added x23 3592 Model E05 x24 Model E06. VMACBVIR x23='x23:3592 Model E05 (Encrypted) May 6, 2009 x24='x24:3592 Model E06. -New DLIBSEQN, Distributed Library Sequence Number is added to all datasets; while documented as EBCDIC, the same protective algorithm for GLIBSEQN in Change 27.077 is used for DLIBSEQN in case it really is also ASCII. -BVIR10 new variable DEFTHRTL -BVIR30 new variables: PCTWDFTH AVGDEFTH BASEDFTH PRMIGTTH UNMIGD00 AWAITR00 UNMIGD01 AWAITR01 -BVIR33 new variables: G1MLCTA1-G1MLCTA4 G1ALCTA1-G1ALCTA4 G2MLCTA1-G2MLCTA4 G2ALCTA1-G2ALCTA4 G3MLCTA1-G3MLCTA4 G3ALCTA1-G3ALCTA4 G4MLCTA1-G4MLCTA4 G4ALCTA1-G4ALCTA4 G5MLCTA1-G5MLCTA4 G5ALCTA1-G5ALCTA4 G6MLCTA1-G6MLCTA4 G6ALCTA1-G6ALCTA4 G7MLCTA1-G7MLCTA4 G7ALCTA1-G7ALCTA4 G8MLCTA1-G8MLCTA4 G8ALCTA1-G8ALCTA4 Thanks to Jens Mohring, HUK-COBURG, GERMANY. Thanks to Markus Bansemir, HUK-COBURG, GERMANY.
VMACNMON variables; the OUTPUT logic was relocated and revised. May 5, 2009 -Variable BBBP029='ENTITLED*CAPACITY' instead had value of BBBP050='ENTITLED CAPACITY OF POOL'. The values are corrected, and several BBBPnnn labels were revised. Thanks to Silvio Ferrari, Banca Carige S.p.a., ITALY. Thanks to Franco Tonelli, Banca Carige S.p.a., ITALY. Thanks to Gianvittorio Negri, SAS Institute, ITALY. Change 27.086 -DB2STATS variables QISEKPGE, QISESPGE, QISESFRE, QISESKCT VMACDB2 QISESKPT and QISEKFRE aren't accumulated fields, but they May 5, 2009 were deaccumulated; variables QISEKTA and QISECTA were also deaccumulated, and probably also shouldn't have been but all test values are zeros for those two variables, so they have not been validated. All eight variables are no longer deaccumulated. -Variable QISESPGE has a default value of 524287 pages (2GB) that is set by a "hidden" zparm value of "SPRMABVC" in DSN6SPRC, but IBM STRONGLY RECOMMENDS THAT YOU DO NOT CHANGE THAT DEFAULT VALUE UNTIL/UNLESS DB2 L2 determines there is a storage problem. Thanks to John Shuck, Suntrust, USA.
VMACOMCI values for the "xTRAN" variable because MXG did not INPUT May 8, 2009 these three variables from the header: OMCIJOB, OMGAPPL, and OMSAPPL. Now, all are kept in the OMCI-203 datasets: OMCIADA OMCIADAT OMCIDLI OMCIDLIT OMCIDTCO OMCIDTCT OMCIIDMS OMCIIDMT OMCISUPR OMCISUPT OMCIVSAM OMCIVSAT Thanks to Richard Schwartz, State Street Bank, USA. Change 27.084 First MXG 27.03 had two members revised: VGETDDS -The enhanced VGETDDS wasn't, having not been tested with VMACIMSA all options; a missing %END and non-defined GOOVOO were May 5, 2009 added (but that's why I didn't list VGETDDs in the list May 12, 2009 of Major Enhancements, since it was still in testing, and May 20, 2009 is not exactly mainstream!). Additional cleanup of MXGWARN versus MXGERROR, protection for START END, etc., were added. -VMACIMSA addition of the new IMS45x statistics records didn't have the new ST* variables in a FORMAT statement; this was missed in QA because the same variables were in a FORMAT statement in VMACIMS. ====== Changes thru 27.083 were in MXG 27.03 dated May 4, 2009======== Change 27.083 -VGETDDS reads "logically concatenated" PDB libraries with VGETDDS DDnames "starting with", e.g. (PDB1 PDB2 PDB3....) to May 2, 2009 select a SAS dataset (e.g. JOBS) from all of those PDBs. You control which data libraries are read in your JCL, without modifying your program, using VGETDDS & VMXGSET. -This change enhances VGETDDS to allow dynamic allocation of DSNAMEs that are GDGs, or of DSNAMES with embedded DATEs.
-Extensive comments and examples describe how to read a SAS dataset from multiple data libraries in a single "SET" statement that doesn't require separate DDs in your JCL.
Thanks to Brian A. Harvey, HCL America, USA. Change 27.082 Support for DCOLLECT's z/OS 1.10 change to DCDOVERA, now VMACDCOL defined as a 32-bit unsigned number, previously defined Apr 30, 2009 as a 31-bit signed number, requires NO CHANGE to MXG, as that variable has always (since 1994!) been INPUT with a INFORMAT of PIB4, which reads all 32 bits. MXG always has used PIB4 for any variable for which a negative value is Yüklə 28,67 Mb. Dostları ilə paylaş:
|