* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
data with values CTGRECID=2 being created. Thanks to Jim Poletti, Edward Jones, USA. Change 28.328 New JCLINSTT member is the recommended z/OS install JCL JCLINSTT with these four steps to "drop-in" the new version INSTALL FTPMXG Jan 13, 2011 FTP DOWNLOAD TER2828.TER FILE FROM THE MXG FTP SITE. UNTERSE UNTERSE THE DOWNLOADED TER2828.TER FILE. ALOCUSID ALLOCATE THE MXG.V2828.USERID.SOURCLIB PDS LIBRARY. FORMATS ALLOCATE AND CREATE MXG.V2828.MXG.FORMATS LIBRARY. Change 28.327 -Connect Direct 'RT' record's format was changed; while VMACNDM offsets for the PACCT and SACCT exist and are populated, Jan 12, 2011 the ACCT fields do NOT exist, and instead a text string Jan 13, 2011 inside double quotes ('7F'x) is at the end of the record. This change detects the quote pair and stores that text in new NDMRTDAT text variable. However, some 'RT' don't have the quote pair, so a length test will skip over the data at the end but will still output the RT record. -And short RT records, less than the 216 bytes have been found and are printed on the log and skipped. -The 'AE' family of records UID and XUSER fields are now input $EBCDIC64 as they were expanded. Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY. Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY. Thanks to G. Bosker, Rabobank Nederland, THE NETHERLANDS.
VMACDB2H by two bytes, causing INPUT EXCEEDED error when QWHDPRID Jan 12, 2011 had non-null value in the last two bytes, as those bytes were expected to contain the OFFSET to QWHDRQNM when they are non-zero. The defective records are now detected by '0000'X value in the first two bytes of QWHDPRID, the header is skipped, new variable QWHDBAD is set to one, and an error message is printed for the first three. IBM has accepted a PMR and will have an APAR to correct. This change protects the Invalid Header so the APAR is NOT required for MXG. APAR PM32425 corrected the problem. Thanks to Joe Babcock, JPMC, USA.
VMAC102 bytes if COMPRESS=NO is specified. The normal length of Jan 11, 2011 32000 with YES must be reduced with NO because massive disk space could be required. But you can change this behavior by using //SYSIN DD * %LET SASCHRLN=32000; even if you have specified COMPRESS=NO. -Two variables had default lengths of 4000 and 5000 set by &SASC4000 and &SASC5000, but they now use &SASCHRLN to be consistent. -The list of variables was updated in the text of 22.108. Thanks to Joachim Sarkoschits, DATAEV eG, GERMANY.
MONTHASC WEEKBLD/MONTHBLD member is in your "USERID.SOURCLIB". -Inserted Jan 24, 2011, after MXG 28.28 was created: Similar DB2STATS NOT-SORTED ERROR in Change 29.008, but you can Circumvent/eliminate sorting as shown below.
MONTHBL3 in QA tests when PDBs built by old and new versions were MONTHBLD combined, because the sort order in WEEKBLD/MONTHBLD for MONTHBLS TYPE72DL was erroneously different in VMAC7072/BUILDPDB. MONTHDSK The only prevention, if WEEKBLD/MONTHBLD exists in your MONTHWEK USERID.SOURCLIB, is to change the _BYLIST, before you run WEEKBL3 WEEKBLD or MONTHBLD with MXG 28.28, to this order WEEKBL3D MACRO _DSET TYPE72DL % WEEKBL3T MACRO _BYLIST SYSPLEX SYSTEM SYSNAME STARTIME % WEEKBLD which is the new default in MXG's WEEKBLD/MONTHBLDs. WEEKBLDD -Alternatively, you can disable sort order and tests in WEEKBLDT WEEKBLD/MONTHBLD using this example (from comments): Jan 10, 2011 //SYSIN DD * Jan 15, 2011 %LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ; Jan 16, 2011 %INCLUDE SOURCLIB(WEEKBLD); -With BLDSMPDB, add SORTEDBY=NO, to bypass sort test. -MONTHWEK was updated Jan 15 with a RUN; added.
VMACTMVT a typo that caused SXHRTA to be a missing value. Jan 10, 2011 -SXBV1/BV2/BV3/BV4/HRTD/NRTTD/HRT/SXNRTT variable were incorrectly input as PIB4 vs PIB4.6 and were incorrectly converted (i.e., the 1024 multiplier to convert those durations into seconds/fractions was nonexistent for SX, but was in place for the existing SI variables.) Thanks to Paul Volpi, UHC, USA. Change 28.322 z/TPF records SB, DB, and DE had incorrect length for VMACZTPF reserved fields that are now corrected and validated Jan 10, 2011 with data records. Thanks to Bob Wilcox, HP, USA. Change 28.321 Harmless DIVIDE BY ZERO in a 7-second-long RMF interval VMAC7072 when there was a WLM Policy switch that causes SMF70DSA Jan 9, 2011 sample count to be zero; all divides are now protected. Harmless because the created variable was not used in a subsequent calculation, and is missing either way. Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA Change 28.320 -LPARBUSY calculation in PDB.ASUM113 was wrong if the CPs ASUM113 are slower than your zAAPs/zIIPs, because the SM1132CP Jan 7, 2011 (speed) of the last engine (the zIIP or zAAP) was used. And with multiple engine types, even at same speed, it makes more sense to create separate observations for each SMF70CIN/SM113CPT engine type for each interval. But SM113CPT is only populated in 113s from z196, and SMF70CIN is only populated if there's PDB.TYPE70PR data, so the actual separation is by SM113CPT and SM1132SP to ensure the correct speed is used to calculate LPARBUSY. -For z10, SMF70CIN in PDB.ASUM113 is populated from the TYPE70PR data, but the logic was not always correct. Now SYSTEM=SMF70STN is used to select the correct LCPUADDR, the sort order was changed to match correctly, and then the SMF70CIN value is used to populate SM113CPT for the z10 processors. (For z196 SM113CPT is already there.) Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
EXXAMQDS creates new XMIODQDS dataset. IMACXAM VMACXAM
VMXGINIT Jan 6, 2011 Thanks to Francois VanCoppenolle, PVGROUP, BELGIUM
VMAC110 LT 330 fields OR LT 2640 bytes, but since the default Jan 5, 2011 record has 337 fields and 2668 bytes, a false detection of EXCLUDED fields was not possible. Additionally, the primary flag of EXCLUDEd fields is an invalid TASKNR, as it is a packed decimal field whose shift is detectable. But, the MXG test and comments were corrected. Thanks to Patricia Hansen, ADP, USA. Change 28.317 In analysis of the impact of possible capping values, if ANALCAPD the desired CAP was exceeded, those excess MSU had to go Jan 5, 2011 somewhere: this modification keeps track of the excess MSU and spreads them out across the following intervals up to the level of the desired CAP until they are all used up.
Thanks to Dick Arnold, Commerce Bank of Kansas, USA. Change 28.316 If you fail to reset the _NOOBS and _YESOBS tokens before VMXGUOW you run ASUMUOW, no observations were processed, but with Jan 5, 2011 no explanation. Now, when zero observations are detected an MXGWARN message is printed to explain why there was no output observations created in ASUMUOW.
VMACVMXA "VM" CP address of 00-0Fx, but is the LCPUADDR in the CEC Jan 5, 2011 causing VXSUMCPU to contain many spurious observations. This correction for the unexpected PFXCPUAD values is to deaccumulate by PFXCPUAD, but then sum by ENDTIME for the merge to create VMXAINTV. Fortunately, the only variable in VXSYTCUM is the LPAR Management Time LCUMGTM, and in spite of the spurious observations, the value in VMXAINTV was correct before and after this change; the increase in observations during summarization just looked wrong! -Division by zero in creating VXAPLTCB was because the BY list did not include SUBTASKN. Thanks to Frank Bright, MEDCO, USA. Thanks to Nick Said, MEDCO, USA. Change 28.314 -%UTILBLDP(SUPPRESS= 6 26 30 110 DB2,BUILDPDB=YES) caused UTILBLDP ERROR: FILE WORK.TYPE30MR DOES NOT EXIST. TYPE30MR is Jan 4, 2011 now protected when SUPPRESS 30 is requested. -If SMF 6 26J2/26J3 AND 30 are suppressed, BUILD005 is not executed. -If 26 (instead of 26J2/26J3) is specified, 26J2 is used, with a note. -A new QA report now compares the suppressed records list of dddddd tokens with the list of datasets created by the SMF record to ensure UTILBLDP is updated when needed. Thanks to Charles Savikas, DCF, State of Florida, USA.
TYPE0 some time zones, because the CEIL/FLOOR functions that TYPE28 are needed in MXG to create integer Time Zone deltas were TYPEEPIL omitted when CVTTZ was added to the record. The CVTTZ TYPEHPDM field is documented in the CVT as if it is the actual GMT TYPEMVCI offset, but its value of 1.048576 seconds per binary bit TYPENTCP is not an integer value; IBM actually uses the 8-bytes in TYPEOMCI CVTLDTO with 1 microsecond resolution for the GMT offset. TYPETIMS -The CVTTZ field is the first 4 bytes of CVTLDTO, so those TYPETMDB CEIL/FLOOR functions are used to create exact GMT Offset; TYPETPX their absence in TYPE0 caused a search for all MXG code Jan 3, 2011 with CVTTZ-based GMT offset, which found some members needed corrections. Luckily, some of the vendor records store an integer value, so MXG's use of CEIL/FLOOR is not always required, but MXG now uses them consistently. Fortunately, in most cases below, the GMT Offset was not used to convert (when all timestamps are already LOCAL), so only the GMT Offset variable might have been wrong. And by only one second: -VMAC0: CVTTZ had no CEIL/FLOOR. -VMAC28: NPMGMTTZ had only (wrong) PIB.4., no floor. -VMACEPIL OMGMTOFF CEIL/FLOOR functions reversed. -VMACHPDM SOVHTZOS no 1.048576 multiply, no CEIL/FLOOR -VMACMVCI T6ECVTTZ CEIL/FLOOR functions reversed. -VMACNTCP MONCVTTZ only PIB.4, no multiply, no CEIL. -VMACOMCI SMCVTTZ CEIL/FLOOR functions reversed. -VMACTIMS CHGMTA no CEIL/FLOOR -VMACTMDB GMTOFFTM no CEIL/FLOOR -VMACTPS TPXCVTTZ CEIL/FLOOR functions reversed. Note: CVTLDTO is not externalized; APAR OA23267 listed a value of FFFE6053 1927B4DE for a 31 hour offset, but that value is 30.99500413 hours, .005 hours or 0.35 seconds instead of the one microsecond resolution expected. But, the error in that APAR apparently impacted both the hour and the seconds; examination of current CVTLDTO values FFFFAF88 -6 hours FFFFAF88 A2800000 -21600.000000 FFFFBCF1 -5 hours FFFFBCF1 DCC00000 -18000.000000 FFFFCA5B -4 hours show full microsecond resolution produces exact integers. Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA. Change 28.312 The default "SMFSMALL" file for testing SMF processing UTILGETM created by UTILGETM writes only 10 records for each SMF Dec 31, 2010 ID and SUBYTPE, so the TYPE72GO dataset had only the first 10 service classes and NO reporting classes. The default NRECORD=50 is now set so there should be at least some Reporting Class observations in SMFSMALL (which was increased from 4 to only 19 cyl, so it's still SMALL). Thanks to Ken Jones, Xwave, CANADA. Change 28.311 Support for IMS/DBCTL transactions made in Change 28.310 TYPEIMSA are implemented in the JCLIMSL6/ASMIMSL6 IMS processing. TYPEIMSB -TYPEIMSA was revised to split and separately process the VMACIMSA IMS/TM from the IMS/DBCTL transactions. Dec 31, 2010 -TYPEIMSB was corrected to correctly work on ASCII SAS, and ancient code blocks were removed for IMS Version 5! -VMACIMSA revised to create IMS07D/IMS08D for DBCTL. -Some code blocks for _IMSVERS LE 6.1 were removed. Thanks to Ojnan Lindholm, Volvo, SWEDEN.
EXIMS07D IMSTRAN.IMS0708 is revised. While IMS/DBCTL transactions EXIMS08D were correct, identifiable by PROGTYPE='D', DBCTL records FORMATS also created thousands of spurious observations that had TYPEIMS7 PROGTYPE=' ', but, fortunately, had no resources, so they TYPEIMSD only wasted disk space! Now, VMACIMS splits the 07/08 VMACIMS records (DLRUSSN GT 0 for DBCTL) to create separate pairs VMXGINIT in IMS07/IMS08 and IMS07D/IMS08D datasets that are then Dec 31, 2010 separately sorted and combined by different algorithms to eliminate the spurious observations. TYPEIMS7 can create datasets for all IMS log records, or you can select which records are read to populate only desired IMS datasets. These tailoring macros allow you to define the LIBNAMEs that will be used; all default to WORK. See examples in the comments in TYPEIMS7 member.
TOKEN
&WIMS78 IMS0708.IMS0708 IMS/TM,IMS/DBCTL TRANS &WIMSBMP IMSBMPS.IMSBMPS BMP EXECUTIONS &WIMSA78 IMS0A78.IMS0A78 IMS/TM CPIC TRANSACTIONS &WIMSOTH IMSOTHER.IMSOTHER ALL OTHER IMS LOG RECORD -VMACIMS creates the new IMS07D and IMS08D datasets from which the IMSDBCTL dataset is created by TYPEIMSD. -FORMAT $MGIMFPT adds ' '='BLANK:UNMATCHED', because the mismatched 08/07s can exist and now will be output and can be seen with that value if you print PROGTYPE. However, if you want to tabulate PROGTYPE, because it is a character variable, you must add the /MISSING option to see the formatted value tabulated: PROC FREQ DATA=IMSTRAN.IMS0708;TABLES PROGTYPE/MISSING; -Some code blocks for _IMSVERS LE 6.1 were removed. -Member TYPEIMSD is replaced by TYPEIMS7 and contains only comments. The original TYPEIMSD had the IMS/DBCTL logic for the 07/08, but it did not handle IMS/TM transactions. Thanks to Ojnan Lindholm, Volvo, SWEDEN. Change 28.309 The Raid Rank ID variables R745RRID and R748RRID are now VMAC74 formatted with HEX4. as both RMF and HDS internals show Dec 27, 2010 the hex value in printed reports. Thanks to Ron Hawkins, HDS, USA. Change 28.308 Removal of duplicate SMF records (now, ANY non-VSAM z/OS ANALDUPE data file). See MXG Newsletter FIFTY-SEVEN, MXG TECH NOTE UNDUPSMF TWO for benchmarks of the four alternatives, and read the Dec 23, 2010 ANALDUPE discussion of why MP's discovery that the SAS MD5 Hash Function is an elegant and efficient solution to remove duplicates from ANY z/OS file, not just SMF data. For comparison, see the timings in UNDUPSMF, the original de-dupe program. Thanks to MP Welch, Aprize, Inc, USA.
VMACVMXA messages on the log of broken data, but MXG recovery was Dec 23, 2010 successful. The invalid segment had MRHDRLEN=140 with NRCPUS=2, so it had only 44 bytes for the two sets of 9 4-byte per-CPU counters. The short record is detected and the second CPU observation is not output, but there are no MXG messages on the log; if/when a user notices the same problem we'll then pursue a problem report with IBM. Thanks to MP Welch, Aprize, Inc, USA.
VMAC116 was no period in QWHCTOKN; that same correction is now Dec 21, 2010 made in SMF 116 when there is no period in QWHCNID. Thanks to Nick Varvarigos, IBM Global Services, CANADA. Change 28.305 -PDB.NJEPURGE did not contain all NJE-related SMF 26 Purge BUILD005 records; MXG only output INREASON=JR or JT records into VMAC26J2 that dataset, so INREASON=SR records were not output. Dec 21, 2010 Now, all TYPE26J2 with SYSEXEC blank and any JES2 Offload Jan 3, 2010 Purge Records are output in PDB.NJEPURGE. -All TYPE26J2 variables are now kept in PDB.NJEPURGE. -Variable INREASON='RD' is now set for purge records that have INDEVICE of INTRDR, STCIRDR and TSOINRDR; previously INREASON was blank. -Blank INREASON will now print the first three instances. -Jan 3: BUILD005 revised; it had added all of the _NJE26 variables to the PDB.JOBS dataset, wasting space, and the dataset SPIN26 had also kept RDRTM SUBSYS. Thanks to Jim Horne, Lowe's Companies, USA. Change 28.304 SMF 89 subtype 1 with no usage segment had INPUT EXCEEDED VMAC89 RECORD LENGTH error, because Change 28.282 added test for Dec 20, 2010 new data in line 390, but the test was GE 195 but should have been GE 205. Only one record with no usage occurred in 160,000+ records, but MXG now detects and output these records in TYPE89. They can be identified because both PRODTCB and PRODSRB are missing values. If a problem is opened with IBM and a response is received, this note will be updated. Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA. Change 28.303 Printed output location was shifted to accommodate longer ANAL119 host names and URLs, and to avoid print overlay of the Dec 17, 2010 remote IP address on detail reports when reading IPHOSTS. Thanks to Dave Ireland, USDA National IT Center, USA. Change 28.302 The BY list for dataset TYPE30MU was insufficient and it VMAC30 removed some non-duplicated observations. Adding vars Dec 17, 2010 STEPNR STEPNAME PRODTCB PRODSRB SMFRECNR MULCEGNR to the BY list eliminates the false duplicate removal, and by adding after SMFTIME, they won't cause NOTSORTED errors. However, there ARE duplicate TYPE30MU segments from the same SMF record that are now kept only because MULCEGNR, (segment position in each record) are different. You can examine these duplicated segments with this example: %INCLUDE SOURCLIB(TYPE30); PROC SORT DATA=TYPE30MU OUT=SORT30MU; BY READTIME JOB JESNR INITTIME SUBTYPE PRODOWNR PRODNAME PRODQUAL PRODID SMFTIME STEPNR STEPNAME PRODTCB PRODSRB; DATA DUPES; SET SORT30MU; BY READTIME JOB JESNR INITTIME SUBTYPE PRODOWNR PRODNAME PRODQUAL PRODID SMFTIME STEPNR STEPNAME PRODTCB PRODSRB; IF FIRST.PRODSRB AND LAST.PRODSRB THEN DELETE; PROC PRINT; TITLE DUPLICATE SEGMENTS IN TYPE30MU; Thanks to Christa Neven, KBC Global Services, BELGIUM.
VMXGGETM to detect non-numeric typed values for NRECORD argument Dec 20, 2010 in %VMXGGETM call. VMXGGETM is used only to create the SMFSMALL file or to count records/bytes in an SMF file. That change was only to replace an obscure failure with a successful run by forcing NRECORD to the OBS value. That enhancement is now bypassed when executed under WPS. Thanks to Matt Henson, McMaster-Carr Supply Co., USA. Change 28.300 TYPETCP (SMF 118) Port Numbers (IN DECIMAL) were wrong if VMACTCP MXG was executed on ASCII because the input was PIB2. but Dec 14, 2010 must be the &PIB.2. macro variable to resolve correctly. Having found this one exposure precipitated a search of all MXG members and these members also had to be fixed; fortunately, almost all of these members are ancient and no longer used so there was no impact except consistency: TTXPDS XIBMFDP XGTFANAL TYPSIMS1 TYPEIMS1 VMACZTPF VMACTPF VMACTMVS VMACSMSX TYPESRLI PRODTESW PRODTEST IDMSLOG IDMSLO57 IDMSJRLN ANALCM29 ANALCM27 Thanks to Cristian Molero, MConsulting Bvba, BELGIUM
VMAC7072 if SMF70PAT was non-zero in any engine, because SMF70PAT Dec 14, 2010 was kept in both TYPE70EC and TYPE70EL, which are MERGEd to create PDB.TYPE70EL, but it only should have been kept in TYPE70EC. Having the same named variables in datasets that are merged can have unintended consequences if they are not in the BY list for the merge. Fortunately, the PDB.TYPE70EN (one obs per engine) is not (yet) used to create the per-engine values in PDB.TYPE70. And, only software developers like Don are even likely to ever need the level of detail from RMF 70s in TYPE70EN. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 28.298 -EXITCICS decompresses SMF 100,101,102,110 & 112 records, EXITCICS The previously reported errors with SMF 112s and EXIT112 EXIT112 were not in the CICSIFUE exit code, but in VMAC112 due to VMAC112 IBM's change of FOCVER='V560' backwards to FOCVER='V420' Dec 18, 2010 (with NO change in the record itself), which caused MXG's tests for GE 'V560' to fail and misalign the decompressed record. With the exit, the ABEND was incorrectly blamed on the Exit, or, processing uncompressed records caused zero observations in the T112xxxx datasets. Member EXITCICS invokes the CSRCESRV function; this note here so a search for it will find this change text. -VMAC112 was revised for FOCVER='V420'. -The EXIT112 member is now only comments to use EXITCICS. -EXITCICS added DB2 100,101,102s support in MXG 28.06. Thanks to Dick Arnold, Commerce Bank of Kansas City, USA Thanks to Tom Kelman, Commerce Bank of Kansas City, USA ====== Changes thru 28.297 were in MXG 28.08 dated Dec 13, 2010========= Change 28.297 WANTONLY=DB2ACCT, now works; it worked fine if there was READDB2 a blank before the comma. Now in QA TESTREAL. Found this TESTREAL when I tried to use it in ANALDBUT, so Tom gets 2nd cite! Dec 12, 2010 Thanks to Tom Glaser, MasterCard, USA.
ANALDBUT observations with QWHSPLAN='DSNUTIL' with DB2 Trace data Dec 12, 2010 IFCIDs 23,24,25 to add UTILNAME, UTILPHAS, and UTILID variables to the DB2ACCT observation for each DSNUTIL execution. The output WORK.DSNUTIL dataset is created. Thanks to Tom Glaser, MasterCard, USA. Change 28.295 Analysis of WHO deleted your DB2 data, combining TYPE6156 ANALWHO and DB2ACCT. If you have the DDL Audit Trace its easy: Dec 10, 2010 %ANALDB2R(PMACC01=NO,PMACC02=NO, PMSTA02=NO,PMAUD02=YES,AUDIT=DDL); and this program would not be needed. However, ANALWHO selects the z/OS Dataset name from Yüklə 28,67 Mb. Dostları ilə paylaş:
|