* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
several were removed from members VMAC42, VMAC7072, VMAC79, Oct 4, 1997 VMAC80A, VMAC99, VMACICE, VMACMWUX, and VMACXPSM. These caused no error, but should not have been repeated. Thanks to Freddie Arie, Lone Star Gas, USA.
VMAC1415 to dataset TYPE1415 to flag whether an individual 14/15 Oct 4, 1997 record is the last volume, by decoding '40'x in RECIND1. See Change 15.304. ======Changes thru 15.238 were in MXG 15.05 dated Oct 2, 1997====== Change 15.238 "ERROR. NEGATIVE CPU-UNCAPTURED-TIME (TYPE70-TYPE72)" is RMFINTRV printed by RMFINTRV when MXG detects bad CPU time values Oct 2, 1997 in type 72 records. Back in 1992, IBM APAR OY51878 found bad values in CPURCTTM (SMF72RCT), and now APAR OW28256 reports bad values again! When CPURCTTM is corrupted, CPUOVHTM (actually the "Uncaptured CPU Time" rather than overhead) becomes negative because the total CPU in type 72 records exceeds CPU Active time for the box! This is because MXG includes CPURCTTM in CPUTM in building the TYPE72/TYPE72GO datasets, and in RMFINTRV calculations. You can correct this error in advance by inserting in the EXTY72/EXTY72GO exit members: CPUTM=CPUTM-CPURCTTM; so that TYPE72/TYPE72GO and RMFINTRV will not include the CPURCTTM (Region Control Task, mostly TSO Quiesce/Resore) in the total CPU time captured, and then remove this workaround when you install the PTF for the APAR OW28256. Note: for Boole's CMF, APAR BPM6782 is reportedly also a requirement. 29May98. Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY. Change 15.237 Support for BETA93 Release 3.1.3 (INCOMPATIBLE) inserted VMACBETA fields in the header, and changed the length of many of Oct 2, 1997 the fields. Unfortunately, I only received subtype 21 records, so only that subtype is supported in MXG 15.05. In fact, all other subtype will produce a hex dump of the first record of each unsupported subtype and prints an MXG message to please send that dump to me so I can add support for those subtypes. (If the BETA93 vendor had documented their alignment bytes in their DSECT, I could have delivered the code for all subtypes, but the subtype 21 record proved their documentation is inadequate. I presume that since only the subtype 21 records were sent, that that is the most important record for BETA92, and I hope this change will get you through the nite!). Thanks to Manfred Thomas, BHF-Bank, GERMANY.
ANALCISH match new IBM reports, but not all reports were finished Oct 2, 1997 in time for MXG 15.05 (notably, CICFCR). See notes in the member for additional status. Thanks to Steve Colio, CIGNA, USA.
BUILDPDB option, but only for steps with more than one physical 30 BUILDPD3 record for a step (eg., steps with many DD segments, aka BUILD005 MULTIDD='Y' steps). The sort order for TYPE30_4 did not BUIL3005 include MULTIDD EXTRADD variables, and if the multiple 30 VMAC30 records had exactly the same TERMTIME, the sort did not Oct 2, 1997 place them adjacent, and the NODUP only deletes duplicate records that are adjacent. The correction is to change the BY list for PROC SORT NODUP DATE=TYPE30_4 ... ; to BY READTIME JOB JESNR TERMTIME MULTIDD EXTRADD; Of course, if you never have duplicate SMF data (which can ONLY happen when a failure in SMF dump AND an incorrect human recovery occurs) you will not have cause for concern! The impact was that two observations were created in PDB.STEPS, and the job's CPU time was doubled. -Variables EXTRARMS, EXTRMULC, and EXTROMVS are now kept in the TYPE30_V and TYPE30_4 records, as they may be needed for additional protection. -Member ADOC30 has been updated with a discussion of the existence of multiple step records that was written in reply to a request from IBM to review SMF documentation on how to know whether a physical step record was the first, last, or in-between record for a step terminate. Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
VMACTCP length of the API Call record (on which MXG depends to Oct 01, 1997 sort out API from FTP from TELNET), relocated APIJOBNM, and added new variables APIJOBID (JCTJOBID) and APISTART (JES Start Time) for HPNS applications (where the HPNS enabled interfaces are - C sockets API (including C sockets for CICS) - Sockets Extended APIs: - Macro Interface - Call Instruction Interface, including Call Instr for CICS and IMS). Thanks to Harmut Richter, BASF Computer Services GmbH, GERMANY. Change 15.233 The discussion of documentation of MXG Software, the DOC MXG books, etc., is now contained in member DOCUMENT. Sep 30, 1997 There are several "tables of contents" of ACHAPxxx and ADOCxxx members (this consolidates and enhances the old "Online Documentation" section of member CHANGES).
EXXAMSYT were contributed to add new XAMSYT and XAMSYU datasets, EXXAMSYU and to correct "IF SKIP GE 20... SKIP=SKIP-20;" before IMACXAM the INPUT TCMXIDSZ to ..GE 16 ...SKIP-16" so that the VMACXAM fields are actually input. Datasets XAMSYT and XAMSYU Sep 30, 1997 report LPAR dispatch and management time from VM/ESA. Thanks to Anthony P. Lobley, EDS, ENGLAND.
DIFF28 (added by Change 15.206) now creates variable DURATM Sep 30, 1997 instead of DELTATM, and creates variable STARTIME to be consistent with other interval datasets. Thanks to Chris Weston, SAS Institute Cary, USA.
TYPEVLFC with the F CATALOG,REPORT,VLF command that creates the Sep 30, 1997 messages IEC359I. This program will read //SYSLOG and create dataset PDBVLFC.VLFCATLG from those reports and also trends the new and old reports in PDBVLFC.TRNDVLFC. Note that the report values are cumulative: the command must have been issued at least twice to produce data. Thanks to Chuck Hopf, MBNA, USA. Change 15.229 These IMS Log Processing Assembly programs were revised ASMIMSLG in MXG 14.07, but the revisions did not support archaic ASMIMSL5 pre-DFP 3.0 systems, and there was at least one MXG site Sep 30, 1997 at that level that encountered an 0C4, so the programs were revised to support the earlier QSAM level. Thanks to Skip Abadie, MBNA, USA. Change 15.228 IBM APAR OW26297 for JES3 add a new triplet section and VMAC26J3 Job Account fields at the end of the purge record (though Sep 30, 1997 the original APAR text made it look like it was inserted in the middle of the record, it was in fact added at the end). There was already a 42-byte accounting field in the JES3 purge record, but IBM added the new section to support all Job accounting fields. MXG previously used the 42-byte field to decode only variable ACCOUNT1, but with the new section, MXG will decode ACCOUNT1-ACCOUNTn (where the number of fields kept is set in your IMACACCT tailoring member). All of this is relatively unimportant since MXG needs the Purge record account fields only for jobs that did not initiate (i.e., JCL errors or cancel before execution); account fields are normally taken from the type 30 records.
VMAC30 is in error, and when installed causes APPC-using flushed Sep 30, 1997 steps to fill your log with hex dumps, and causes MXG to Dec 13, 1997 delete those step records. The APPC section was removed by the APAR, but the triplet values were not zeroed. This circumvention will print only one instance message on the log, will skip the non-existent APPC section, but will then output the type 30 record, and when the APAR error is fixed, the circumvention will be passive. Dec 13 update: APAR OW30802 is the new fixing APAR that will make this circumvention passive. Thanks to Bill Shanks, BR Business Systems, ENGLAND. Change 15.226 Support for APAR XXnnnnn, which increases the number of ANALRMFR structures in a Coupling Facility from 64 to 255. The VMAC74 SUBSCRIPT OUT OF RANGE error will occur if you install Sep 29, 1997 the PTF without this change. This change also eliminates four sets of variables QSTR01-QSTR64, QSIZ01-QSIZ64, QFLG01-QFLG64, and QVER01-QVER64 from dataset TYPE74CF. That information was already stored in TYPE74ST dataset, which has one observation per structure, and those fields should not have been kept in TYPE74CF anyhow! Reports in ANALRMFR have not been updated for more than 64 structures, and Total Size of Structures Allocated value will be missing until the CF Reports are revised. This change also corrected INPUT STATEMENT EXCEEDED error with type 74 subtype 4 records with NRTRIPLT=8. There is still an open problem with IBM for this APAR, as pointer R744CDSI is sometimes wrong, pointing beyond the end of the data record; MXG now conditionally inputs the R744CDSI extension fields, pending a fix from IBM. Thanks to Dennis Pugh, BMC Software, USA.
ANALCACH PDB.TYPE74CA and/or PDB.CACHE90 dataset, and will not Sep 26, 1997 fail if either dataset does not exist. (TYPE74CA has replaced the old CACHE90 dataset created from CRR.) Thanks to David Ehresman, University of Louisville, USA.
DAILYDSN variable SPACE5 (Non-HSM Tape) to be missing and causing Sep 26, 1997 UNINITIALIZED VARIABLE TAPEBYTE message on the log. The DAILYDSN program is used in JCLDAYDS example to measure the size of all of your datasets (DASD/TAPE/HSM) using DCOLLECT, CA-1, and HSM records. Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
ANALDB2R causing Authid to be overlaid. I changed DATETIME16. to Sep 26, 1997 DATETIME18. expecting to show all four digits of year, but did not check to see there was space on the line for the two extra positions. (Worse, DATETIME18 does not print the four digit year, it justs shifts right and then prints two digits of year!). Therefore, change all of the occurrences of DATETIME18. to DATETIME16. (Note the datetimes printed at the top of the page use DATETIME21.2 so you will see the four digit year on each page!) Thanks to Brian Hawthorne, Mutual of New York, USA.
VMAC6156 INPUT STATEMENT EXCEEDED error, because Change 15.166 was Sep 25, 1997 not correct. In the block ELSE IF CLTYPE='E7'X THEN DO; delete these two lines after the INPUT statement: ALICELN &PIB.2. /*LENGTH OF ALIAS INCLUDING ITSELF*/ ALITYPE $EBCDIC1. and then change ALIRESV $EBCDIC1. to ALIRESV $EBCDIC2. Thanks to Lawrence Jermyn, Fidelity Systems Company, USA. Change 15.221 The new ASUMUOW in MXG 15.04 fails with LIBNAME TEMP01 ASUMUOW not found. Test code that should have been removed had IMACUOW the specific reference. You can change TEMP01.CICSTRAN Sep 24, 1997 to CICSTRAN in both places to circumvent. However, this revision changes the MXG defaults so that PDB.ASUMUOW will always have zero observations, until you enable it in member IMACUOW. I create dataset PDB.ASUMUOW by default in JCLPDB6, but the default sets OPTIONS OBS=0 at the beginning and then resets OBS back to the original value (using VMXGOPTR) at the end of member ASUMUOW, so no data will be sorted or merged until you turn it on. I really think that large CICS and DB2 shops will find PDB.ASUMUOW better than its predecessor PDB.CICS, but it can use lots of CPU & DASD, so I think it safer to make you enable it. In addition, IMACUOW now externalizes the output of the PROC SORTs so you can send them to tape and save DASD space as well. The options are documented in comments in both members. Thanks to Mike O'Brien, McKesson General Medical, USA.
EXNTCNRS later (MXG 15.03 was required for NTSMF Version 2.0). IMACNTSM -Support for new Object 'Content Replication Service' adds VMACNTSM creation of new dataset CONTRPSV. Sep 26, 1997 -Existing dataset CONTNFI (Content Index Filter) has been validated with data, with new CNFINAME instance. -Existing CONTINDX (Content Index) has been validated with data, with new CNINNAME instance. -Existing IMAGE (Image) has been validated with data, with two instance variables IMAGNAME and IMAGFILE. -Existing MSEXCHMS (MSExchangeMSIM) object is validated, and will have observations (if you change the misspelling in IF UPCASE(OBJECT)='MXEXCHANGEMSIM' from MXEX.... to MSEX...., even earlier versions of MXG will have obs!). -Many new variables in CMPQxxxx datasets (from COMPAQ) were not in the INFORMAT statement, which would cause their values to be off by a factor or 100. -The _BNTxxxx macros were not defined for all datasets, and not all datasets were in the _SRTPRNL and _SRTPRNV print macros. -Member ADOCNTSM's list of datasets and Instance Variables has been updated to include recently added objects. -Variables CPUNUM1, FAMILY1, and MANUFAC1 and CPUSPED1 are now decoded from the "0.0 configuration record" (new in NTSMF 2.1). -The location of the calculation of SMFTIME was relocated so it does not generate "MISSING VALUES" message with 2.1 data; the value was re-calculated later and was never actually missing. Thanks to Jim Quigley, Con Edison, USA. Thanks to Carmen Vitullo, Boeing, USA.
CICINTRV DSGTL are static values and should not have been DIF() VMAC110 (as was DSGTL), and should not have been in SUM= nor Sep 22, 1997 MEAN= statements, and are now in the ID= statement. In spite of their mis-location, most of the time they yielded correct values, so the error was overlooked. (Note DSGTL only existed in CICS 3.3 and earlier) -In VMAC110, the new A04 variables in the INPUT statement begining with A04RDINT were all incorrectly labeled, and the two time durations, A04RDINT and A04RDIDL had wrong values with no TIME12.2 format. -The SKIP=SKIP-220 for archaic CICS 3.1.0 if there were no index segments and its INPUT +220 were changed to 218, to suppress an "UNEXPECTED DATA" message that, while harmless, could be eliminated. Thanks to Dan Gilbert, Bergen Brunswig, USA. Change 15.218 Support for CA's IDMS 14.0 (INCOMPATIBLE) splits existing EXIDMDGB subtypes 1 and 16, adds new subtype 16 for new dataset IMACIDMS IDMSDBG, and adds variables to IDMSBUF, IDMSINT, IDMSRUS, VMACIDMS IDMSTAS, and IMDSTAW. Sep 22, 1997 Thanks to Terry Heim, ECOLAB, USA. Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS.
IMACDALO the impossible value of 512 (so that JCLTEST6 does not IMACENDV try to read the wrong record type), but these three IMAC IMACSVCC members had values left over from testing; all are now Sep 20, 1997 set to the 512 default value. Thanks to Chuck Hopf, MBNA, USA. Change 15.216 DB2 Trace SMF type 102 Subtype 140 INPUT STATEMENT VMAC102 EXCEEDED if there was no SQL text in the Audit record. Sep 19, 1997 between NRSQLSEG=CEIL(( .... and DO SEGSQLT=1... insert IF QW0140LL GE 2 THEN so that the loop is only executed when there's text. Thanks to Chuck Hopf, MBNA, USA. Change 15.215 IXFP records, MXG 15.02-MXG 15.04 only. A line was VMACICE dropped by change 15.134, causing zero observations Sep 16, 1997 for subtypes 2, 3, and 4 (datasets ICEBRGCH,DV,DR). In the DO group for subtypes 1 thru 4, between the INPUT of ICEVERS and COLLID, insert a line with +2 to skip over the two reserved bytes that were dropped when ICEVERS's input was added by Change 15.133. Thanks to Angela Mulcahey, Summit Bank, USA. Change 15.214 MXG 15.01-MXG 15.04. Variable PCTMVSBY in TYPE70 is ACHAP10 wrong. The new algorithm used by MXG in Change 15.023 VMAC7072 should only have been used for Wait Completion = Yes, Sep 16, 1997 and although I think it is a better way to look at the Sep 20, 1997 MVS busy time for WC=Yes, I decided to revert back to match IBM's number while I do more research on the whole subject of PR/SM, MDF, and MLPF instrumentation. -Member ACHAP10, the MXG Chapter on Processor Utilization has been revised to describe how PR/SM, MDF, and MLPF can be measured, and includes description of how IBM calculates PCTCPUBY and PCTMVSBY and PCTLnBY on their RMF CPU Activity and Partition Data Reports. Numeric values for Dedicated, Shared Wait=Yes, and Shared Wait=No LCPUs are now provided. This article will be in the next MXG Technical Newsletter and was posted to MXG-L Listserv. -The test IF CPUWAIT GT 0 THEN DO; ... END; was removed because CPUEFFTM and PCTMVSBY/PCTCPUBY were missing if an LPAR was 100% busy in all LCPUS (the case noted was a single LPAR); the test was unneeded because the block of code is already inside the LPAR processing section. -Calculation of PCTCPUBY and PCTMVSBY in TYPE70PR dataset is made only in the TYPE70PR observation for the LPAR in which that MVS System executed, because only that LPAR's TYPE70PR observations knows what ORIGWAIT, the MVS Wait time, was recorded for that LPAR's LCPUs. They will be missing in TYPE70PR observations for other LPARs in that type 70 record. -Added variable NEWWAIT to TYPE70PR. NEWWAIT contains the "wait" time that was actually added to CPUWAIT for the calculation of CPUACTTM=CPUUPTM-CPUWAITM and for the calculation of PCTCPUBY in TYPE70 dataset. This new field may be useful to some sites with Dedicated or Wait Completion=Yes to match some RMF calculations. Thanks to Carl Downing, Blue Cross Blue Shield of Minnesota, USA. Thanks to Jan Tits, Amdahl, BELGIUM.
EXTY9121 SMARTBATCH at data set close for each VSAM or non-VSAM IMAC91 data set processed by the Data Accelerator component. VMAC91 New MXG dataset TYPE9121 contains a wealth of statistics Sep 12, 1997 and activity information for this new component.
VMAC74 units, rather than the 4000 byte unit discussed in Change Sep 3, 1997 14.328, probably beginning with OS/390 Release 1.2, so the three lines multiplied by 4000 are now by 4096. Note that R744SSIZ rather than R744QSIZ is used by RMF in its reports as the allocated structure size. Thanks to Tim VanderHoek, Fidelity Systems Company, USA.
VMACNAF a value of yyyydddF (instead of 0cyydddF) for SMFSTAMP8 Sep 4, 1997 fields, causing 1997 dates to be in year 3897! While Sep 26, 1997 Candle's choice is not illegal, SAS's SMFSTAMP8 informat expected IBM's documented century-bit format, so it used that first byte as the number of centuries after 1900. While SAS has agreed to change their SMFSTAMP8 format to support both yyyydddF and 0cyydddF formats, that fix won't be available on all platforms until next year, and as Candle's PTF creates the problem today, all 15 internal timestamps in VMACNAF are now protected by: CENT=FLOOR(YEAR(DATEPART(datetime))/100); IF CENT GE 38 THEN datetime=datetime-59958230400+(CENT-38)*86400; (The SMFTIME field in byte 3 of Candle's record was not changed by their PTF, so it needed no protection!) Update 26Sep97: Candle now says that if you put all of these PTFs on: QLS1303,1304,1305,1306,1307,1308,1310 and QLV1465, that their dates will conform to IBM's use of the century bit. Thanks to Joseph J. Faska, Depository Trust, USA.
TRNDTALO not exist in your TREND library. Add the statement Sep 2, 1997 OPTIONS NODSNFERR NOVNFERR; at the beginning of the member to correct. Note that if you were previously creating the TRNDTALO member, the new code did not fail, so only first-time users of TRNDTALO got hit. Note also that TRNDTALO requires that ASUMTALO be in your WEEK library, so you will need to update your WEEKBLD to propagate ASUMTALO before you can use the trending in TRNDTALO. Change 15.208 Cosmetic: comments /* _Lxxyyyy OUTPUTS TYPExxxx */ EXVMADSM are after each %INCLUDE SOURCLIB(EXxxyyyy); statement VMACNTSM name the default MXG dataset for each _Lxxyyyy macro, to VMAC80A make the MXG source code documentation, but seven new VMAC99 datasets had wrong names or no comment. I block copy and VMACSVCC revise when I can, but sometimes I overlook the comments. Aug 31, 1997 But Freddie's sophisticated analysis of my source code uncovered seven inconsistencies in MXG 15.04, and I plan to add his QA to my QA before I build the next version! Thanks to Freddie Arie, Lone Star Gas, USA. Change 15.207 CA-1/TMS 5.2 Change 15.199 had one incorrect new variable VMACTMS5 DEFEXPOO. The second occurrence in the KEEP, LABEL, and Aug 30, 1997 assignment should have been NRESTAPE. Thanks to Freddie Arie, Lone Star Gas, USA. ===Changes thru 15.206 were included in MXG 15.04 dated Sep 01, 1997=== ===Changes thru 15.206 were published in MXG NEWSLETTER THIRTY-TWO===== Change 15.206 NPM dataset NPMINPMT contained accumulated fields that DIFF28 were deaccumulated inside VMAC28, but when SMF data was TYPE28 sorted before MXG processing, wrong results occurred! VMAC28 In addition, not all variables were deaccumulated that Aug 28, 1997 should have been. This change adds new member DIFF28 Yüklə 28,67 Mb. Dostları ilə paylaş:
|