* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
VMAC80A error. The record, an RACFEVNT=21:RDEFINE has pairs of Jan 28, 1997 (SMF80DTP,SMF80DLN) (data type, data length, in decimal) of (6,151),(12,12),(81,08),(0,21),(6,8), then 543 (24,12) segments, a (49,20) and a (53,80). The first DTP=6 is the expected 151 bytes, but there is a later DTP=6 with unexpected length of 8. The DTP=12 is 12 bytes instead of the documented multiple of 9. There are no DTP= 0 or 81 values documented by IBM. And inside the DTP=12 data segment, the characters do not conform with the expected format, so this record was partially hosed, but still by adding protection for these (invalid) unexpected lengths in the DTP= 6 & 12, and for the unexpected DTP= 0 & 81, the rest of the type 80 records can be read while IBM is contacted to find a fix to prevent the bad record. Thanks to Silva Viviani. Fondo Commune D.C. Rurali Trentine, ITALY. Change 14.312 IMF flag variables in the DBD section were not reset for VMACCIMS the next DBD segment, and thus were incorrectly carried Jan 28, 1997 forward. ELSE variable=' '; clauses were added for the variables: DBTOVFLW DBTMSCNT DBTTYDDN DBTTYOTH DBTTYSEC DBTVSAM and DBTOSSB Thanks to Sieghart Seith, FICUCIA, GERMANY. Change 14.311 MXG now converts GMT timestamps in DB2 records to local EXDB2ACC time automatically, but this change is INCOMPATIBLE for: VMACDB2 sites that already use member EXDB2ACC to change GMT to VMACDB2H local for variables QWHCBSC and QWHCESC (which was the VMAC102 MXG recommendation prior to this change!). For those Jan 27, 1997 sites, you must remove your conversion code and let MXG convert those and all DB2 timestamps for you. The revised algorithm detects not only the hours of delta time between SMFTIME (local) and THISSTCK (GMT), but also now detects the seconds of delta time (values of 20 seconds were seen, which is about the current number of leap seconds that is included in the STCK value in SYSPLEX environments, but leap seconds are not included in SMFTIME values). The value of the GMT Offset, GMTOFFDB, may not be exact hours. We found a THISSTCK value of 16:00:20 and SMFTIME was 10:00:00 so GMTOFFDB was -06:00:20! Without those extra 20 seconds in the GMT offset, the converted local times would be off by 20 seconds, so don't disbelieve a GMT offset that is not exact hours. I arbitrarily set any difference less than 10 seconds to zero, even though current measurements show a maximum real fuzziness of less than 0.12 seconds, because I expect delta seconds to be due to leap seconds and the value of 10 might cover pathological cases when SMFTIME was delayed. The new algorithm to calculate the GMT offset, GMTOFFDB, which is used in VMACDB2 & VMAC102 members, is contained in VMACDB2H: DELTASMF=SMFTIME-THISSTCK; GMTOFFHR=(100*FLOOR((DELTASMF+30)/100))/3600; GMTOFFSC=DELTASMF-3600*GMTOFFHR; IF ABS(GMTOFFSC) GT 10 THEN GMTOFFDB=3600*GMTOFFHR+GMTOFFSC; ELSE GMTOFFDB=3600*GMTOFFHR; Thanks to Chuck Hopf, MBNA, USA. Change 14.310 -Dataset PDB.DB2GBPST (Global Buffer Pool Interval Stats) DIFFDB2 contained accumulated (and hence useless) values, but it VMACDB2 is now deaccumulated to contain valid interval data by Jan 27, 1997 its support in member DIFFDB2. -Dataset PDB.DB2STAT1 and PDB.DB2STATS variable QBGLGN should never have been kept; it is the Group Buffer Pool ID in each of the segments, and is kept only in the detail PDB.DB2GBPST dataset. Thanks to Ermanno Bertolotti, Banca Commerciale Italiana Thansk to Daniela Busani, Banca Commerciale Italiana Change 14.309 Support for additional variables in type 42 subtypes 15, EXTY42X1 16, 17, 18, and new subtype 19 creates new MXG dataset: VMAC42 TYPE42X1 - VSAM RLS Local Buffer Manager counters. Jan 25, 1997 See notes in member ADOC42 for details. Thanks to Michael E. Friske, Fidelity Systems, USA.
VMACNTSM 3.51, and graceful detection of new record types. Have Jan 25, 1997 tested 34 record types, of the 56 known records. See the status and complete technical discussion in ADOCNTSM. Change 14.307 Support for APAF v3.0 added new Millennium subtype 31 and EXAPAFCB 32 records which create three new APAF datasets: EXAPAFLP Dataset Subtype Description EXAPAFSY APAFSYSD 31 Global system data IMACAPAF APAFLPAR 32 LPAR and Physical CPU data VMACAPAF APAFCHN 32 Channel data Jan 25, 1997 Member IMACAPAF was incompatibly changed (because of the Jan 30, 1997 creation of new datasets) and must be refreshed in your USERID.SOURCLIB tailoring library. The new subtype 31 contains only the "Physical" partition times, while the subtype 32 contains the Total Dispatch and Effective Dispatch, from which LPAR Management Time is calculated for the Millennium processors. Thanks to Bob Gauthier, American Stores Company, USA. Change 14.306 Variable QBACHRF was added to the SUM= list of variables ASUMDB2B to be summarized in creation of ASUMDB2B. Jan 21, 1996
YEAR2000 ongoing list of vendor fixes which are required for those Jan 17, 1996 products that did not support 2000 but now do.
MXGSAS Error 180-322, right after the NOTE: THE INITIALIZATION Jan 17, 1996 PHASE USED 0.13 CPU SECONDS AND 2233K results because the default value for the TAILORNG symbolic parameter in the MXGSAS JCL Procedure was still wrong in MXG 14.10. The error was supposedly fixed by Change 14.239, but that fix was not implemented in the MXGSAS member until now. The default TAILORNG symbolic in MXGSAS must be: TAILORNG='*.NULLPDS,VOL=REF=*.NULLPDS', Thanks to Ram V. Ramamurthy, Associates Corporation, USA. Thanks to Walter ?, ???, USA.
VMAC26J2 of the (old) expected style of Lnnn.JRm caused INREASON Jan 17, 1997 to be blank (instead of SR/JR/JT), so these NJE purge Jan 21, 1997 records were not recognized and were kept as real purge records in BUILDPDB, causing some fields (like JENDTIME) to be taken from the wrong purge record. The MXG logic to create INREASON was revised to recognize the old and new style of INDEVICE and DEVNAME: DOTLOC=INDEX(INDEVICE,'.');/*CHECK INDEVICE, 'JR' OR 'SR'*/ IF DOTLOC NE 0 THEN DO; DOTLOC=DOTLOC+1; INREASON=SUBSTR(INDEVICE,DOTLOC,2); IF (INREASON='JR' OR INREASON='SR') AND ORIGNODE GT ' ' THEN SOURCE=ORIGNODE; ELSE INREASON=' '; END;
ELSE IF INDEVICE=:'L' AND '0001' LE SUBSTR(INDEVICE,2,4) LE '9999' THEN DO; /* FORMAT LnnnnSRm DOES NOT CONTAIN A DOT */ INREASON=SUBSTR(INDEVICE,6,2); IF (INREASON='JR' OR INREASON='SR') AND ORIGNODE GT ' ' THEN SOURCE=ORIGNODE; ELSE INREASON=' '; END; IF INREASON=' ' THEN DO;/*IF STILL BLANK, THEN CHECK DEVNAME*/ DOTLOC=INDEX(DEVNAME,'.'); /* 'JT' */ IF DOTLOC NE 0 THEN DO; DOTLOC=DOTLOC+1; INREASON=SUBSTR(INDEVICE,DOTLOC,2); IF INREASON='JT' AND ORIGNODE GT ' ' THEN SOURCE=ORIGNODE; ELSE INREASON=' '; END; ELSE IF DEVNAME=:'L' AND '0001' LE SUBSTR(DEVNAME,2,4) LE '9999' THEN DO; /* FORMAT LnnnnSRm DOES NOT CONTAIN A DOT */ INREASON=SUBSTR(DEVNAME,6,2); IF INREASON='JT' AND ORIGNODE GT ' ' THEN SOURCE=ORIGNODE; ELSE INREASON=' '; END; END;
Thanks to Silvio Orsini, Banca D'Italia, ITALY. Change 14.302 The 22 new Shared Paging variables in TYPE71 starting VMAC71 with SHPBINAU and thru SHPGLOAV need to be INPUT as Jan 17, 1997 &RB.8. instead of &RB.4. This corrects Change 14.257. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 14.301 MXG 14.07-MXG 14.10 only, JES3 only, and only if you use BUIL3005 BUIL3xxx members instead of BUILDPD3. Error 22-7 UNKNOWN JCLUXRE6 OPTION because SORTEDBY= was misspelled as SORTECBY=, and Jan 15, 1997 because BUIL3005 was not in my QA stream (but now is)! Thanks to Chris Weston, SAS Institute Cary, USA.
VMACRMDS section (or one added by APAR) with Originating Job and Jan 14, 1997 Originating JOBID that was not previously INPUT by MXG. To add these variables, insert after the @; that is immediately after the INPUT of RMDSUDAT: IF RMDSORG='A' AND RMDSACT='C' AND RECKEY='8080'X AND LENGTH-COL+1 GE 16 THEN INPUT
RMDSARN $EBCDIC8. RMDSARI $EBCDIC8. @; (These two variables are already INPUT in the code for later RMDS versions, and so they are in the KEEP= and LABEL statements already!). Thanks to Steve Colio, CIGNA Corporation, USA.
(although top of CHANGES said only thru 14.298, 299 was there!) Change 14.299 Support for NTSMF (Windows NT) measurement is now ready ADOCNTSM for beta testing, and is very well documented. ADOCNTSM NTINTRV now documents all 54 NTSMF datasets, and the new NTINTRV VMACNTSM dataset is created (like RMFINTRV). See NTSMF Technical Jan 8, 1997 Notes.
EXPROSMS but new sample code in this exit member (commented out, Jan 2, 1997 as it may be installation dependent) shows how one site was able to parse the text to identify which dataset and DDNAME was altered by PRO/SMS. Thanks to Warren Hayward, TJX Companies, USA. Spent an actual Christmas vacation with family, and nothing broke! Change 14.297 Variables MVUOBMDN,MVUSBIN,MVUSBMDN,MVUSOBIN,MVRETDAT are VMACEDGS now INPUT from the type 'V' DF/SMSrmm record and are kept Dec 19, 1996 in dataset EDGSVREC. Also, the CDS records can be read directly with TYPEEDGS, so using IBM's utility to dump the data is not required! Thanks to Richard Fortenberry, Mitsubishi, USA. Change 14.296 H-P Measureware variable SOFTWARE was kept as a 200-byte VMACMWAI variable because it was not in the LENGTH statement; now VMACMWSU it is set LENGTH $30. (and variable AMPM is now $2) to VMACMWUX reduce the size of the datasets. Dec 18, 1996 Thanks to Al Holtz, Medco Data Corporation, USA. ===Changes thru 14.295 were included in MXG 14.09 dated Dec 17, 1996=== Change 14.295 If you create type 74 records for devices other than just RMFINTRV TAPE and DASD, the DEV..... SIO74CNT and AVGRSPTM values Dec 17, 1996 include those other devices (eg, CTC) counts. Since it is the intention to have only DASD counts in those fields by inserting ELSE DELETE; before LENGTH SIO74TAP 4; those other device records will not be included in RMFINTRV. Thanks to W. Rathfelder, Taylorix AG, GERMANY.
DAILYDSN last volume's size was included in variable SPACE5, the Dec 17, 1996 megabytes on non-HSM tape. Replace SPACE5=BLKSIZE*BLKCNT; with SPACE5=TAPEBYTE; Thanks to Chuck Hopf, MBNA, USA.
ADOCNTSM created by Demand Technology's product. This support is EXNTxxxx for the beta testers of NTSMF. The fifty-four new MXG IHDRNTSM datasets (one per "object") are described in ADOCNTSM IMACNTSM member, and a more extensive discussion of NTSMF records TYPENTSM will be in the NT Technical Notes section of the next MXG VMACNTSM Version. Status of testing is also in ADOCNTSM. Dec 17, 1996 Change 14.292 The very last IMS log record was not processed, because VMACIMSA the ELSE IF LCODE=07X THEN DO; statement should have been Dec 17, 1996 IF LCODE=07X THEN DO; Thanks to Juerg Frei, SAS Switzerland, SWITZERLAND. Change 14.291 Coupling Facility data added by PTF UW90312 was on a per VMAC74 structure basis, not per-CF basis, so variable names were Dec 14, 1996 R744CCOC thru R744CXRL were moved from TYPE74CF to the TYPE74ST dataset, and MXG input logic was revised. IBM's "CF Reporting Enhancements to RMF 5.1", WSC Flash 9609 has an excellent discussion of how to use these important fields for determining if your Coupling Fac. becomes the bottleneck in your sysplex. The flash also lists APARs OW11789, OW12415, OW13418, and OW13536 as required and it lists the additional hardware ECs that you want to have installed for accurate CF measures. -R742MSTF was FORMATed $HEX2, input $CHAR1. -Variables R744FTIM, R744FSQU, R744FCTM, R744FCSQ are input with PIB8 instead of the (IBM-documented!) RB8.6 informat, and variables R744CDEC,R744CDAC,R744CTCC, and R744CDTA are input as PIB4 vice RB4. Thanks to Steve Dodge, Amdahl Corporation, USA.
IMACICSA type 110 records can be created, causing INPUT STATEMENT Dec 3, 1996 EXCEEDED error. This change, inserted after STCLEN has been INPUT, verifies the real data length agrees with the STCLEN value, eliminating the exposure. Thanks to Helgund Linck, BASF Compuer Services, GERMANY. Change 14.289 DF/SMS Rmm EDGS records type V can cause INPUT STATEMENT VMACEDGS EXCEEDED error because variable length fields & variable Dec 3, 1996 number of fields at the end of the record were not input Dec 17, 1996 correctly. Conditional INPUT of the variables MVDSN1, MVDSNL, MVACCINF and MVDESC with $VARYINGnn. INFORMATS with associated length variable, and INPUT of variables MVAUTID1-MVAUTIDC based on MVACCLST was necessary. Dec 17: Input of MVVOLSEQ must be &PIB.2. vice &PIB.1. Thanks to Richard Fortenberry, Mitsubishi, USA.
ASUMTALO clocks are out of synchronization, if the clock delta is TRNDTALO greater than the duration of the allocation, because only Dec 3, 1996 the start time of allocation had been adjusted. Now both the front-end and back-end timestamps are adjusted, and a note is printed on the log that we are adjusting times (and by how much). Thanks to Ruth Whitney, CITICORP, USA. Change 14.287 The number of DB2 Plans executed is no longer equal to ANALDB2R the number of observations in DB2ACCT, if DB2 Parallelism ASUMDB2A is used. Variable DB2PARTY (Parallel Type) identifies a Dec 3, 1996 "real" plan execution (DB2PARTY='S' or DB2PARTY='O'), but Dec 19, 1996 observations with DB2PARTY='P' are additional records for parallel tasks within a plan execution and must not be counted. In ANALDB2R and ASUMDB2R, NUMPLANS is now calculated as: IF QWHSRELN GT 4.0 AND DB2PARTY='P' THEN NUMPLANS=0; ELSE NUMPLANS=1; and then NUMPLANS is summed to get total count. Without this change, you will see very, very large counts of plans executed and per-plan measures will be very small, if your DB2 application exploits parallelism. Dec 19: The original test QWHSRELN GE 4.1 was changed to QWHSRELN GT 4.0 (because 4.1's value is 4.0999994278!). Also, this change removed the parallelized transactions from being counted as NUMPLANS, but sequential parts or parallelized transactions are still counted in NUMPLANS. I have to count the DB2PARTY='S' transactions, because for a non-parallelized transaction, that's all there is! I hope to review this counting and see if there is a safe way to only count 'S' obs for non-parallelized trans. Thanks to Glenn Bowman, Wakefern Food Corporation, USA. Change 14.286 DB2 Buffer Statistics in the Accounting Detail Report did ANALDB2R not include buffer pools 1 and 2, so they did not cross- Dec 3, 1996 foot to the "Total Total" field. Additional corrections were made and fields on HPOOL/VPOOL usage were added. Thanks to Terry Dehart, First of America Services, USA.
VMAC102 in DB2 Trace IFCIDs 21 and 44, but the real fix is: Dec 3, 1996 Change both occurrences of IF I=19 AND J=13 THEN J=20; to IF I=19 AND J= 7 THEN J=20; and change the LENGTH of COLLECT back to $ 26. Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Thanks to Harmuth Beckmann, Karstadt AG, Germany
EXTYSTRS This support decodes records into new dataset TYPESTRS, IMACSTRS but enhancements under development will use your current TYPESTRS TYPE74 and TYPE74CA statistics to create control cards VMACSTRS that will drive Stress Test to simulate that current I/O Dec 3, 1996 configuration. Thanks to Chuck Hopf, MBNA, USA.
VMACMWUX system had incorrect values for some variables, because Dec 2, 1996 -the variable PEAKTM should not have been INPUT, and it must be removed (i.e., the line INPUTing PEAKTM was deleted by this change, as was the line LABELing PEAKTM and it was removed from the KEEP= list for HPUXGLOB), and -the variable NTPACKRT should have been INPUT, between the INPUT of variables NTOUPKTS and NTCOLPCT (and it was LABELed as NET*TOTAL*PACKET*RATE, and added to the KEEP= list for HPUXGLOB). Thanks to Al Holtz, Medco Data Corporation, USA.
ASMVTOC using DCOLLECT and TYPEDCOL) is also a pig! For a system Dec 2, 1996 with 2496 DASD devices, ASMVTOC took 3.25 CPU minutes, 10 million EXCPs and 2.5 elapsed hours, while DCOLLECT took 2.72 CPU minutes, 86 thousand EXCPs and 23 elapsed minutes (and got VVDSs, Migration, and Backup data too!). Note that the MXG 13.13 version of ASMVTOC either failed during assembly, or assembled but then produced no output records when executed, so if you still use ASMVTOC, you will need 14.01 or later (to get Change 14.003). Thanks to Chuck Hopf, MBNA, USA.
VMAC102 ranges (page range in QW0221PL,PH, index range in KL-KX, Nov 23, 1996 and KH-KY), which are needed if you wish to verify that the I/O parallelism partitioning was even, and obs were only output for the record, not for each segment. The segment variables were added to the KEEP= list, and the OUTPUT T102S221; statement was moved to immediatley be after the @; after the INPUT of QW0221KY. Thanks to Ted Blank, IBM, USA.
VMACBETA at the start of print, and once at the end of print. As Nov 23, 1996 there are no resources in the start record, that record is now deleted. In the SUBTYPE=3 logic, between BETAATTR and BETABPGE, insert: @; IF BETAATTR NE 'C5'X THEN DELETE; INPUT Thanks to Paolo Carloni, AGIP PETROLI S.p.A., ITALY
VMACMWAI LENGTH statement for $16 (default of $8 was not enough, Nov 23, 1996 causing trunctation but no error), and variable SWAPMEM was added to the KEEP= list for dataset HPAICONF. Thanks to Lorenzo Wright, NCCI, USA.
EXTYVSME is described in Appendix K of IBM ITSC Red Book "Network IMACVSME Security Using the VTAM Session Management Exit, pub nr TYPEVSME GG24-3544-00). VMACVSME Nov 23, 1996 Thanks to Kwok Wong, Commonwealth Bank of Australia, AUSTRALIA.
IMAC6ESS segment in the type 6 SMF record, and variable ROOM was VMAC6 used in that commented-out code, but variable ROOM also Nov 23, 1996 exists in TYPE26J2, so to prevent a possible conflict, I renamed the ROOM in IMAC6ESS/VMAC6 to ROOM6. This should cause no compatibility issue, since ROOM was not kept in TYPE6 unless you tailored IMAC6ESS, and ROOM from TYPE26 was not kept in PDB.JOBS unless you tailored IMACPDB. Thanks to Helgund Linck, BASF Computer Services GmbH, GERMANY.
VMACTCP FTPLOCAL and FTPREMOT in the TYPETCPF dataset, causing Nov 23, 1996 those two variables to be missing in TYPETCPF. To correct copy the 16 lines beginning with FTPLOCAL=PUT... ending with FTPREMOT=COMPRESS... so they are immediately before the %%INCLUDE SOURCLIB(EXTYTCPF) statement. Thanks to Helgund Linck, BASF Computer Services GmbH, GERMANY.
IMACAAAA from KEEP= list in VMACHARB and VMACMWAI, IMACAAAA was VMACHARB updated with new member names that were overlooked, and VMACMWAI the AS/400 support for Release 3.7 was listed under 14.08 Nov 18, 1996 in the list of Significant changes in 14.08. Thanks to Freddie Arie, Lone Star Gas, TEXAS. Change 14.274 SuperIND$FILE SMF record had some character fields off by VMACSUIN one byte, because the +1 between XFERMODE and INBUFFSZ Nov 18, 1996 does not belong and was deleted. Thanks to Chuck Hopf, MBNA, USA. Change 14.273 MXG 14.05-08 only. INVALID DATA FOR R744FCTM and FCSQ. VMAC74 Added by Change 14.165, conditionally INPUT by Change Nov 15, 1996 14.196, the fields were still wrong in MXG 14.07 because the DSECT shows BL8, like the two preceding fields so I expected &RB.8.6 fields, but actual data values show the two fields must be INPUT as &PIB.8.6 instead! Thanks to Diane Eppestine, Southwestern Bell, USA. Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Thanks to Harmuth Beckmann, Karstadt AG, Germany
IMACICOC in variables OMUMBUSR and OMUMBPTC, while the variables Nov 14, 1996 PROGRAM and TRANNAME contain the name of the SAP Primary Program and Transaction. If you want your SAP reports to show the Umbrella names rather than Primary names, you can insert these lines in your reporting programs: IF OMUMBUSR GT ' ' THEN PROGRAM=OMUMBUSR; IF OMUMBPTC GT ' ' THEN TRANNAME=OMUMBPTC; You could insert these lines in member IMACICOC to store the Umbrella names into PROGRAM and TRANNAME in CICSTRAN, Yüklə 28,67 Mb. Dostları ilə paylaş:
|