* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
-The CPUG3 Table output record is reduced in size to contain only the data that is currently documented by IBM; previously, a large number of LPARs/LCPUADDR could generate a record that was greater than 32K. -New optional messages RMFVO28I and RMFV029I report the usage of RMF III Index; see prolog in ASMRMFV. -DOCLRMFV documentation of the CLIST is updated. Thanks to Jerry Urbaniak, Acxiom CDC, USA. Change 24.090 RMF III RESOURCE TYPE AND USE/WAIT TYPE MISMATCH messages VMACRMFV caused ZRBUWENQ dataset to be incomplete or wrong; the Jun 2, 2006 MXG code for REDG3 and UWDG3 segments was revised. Thanks to Betty Wong, Bank of America, USA. Change 24.089 MXGWARN: INTERVAL IS NOT A VALID VALUE FOR INTERVAL= may VMXG70PR occur if you changed the default INTERVAL=DURSET in your Jun 2, 2006 own %VMXG70PR invocation. The error was due to line 304 which should have had INTERVAL=&INTERVAL, syntax. Thanks to David J Schumann, Blue Cross of Minnesota, USA.
VMACDB2 in the DB2STATS dataset have been wrong since they were May 30, 2006 added by Change 18.305; the wrong variable name was used in MXG's deaccumulation logic. Thanks to Erling Andersen, SMT, DENMARK.
FORMATS so format $MGD141A now exists and it decodes: VMAC102 'G'='G:GRANT' May 30, 2006 'R'='R:REVOKE' Thanks to Mike Duffy, LLoyds, ENGLAND.
VMAC78 format that contains the value of R783CSs, which is a May 26, 2006 numeric variable with HEX2. format, so that the TYPE78IO R783CSSC and the TYPE73 SMF73CSS are both characters, so they can be used without conversion to MERGE the two data sets by Channel Subsystem ID. Thanks to Bill Cool, EDS, USA.
VMACNDM first VOLSER in the Receiving or Sending VOLSER list. May 26, 2006 -New values set for bits in NDMBYTE1 for NDMCOMPR: NDMCOMPR='T' - COMPACTED? NDMCOMPR='E' - COMPRS EXT? NDMCOMPR='X' - DMDSSIOX Thanks to John Shuck, SunTrust, USA. Thanks to Srinivas Guntapalli, Citigroup, USA. Change 24.084 Support for optional CICS fields with CMODHEAD/CMODNAME IMACICMN values of MSGNAME and MSGTYPE. IMACICMT VMAC110
UTILEXCL May 26, 2006 Thanks to Alan O'Hara, HBOS plc, SCOTLAND.
ASUM70PR old PDB libraries built prior to MXG 23.23, because the May 22, 2006 SMF70GIE variable was NOT kept in all RMF datasets until Change 23.231. YOu can use ASUM70PR to summarize PDBs built with 23.23-24.02, but you must add this OPTIONS: OPTIONS DKRICOND=NOWARN; %INCLUDE SOURCLIB(ASUM70PR); Thanks to Jim Horne, Lowe's Companies, Inc, USA. Change 24.082 RACF formats MG080EV for Event and MG080QU for Qualifier FORMATS decoding were updated with new values of both Events and May 22, 2006 Qualifiers. Thanks to Linda Berkley, DISA, USA. Change 24.081 -MXG 24.03 did not have ZDATE kept in PDB.ASUM70LP nor in VMXG70PR PDB.ASUMCELP, which will cause an error if MONTHBLD from May 19, 2006 24.03 is used, because those datasets were added to the MONTHLY PDB, but ZDATE is used to select observations. (The error message only occurs if ALL of your WEEK/DAY datasets were created by MXG 24.03; if any PDB used in the MONTH job was created with this change, then that MONTHBLD run will not fail with an error; however, the two output datasets will still be incomplete and wrong.) -Since those two datasets never existed in the MONTH PDB previously, you could use the prior MONTHBLD until all of your DAY/WEEK PDBs have been created with this change. Thanks to Jim Horne, Lowe's Companies, Inc, USA.
ASUMMIPS adds _SYNC59 macro for sites still stuck with the unwise May 23, 2006 SYNCVAL(59) SMF option that was only required by MICS and is unneeded and unwise if you no longer have MICS, and a new _INTVAL macro so you can change the summary interval. The default _INTVAL is HOUR, and _SYNC59 is NO. Thanks to Pat Curren, SuperValu, USA.
VMXGRMFI when creating PDB.RMFINTRV dataset. Only these variables May 18, 2006 AVGRSPMS DEVACTTM DEVCONTM DEVDISTM DEVPNDTM SIO74CNT SIO74TAP in PDB.RMFINTRV come from TYPE74 data, and they are total across ALL of your DASD devices, so they have very little value if you have ESCON and FICON channels, or have both Cache/Non-Cache Controllers, or have different devices; they will all have missing values with the YES default. The new default can significantly reduce the run time and CPU time of your RMFINTRV execution, but if you need the above variables, specify NOTYPE74=NO in your RMFINTRV will read the PDB.TYPE74 dataset and populate them. -Datasets PDB.TYPE72 and PDB.TYPE73P are no longer used as those datasets now always have zero observations. -Comments document the only PDB datasets required are TYPE70 TYPE71 TYPE72GO TYPE74 TYPE75 TYPE78 TYPE78IO. Thanks to Steve Olmstead, Northwestern Mutual Company, USA. Change 24.078 All z/VM MONWRITE datasets now have variable SYSTEM, that VMACVMXA was previously only in the VMMTRSYS configuration dataset May 18, 2006 from the 1.4 record, so you can combine MONWRITE data and SORT/REPORT by each of your z/VM SYSTEMs. Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY.
FORMATS $MGSASPR format that maps SAS Procedure Name to the SAS May 17, 2006 product that "owns" that procedure, for the decoding in the TYPESASU SAS User Record dataset. Thanks to Len Rugen, University of Missouri, USA.
VMXG70PR HAS NEVER BEEN REFERENCED (and the same warning for the May 16, 2006 variables SMF70CPA, SYSDUR, MAXCPUS, MINCPUS, SYSSHARE May 19, 2006 and CURSHARE), fortunately, does NOT impact the output. These variables were left in DROP statements from an earlier iteration of the redesign, but were not used in the DATA steps that produced the warning message. These messages are not printed using the MXG default OPTIONS DKROCOND=NOWARN; using DKROCOND=WARN will cause the above messages to be printed on the log, and if you set OPTIONS DKROCOND=ERROR, my failure to remove them will cause your job to fail with ERRORs. -Variable DURATM in ASUMCELP is again TIME12.2 format. Thanks to Randy Shumate, LexisNexis, USA. ====== Changes thru 24.075 were in MXG 24.03 dated May 15, 2006========= Change 24.075 ML-39 of MXGTMNT Tape Mount Monitor enhancements include: ASMTAPEE - support for the hardcopy message set, which allows for May 15, 2006 the monitor to capture suppressed SYSLOG messages. (Previously, if console messages were suppressed, MXGTMNT didn't capture SYSLOG messages, and there were zero observations in TYPESYMT dataset.) - eliminates S0C4 ABEND in IEAQPGTM+01E6, which occurred only at shutdown of the MXGTMNT task, with no impact on the monitor's records. Because it was unexpected, and appeared to be circumvented by changing the SYSOUT class of the SYSUDUMP DD, IBM Support was invoked, but their SLIP trap proved the error was, as they had said before the SLIP trap, in our code! - provides protection for future z/OS releases which may enforce the No User Key CSA rule, by eliminating the use of CSA Key 8 virtual storage in MXGTMNT coding. While ASMTAPEE requested SP 241 in Key 0, it was being ignored and the storage was allocated instead in Key 8, which, while still "legal", is undesired. Added Sep 2008: This change from 2005 does support VSM ALLOWUSERKEYCSA(NO) to be specified in your DIAGxx member. - The B78-5C ABEND condition was also prevented in ML-39 Note added Apr, 2008: ML-39 is REQUIRED for z/OS 1.9. Thanks to Normand Poitras, IBM Global Services, CANADA. Thanks to Ed Webb, SAS Institute z/OS, USA. Thanks to Eladio Aviles, Arizona Public Services, USA Thanks to George Kozakos, IBM Support, AUSTRALIA. Change 24.074 Variables INTBTIME and INTETIME, Interval Begin and End, VMAC30 were never defined for the TYPE30_4 and TYPE30_5 step and May 15, 2006 job termination events, because they were previously only output in the TYPE30_V Interval dataset. For the subtype 4 & 5 records, not only were they on the GMT clock, their times were for the last interval, but for step and jobs, the interval of the data is the step or job itself. Fortunately, only the TYPE30TD dataset contained the two variables from the subtype 4/5 records, and TYPE30TD is only used internally in BUILDPDB to count tape drives, and MXG's logic didn't use those timestamps; it was only if you investigated the WORK.TYPE30TD dataset that you could have observed the incorrect values. Now, for the step and job termination records, the two variables are now set as INTBTIME=INITTIME and INTETIME=SMFTIME, so the variables describe the data interval in all cases. Thanks to Mike O'Brien, Bank of America, USA. Thanks to Betty Wong, Bank of America, USA. ====== Changes thru 24.073 were in MXG 24.03 dated May 13, 2006========= Change 24.073 Change 23.334 caused type 30 interval records to always IMACINTV be created, without having to edit IMACINTV, by removing May 12, 2006 the old comment block around the OUTPUT statement. But, the &MACINTV macro variable was located physically after the OUTPUT statement, so it could not be used to alter the TYPE30_V - PDB.SMFINTRV datasets as intended. The &MACINTV statement was relocated ahead of the OUTPUT. Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM. Change 24.072 INVALID DATA FOR SYTNLPMG/SYTACTM with XAMSYS 3507 data. VMACXAM MXG used the TOTALs SEGLEN (if GE 48) to INPUT the two May 11, 2006 percent SYTPCTBY/SYTPCTOV fields that may or may not be present, and that worked for prior test data, but this new data has SEGLEN=40 in TOTALs for its 1 LPAR, so the LENDATA=12 (bytes after DURATM, so PCT fields are NOT in the TOTALs section, but the LPARA section has LPAR count of six with SEGLEN=168, but there are seven "buckets" of LPAR data, so the LENDATA=20, and the "real" LPAR data does have the PCT fields, while the TOTALs doesn't. That 7th LPAR segment has a Partition Number of '0040'x. To process these records and protect for the future, MXG code now recalculates LENDATA for each SYTCUP record, no longer retaining the value from the TOTALS record, and used LENDATA to conditionally input the two fields. May 13: Barton acknowledges the undocumented seventh LPAR is actually a sub-total for that LPAR, with the '40'x the LPARNUM of decimal 64 as his flag. Outputting totals and details to the same dataset is exposed to reporting errors, and since only detail LPAR data was previously output to XAMSYT dataset, this change does NOT output the new LPAR sub-total section. The decision is internal now, but could be externalized to EXXAMSYT if someone convinces me they need that facility. Thanks to Michael J. Salyer, CitiGroup, USA. Change 24.071 The SMF manual mis-documented DFSORT bit 6 in ICEFLBY3 to VMAC16 set new MEMOBJUS='Y' when a Memory Object is USED, but May 10, 2006 SMF data shows MEMOBJUS must be IBM bit 7 (last), and the updated DFSORT Installation and Customization Guide, pub SC26-7524-00, page 212) confirms that bit, as well as documenting that ICEMON is a 2-byte field at offset 438, but MXG had input it as a 4-byte field at offset 436. Fortunately, offset 436 and 437 are reserved and zeros so ICEMON's value was correct, but MXG code is now revised. Thanks to Diane Eppestine, AT&T Services, Inc, USA Thanks to Gennady Katsnelson, AT&T, USA.
FORMATS changed to '03'X='3:LIST STRUCTURE' May 10, 2006 instead of '03'X='1:LIST STRUCTURE' Thanks to Lawrence Jermyn, Fidelity Systems, USA. Thanks to Thom Kight, Fidelity Systems, USA.
UTILEXCL if the PGM=DFHMNDUP was used to create CICS Dictionary May 10, 2006 "SMF" records for five executing regions, but each of the SMF files were read in five separate _BLDDICT executions. The SMFTIMEs of DFHMNDUP were all the same (and in 1906!) and because the records were processed one at a time, the NREC variable was the same in all of the records, so the MXG sort on SMFTIME NREC saw way too many entries. If the five "SMF" files had been concatenated in one run of _BLDDICT, the problem does not exist, even with same SMF value, because they will get a different NREC when there are five records read by _BLDDICT. However, a new example in comments in UTILEXCL show how you can correct an existing PDB.CICSDICT dataset without going back to re-read the SMF data. Thanks to Doug Jones, T-SYS, USA. Change 24.068 -SHORT SEGMENT error messages in SYTCPC & STOSHR segments VMACXAM are corrected; MXG logic did not protect for new fields. May 9, 2006 The SHORT SEGMENT message is a real error in MXG code that must be fixed, because that means that observations were NOT output. Contact support@mxg.com if these occur. -There were UNKNOWN SEGMENT xxxxx messages printed on the SAS log that are NOT real errors; they are simply MXG notes that new segments exist in the XAM data that are not yet decoded, but the record was still output. -The text of both messages was rewritten to clarify which is an error (and what to do), and which is just a note. -New segments are always supported when a user asks for the new data, as I prefer to have real data and a real user to validate new stuff, especially in zVM. Thanks to Pat Curren, SuperValu, USA.
VMXGDUR will cause DATETIME value to be the original, raw, value May 6, 2006 to be output, unmodified.
VMACXAM were always expected, but they did not exist in Release May 5, 2006 3507 of XAM. Logic revised to keep the SEGLEN of the "Total" segment and use to INPUT the two fields that were found in Release 3519. Thanks to Michael J. Salyer, CitiCorp, USA. Change 24.065 Variables STARTIME and SYNCTIME in TYPE23 were in the GMT ADOC23 timezone while SMFTIME was (always) in Local time, but VMAC23 the only documentation clue was that third argument "GMT" May 4, 2006 in the %VMXGTIME(SYNCTIME,SYSTEM,GMT); statement used only by the optional TIMEBILD facility, and only when there was no GMT offset in the SMF record. However, the PROC PRINT of TYPE23 (from 1999!!) in the ADOC23 member clearly shows an exact 6-hour difference between SMFTIME and SYNCTIME, so the GMTOFF23 can now be calculated and used to convert SYNCTIME and STARTIME to the local time zone. GMTOFF23 is kept in TYPE23, and if it is non-missing, then STARTIME/SYNCTIME were converted from GMT to local time zone. I think this was not done before because nobody asked, and maybe because SYNCTIME was not always present in SMF 23 records way back end. Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
VMAC7072 Major changes, perhaps incompatible: VMXG70PR - ASUMCEC/ASUMCELP default summary interval is HOURLY. VMXGINIT - ASUM70PR/ASUM70LP interval no longer set by IMACRMFI WEEKBLD so you may have to add INTERVAL= in your ASUM70PR. MONTHBL* - BY List variables were changed for all four datasets. VMXGINIT TRNDCEC This redesign is required because the old BY list of MXG May 9, 2006 variables that I thought were sufficient to identify a May 11, 2006 unique "SYSTEM", for summarization, these variables: May 13, 2006 SYSPLEX SYSTEM SYSNAME STARTIME are not sufficient, and cause incorrect output. The new BY variables required to identify a "SYSTEM" CECSER SYSPLEX SYSTEM SYSNAME LPARNUM LPARNAME SMF70GIE are used in VMXG70PR logic to group, but you would use CECSER SYSPLEX SYSTEM SYSNAME LPARNUM LPARNAME STARTIME for your reports by Start time, and any other summaries.
data were less exposed to serious errors (because they are per system with less time variance) than were the ASUMCEC/ASUMCELP "CEC" and "CEC-LPAR" datasets, which were very wrong when DURATM and/or STARTIME values were not the same for all SYSPLEX and SYSTEMS in a CEC, but all four datasets could be in error with the old "BYs". And even with the revision, you need to remember that the "SYSTEM" and "SYSTEM-LPAR" datasets have observations for each interval from every SYSTEM in each SYSPLEX, so they have duplicate and replicated data, and you must always select which "SYSTEM" to use. -While I do find a PROC PRINT of PDB.ASUM70PR/PDB.ASUMCEC datasets can be useful to get a snapshot of overall usage for each LPARs, those two datasets are very unwieldy for reports, with their 61 sets of different variable names to deal with. Furthermore, the "LPARNUM" bucket-number changes with new LPARs so it's not really stable for long term comparisons. -Instead, the best datasets to use for LPAR analysis are the ASUM70LP or ASUMCELP, as they have only one set of variable names, and you can select and sort by LPARNAME or SYSTEM, etc., without scanning 61 possible variables.
logic could result in multiple observations with slightly different STARTIME or SMF70GIE values, and/or you could have duplicate, overlapping, or incorrect data: -The SPLIT70 rewrite correctly used SMF70GIE to group by the end of interval for all "BY SYSPLEX-SYSTEM" (TYPE70,RMFINTRV,ASUM70PR/ASUM70LP) datasets, but it cannot be used (as-is) to group "BY CECSER", because SMF70GIE is not the same value in all LPARs in a CEC for a particular interval, and it caused multiple observations with overlapping STARTIME to SMF70GIE. -The DURATM of ASUMCEC was wrong when there were LPARs with different interval durations. The minimum DURATM for CEC summary must be at least the largest DURATM, but for some DURATM values, it must be larger still. It must be the Least Common Denominator of all of your DURATMs, so with 10 and 15 minute DURATMs, your minimum summary interval is 30 minutes. -Interval DURATM values are very "fuzzy", even for the "interval pop" observations that you expected to have the exact INTERVAL you requested (10, 15, or 30 min). Here's some reality from four CECs that share SYSPLEX: Interval DURATM Min Max
CECONE 14:58.99-15:53.26 CECTWO 14:59.62-15:00.50 29:59.88-30:00.11 CECTHREE 09:59:54-10:00.74 14:59.24-15:23.17 CECFOUR 14:59.75-15:00.23 28:54.08-30:00.08 And there are always intervals of much smaller DURATM: the first RMF interval's end is forced so the next is synchronized with time of day, so any value of DURATM less than the maximum can occur in SMF data, which prevents using the data to set the summary interval. -CECs with LPARs with both SYNC(0) and SYNC(59) have some SMF70GIE values of 00/15/30/45 minutes and some with values of 59/14/29/44 minutes, so it's impossible to exactly summarize that data to a true CEC interval. -Inexactness of DURATM across LPARs in a CEC caused the STARTIME=SMF70GIE-DURATM; to be as inexact as DURATM, so STARTIME can not be used, either. -With these inconsistent/fuzzy times, creating a perfect CEC-LPAR summary dataset for each LPAR in each CEC is not possible, but we can create a very-good summary dataset, that gets to be nearly-perfect if all of your systems are on the same SYNC() and INTERVAL() specifications in RMF. But you still may occasionally get percentages over 100%!
used to be set by the IMACRMFI member's _DURSET macro, so the interval of those two datasets matched your RMFINTRV. And this still works fine, if your _DURSET macro made no change in STARTIME (i.e., your RMFINTRV/ASUM70PR/ASUM70LP were at the original, raw datetimes of your RMF data). But if you have used _DURSET to change the STARTIME of PDB.RMFINTRV to a summary interval, I can't tell what you wanted for your interval, so I will now print a message that I have to build those two datasets a detail level, and telling you to use the INTERVAL= parameter in your ASUM70PR member, instead of IMACRMFI, to define interval. -The redesign creates the CEC-level by-LPAR summary data in the PDB.ASUMCELP ("CEC-LPAR") dataset, starting with the just=built PDB.ASUM70LP ("per-SYSTEM-LPAR" resources for each "LPAR" for each "STARTIME" within each "CECSER" box, with the new duration DURATM = "CECINTRV": "LPAR" - Variables SYSPLEX LPARNUM LPARNAME are used to uniquely define each "LPAR", as the same LPARNUM and/or LPARNAME can be used in different SYSPLEX on same CECSER. "STARTIME" - STARTIME and SMF70GIE are shifted to the "expected, exact" time of day value for CECINTRV interval. See algorithm below. "CECINTRV" - Default summary interval is 60 minutes, so STARTIME/SMF70GIE will be on the hour. As noted above, the CEC summary interval MUST be the Least Common Denominator of all of your DURATMs, so using 60 minutes safely summarizes every RMF Interval that I've ever used (1,3,5,10,15,20,30,60). You can use a smaller value for CECINTRV only if it is equal to the LCD of all of your DURATM values for all of your LPARs. - SMF70GIE is changed to be the "correct" interval end time of day for the CECINTRV duration. One minute is added if SYNC(59) minutes of 14,29,44 or 59 are found, Yüklə 28,67 Mb. Dostları ilə paylaş:
|