* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
end of the subtype 20 record, following SM120XP; its has a value about a third of the CPU duration in SM120XP. -The offset values in the documentation are bogus; they implied the character variables were fixed length, but in fact, the data shows the fields are only as long as the value in their preceding length field -There are pairs of duplicate Subtype 20 records with all fields except SMFTIME identical. They are not adjacent, with 8 subtype 9 records and 3.34 seconds between them. -Variable SM120SMF is the delay from XL Last Referenced datetime to SMFTIME, and is as much as 10 seconds, which is a VERY significant and unexplained delay. The problem with a big delta is that SMFTIME must be compared with XL to calculate the GMT Offset, because there is no GMT Offset value in WebSphere SMF 120s. Thanks to Paul Gordon, Bank of America, USA.
ANALID you reuse the same DSNAME with DISP=OLD for your //PDB, Oct 28, 2010 and your old PDB library was created before MXG 27.27, and there is a dataset PDB.ID in your old PDB library. You need to delete that old PDB.ID dataset, e.g.: // EXEC MXGSASV9 //PDB DD DSN=YOUR.PDB,DISP=OLD //SYSIN DD * PROC DELETE DATA=PDB.ID;RUN; Prior to MXG 27.01, BUILDPDB created the PDB.ID dataset to count SMF records, but Change 27.005 instead created the new PDB.SMFRECNT (smaller but more information), and left the ID dataset (which now had new variables) in the WORK file by default. But Change 28.148 created ANALID member to externalize the creation of PDB.SMFRECNT, which uses %VMXGWORL to locate the ID dataset, since you could could have tailored MXG to still keep the new ID dataset in your PDB library. Unfortunately, if the old PDB.ID dataset exists, the above error occurs. -Initially, I said: While it would be possible to detect and delete the old PDB.ID dataset, that would require you to install at one new MXG code member, so the simple delete above is far simpler and safer. That the error has only occurred once suggests that most MXG sites create a new DSNAME (GDG or date-in-name) for each daily PDB library (required for some job sked pkgs), or that sites that do use DISP=OLD on their //PDB also use PROC DELETE DATA=PDB._ALL_; before each BUILDPDB. -However, this Change looks first for WORK.ID and variable IDANDSUB or second for PDB.ID with that variable to build PDB.SMFRECNT; otherwise a zero obs PDB.SMFRECNT is built. P.S. Change 28.148 for ANALID/BUILD001/BUIL3001 was never written up in CHANGES; a separate change got that number. Thanks to Alan Gray, CareFirst, USA.
ASUMDB2A reports, because there is always a named variable, like ASUMDB2B QWACBSC, that is self-documenting and code-clarifying. ASUMDB2G Variable DATETIME was intended to be a temporary token ASUMDB2P and shouldn't have been kept, but where it slipped thru Oct 27, 2010 and ended up being kept in MXG-built datasets, it now has to be kept and populated. The quick fix, added in MXG 28.06, to insert a "compiler faker" to suppress an uninit warning, caused DATETIME to be a missing value. The first three member's faker was replaced by code to create/populate DATETIME, and the faker was removed from ASUMDB2P where it was never kept. Feb 4: Cosmetic. Variable DATETIME is now length 8. Thanks to Jim Kovarik, AEGON USA, USA. Change 28.255 Variable SMF30DAS='EXCP*SEGMENTS*THAT WERE*SUPPRESSED' VMAC30 was INPUT but not kept. EXCP segments can be suppressed Oct 27, 2010 with EMPTYEXCPSEC(SUPPRESS) option in SYS1.PARMLIB, or by DB2 V10 APAR PM17542 which enables S99DASUP. Change 28.254 The protection for OFF42S3 NE 108 added in Change 28.093 VMAC42 was no protection as it caused misalignment and is now Oct 26, 2010 removed. With that protection removed, reading the old data, I now detect, legitimately, an invalid S4 record with 21 segments totaling 27888 starting at 4053 for an expected 31944 bytes but the record LENGTH is only 31832. Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
VMAC85 TYPE85AC dataset. Oct 26, 2010 Thanks to Harald Seifert, Huk-Coburg, GERMANY. Thanks to Jens Mohring, Huk-Coburg, GERMANY.
ANALDB2R reports fields AUTHID DB2 CONNID CORRED to not be Oct 26, 2010 correctly translated and propagated, and caused attempt to delete dataset named RUN; ACCTSORT option added.
EXITCICS 346 * DC XL2'0000' For Debug purposes RHA Oct 26, 2010 JZ OPENX no... ** ASMA144E Begin-to-continue columns not blank - JZ because I had accidentally moved that RHA text in source line 361 in EXITCICS into column 72, making the statement a continuation. code and the decompression exit, when storing into the MXG Source Library. -SYSLIB DD needed a third concatenation for the site's CICS Macro Library. Thanks to Ken Goodis, Emblem Health, USA. Change 28.250 -COPYONLY= logic was still dysfunctional. Change 28.211 READDB2 did not proper locate the selection by IFCID, and now the Oct 26, 2010 SUBTYPE, decoded by VMACSMF, is used for COPYONLY. -NOTE: VARIABLE QWHCCCN UNINITIALIZED because it should have been spelled QWHCCN. If CONNID=xxxxxxx selection was requested in ANALDB2R, this error caused zero obs to be selected. -Option UNIQUE will write each DB2 dataset to its unique DDNAME (e.g., DB2ACCTP to DB2ACCTP.DB2ACCTP) for all of the datasets that would likely be kept. Thanks to Larry Stahl, IBM Global Services, USA.
VMXGSUM statistics can be created. The complete list of all of OCT 20, 2010 the statistics that VMXGSUM can be created: MEAN MEAN (AVG) P1 PERCENTILE 1% MIN MINIMUM P5 PERCENTILE 5% MINLONG MINIMUM 8 BYTE P10 PERCENTILE 10% MAX MAXIMUM P25 PERCENTILE 25% MAXLONG MAXIMUM 8 BYTE P50 PERCENTILE 50% SUM SUM 4 BYTES P75 PERCENTILE 75% SUMLONG SUM 8 BYTES P90 PERCENTILE 90% FREQ NUMBER OBS P95 PERCENTILE 95% STD STANDARD DEVIATION P99 PERCENTILE 99% VAR variance T Students T CV coeff of Variation STDERR Standard Error MEDIAN median KURTOSIS Kurtosis MODE= mode With AUTONAME=YES the variables will be named variable-name_statistic-name e.g., XXXXXXXX_SUM Thanks to Chuck Hopf, Independent Consultant, USA.
VMAC110 is revised so it works, and its exceptions documented: Oct 20, 2010 1. The %QUOTE(text) function is needed around text that contains semicolons (which would otherwise end the %LET statement). 2. But %QUOTE(text) cannot be used if a close paren is in the text. 3. So the macros with no semicolons are first, followed by those that contain semicolons in the %QUOTE(text). 4. When redefining MACRO _Edddddd you can use syntax of a. %%%INCLUDE of the EXdddddd member, and whatever logic is in that Exit member will then determine which obs are output. I can't explain why THREE percent signs are required here, but they are. b. OUTPUT ddname.dataset syntax to output all obs to both datasets, or you can use the IF condition DO group to select which obs to output. c. NEVER use a DELETE; statement in _Edddddd exits. Always use a positive IF condition THEN DO; group. The DELETE statement terminates reading of the SMF record, which would prevent the reading of any of the additional repeated segments. 5. You can also specify COMPRESS=NO in the _Kdddddd to override the MXG COMPRESS=YES default, by putting COMPRESS=NO before the close paren for that dataset. 6. The example uses _N110 to null all of the 110 datasets so that ONLY the datasets "reinstated" by defining their _Wdddddd macro will be created. %LET MACKEEP= _N110
MACRO _KCICTRN COMPRESS=NO) &PDB..NEWDS (KEEP=ABCODE APPLID ENDTIME FCTOTCN PROGRAM SYSTEM STRTTIME TASCPUTM TDTOTCN TRANNAME TSTOTCN % MACRO _WCICTRN CICSTRAN.CICSTRAN % %QUOTE( MACRO _ECICTRN %%%INCLUDE SOURCLIB(EXCICTRN); IF CONDITION THEN DO; OUTPUT &PDB..NEWDS; END;
% ); %INCLUDE SOURCLIB(TYPE110); -The _N110 macro in VMAC110 was updated in this change to also null the CICSBAD dataset, which had been overlooked. Thanks to Brian A. Harvey, HCL America, USA.
ANALCAPD SAS/GRAPH it will automatically be set to NO, but if we OCT 19, 2010 detect SAS/GRAPH but you only want a printer plot, you Oct 26, 2010 can specify GRAPHICS=NO. For readable non-graphics plots the values being generated by the PROC FORMAT for TYPE now use the first character. -Oct 26: Uninitialized LQxLAC, LQxMSU & LQxMSU70 variables were harmless variables that didn't exist in ASUMCEC. Thanks to Michael Marcus, ATOS Origin, USA. Thanks to Karl Lasecki, Chemical Abstracts Service, USA. Change 28.246 -ITRM Validation of MXG 28.06 for their next dictionary VMAC30 precipitated these discoveries and corrections: VMAC7072 -VMAC30: New Initiator CPU time at INIT and TERM variables VMACDB2 CPITCTTM CPITCITM CPISRTTM CPISRITM VMACIMSA were wrong in 28.06; they were INFORMATed and FORMATed VMACNTSM incorrectly with PIB4.6 instead of PIB4.2 and TIME12.2. Oct 22, 2010 The wrong FORMAT caused their values to print as trash, ASUMMIPS the wrong INFORMAT caused their value to be wrong, too Oct 28, 2010 small by a factor of 10**4. Nov 14, 2010 These four new CPI CPU times are important and discussed in Change 28.175. -VMAC7072: Counter NBKDUPE should not have been kept in dataset TYPE70EN, and now isn't. And all of these variables for Engines 64-95 should never have been kept in PDB.TYPE70 and are now DROPped: CAIVA -CAIVI CAIYD -CAIYZ CPUEDTVA CPUEDTVI CPUEDTYD-CPUEDTYZ CPUPATVA-CPUPATVI CPUPATYD-CPUPATYZ CPUPDTVA-CPUPDTVI CPUPDTYD-CPUPDTYZ CPUWAIVA-CPUWAIVI CPUWAIYD-CPUWAIYZ IFATYPVA-IFATYPVI IFATYPYD-IFATYPYZ IFAWAIVA-IFAWAIVI IFAWAIYD-IFAWAIYZ IORATEVA-IORATEVI IORATEYD-IORATEYZ MVSWAIVA-MVSWAIVI MVSWAIYD-MVSWAIYZ PCTCIBXD-PCTCIBxz PCTCIBUa-PCTCIBUi LCPUDEXD-LCPUDExz LCPUDEUa-LCPUDEUi LCPUWAXD-LCPUWAxz LCPUWAUa-LCPUWAUi PCTCPBXD-PCTCPBxz PCTCPBUa-PCTCPBUi PCTONLVA-PCTONLVI PCTONLYD-PCTONLYZ ZIPWAIVA-ZIPWAIVI ZIPWAIYD-ZIPWAIYZ If OPTIONS DKROCOND=WARN is used, there will be messages on the log: WARNING: variable LCPUDExx in the DROP KEEP... WARNING: variable LCPUWAxx in the DROP KEEP... that are not errors and are normal. -VMACDB2: Variables QWARACE/QWARBSC/QWARESC are Labeled in new in Version 10 dataset DB2ACCTW. Variable DB2START is now labeled, and STA0DUR and STA1DUR are formatted. -SAPIMSBA, SAPIMSON, SAPIMSSP datasets created by TYPEIMSA processing in JCLIMSLx/ASMIMSLx IMS Log Processing kept ALL-POSSIBLE 937 variables instead of 31/33/30 kept; MXG Change 28.066 updated VMACIMSA to use the three _VSAPxxx macro tokens for their KEEP=list, but then failed to fill them with the KEEP= syntax and the list of variables to be kept. Now, only the intended SAP variables are kept in the three (optional) datasets. And variable IMSRECCH is now labeled IMS*RECORD*NUMBER*AS HEX CHAR. -VMACNTSM: Variable VWGRACQP was corrected to VWGRAC1P. -ASUMMIPS: Datasets/variables were labeled/formatted. Thanks to Chris Weston, SAS ITRM Development, USA. Change 28.245 MXG 28.06 added ASUMDB2G/ASUMDB2P/ASUMDBSB/ASUMDBSS to WEEKBLD WEEKBLD, but are now removed. None of those optional data BLDSMPDB sets should have been added, since neither was previously Oct 19, 2010 created by prior JCLPDB6 examples. If your BUILDPDB JOB didn't create them, then WEEKBLD in 28.06 failed with ERROR: VARIABLE SYSTEM NOT FOUND ON MON.ASUMDB2G -I had presumed you would EDIT your WEEKBLD to remove datasets you don't want weekly, and would use EXPDBWEK exit to add any new datasets to your WEEKBLD output. -But henceforth, I will NOT add any new optional datasets to the defaults in WEEKBLD and MONTHBLD examples. -There is an alternative to WEEKBLD and MONTHBLD to use: The BLDSMPDB example can EASILY be set up to run daily to create your daily PDB, and it dynamically creates your weekly PDB from whatever datasets exist in your daily PDB libraries, and similarly creates your monthly PDB from whatever datasets are found in its weekly/daily PDBs. And you can drop unwanted datasets easily as well. Thanks to William Edwards, Blue Cross and Blue Shield of Florida, USA
VMACSTC -Most datetime variables are changed from GMT to LOCAL. Oct 19, 2010 These were overlooked. MXG always converts datetimes on GMT to LOCAL zone, when the GMT offset is known or can be determined (i.e., when the records have a GMT END time to match with the always-LOCAL-zone SMFTIME). Dataset Variables now on LOCAL STCVSM13 STC13MET STC13MST STC13TIM STCVSM14 STC14TIM STC14RUN STCVSM16 STC16MET STC13MST STCVSM18 STC18MET STC13MST STCVSM19 STC19TIM STC19RET STC19RST STCVSM20 STC20MET STC20MST These variables are now in %VMXGTIME with GMT=YES. But these datetimes are for events that can be days or weeks earlier, and the GMT Offset can't be known from the SMF record, so they are left on GMT, but their LABEL now contains "ON GMT" to flag them as still on GMT: Dataset Variables STCVSM15 STC15LTR STC15TIM STCVSM25 STC25LUT STC25LWT STCVSM27 STC27LUS STC27TIM These variables are now in %VMXGTIME with GMT=YES. Yes, this is INCOMPATIBLE, if your reporting code changes the time zone for those former GMT-containing variables. -STC/STK/Oracle VSM SMF records' _SSTCvvv macros are now correctly implemented with PROC SORT NODUP and with BY lists that remove duplicates (and datasets STCVSM25 and STCVSM27 appear to have occasional fully duplicated SMF records that are detected and deleted). -Datasets STCVSM10, STCVSM11, and STCVSM20 are interval datasets, and their _S Sort Macros create new variables STCSTRTM='INTERVAL*STARTIME' DELTATM='INTERVAL*DURATION'. -But Dataset STCVSM20, the Interval RTD utilization data, which was the actual purpose of this examination of STC data, has serious holes. The STC20ATM Device Available time is frequently zero for several 15-minute intervals but then the next interval record has what appears to be the total Available Time since the last interval record with a non-zero value. This means that individual hour intervals can't be safely analyzed, but by summing the interval data to the SHIFT or DATE level should provide reasonable valid data. A problem report will be opened with Oracle technical support. Change 28.243 Cosmetic. The MXGNOTE that a SEQUENTIAL or EXPORT format VGETOBS dataset was found by VGETOBS was revised; that note is VMXGSUM harmless and is only printed to be in the log in case of Oct 15, 2010 a subsequent error; in some reports with multiple inputs, "TAPE" data libraries cannot be used, and this message is useful to diagnose those (rare) problems. But also, the call to VGETOBS in VMXGSUM suppresses the message for the many cases where we know it doesn't matter. Thanks to Robbie A. McCoy, Salt River Project, USA.
VMAC7072 distribution variables (which include ALL engine types) VMXGRMFI and the three average variables for each engine type Oct 26,2010 SMF70CTT='AVG*WORK UNITS*FOR CP-S' SMF70DTT='AVG*WORK UNITS*FOR ZAAPS' SMF70ETT='AVG*WORK UNITS*FOR ZIIPS' were not divided by SMF70SRM (sample count) in TYPE70. These should replace the old READYAVG metrics, per Don: Be aware that READYAVG deals only with ready address spaces. The number of ready address spaces can present a seriously misleading impression of the work on the system and work being delayed, because READYAVG does not measure total dispatachable work units. Both the ready address spaces and the ready enclaves must be included to count the total dispatachable work units, and new-in-z/OS-1.12, the above variables provide the min/max/avg number of work units for CP-s,zAAPs/ZIIPS and the new PCTWUQWT and SMF70U00-SMF70U15 metrics for dispatchable work units, quite similar to the original measures for ready ASIDs. In addition to correcting the values, this change adds those min/max/avg Work Unit variables to RMFINTRV, and three percentage waiting variables are now created from the three distributions (READYxx, SMF70Qxx, SMF70Uxx) and are kept in both TYPE70 and RMFINTRV datasets. PCTRDYWT='PERCENT WHEN*READY TASKS*ARE WAITING' PCTRDQWT='PERCENT WHEN*IN READY TASKS*ARE WAITING' PCTWUQWT='PERCENT WHEN*WORK UNITS*ARE WAITING' These new work unit distributions are only kept in TYPE70 and they include the waiting and active work units for all engine types, so my labels are revised. The N value is the count of ALL online engines, except that when HyperDispatch is active, only the non-parked engines of ALLl types are included in the N being compared. SMF70U00='PCT WHEN*WORK UNITS*WAS LE N ONLINE' SMF70U01='PCT WHEN*WORK UNITS*WAS N+1 ONLINE' SMF70U02='PCT WHEN*WORK UNITS*WAS N+2 ONLINE' SMF70U03='PCT WHEN*WORK UNITS*WAS N+3 ONLINE' SMF70U04='PCT WHEN*WORK UNITS*WAS N+4-5 ONLINE' SMF70U05='PCT WHEN*WORK UNITS*WAS N+6-10 ONLINE' SMF70U06='PCT WHEN*WORK UNITS*WAS N+11-15 ONLINE' SMF70U07='PCT WHEN*WORK UNITS*WAS N+16-20 ONLINE' SMF70U08='PCT WHEN*WORK UNITS*WAS N+21-30 ONLINE' SMF70U09='PCT WHEN*WORK UNITS*WAS N+31-40 ONLINE' SMF70U10='PCT WHEN*WORK UNITS*WAS N+41-60 ONLINE' SMF70U11='PCT WHEN*WORK UNITS*WAS N+61-80 ONLINE' SMF70U12='PCT WHEN*WORK UNITS*WAS N+81-100 ONLINE' SMF70U13='PCT WHEN*WORK UNITS*WAS N+101-120 ONLINE' SMF70U14='PCT WHEN*WORK UNITS*WAS N+121-150 ONLINE' SMF70U15='PCT WHEN*WORK UNITS*WAS GT N+150 ONLINE' They can be compared with the existing distributions in READY00-READY15,SMF70Q00-SMF70Q12 in TYPE70 dataset. -VMXGRMFI was also corrected to support R70MIN, which has been defined, but as it had a null value, the absence of its invocation was never noticed until now. -In testing this change, Jim noticed SMF70NCA needed to be multiplied by 100 as it is 'PCT WHEN*CAPPING*LIMITED...'. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Thanks to Jim Horne, Lowe's Companies, USA.
VMAC7072 The typo'd CPUWAIYA=MVSWAITA is now CPUWAIYA=MVSWAIYA. Oct 14, 2010 Thanks to Heimir Hauksson, Barclays, ENGLAND. Change 28.240 -UTILEXCL could create wrong values in PDB.CICSDICT if IMACICUN CICS dictionary entries with the same "triplet" values IMACICUO RVR/DCN/DRL have the same CMODIDNT (field number) in IMACICUP different orders (could be in different or same APPLID). UTILEXCL These wrong values were then used to create the IMACEXCL VMAC110 tailoring member, but that caused no execution error. Oct 13, 2010 But the wrong variable(s) in CICSTRAN were populated or IMACICUQ had missing values when they should have been populated. Oct 14, 2010 Dec 22, 2010 But even after installing this change, and rerunning the new UTILEXCL's _BLDDICT to build the correct PDB.CICSDICT observations, your IMACEXCL could still be wrong, because _BLDDICT appends the new dictionary records to the old in its replacement of PDB.CICSDICT, so both good and bad records were still being used, causing that same error.
then you can simply use PROC DELETE DATA=PDB.CICSDICT; to delete that dataset, and then rerun _BLDDICT, etc.
and then _BLDDICT _BLDEXCL _RPTEXCL to use only the fixed PDB.CICSDICT records to build your tailored IMACEXCL. Dec 22: Above paragraph was added, no code was changed. -Dictionary records with duplicate RVR/DCN/DRL. but with different field order are now detected and printed by the macro _BLDEXCL when it creates the IMACEXCL, but UTILEXCL cannot support two different records differently; as only the RVR/DCN/DRL exist in the CICSTRAN records. UTILEXCL can only create one "do group" from the first dictionary record and that IMACEXCL will create CICSTRAN for all SMF records that RVR/DCN/DRL, with no execution errors, but all variables from the fields/segments that are different in the second dictionary record will be wrong. MXG can't fix this error because only the RVR/DCN/DRL exist in the CICSTRAN records. Your CICS guru will have to correct the DFHMCT text so all structures with the same number and length of fields have their fields in the same order. -Support for more Optional CICS fields, UTILEXCL Error. Member Variable Label IMACICUN SCBKPOUN Application*USER*AREA*ONE IMACICUO SCBKNUMB Application*USER*AREA*TWO IMACICUP CIBIZID Application*USER*AREA*THREE -Support for another optional CICS field Member Variable Label IMACICUQ CANUE1 CANUE1 Thanks to Tony Hirst, Wells Fargo, USA. Thanks to Henry Steinhauer, Northwestern Mutual, USA. Thanks to James Hein, Erie Indemnity Company, USA.
VMAC7072 to create ONLY the PDB.TYPE70 dataset caused errors Oct 7, 2010 NO DATA SET OPEN TO LOOK UP VARIABLES when PROC SORT DATA=_NULL_ (were _NULL_ replace TYPE70EC) caused SAS to error (in spite of _NULL_, PROC SORT still looked for BY variables). Recent changes in SMF 70s now requires datasets TYPE70SP/EC/EL to be created when the Yüklə 28,67 Mb. Dostları ilə paylaş:
|