* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
entire open; however, the Close event actually contains only the counts between the end of the last interval and the Close, so I have changed the INTVCLOS format values from 0:CLOSE TO 0:FINAL INTERVAL. Thanks to Peter Lauper, Bank of America, USA.
VMAC28 STATEMENT EXCEEDED RECORD LENGTH with type 28 subtype D6x Jan 10, 1996 D7x or D9x SMF records. Their fixes are 4030030/4030031 for 4.03 and 4040035 for 4.04. All are reported fixed in their release 4.10, currently in beta testing. I have added traps in MXG to recognize their short records and prevent the ABEND. Thanks to Kevin Batten, Roses Stores, Inc, USA. Change 13.314 Variables MVCRTIME,MVLCTIME and MVUCTIME in EDGSVREC VMACEDGS dataset should have been LENGTH 8 with DATETIME21.2 TYPETMS5 format, and variable DSAUTIME in dataset DSNBRECD should Jan 10, 1996 have been LENGTH 8 with DATETIME18.; now all are! Thanks to Freddie Arie, Lone Star Gas, TEXAS
VMAC92 new flag variable SMF92MFG to TYPE9201 and SMF92UFG to Jan 9, 1996 TYPE9205 to identify the mounter/unmounter of the file system, and new subtype 6 (for File System Remount) will now be output in TYPE9205 dataset (and variable SMF92STP was added to identify Unmount or Remount). Unfortunately, the new flag fields were inserted in the subtype 1 and 5 records, incompatibly altering format. Change 13.312 Support for DFSMS/MVS 1.3 (compatibly) added several new VMAC64 variables for VSAM Record Level Sharing (RLS), including Jan 9, 1996 separate counts of I/O requests satisfied from LSR, DASD, or the CF (Coupling Facility) Cache Structure (variables SMF64BMH,SMF64RIO, and SMF64CFH, respectively), and flag variables to identify if RLS is in effect, if RLS is in effect but measurement has been turned off, or if this is an extended addressable dataset. When VSAM RLS is in use existing Hiperbatch fields and buffer counts are zeroed, and EXCP count variables ACCEXCPS and EXCPs count buffer manager request rather than SSCHs.
EXTY42D1 subtypes for VSAM Record Level Sharing (RLS) activity, EXTY42D2 with excellent measurement of RLS's usage of CF structure EXTY42L1 (counts and durations and response). MXG creates eight EXTY42L2 new datasets from these four new subtypes: EXTY42P1 From new Subtype 15: EXTY42P2 TYPE42S1 - Storage Class Sysplex-wide statistics EXTY42S1 TYPE42S2 - Storage Class By-System statistics EXTY42S2 These two datasets provide six sets of 17 variables: IMAC42 DASD Summary (variables SMF42FCx and SMF42FIx) VMAC42 DASD REDO (variables SMF42FDx and SMF42FJx) Jan 9, 1996 SEQ Summary (variables SMF42FEx and SMF42FKx) SEQ REDO (variables SMF42FFx and SMF42FLx) SEQ READAHEAD (variables SMF42FGx and SMF42FMx) SEQ PREFORMAT (variables SMF42FHx and SMF42FNx) From new Subtype 16: TYPE42D1 - Data Set Sysplex-wide statistics TYPE42D2 - Data Set By-System statistics These two datasets provide six sets of 17 variables: DASD Summary (variables SMF42GCx and SMF42GIx) DASD REDO (variables SMF42GDx and SMF42GJx) SEQ Summary (variables SMF42GEx and SMF42GKx) SEQ REDO (variables SMF42GFx and SMF42GLx) SEQ READAHEAD (variables SMF42GGx and SMF42GMx) SEQ PREFORMAT (variables SMF42GHx and SMF42GNx) From new Subtype 17: TYPE42L1 - Lock Structure Sysplex-wide statistics TYPE42L2 - Lock Structure By-System statistics These two datasets provide 9/10 variables. From new Subtype 18: TYPE42P1 - CF Cache Partition Sysplex-wide statistics TYPE42P2 - CF Cache Partition By-System statistics These two datasets provide 33/34 variables.
VMAC30 -TYPE30OM dataset has new variables SMF30OMS,SMF30OMR, and Jan 9, 1996 SMF30OSY for message queue bytes and sync() functions for Open Edition/MVS. Change 13.309 INPUT STATEMENT EXCEEDED INPUT for PSF type 6 SMF record, VMAC6 because IBM added 32 undocumented bytes to the APA Jan 8, 1996 section. The change was made by APAR OW10067 and PTF UW18264, but the description and location of the change to the type 6 record was not contained in the APAR text! (nor is the change documented in the 5.2.2 SMF manual). Change VMAC6 to read: SMF6PTDV $EBCDIC8. /* ... */ existing @; existing IF SMF6LN4 GT 84 THEN DO; insert INPUT insert SMF6OCNM $EBCDIC20. /*OUTPUT*COM*NAME*/ insert +12 /*RESERVED*/ insert @; insert SKIP=SMFLN4-116; insert IF SKIP GT 0 THEN INPUT +SKIP @; insert END; insert IF SMF6BNOF GT 0 THEN DO; existing This error only occurs if the Multi-Bins header and counter sections exist in the type 6 record. Thanks to Veronique Planes, SAS Institute, FRANCE.
TYPETMS5 dramatic reduction in elapsed time. A fifteen-minute run Jan 8, 1996 ran in under 4 minutes with increased buffers. Thanks to Freddie Arie, Lone Star Gas, TEXAS. Change 13.307 Some very simple HSM reports and a preliminary technical ANALHSM note on how to measure HSM, and what's important in the ADOCHSM HSM SMF records has been added in these members. Jan 7, 1996 Thanks to Chuck Hopf, MBNA, USA.
VMXGSUM still had "XMXGSUM" and "13.01" hardcoded, now corrected, Jan 7, 1996 and the output dataset label was double quotes instead of blank if no dataset label was provided in the outcode. Thanks to Freddie Arie, Lone Star Gas, TEXAS.
VMXGDUR QTRHOUR HALFHOUR and MINUTE were created and dropped Jan 7, 1996 inside VMXGDUR macro, which is called by VMXGSUM when INTERVAL= is specified. If you wanted to keep one of those variable names, the internal DROP statement prevented you from doing so (and it was most definitely not obvious why your VMXGSUM did not work!). Now, the temporary variables names start with DUR to prevent the inadvertent loss. Thanks to Neil Ervin, Huntington Services Company, USA. Change 13.304 Support for BETA93 Release 1.06.50 (INCOMPATIBLE) inserts VMACBETA fields in existing records, and adds five new subtypes Jan 7, 1996 which create five new datasets: BETA20 - Browse or Print of List or Report BETA21 - Browse Selection Action BETA40 - Archive of a List BETA41 - Reload of a List BETA42 - Deletion of an Archive Generation Record Existing variable names were based on the DSECT names, but this caused the same entity (eg., pages or lines) to have a different variable name in each of the existing seven datasets; for consistency and ease in reporting I have renamed some of these variables, knowing full well that my changes may cause your existing reports to fail with VARIABLE NOT FOUND errors, for which I apologize! Labels were also made consistent and more descriptive. The changes have been tested with prior release data, but not yet with records from 1.06.50. See Change 13.322. Change 13.303 New variable MXGVERSN is kept in TYPE70 and PDB.RMFINTRV RMFINTRV datasets so you can tell which version of MXG created the VMAC7072 dataset from SMF. I did not think it necessary to add Jan 6, 1996 the 6-byte version name ('13.13 ') in each MXG dataset. Should you need to create MXGVERSN in other datasets, you can use this logic (as macro variable MXGVERS is a Global macro, set at SAS initialization by VMXGINIT): MXGVERSN=SYMGET('MXGVERS'); and then add MXGVERSN to the _K macro defined in the IMACxxxx member for the product - See Change 10.175. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
EXTUXCPU all datasets have now been tested with data, and formats VMACTUX for rates and percentages are now consistent. However, Jan 6, 1996 there are still unfixed problems that won't be fixed at least until their ML 3.3 release:
TUXPROC (process) have occasional short records (i.e, one or more fields and their delimiters do not exist in the data record!), causing INPUT STATEMENT EXCEEDED LENGTH errors. Landmark Activity 49861 still open.
in the header in TUXNFSCL (nfsclient), TUXSOCK (sockets) and TUXUSERI (userio), causing variables WRITBLOK, READPART, WRITPART, READFAIL, and WRITFAIL to be trashed in those three datasets. Ref. 47164.
and timestamp values are very suspect. I expected one minute interval data to be written each minute, but the one set of TUXINFO (info) records had event timestamps starting at 17 seconds after the minute, drifting to 55 seconds after the minute in only a few minutes: 17,15,26,28,26,26,...26,36,37,39,44,49,55 New test data for the cpu table (TUXCPU) permits better analysis, because both EVENTIME (log_time) and the true HRDWTIME (BOOTTIME plus UPTIME) can be compared. Both clock shows that interval durations are not only not synchronized but also are quite erratic, and each record shows a different interval depending on which clock value you examine! Comparing durations in the same record: from hardware clock: 59,99,151,41,60,126,146,113 from log_time clock: 60,97,116,61,60,122,142,118 Comparing the hardware timestamp with the log_time in the same record shows that the logtime sometimes is only 1-2 seconds later than the hardware timestamp (with a 5-hour difference between GMT in hardware and EST in local), but other intervals have a log_time several minutes later than the hardware time, and a few records are really bad, with the hour-part difference only two instead of five! This is clearly a serious problem, and Landmark is now aware of these discrepancies in their monitor. This text will be updated when Landmark responds. Thanks to Dan Sidorick, SmithKline Beecham, USA.
VMACUCB first bit of DEVNR and set DEVICE='MSS' if on, but this Jan 5, 1996 is incorrect now, as four-digit device numbers exist, and MSS devices do not, so that test is now disabled! Change 13.300 New variable HIGHRBA is now created in TYPE64 with the ANAL4GB allocated size (in bytes) of the VSAM file (using logic VMAC64 from GC26-4574-2 to calculate CI's per track for 3380s Jan 5, 1996 and 3390s). Member ANAL4GB then identifies those VSAM files that are over 80% of the IBM hard limit maximum of 4GB for VSAM files, so you can forewarn their owners! Thanks to Chuck Hopf, MBNA, USA.
IMACHPAI CPU seconds in the HPxxGLOB and HPxxAPPL datasets, but IMACHPSU instead records only the Average CPU time per CPU Engine, IMACHPUX and then does NOT record how many Engines there are, so VMACHPAI so you get correct total CPU time from the data records. VMACHPSU While I regard this as an ERROR, HP considered it only an VMACHPUX enhancement request! The NRCPUS field is in the CONFIG Jan 6, 1996 records, but unfortunatly the HP Extract program is hard- Jan 18, 1996 coded to put the CONFIG records at the end of its output file. HP was persuaded to provide a workaround Script that was to sort the Extract output and interleave the CONFIG records to appear first (and simultaneously, that interleave would have supported dynamic changes in the number of engines, if "VARY CPU OFFLINE" ever becomes a UNIX option!), so MXG logic was reordered to look for the CONFIG records first, and retain NRCPUS into the needed datasets. Unfortunately, the first Script did not work as expected, so HP is back working on the problem as this Newsletter goes to press. As an interim MXG workaround, I have added a user-specified macro in IMACHPAI, IMACHPSU and IMACHPUX which defaults to one CPU, but allows you to tell MXG if you have more than one Engine. That logic will be revised when HP provides a solution to the basic problem, and this text will be revised to point to a later change when there is a solution.
stated in this text in Newsletter TWENTY-NINE, I had just received test data as that newsletter went to print, and now my fears are confirmed: HP made INCOMPATIBLE changes between PCS records and MEASUREWARE records that will require significant changes in MXG support. If you are replacing HP-PCS with MEASUREWARE, please fax me for the status of those changes (and identify the system, HP, AIX or SUN, that you need supported, as each is different!). Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM. Change 13.298 Format MGTANDS now decodes device type =38 (38:2GB) disk FORMATS device, and variables LDEV and CTRL are now input as VMACTAND $CHAR2. with a $OCTAL6. format, so device and control Jan 4, 1996 unit are printed as TANDEM sysprogs expect. This was my first use of the $OCTAL format, and Steve Smith discovered what happens when I underspecified the output width. Forgetting that a two-byte field requires six print positions for its value in octal, I initially assigned $OCTAL4 to a two-byte character variable, but when a two-byte field containing '0056'o (octal), or '002E'x (hex) was input, the value 0000 was printed, because SAS truncates character variables on the right. Steve changed $CHAR2 to PIB2 and $OCTAL4 to OCTAL4, and the correct value 0056 was printed, because SAS truncates numeric variables on the left! Of course, specifying the correct width of $OCTAL6 or OCTAL6 prints 000056 and eliminates the exposure to truncation differences! Thanks to Steve Smith, BGS Systems, USA.
EXVMxxx output statements, and removal of duplicate names in KEEP VMACIDMS lists were made in members VMACAXC, VMACDB2, VMACDCOL, Jan 2, 1996 VMAC28, VMACAIM7, EXDB2PAT, EXTY72GO, VMACTPM, JCLUXRE6. VMACIDMS now includes IMACZDAT (needed only if TYPEIDMS was executed standalone). EXVMxxx members now have their "_LVMxxxx" macro names instead of hard-coded dataset names for VM Accounting. All of these changes were precipitated by Freddie's excellent "MXG SOURCE CODE ANALYZER" program. Thanks to Freddie Arie, Lone Star Gas, TEXAS.
FORMATS was changed by IBM. Previously IBM used the fourth byte VMAC110 of a four-byte field; now they use the first two bytes of Dec 29, 1995 a four-byte field, so the length of TRANTYPE is increased to two bytes, the INPUT for 4.1 records was reordered and the MG110TT format was changed to decode both the old one-byte value and the new one-and-two-byte values! Thanks to ????, Banco Santander, SPAIN. Change 13.295 Support for DFSMS/MVS 1.3 DCOLLECT records COMPATIBLY EXDCODAI added a number of new variables to these datasets: EXDCODCN DCOLDSET,DCOLCLUS,DCOLMIGS,DCOLBKUP,DCOLDC,DCOLSC,DCOLBC IMACDCOL DCOLSC,DCOLVL,DCOLAG,DCOLDR,DCOLLB VMACDCOL and two new datasets are now created: Dec 29, 1995 DCOLCN - Cache Names (Cache Set name and 8-SES Caches) DCOLAI - Accounting Information (audit of definitions of data class, management class, storage class and storage group - who/when updated, which dsname/member) In addition, enhancements to the existing DCOLLECT code for the construct datasets were made. Variables with hex flag values are now INPUT as $CHAR instead of $EBCDIC and are formatted HEX or $HEX, new MGDCOxx formats now decode variables, especially in DCOLMC and DCOLSG datasets, and new multi-valued flag variables were created and decoded. Thanks to Mike Moos, British Rail, ENGLAND, for construct changes.
VMAC64 TYPE64 member was executed by itself. The statement TRNDCICS DEVICE=' '; must be changed to DEVICE=' '; to get Dec 28, 1995 all seven positions of DEVICE type name. Thanks to Chuck Hopf, MBNA, USA.
ASUMCICS PDB.CICS from CICSTRAN) was not applied to ASUMCICS nor TRNDCICS to TRNDCICS, but now both members have been changed. Dec 18, 1995 Thanks to Richard S. Ralston, Whirlpool, USA.
VMAC110 that cause UNEXPECTED STATISTICS RECORDS with STILEN=0, Dec 18, 1995 which caused MXG to fill the //WORK file. While IBM is trying to find their error, MXG has added logic to detect the STILEN=0 condition and prevent the error. To circumvent the error, in member VMAC110, find the INPUT statement that inputs STILEN, STID, and STIVERS, and after the @; that ends that INPUT statement, insert IF STILEN=0 THEN DELETE; which will cause MXG to stop processing that 110 record. Thanks to David Callahan, Caterpiller Inc, USA.
VMAC110 variables ENDTIME, ELAPSTM and IRESPTM are wrong. Change Dec 18, 1995 13.247 (GMT support) was incorrectly typed in VMAC110. The two lines reading: ENDTIME =ENDTIME =MCTMNTAD; must both be changed to: ENDTIME =ENDTIME +MCTMNTAD; (Since ASUMCICS and TRNDCICS use STRTTIME rather than ENDTIME to classify a transaction, the ENDTIME error is noticed only if you look at a specific transaction, but because IRESPTM is used for the response time buckets, those data for your CICS/ESA 4.1 systems is wrong.) ENDTIME is also wrong in dataset CICSEXCE. Thanks to Neil Ervin, Huntington Service Company, USA. ==========MXG 13.08 dated Dec 15, 1995, thru Change 13.290============ Change 13.290 Cleanup of dead members and dead references; Freddie has IMACNPM built a SAS program that reads my SAS programs to find TYPEZRB members-not-referenced, comments-misspelled, etc. This Dec 12, 1995 sweep removed references to VMAC43PC,VMAC47PC,VMAC48PC, and VMAC49PC in member VMACTEST (a private test program), and deleted members IMACNPM and VMACZRB0 (both archaic and no longer needed nor referenced) Thanks to Freddie Arie, Lone Star Gas, TEXAS. Change 13.289 Support for MVS Solutions's Thruput Manager SMF record EXTYTPMF creates two data sets from the single SMF record: EXTYTPMV TYPETPMF - Thruput Manager Job Analysis IMACTPM TYPETPMV - Thruput Manager Variable Fields TYPETPM VMACTPM
Dec 12, 1995 Thanks to Dan Kaberon, Hewitt Associates, USA. Change 13.288 Support for Landmark's TMON for UNIX creates 34 datasets: EXTUXBLO
EXTUXCLI MXG Data INFILE Landmark EXTUXCON Set Name name Table name status EXTUXCUR EXTUXDIS TUXBLOCK TUXBLO blockdevice TESTED EXTUXDSK TUXCLIEN TUXCLI clientdetail TESTED EXTUXFIB TUXCONEC TUXCON connections See Note 1, below EXTUXFIH TUXCURDI TUXCUR currentdir TESTED EXTUXFRE TUXDISK TUXDIS disk TESTED EXTUXINF TUXDSKPR TUXDSK diskprocess TESTED EXTUXINT TUXFILEB TUXFIB filebalance TESTED EXTUXLIM TUXFILEH TUXFIH filehistory TESTED EXTUXMEM TUXFREE TUXFRE freespace TESTED EXTUXNFS TUXINFO TUXINF info TESTED EXTUXNFR TUXINTER TUXINT interface TESTED EXTUXOPN TUXLIMIT TUXLIM limits TESTED EXTUXPRD TUXMEMRY TUXMEM memorymgmt TESTED EXTUXPRC TUXNFSCL TUXNFS nfsclient See Note 2, below EXTUXPRO TUXNFSRV TUXNFR nfsservice TESTED EXTUXPRF TUXOPENF TUXOPN openfiles TESTED EXTUXPRS TUXPRODI TUXPRD processdisk TESTED EXTUXPGM TUXPROC TUXPRC process TESTED EXTUXPCL TUXPROCO TUXPRO processor TESTED EXTUXQUO TUXPROFI TUXPRF processfiles TESTED EXTUXRSP TUXPRODS TUXPRS processdisposition TESTED EXTUXSRV TUXPROG TUXPGM program TESTED EXTUXSOC TUXPROTO TUXPCL protocol TESTED EXTUXSTO TUXQUOTA TUXQUO quotas no test data yet EXTUXSYS TUXRESP TUXRSP response TESTED EXTUXTAB TUXSOCK TUXSRV server See Note 2, below EXTUXTRM TUXSTOR TUXSOC sockets TESTED EXTUXUSR TUXSYSTM TUXSTO storage TESTED EXTUXUSI TUXTABLE TUXSYS system TESTED EXTUXWAI TUXTERM TUXTAB tables TESTED IMACTUX TUXUSER TUXTRM terminal TESTED TYPETUX TUXUSER TUXUSR user TESTED VMACTUX TUXUSERI TUXUSI userio See Note 2, below Dec 12, 1995 TUXWAITS TUXWAI waits TESTED The Landmark EXPORT command that is used to create the data files that are read by MXG has these known errors December. Landmark expects to have a revised EXPORT command module by January to correct these errors: 1) The connections table, MXG data set TUXCONEC, has some data records with fields missing, causing an INPUT STATEMENT EXCEEDED RECORD LENGTH error with that file. 2) The TUXNFSCL (nfsclient) TUXSOCK (server) and TUXUSERI (userio) tables have numbers instead of names for some fields in the header, so those data sets are not yet completely valid until Landmark corrects their data. Member JCLTUX gives an example of the JCL required that will read all 34 files created by TMON for UNIX's export command.
EXVMSQLR VM Account file. The new record INCOMPATIBLY alters the TYPEVM VMSQLUSR record (SQLCPUTM in hundreds of hours), because Dec 12, 1995 it the MXG logic unknowingly output the new record there! This change recognizes the new record and outputs it into new dataset VMSQLRMT instead. Thanks to Norbert Korsche, OMV AG, AUSTRIA.
ANALTAPE WAS NOT DEFINED. Two line reading ALOC3490=TAPE3490;, Dec 12, 1995 must have the comma at the end of the line removed, and twos line reading ALOC3490='3490 ALLOCATIONS WAITING';, must have both the semi-colon and the comma at the end of the line removed. Four lines needed correction. Yüklə 28,67 Mb. Dostları ilə paylaş:
|