* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
replaced an equivalent algorithm. Thanks to ???, Alm. Brand, DENMARK.
RMFINTRV has been used to re-define the startime of your RMF data, Jan 14, 1992 since STARTIME is both being changed and in the BY list. Insert:
PROC SORT DATA=RMF72D %VMXGFOR;BY SYSTEM STARTIME; immediately before the PROC MEANS NOPRINT DATA=RMF72D; to ensure that RMF72D is always sorted. Thanks to Bill Stoneberg, National-Oilwell, USA. Change 09.203 CA7 corruption of TSO/MON READTIME was only partially VMACTSOM corrected in MXG 8.8 by Change 8.209. That change should Jan 14, 1992 have also been applied to the second correction of the CA7 corruption, lines 076500 and 076800. Thanks to Paul Hill, Midland Bank, ENGLAND.
FORMATS type 84 SMF record. There are nine subtypes, and only TYPE84 subtype 5 has been addressed thus far, and not even all VMAC84 of the sub-subtypes are yet coded. This change will Jan 13, 1992 extend over time. Thanks to Jonathan E. Paley, Massachussets Mutual, USA. Change 09.201 A cosmetic change. Variable RECNR should have been VMAC6156 RECNR156 in line 013400. Jan 13, 1992 Thanks to James F. Cook, CocaCola Company, USA. Change 09.200 Support for Emc2/TAO (Fischers Totally Automated Office) FORMATS Release 3.3.0 SMF record. The new release switched the VMACTAO database reads and writes, but was otherwise implemented Jan 12, 1992 compatibly. This support also added format MGTAOTC and decoded three bitstrings into new variables. Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA. Change 09.199 This member creates reports for use at IBM's SNAP/SHOT. ANALSNAP The SNAP/SHOT report is created from MXG's TYPE30_5 data. Jan 11, 1992 A DASD farm report was created from DMS DSINDEX report. A report from CA-11 (JEHF Version 2) was developed. Mantissa run tracking file formats for RMS/BASIC are provided, and the TMC file was used for tapes (MXG's TYPETMS separately processes that data). These reports could save you lots of time if you plan to model your workload with SNAP/SHOT (and look at TYPETPNS which will analyze the TPNS log produced by SNAP/SHOT!) Thanks to John Leath, Fleet Real Estate Funding, USA.
TYPEIMS the diligent research of the three authors of this very VMACIMS significant contribution. VMACIMS now creates temporary VMACIMS datasets IMS5901,03,36,37, and 38 from those subtypes of Jan 11, 1992 the 59x log record, and TYPEIMS has additional logic at the end to sort and combine these to create the IMSFASTP fastpath dataset (and IMS5838 with syncpoint failures. Not only has this code been in production (IMS 2.2 & 3.2) for over a year, its output has been validated with IBM's DBFULTA0, and these author's comments in member TYPEIMS are an excellent mini-tutorial on IMS Fastpath. (Usually ANY activity in IMS makes my stomach hurt, as there just isn't any documentation or help from IBM. This contribution was done so well that my stomach feels like it just received a piece of cake! Thanks!) Thanks to Lars-Olof Thellenberg, Forsta Sparbanken, SWEDEN Thanks to Goran Zebuhr, Forsta Sparbanken, SWEDEN Thanks to Sven Agrell, Forsta Sparbanken, SWEDEN Change 09.197 A sample report using TYPE30_4, TYPE30_5, and TYPE30_D ANAL30DD datasets to report on all your active ddnames by job. Jan 10, 1992 The comments in the member describe how to use ANAL30DD. Thanks to Phil Mason, ANZ Bank, AUSTRALIA Change 09.196 Support for LLA exits CSVLLIX1 and CSVLLIX2 are added in ANALLLA this significant user contribution. Member ASMLLA is the ASMLLA ASM source for the two exits that will capture LLA module IMACLLA accesses and create a user SMF record. Members IMACLLA, EXLLAEX1 EXLLAEX1,TYPELLA, and VMACLLA are the MXG members to read TYPELLA those SMF records and create dataset LLAEXIT. The final VMACLLA member, ANALLLA, provides some sample reports on LLA. Be Jan 10, 1992 very careful as these exits can create many SMF records! Thanks to Ken Williams, ANZ Bank, AUSTRALIA Thanks to Peter Beer, Amdahl AUSTRALIA Change 09.195 SAS can write zero-length VB or VBS records to a FILE IMACFILE statement, and files containing zero-length records may VMACSMF cause other programs (specifically, DFSORT) to fail. The Jan 10, 1992 problem was precipitated by MXG's change in VMACSMF to Feb 9, 1992 PUT a new message to the SAS LOG telling you how many megabytes of SMF data had been read. In that message there is // (two skip to the next line on the log). The site had used IMACFILE to write selected SMF records to an external file using FILE SMFOUT; PUT _INFILE_; The SAS log showed "minimum record length 0" to SMFOUT! The FILE SMFOUT had changed the destination for all PUTs from the LOG to SMFOUT, causing the MXG message and its // to be written as a length zero record to SMFOUT! The real error was in not recognizing that any FILE statement changed the destination for all subsequent PUT statements, and the moral therefore is to ALWAYS follow any FILE/PUT statement that you add to MXG with a FILE LOG statement to reset the destination for PUTs. The real error was MXG's failure to reset the log in VMACSMF; that has been done. Change 9.087 originally discussed the need for the FILE LOG; statement, and the new "megabytes" note was added by Change 9.094. Thanks to Keith Stout, City of Anchorage, USA.
EXNSMCON this significant user contribution. Three datasets are EXNSMPRC created: NSMCON, NSMPRC, and NSMTRM, and you specify the EXNSMTRM SMF record ID in MXG member IMACNSM. IMACNSM TYPENSM
VMACNSM Jan 9, 1992 Thanks to David B. Adams, National Life of Vermont, USA.
VMXGHSM all 44 bytes of the dataset name are captured in the Jan 9, 1992 MCDDSN variable. Thanks to Ray Dickensheets, Yellow Freight System, USA. Change 09.192 User of Amdahl Cache Controllers will thank Dick Sziede ADOCSPMS for his excellent paper "A Look at Cache Performance Data Jan 9, 1992 for the Amdahl 6100" which is contained in this ADOC. The member is not complete, but his discussion of what's good and what's bad is must reading for SPMS users. Thanks to Richard R. (Dick) Sziede, PRC Inc, USA. Change 09.191 Members ADOCDB2 and ADOC102 completely describe each of ADOCDB2 the variables created by VMACDB2 and VMAC102 in DB2ACCT, ADOC102 DB2STAT0, DB2STAT1, and all 200 of the T102.... datasets. ANALDBTR The variable-level documentation is complete, but there FORMATS is still substantial writing to finish before theses two VMACDB2 ADOCs are completed. It is the process of documentation, VMACDB2H however, that uncovers inconsistency in formats, names, VMAC102 labels, etc., and that has been completed. Additionally, Jan 12, 1992 some datasets that formerly created multiple observations per SMF record were revised to create a single obs with multiple variables, so that the SQL trace logic to match begin and end would be more straightforward. These notes identify the highlights of this significant enhancement: 1.Variable QWHSIID was added to DB2ACCT/STAT0/1 datasets to eventually replace incorrectly spelled QWHSSIID. MXG will now use QWHSIID for IFCID variable in 100,101 and 102. Both variables continue to exist in DB2ACCT/DB2STATn for backwards compatibility. 2.Format MGDB2ID replaced with MGDB2II. 3.DB2 database "Object IDs" (PSID,OBID,DBID,ISOBID) are all now consistently $CHAR2 with format $HEX4, and the labels are now consistent and accurate. Seven variables had to be changed from numeric to character: QW0023PD,24PD,25PD, 44KD,44KP,143PS, and 144PS. 4.SQL statement type exists in two different formats. A one byte character value is found in IFCIDS 59-62 and 64-66 that is decoded by an expanded MGD062S format. A four hex digit numeric value is found in 124, 145, and 145 IFCIDs that is decoded by an expanded MG145S format. 5.Variable QW0032AR should not have existed; QW0032FT is the name of the field (QW0032AR is an EQU value!). 6.Variable QW0145TS was changed from numeric to $CHAR8 and formatted $HEX16 so all 'PRECOMPILER*TIME*STAMP' fields (in IFCIDs 53,58,59,60,61,64,65,66)are now character. If I can find out how to decode this timestamp (a hex value of '148CDFEF19AC29AC'X, for example), all these variables will be decoded into numeric datetime values! 7.Variable QW0063HL was not kept but should have been, and is formatted by new $MGD063H. 8.Variable QW0063OT is now formatted $HEX2. The MGD060O format formerly used did not correctly decode the multi valued bit fields, and is no longer used. 9.MXG 9.5 created observations for new IFCIDs 126-139 and 170-194 even without any 102 records because the OUTPUT statement for these IFCIDs was missing in VMAC102. 10.Datasets T102S018,T102S053,and T102S058 formerly had one or two observations per SMF record, one for index and one for data. This change eliminates the second record by putting the data portion counts in QW00.... variables, and by putting the index portion counts in QW0I.... names so that pairing these three records with their partners in ANALDBTR can be more easily/accurately accomplished. Variable SDSNUM, a sequence counter, is thus no longer required in these datasets and has been dropped. 11.ANALDBTR was revised to pair 044/045 data, to create additional datasets (S018S018 and S058S058) for unpaired ends, and to keep only the first segment of 063 data, all in support of SQL trace reporting. 12.VMAC102 was revised to create single observations for IFCIDs 13,15,and 17. Previously, one observation for each predicate was created. Now, the up-to-ten predicates are stored is sets of variables. The first set is prefixed QW0013, the second set QW0A13, the third QW0B13, etc. 13.VMAC102 was revised to create single observations for IFCIDs 58-62 and 64-66; previously they could have one or two observations describing DATA and/or INDEX activity due to SQL statements, but now the QW00nn variables have the data activity, while new variables QW0Inn contain the index activity. This made matching begin and end of SQL events much simpler in ANALDBTR. 14.The only IFCIDs that create multiple observations now are 22 (one miniplan per table per subselect block), 63 (one per each 200 bytes of SQL statement text), 126 (one per each index used to obtain candidate RIDs, up to 16), 145 (one per Audit Log Table), 148 (only for distributed allied agents, R8O one per conversation, R9O, one per location), and 191 (one per parse, up to 5). 14.VMAC102 and VMACDB2 labels and formats were revised to be consistently spelled, etc. 15.ANALDBTR, the routine which matches pairs of trace data, is now a %MACRO which invokes the old-style _nnnPAIR macros. This change added flexibility to its use and its invocation inside %ANALDB2R reporting. 16.VMACDB2H now creates variable QWHDYES, indicating that there was a distributed header, and which is now used in VMACDB2 to create new variable THREADTY (formatted with $MGDB2TT) to describe the type of thread (Allied, Allied- Distributed, DBAT (Database Access) or DBAT-Distributed). Thanks to Debby Meister, Loews Corporation, USA.
VMAC110 STID=63 (CICTM) record contains sixteen tables, but only Dec 27, 1991 the first twelve were kept by MXG prior to this change. Seven records (that contained only totals) are no longer created by IBM (because they are redundant with their corresponding detail record) and thus these MXG datasets always contain zero observations: CICTST(STID=5),CICTCT (35),CICLSRT(38),CICLSRFT(41),CICCONST(53),CICTCLT(59), CICFCT(68),CICCONMT(77). (Their detail dataset names are minus the ending "T".) -IBM added two undocumented bytes in the STID=57 (CICSDS) record, which corrupted the CPU times in CICSDS dataset, and in the CICINTRV, etc., datasets created from it. The two bytes added for alignment (immediately before the repeating DSECT) are not documented in DFHGSGDS. And in an unrelated change, CICS APAR PN02625 removes two filler bytes following DSGNTCB, but did not update the STIVERS version indicator, so there is no direct way to know what length record to expect! As a result, MXG protects for none, two, or four filler/alignment bytes in this record. -IBM documentation for statistic record STID=49 is wrong. DSECT DFHA13DS describes STID=49 as containing 39 bytes, but actual data records have STILEN=40; a one-byte field (reserved) following A0013BFC is not described in that DSECT (the only IBM documentation of the record!). IBM will correct their error (eventually) with a doc APAR. How can the record disagree with the DSECT you might ask? Because IBM records are built by PL/S DSECTS, but IBM documents with ASM DSECTS that are never actually used! -Two occurrences of broken CICS 3.2.1 records were found with only 80 bytes of data. MXG new detects the short record, messages to the log, and avoids STOPOVER ABEND. Thanks to Lee F. Johnson, Talbots Systems Center, USA. Thanks to Bruce W. Galle, Talbots Systems Center, USA. Change 09.189 Processing VVDSs previously failed with a USER ABEND 666 ASMVVDS when ASMVVDS tried to read a VM system volume that was Dec 20, 1991 online to MVS (because the volume does not have a normal VTOC/VVDS). Now, instead of the ABEND, the program puts out a message that the OBTAIN macro failed for that UCB (DEVNR), and then continues to process additional UCBs. Thanks to Chris Taylor, First Wachovia Bank, USA.
VMACVVDS in line 017100 was mistyped as ='D5' instead of ='D5'X. Dec 20, 1991 Thanks to Chris Taylor, First Wachovia Bank, USA. Change 09.187 Support for ASTEC Version 1.5. Several new fields were VMACDMON added (incompatibly) to the SMf record. This support was Dec 16, 1991 actually shipped in MXG 9.5, but this change was not in member CHANGES of that library. Thanks to Joseph J. Faska, Depository Trust, USA
VMACVPD VPDRSVR2 should have been input as $CHAR11. instead of Dec 16, 1991 $CHAR12. (line 014200). Thanks to Jim Nicholas, Mead Data Central, USA. Changes thru 9.185 were contained in MXG PreRelease 9.5, Dec 1, 1991 Change 09.185 Change 9.164 was a major restructuring of ANALDB2R, and ANALDB2R had not been sufficiently tested for all DB2 reports. ANALDBTR Using SAS 6.07 (and reading all of the SAS messages on Dec 1, 1991 the log!) not only corrected UNINITIALIZED variables, but the 6.07 feature which warns of unreferenced variables in the KEEP= list caught a number of mispellings in some of the type 102 trace reports. SAS 6.07 furthermore found a syntax error that SAS 5.18 had accepted! This was an another superb contribution from Koln. Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY. Change 09.184 Several important variables have now been added to the EXRMFINT TYPE70 and RMFINTRV datasets for MVS/ESA and PR/SM data. EXTY72 1.If PR/SM data section is found in type 70 (PR/SM, MLPF, RMFINTRV or MDF) records, both the Partition Dispatch (PDTM) and VMAC7072 Effective Dispatch (EDTM) are carried into the TYPE70 Nov 28, 1991 dataset. MXG continues to calculate PCTCPUBY based on Sep 21, 1994 Partition Dispatch Time for consistency, but now provides PCTCPUEF, based on Effective Time, which matches the RMF reported "CPU Busy" under PR/SM. The individual LCPUs times are in new variables CPUPDTM0-8, CPUEDTM0-8, and totals across all LCPUs are in CPUACTTM and CPUEFFTM. 2.RMFINTRV was enhanced to provide the three new CPU times (HPT,IIP,RCT) in each set of workload variables and their total for each workload. New variable BATCPU is the sum of existing BATTCB,BATSRB plus BATHPT,BATIIP, and BATRCT. Total CPU times are also kept in CPUTM, CPUHPTTM,CPUIIPTM and CPURCTTM variables. Next paragraph revised in 1994: ACTFRMTM replaced MSOUNITS as a metric in 1994: Additionally, in each workload, the memory is now calculated (Central+Estore) from ACTFRMTM in bytes in BATMEMR, CICSMEMR, etc. (but recall that ACTFRMTM does not include logically swapped pages nor the nucleus, LPA, nor CSA). This is a much better indicator of memory utilization than AVGMEMSZ, which is based on MSOUNITS as discussed in prior newsletters. And the total memory of all workload's memory is variable TOTMEMR. 3.See the MVS Technical Note on CPURCTTM in Newsletter 21. It is unmodified in the TYPE72 dataset, so you can see how wrong it is, but it is now subtracted from CPUTM in EXTY72 (temporarily, until a PTF exists). This will prevent negative overhead calculations in RMFINTRV due to the wrong value of CPURCTTM until fixed by IBM.
VMACDB2 to show the milliseconds. Sites using DB2 trace found VMAC102 the increase in printed resolution useful for tracking Nov 28, 1991 detail event sequences. Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
VMACIMS additional idiosyncrasies and undocumented Enqueue record TYPEIMS flags in this significant contribution. In VMACIMS, Nov 28, 1991 35x records with ENQFLAG=04C or 08C and FLAG2=08 are now added to IMS35P. This site uses Terminal-Databases with SPA-information and a Code-Information in the INPUT msg to jump from one transaction to another, which are now supported by additional logic, even when outputs do not match inputs. Compare criteria using LOGONID and ODEST do not work if there is no external LOGON-processing, (DEQTIME was always equal to OGUTIME), but by using CLINENR instead, and revising the MERGE logic, this case appears to be now protected as well. However, as past history indicates with IMS, what works at several sites may not always work at all sites, so please verify your output if you must process IMS log data. Additional cosmetic changes were a new message that tells you how many megabytes of IMS log data MXG read in, and if invalid 035x records are found, a hex dump of the record is printed on the log for Merrill debugging! Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
IMACICDB 110 DBCTL segment. However, since the APAR does not say VMAC110 where the field was added, I had to assume it's at the Nov 27, 1991 end of the known fields (in the 96 skipped bytes). This new field captures the IMS CPU time in DRA thread TCBs (but not time spent in the control region, as DBCTL cannot capture that CPU time). Originally, IMS 3.1.0 did not provide CPU time for threads because the original design provided for an alternate method called "commit- continue"; late in the release, a decision was made not to support the commit-continue, and nothing was provided in its place. Now, STATCTM1 has been provided to capture the CPU time spent in the DRA thread TCB from the begin of schedule request to the release of the PSB (any SYNC POINT that also says 'TERMINATE TCB'), using existing STIMER and TTIMER cancel code in DRA. STATCTM1='ELAPSED UOR*CPUTIME FOR*THREAD TCB' -This APAR also corrects the value in STATDBIO: IBM code existed to catch the SLOG22/SLOG23 pair (OSAM buffer handler) and count it as one Database I/O, but there was no code to catch the SLOG24/SLOG25 pair (VSAM buffer handler). The DBIO field is also copied into the IMS 07 log record, so now that field will also be valid. -The APAR text also states that the new CPU time, STATCTM1 is added to the IMS log Type 07 record as field DLRTIME, but I need DSECTS to find out where, before I can update TYPEIMS (and there'll be a change for TYPECIMS too!). Thanks to Philip Schwartz, United Parcel Service, USA. Change 09.180 A volume with 1,260,487,800 bytes capacity (tracks times VMACDCOL formatted track capacity) was reported by DCOLLECT as Nov 26, 1991 having a capacity of only 1,260,487,680, a loss of 120 Feb 10, 1992 bytes. The error was thought to be truncation because the variable was stored in 4 bytes, and in Nov, these variables were changed to be stored in 8 bytes: DCDALLSP DCDSCALL DCDUSESP DCVALLOC DCVFRESP DCVLGEXT DCVVLCAP UBDSIZE UMALLSP UMDSIZE UMRECSP UMUSESP Now, the truth is known, and there was no MXG error. The DCOLLECT data field is in kilobytes and not bytes, and thus the values reported by DCOLLECT will be the nearest multiple of 1024 bytes that is smaller than the true value. The extra 120 bytes exist on the volume, but will never be reported by DCOLLECT! Thanks to Terry Duchow, Minnesota Mutual Life, USA.
ASUM70PR datasets were correct if NRPRCS (number of partitions TRND70PR running or defined) was equal to PARTNCPU (number of Nov 25, 1991 physical processors), but PCTLnBY calculations were wrong otherwise, and produced logical busy percentages instead of percent of physical busy that was intended. Now, the calculations use PARTNCPU so the PCTLnBY measures real hardware CPU utilization of your PR/SM or MLPF box. Thanks to Diane Eppestine, Southwestern Bell, USA.
VMAC102 Nov 12. (DB2 2.3 just became available Oct 28!). Fields Nov 25, 1991 were added to IFCIDs 28, 96, 140-142, and 145 (and are now supported by MXG). IBM provided documentation that was good and timely for this change.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|