* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
new AC9 (146), new Accounting Class ACT4 (151), and a new Statistics Class ST2 (152)! Whew! Summary of this change: many hours to decode many record segments which are unlikely ever to be needed by any rational performance analyst!!!!!!!
FORMATS but blank is a CLIST from an FCB. This is corrected by: VMACTSOM Add '40'X to $MGTSOCD format in FORMATS Dec 7, 1989 Insert after 033700: RETAIN COMNDTYP ' '; Insert after 042200: COMNDTYP='00'X; Delete 042800. Variable COMND may contain an 8-byte name or a 2-byte command abbreviation padded with nulls instead of blanks, which makes testing difficult. The translate function is now used to convert nulls to blanks. In addition, the date part of ENDTIME is wrong if the interval crossed midnight. Correct by insert after line 037000: IF TIMEPART(SMFTIME) LT STRTTIME THEN ENDTIME=ENDTIME-86400; Thanks to Pete Shepard, Ashland Oil, USA. Thanks to Steve Cavill, SAS Institute, AUSTRALIA. Change 07.194 ACF2 variables ACTMFCBT (buffer text) and ACTMFKEY VMACACF2 (record key) were not labeled and not kept, but now they Dec 7, 1989 are. Thanks to Ken Williams, ANZ Bank, AUSTRALIA. Thanks to Raymond Wallace, NRMA, AUSTRALIA.
VMACDB2 the DB2ACCT, DB2STAT0, and DB2STAT1 data sets built from Dec 6, 1989 SMF type 100 and 101 records. IBM changes appear to be compatible. DB2 2.2 added five QX..... variables for the MIAP (Multiple Index Access Path) and Create/Drop Alias, and 21 QLAC.... variables for DDF (Distributed Data Facility) accounting to DB2ACCT. DB2STAT0 was also enhanced with 18 QLST.... variables identical to their QLAC.... counterparts for DDF statistics, and new Q3ST and Q9ST DDF counters. DB2STAT1 was enhanced with the same five QX..... variables for MIAP and QTAUCCH. Note that DDF elapsed and CPU times are captured only in the DB2ACCT data set (and not in DB2STAT0).
QWACBJST and QWACEJST are both non-zero, as IBM now does document that zero value for either field means that no CPU timing was available. An additional IBM note says that QWACEJST is invalid for END OF MEMORY (RINV=24 or 28 decimal), QWACBSRB, QWACESRB, and QWACASRB are invalid for DB Access Agents, but it is not clear how to identify that situation. A final note in the PL/S DSECT says that QWACEJST may be invalid when QWACRINV > 20 while the ASM DSECT says it is invalid for EOM condition. I am still checking with IBM:
2. Is QWACRINV of 24 or 28 only values for EOM which cause EJST to be invalid? 3. How does one know this record is for DB Access Agents? 4. When data is invalid, is it non-zero or zero? 5. What are units of QLACCPUL, QLACCPUR, and QLACDBAT? Change 07.192 Continued validation of STX found the test in line 017500 VMACSTX should test for '02'X, '03'X (instead of '02X' and '03')! Nov 24, 1989 and '12'X and '13'X should have been added, and corrected labels for Application connect timestamps, swlu and lu. Thanks to Larry Doub, RJR, USA.
VMACVMON logic. Remove the ELSE in three lines 272000, 272400 and Nov 24, 1989 272800. Thanks to Bob Small, Grumman Data Systems, USA. ===========Prerelease 7.4 was for special ESP customer support========= ===========Changes thru Change 7.190 comprised Prerelease 7.3========== Change 07.190 The DASDMON interval start date could be the wrong date. ANALDMON The Start date in the record is not the interval start, Nov 24, 1989 but rather the date when DASDMON initiated! The program now uses the SMF record Date to correctly calculate the interval start and end dates. Thanks to Danny High, Blue Cross Blue Shield Texas, USA. Change 07.189 The ASUMCICS trend program uses detail transaction data ASUMCICS to create PDB.CICS with response distributions (pct in 2 ASUMDBDS sec) for reports and input to TRNDCICS. Now the program Nov 24, 1989 will read either data source transparently; you no longer have to remove comment blocks to use Landmark data. The new ASUMDBDS program similarly sums the MONIDBDS detail data into PDB.MONIDBD which matches PDB.CICS. Thanks to Chuck Hopf, Hopf Consulting, USA. Change 07.188 New DB2 Reports were added. I/O Reports (PMIOS01-05), the ANALDB2R Locking Reports (PMLOK01-03), and Record Trace Reports IMACDB2 (PMTRC01-01) are completed. The Correlation Name and VMAC102 Correlation Number are decoded differently for IMS, CICS NOv 25, 1989 and other by the new _DB2CORR macro defined in IMACDB2. However, detection of IMS, CICS, etc. in IMACDB2 can be based only on job name (unless you can find a better test), and you may need to modify those names if you are concerned with CORRNAME and CORRNUM values. New DATASET and PAGESET selection was added for I/O reports. Preparation of the Record Trace report uncovered several obscure type 102 variables that were spelled wrong or left out of the KEEP= list.
A site with 10000 DB2 plans executed per day will need 122 tracks of 3380 DASD for storage of the DB2ACCT data set, and the DB2STAT0/DB2STAT1 data sets will need 8 tracks each (at 15 minute intervals), for a total of only 138 tracks (9 cyl, or only 6 megabytes per day!) Thanks to Chuck Hopf, Hopf Consulting, USA.
XMACSAR GCRMODFT $CHAR1. VMACROSC Nov 24, 1989 Thanks to Dee Ramon, Mutual of America, USA.
VMAC71 VSAM SMF file needed help. Line 066400 in VMAC71 needed a VMACROSC +OFFSMF at the end, and line 114600 in VMACROSC should Nov 24, 1989 have tested for LENGTH > 428+OFFSMF . Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
ANALPATH configuration and activity, using TYPE73, TYPE74, TYPE78 Nov 24, 1989 and TYPE78CF datasets from a PDB. Self-describing. Thanks to Cindy Batson, Hewitt Associates, USA. Thanks to Dan Kaberon, Hewitt Associates, USA.
VMAC110 not protected. Now it is. Nov 24, 1989
VMACVMXA 6.06 testing detected the incorrect syntax, which is now Nov 21, 1989 corrected in line 456800. Thanks to Dan Squillace, SAS Institute Cary, USA. Change 07.182 Change 7.151 fixed IMS, but part of the change was not on TYPEIMS MXG 7.2. The two PROC SORTs (lines 107610 to 107670) were Nov 21, 1989 to have been deleted, but were not. NOT SORTED error. Thanks to Lynn Delacourt, Volvo GM Heavy Truck Corporation, USA. Change 07.181 Change 7.035 discussed potential problems if you tried to IMAC30IO eliminate D3330DRV variable. This change eliminates that IMACPDB variable from the default I/O KEEP= list (in IMAC30IO) BUILDPDB and the MAX/MIN/SUM logic was redesigned (in IMACPDB). BUILDPD3 If you have not modified either IMAC30IO or IMACPDB, this Nov 21, 1989 change is not impacting. HOWEVER, if IMACPDB or IMAC30IO have been changed by your site, YOU MUST retrofit your tailoring, using the new members in this MXG Version. I'm still working on a way to fix this once and for all sites without impact. An additional change was made in IMACPDB that should not be impacting. The NODUP option is now always used in BUILDPDB, and the _NODUP macro is no longer referenced in BUILDPDB/3. (For compatibility, though, the macro is still defined in IMACPDB). Thanks to Elliot Weitzman, Oryx Energy Company, USA.
TYPERMDS while all other counts were PIB4.! Change line 035600 to Nov 21, 1989 PD4. from PIB4. There is no change in the SMF record for RMDS Release 4.0, so we therefore now support RMDS 4.0! (Documentation for the SMF record is in SC30-3442-1, Installing and Customizing RMDS Release 4). Thanks to Sim Fleisher, Depository Trust, USA.
VMACEXC2 variables are created in TYPE30, PDB.STEPS and PDB.JOBS VMACUCB data sets, and variable DEVICE (TYPE1415, TYPE74, etc.) Nov 14, 1989 will recognize 3390. This change is in MXG 7.2. Change 07.178 CICS UOWTIME is now set missing if there actually is not VMAC110 a timestamp in UOWID. This is a further enhancement found Nov 14, 1989 when verifying Change 7.170.
VMAC102 variable names and some re-definitions of the same field Nov 14, 1989 as two variables. 1.QW0021RP $CHAR8. is redefined over QW0021KD thru K2. 2.QW0044RP $CHAR8. is redefined over QW0044KD thru K2. 3.DBID and OBID variables were inconsistent. Most were $CHAR2. formatted $HEX2. but some were PIB2. numerics. Now all are $CHAR2., formatted $HEX4. and labels are consistent. Note this affects the variables suffixed with DB for DBID, but IBM uses PS and OB for PAGESET and RECORD OBID, and also KP for PAGESET. This inconsistency in different names for the same logical entity will not be corrected in the MXG built T102Snnn datasets, but the MXG MENU macro variable names used in reporting will be DATABASE and PAGESET, no matter which IFCID variable name contains the information. Thanks to Chuck Hopf, Hopf Consulting, USA.
VMAC102 even after Change 7.122. The GTF header inserts 12 Nov 14, 1989 bytes before the triplets but the offsets themselves are relative to byte 1. MXG used OFFSMF=12 (set in _GTF) to flag the difference, but failed to use it properly! The logic at lines 085900 thru 08500 now reads: IF OFFSMF=12 THEN DO; INPUT @29 SM102SSI $CHAR4. @; OFFPROD=QWT02PSO-3; END:
ELSE OFFPROD=OFFSMF-3+QWT02PSO; The reset IF OFFSMF=12 THEN OFFSMF=0 after the triplets have been INPUT is still correct. Thanks to Susan Marshall, SAS Institute Europe, GERMANY. Change 07.175 Support for STX Release 1.0+ has been coded and syntax EXSTX... tested (no error first execution with SMF DD DUMMY!) but IMACSTX real data has not been yet processed. TYPESTX Five data sets (STXSTART, STXLOGON, STXLOGOF, STXCONON, VMACSTX and STXCONOF are created. Nov 11, 1989 Thanks to Larry Doub, RJR, USA.
VMACTPX the new format records as well as the prior releases. The Nov 11, 1989 2.0.0 record is incompatible with prior TPX records, and does require MXG 7.3. TPX 2.0.0 writes a wrong value for length field MONO5LEN, (it's x28, but there are x30 bytes in the segment based on MONO6LEN and MONO6ID) that MXG detects and circumvents. New variables were added to the TPXSTART, TPXAPLOF and TPXTRMOF datasets by TPX 2.0.0. Thanks to ???, Swan Hunter Shipbuilders, ENGLAND. Thanks to Larry Doub, RJR, USA for excellent dumps and documentation.
VMXGVTOC a.Change 7.164 was misspelled. The Delete list should have Nov 9, 1989 listed datasets EXTENT EXTENTS in place of EXTEND. b.Line 128 example should be NEW=INFO vice NEW=MAP. c.EQ MXTRACK should be EQ MXTRACK-1 in lines 649, 667. d.LAST=MXTRACK should be LAST=MXTRACK-1 lines 652, 670. e.VOLSER should be added to the KEEP= for INFO line 245. f.Labels added for VTOCINFO new variables NTPC, DEVCYL, DEVTRK, TOTRACKS, FCYL, FTRK, LCYL, and LTRK. Thanks to Phil Henninge, Timken Company, USA. Change 07.172 CA/DISPATCH variables are created in TYPE6 dataset by the VMAC6 enablement of their decoding in MXG member IMACCADI. The Nov 9, 1989 variable CADIRCIP was incorrectly spelled as CADIRCVR in the KEEP= list in member VMAC6, causing CADIRCIP to not exist. A note on this MXG technique. SAS does not validate that variables in a KEEP= list actually exist. If a variable name appears only in the KEEP= list, that variable will not be created. All of the CADI.... variables are in the TYPE6 KEEP= list, but they will not exist in your TYPE6 dataset unless you modify IMACCADI, as all of the code that creates the CADI variables (LABEL, FORMAT, INPUT) is inside a comment block in IMACCADI. Removing that comment block is all that is necessary to cause the variables to be created AND kept. This technique works for KEEP= list, but not for the KEEP statement; SAS does validate the existence of all variables in KEEP statemen Thanks to Carol Arnold, K-Mart Apparel, USA. Change 07.171 CICS UOWTIME changes discussed in 7.170 are all true, but TYPEMONI there was one other error (only in MXG's Landmark code) Nov 6, 1989 that actually precipitated the discoverys in 7.171. Line 060700 (ENDTIME=DHMS(ENDDATE,0,0,ENDTIME); must be moved to new line 014710 (immediately before the line BASETIME=FRSTBASE + FFFFF*(FLOOR(ENDTIME-FRST.... so that ENDTIME is converted into a datetimestamp first, before it is used in the UOWTIME decode algorithm! Thanks to Terry Baker, Royal Insurance, USA.
================printed Changes 7.170 to 7.162========================= Change 07.170 CICS UOWTIME can be between 01JAN60 and 22JUL60, or can TYPEMONI have right date and wrong time, or both may be wrong. VMAC110 IBM stores times in two different non-unique formats: Nov 3, 1989 - a 6-byte STCK value in sixteenths of a microsecond, which wraps every 204 days and which therefore requires logic to decide in which 204-day interval since Jan 1, 1900 this UOWTIME occurred, or - a 6-byte HHMMSS in EBCDIC characters. Unfortunately, there is no sure way to identify which format was used. HHMMSS only applies to DL/I batch originators, but there is not yet an unambiguous test to identify DL/I session. The 6-byte EBCDIC HHMMSS field can contain hex F0F0F0F0F0F0x thru F2F3F5F9F5F9x, all of which are also valid STCK values (on days 192 to 195 on the 204-day clock)! MXG always preserved the value in UOWTIME, but its datetime value was sometimes quite far off. Since NETSNAME and UOWTIME are used to match up the TOR, AOR, and FOR transaction record for an MRO event, and MXGs algorithm did support that merge without error. MXG expected NETSNAME would end with 12 nulls if not from DL/I, but actually NETSNAME
networkid.LUname VTAM ISC LUTYPE6.2 or IRC link newtorkid.generic_applid non-VTAM or ISC LUTYPE6.1 jobname.stepname.procname DL/I batch session and non-nulls caused MXG to fail to add BASETIME (real start datetime of the present 204-day interval) to the 204-day value in UOWTIME. Then adding UOWTIME to the SAS base date of 01JAN60 created the 1960 datetimes! Further, MXG logic tested for a HHMMSS format first; a real STCK value of 15:15:51 on day 192 of the 204-day clock was changed to 00:00:00 HHMMSS!. Until DL/I can be uniquely identified, MXG now always presumes the more likely STCK format. At a specific site with knowledge of specific newtworkid values in NETSNAME, one should be able to recognize DL/I and convert back to HHMMSS, but a generic solution is not obvious at present. UOWTIMEs value itself may not be very important; as long as it is constant across MRO regions, it serves its purpose. In the interim, a quick circumvention happens to be to change IF SUBSTR(NETSNAME,9,12)='0000...00'X THEN to IF 1=1 THEN to always cause the addition of BASETIME to UOWTIME and to thereby bypass the ELSE DO logic testing for HHMMSS or HH.MM.SS values at present. I hope it does turn out that the actual UOWTIME value is useful enough for this! Thanks to Terry Baker, Royal Insurance, USA. Change 07.169 The length of variable CHARACTS needs to be 8 to keep the VMACSYNC full resolution of total bytes sorted (just to make sure Nov 2, 1989 comparisons are exact). With length 4, no significant digits were lost, but low order truncation occurred. Thanks to Glen Farmer, Hallmark Cards, USA.
ANALAUDT
Nov 2, 1989 Thanks to Richard Stevens, US Trust, USA. Change 07.167 This utility which iteratively invokes VMXGVTOC to read VMXGVTOR all online VTOCs used DO variable I in the outer loop but Nov 2, 1989 changes to VMXGVTOC also used I. While VMXGVTOC was the culprit, changing the "DO I=" in VMXGVTOR to "DO IVOR=" was simpler and safer. Thanks to Don Wensel, Philip Morris, USA. Change 07.166 Change 7.098 was correct in its text, but the spelling in MONTHBLD the member should be DDNAME= instead of LIBNAME= in both Nov 2, 1989 PROC DATASETS.
Change 07.165 A comma was lost when re-writing comments in this example EXITMONI JCL to create the TMON infile exit. Line 048500 needed a Oct 30, 1989 comma at its end. Change 07.164 MXG DASD VTOC processing did not clean up the WORK file VMXGVTOC if multiple DASD Volumes are processed. After line 068200 Oct 30, 1989 insert: PROC DATASETS DDNAME=WORK MT=DATA NOLIST; DELETE VTOC1 DSNAMES EXTENT EXTENTS OKEXTENT; MXG's 3090-200 CPU time to read 206 triple density 3380 DASD volumes is about 20 minutes per day. Thanks to Phil Henninge, Timken Company, USA. Change 07.163 TYPE71 variable EXTREADS (Pages Read from ESTORE) is only VMAC71 valid if you have MVS/ESA (RMF 4.1+), but MXG created a Oct 30, 1989 value even with RMF 3.5. Now it will be missing if you are not yet on RMF 4.1+. Thanks to George Scott, Rockwell International Corporation, USA.
FORMATS data library, and must be created/referenced with the Oct 21, 1989 DDNAME of LIBRARY, while SASLIB can still be used for SAS Version 5.18 Format libraries (i.e., MXG.SASLIB). This incompatibliity between SAS Version 5.18 and 6.06 will be disussed in Newsletter SIXTEEN. This change uses the SAS Version under which MXG is executing to decide if MXG Formats are to be created in the LIBRARY (6.06+) or the SASLIB (5.18-) DDNAMES.
========Changes thru 7.161 comprised the pre=release of MXG 7.2========= Change 07.161 This change is documentation of the procedures used in Oct 19, 1989 the final testing of this prerelease of MXG 7.2. It may help you in structuring validation of your own SAS based systems, and will let you see MXG's test plan. This process accomplishes these goals:
all MXG code to build all possible MXG datasets. B. Detection of conflicting definitions of same variable in different MXG datasets (CHAR/NUM type, length and format. C. Detection of known coding errors, such as variables without labels, DATETIME formatted variables with a length other than 8, etc. D. Automatic generation of DOCVER documentation of the contents of all variables in all MXG 7.2 datasets. E. Automatic generation of DOCVER07 delta-documentation of all changes in contents between MXG Verion 6.6 and this prerelease.
CONTENTS to create a SAS dataset of all variables in MXG which is then analyzed for these known conditions: -type conflicts (char and num in different datasets), -missing label for variables, -DATETIME formatted variable not length=8. The SYSOUT is also examined for SAS ERROR: messages and for UNINITIALIZED variable messages and any NOT CATLGD JCL messages are located.
VMACACF2 dataset created from the ACSMFREC='L' ACF2 SMF record. Oct 19, 1989 Thanks to Raymond Wallace, NRMA, Sydney, AUSTRALIA. Change 07.159 DB2 Trace dataset T102S063 contained only the first 200 IMAC102 bytes of the SQL text for each BIND, but the actual size IMAC102A of the SQL text can be more than 200 characters. The SQL IMAC102B text can be useful in understanding why a particular DB2 VMAC102 inquiry consumes large resources (DB2ACCT is used to find Oct 19, 1989 the expensive executions, and their SQL inquiry text in T102S063 is then examined to see why). Now, MXG will create multiple observations in T102S063 for each 200 bytes of SQL text (new variable SEG10263 counts 200-byte segment number). Thanks to Bob Olah, Dun and Bradstreet, USA.
TYPEMONI byte-count on Landmark's own reports defaults to average Oct 18, 1989 number of bytes per screen (PRIOUCHR/TCOUPRCN) but MXG PRIOUCHR variable is total bytes for the transaction and TCOUPRCN is the total number of screen. Landmark reports will match MXG totals if "T" is added after the Landmark field number on their report control statements. Thanks to Tim Follen, Blue Cross of Ohio, USA. Change 07.157 Preliminary support for Sterling Software's DMS/OS DASD TYPEDMS management product's VTOC reading utility. Their utility Oct 17, 1989 will read all VTOCs somewhat faster than MXG's VMXGVTOC utility, and their utility's output is then used by this member to create the DMSLIST dataset, similar to the VTOCLIST dataset creatable by VMXGVTOC. However this member does not create the VTOCMAP nor VTOCINFO datasets created when MXG actually reads VTOCs with VMXGVTOC. Thanks to Chuck Hopf, Hopf Consulting, USA.
ASUMTMNT datasets includes a daily TAPEMNTS dataset and also a Yüklə 28,67 Mb. Dostları ilə paylaş:
|