* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
EXAIMRD existing variables to the KEEP= list or deleting dead EXAIMRB variables from the KEEP= list. EXAIMRR EXAIMRA
Dec 18, 1997 Thanks to Ian Heaney, Toyota Australia, AUSTRALIA. Thanks to D. Ackland, Toyota Australia, AUSTRALIA.
ANALCISH not the maximum, because it was in the SUM= argument. Dec 16, 1997 Move variable name A17DSHSW from the SUM= to MAX=. Thanks to Dale Slaughter, Allied Group Insurance, USA. Change 15.309 RACF record from 1.0.9.2 caused INPUT STATEMENT EXCEEDED VMAC80A record, because 3 bytes were documented in Table 4 for Dec 16, 1997 Event Code 25 (19x), RVARY, but this record contained only two bytes, so the third byte is now conditionally input. Change the INPUT to read: KW25OVIO $CHAR1. /*FLAGS FOR*OTHER*VIOLATIONS*/ @; IF RACFDLN GE 3 THEN INPUT /* UNDOC RACFDLN=1 FOUND */ KW25ADSP $CHAR1. /*OTHER*KEYWORDS*SPECIFIED*/ Thanks to Len Rugen, University of Missouri-Columbia, USA. Change 15.308 I changed the CICSEXCE exception dataset when CICS/ESA IMACCICS was introduced, but I can't find where I really discussed Dec 16, 1997 the changes to variables. Non-ESA CICS (2.1 & earlier) had specific variables for each exception, and those only the variables specific to an exception were non-missing in a particular observation. But these specific vars are always missing with CICS/ESA or CICS/TS: ISAMFILE MSREQWT MSWAITCN MSWAITTM PGMCMPTM PGMCMPCN SCWTECN SCWTETM TSREQWT TSWAITTM TSWAITCN VSAMBUFF VSAMFILE VSWAITTM VSWAITCN because CICS/ESA has one set of variables and their values describe the exception event and durations: EXWAITTM - Duration of the exception wait. EXCMNRTY - Exception Resource Type: STORAGE FILE TEMPSTOR EXCMNRID - Exception Resource Identification: UDSA GLLCLAS FDED EXCMNTYP - Exception Type (format MG110EX.): 'X01:WAIT (EXCMNWT)' 'X02:BUFFER WAIT (EXCMNBWT)' 'X03:STRING WAIT (EXCMNSWT)' Exception Exception Resource Resource Exception Type Type Identication EXCMNTYP EXCMNRTY EXCMNRID
'X02:BUFFER WAIT (EXCMNBWT)' FILE B0INDEX 'X03:STRING WAIT (EXCMNSWT)' TEMPSTOR FDED This allows for new exception events to be created by IBM with no need to create new variables for each exception. Thanks to Dale Slaughter, AMCO Insurance, USA. Change 15.307 ASUMUOW could produce missing value for MROTRAN count, as ASUMUOW "spun" observations were not properly reintroduced in the Dec 16, 1997 next run. Logic involving several lines was revised. Thanks to Larry Nova, First Card, USA. Change 15.306 CONTROL-T variables DSUSECT and DSEXCP in CTLTDSN dataset VMACCTLT were wrong; there are three undocumented bytes before the Dec 14, 1997 DSUSECT field. Add +3 after INPUT before DSUSECT: INPUT +3 DSUSECT &PIB.4. .... Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
TYPEDPPX creates eleven datasets in this user contribution, by Dec 14, 1997 reading and decoding the report output as MXG input. DPPX/370 (Distributed PRocessing Programming Executive) runs on ES/9000 series and was written by IBM, originally for 8100, then 9370, and then 9221. Release 4 is the last release and goes out of service in 1998/1999. Thanks to Mark Robbins, W.H. Smith LTD, ENGLAND. Change 15.304 Using 14/15 records to determine the size of datasets ADOC1415 is not straightforward. Descriptions in ADOC1415 have Dec 14, 1997 been revised based on Richard's discoveries:
data to analyze our tape use and develop a model for sizing a VTS subsystem we are considering. In the course of this, I found myself looking at BLKSIZE, BLKCOUNT, TRKSALOC, and TRKREL to develop a size in megabytes for these files. Multi-volume files, both tape and disk, presented a challenge to correctly accumulate the multiple type 15 records generated into a single record representing the creation of the entire file.
This bit is ON for records written for a change-in-volume (written by "End-of-Volume", LASTVOFL=' ' if ON), and this bit is OFF for records written by close (LASTVOFL='Y' if OFF). When ON (EOV), this is normally a volume switch within a multi-vol dataset. Rick thinks this may also occur for file 1 through n-1 for a sequence of n datasets concatenated on a single DDname, but has not seen that in his data, and he has not prove whether or not this bit would be on for the first of two files concatenated together, which happened to reside on the same volume. If you can confirm/deny his thesis, I will update this note.
This is the number of tracks allocated *on the current volume* to this dataset. This must be accumulated across multiple TYPE15s when RECIND1, bit 1 is on. TRKREL This is the number of tracks released at close. In the case of RECIND1, bit 1, this will be zero for all but the last record. Note however, that this last record does *not* have the EOV bit on. BLKSIZE No surprise here. Same for all related records. BLKCNT Again, these represent the block count written on the current volume only. Must be accumulated to get accurate file size.
Because of the fact that the last record for a given step/DD does *not* have the EOV bit on, this flag is really not useful to group records to accumulate. I finally arrived at the following PROC SUMMARY to accomplish the task:
BY JOB OPENTIME DSNAME SMFTIME; /*ELIMINATE DUPLICATE RECORDS (MULTI-VOL INTERMEDIATE EOV)*/ PROC SUMMARY DATA=TYPE1415 NWAY; BY JOB OPENTIME DSNAME; VAR SMFTIME BLKCNT TRKSALOC TRKREL; ID AVGBLK ID DEVICE BLKSIZE ; OUTPUT OUT=SUM1415 MAX(SMFTIME)= SUM(BLKCNT TRKSALOC TRKREL)=; DATA SUM1415; SET SUM1415; IF AVGBLK NE 0 THEN MBUSED = AVGBLK * BLKCNT; ELSE MBUSED = BLKSIZE * BLKCNT; FORMAT MBUSED MGBYTES.;
Thanks to Richard T. Green, Comerica Incorporated, USA. Change 15.303 Revised text, 14May2003: MXG's default _M204VER value in VMACM204 member VMACM204 (4.1, since 1997) is also valid for 5.xt Dec 14, 1997 Release, as there were no changes to their SMF records. May 14, 2003 Original Change text, slightly revised. Support for MODEL204 Version 4.1 or later added two bytes at the end of the header. Version-based logic was added to skip over the bytes, and MXG updated VMACM204 so that the default is now 4.1. Also, a number of variables added by Version 3.2 were added to the KEEP= list for the M24SINCE dataset. The new version is INCOMPATIBLE due to the insertions in the record. Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA. Thanks to Carole J. Storby, Lockheed Martin, USA.
ASMVVDS storage, because it FREEMAINed less than it GOTMAINed.! Dec 14, 1997 Not only was that corrected,, but also optional supports UCBs above the 16M line, and now executes in AMODE 31. Additional cleanup of this old programs for sites that need detail VVDS info (or don't have DCOLLECT). Thanks to Skip Abadie, MBNA, USA.
ASUMTALO wrong, because spun records ("inflight allocations") were Dec 14, 1997 kept after output and were counted by the summary logic! This caused MAXDRVS to be greater than installed devices. Fortunately, the effect was only for the beginning and ending interval of the analysis, so the effect should have been minimal on your analysis. -After IF ALOCEND GT &LOWTIME THEN OUTPUT SPIN.SPINTALO; insert ELSE DO; and then after fourteen lines, insert END; before the PROC SORT DATA=TALOSUM1....; This corrects the basic error in logic. -Additionally, LASTTIME was used as a temporary variable, but was not dropped, and then used in adjusting for clock synchronization. Now it's DROPped: After RETAIN HOLDEND LASTTIME 0; insert DROP LASTTIME; -In addition, the PROC PRINT DATA=TALOSUM1, WHERE, and VAR statements left for debugging were deleted. Thanks to Anthony P. Lobley, EDS, ENGLAND.
EXTYSARX SMF record creates new dataset SARSRQUX. IMACSARX TYPESARX
VMACSARX Dec 14, 1997 Thanks to Tim Haiar, Citicorp, USA.
VMAC7072 partitions that were deactivated (LPARCPUS=0), and some Dec 13, 1997 sites have needed an observation for that LPARNAME for configuration reports. Replace DO J=1 TO LPARCPUS; with IF LPARCPUS=0 THEN DO; %%INCLUDE SOURCLIB(EXTY70PR);END; ELSE DO J=1 TO LPARCPUS; If you do NOT want observations for deactived partitions, you could delete the obs with LPARCPUS=0 in EXTY70PR! Thanks to Harmuth Beckmann, Karstadt AG, GERMANY Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Change 15.298 ERROR: VARIABLE TERMINAL NOT FOUND in these sample CICS ANALCICS reports occurs when _LCICTRN sends CICSTRAN to //WORK Dec 13, 1997 instead of to the //CICSTRAN DD, because the report code used OUT=CICSTRAN for the first PROC SORT with a KEEP= statement, so a later reference to _LCICTRN got the OUT= dataset instead of the original CICSTRAN data. Change CICSTRAN to SORTTRAN (four places) to correct this error. I also added KEEP= logic to each input of _LCICTRN to reduce input data read, but the reports will be re-done using ANALCNCR to much more expeditiously count the CICS concurrent users. Thanks to Doug Jungels, Fingerhut Corporation, USA. Thanks to James Lieser, Fingerhut Corporation, USA.
ANALRMFR TYPE72 and TYPE72GO datasets, but were multiplied by 100 TRND72GO in ANALRMFR reports where they matched IBM report values. VMAC7072 But I now realize they should be 0 to 100 in both the IBM Dec 13, 1997 report and the MXG datasets, so their values are changed. -In VMAC7072, four lines VELOCITY=... are VELOCITY=100*... and ELSE VELOCIOD= is now ELSE VELOCIOD=100* and PERFINDX=R723CVAL/VELOCITY; has its 100* removed. -In ANALRMFR, the VELOCITY=100*VELOCITY; was removed. -In TRND72GO, 100* was added to VELOCITY= and the 100* was removed in the denominator of PERFINDX= calculation. Thanks to Ken Williams, Southern Electric, ENGLAND. Change 15.296 Support for Omegamon for VTAM V400 (COMPATIBLE, but new EXOMVX2L subtypes and exceptions will print "invalid" messages on EXOMVX2M the SAS log). Three new subtypes create datasets: EXOMVX2V Subtype Dataset Description IMACOMVT 15 OMVTX2MC X.25 MCH Link VMACOMVT 16 OMVTX2VC X.25 VC Dec 4, 1997 17 OMVTX2LU X.25 LU There are also nineteen new exceptions, 0939-0957 that are now decoded. Thanks to Joseph E. Darvish, Farmers Insurance Group, USA. Change 15.295 The ACCOUNTn variables in DB2ACCT did not decode skipped VMACDB2 fields correctly. DB2 replaces the comma delimiters in Dec 3, 1997 the job card with 'FF'x, and (TOMP,9999,XXX,,,ACCT6) had variable ACCOUNTn = 'FFFF'xACCT6. Each of the nine DO groups in VMACDB2 that read: IF LOC LE 1 THEN DO;LENACCTn=ACCTLEFT;ACCTLEFT=0;END; were replaced with IF LOC EQ 1 THEN DO;LENACCTn=0;ACCTLEFT=ACCTLEFT-1;END; ELSE IF LOC LT 1 THEN DO; LENACCTn=ACCTLEFT;ACCTLEFT=0; END;
to properly parse the 'FF'x delimiter. Thanks to Tom Parker, CSC Financial Services Group, USA. Change 15.294 Change 15.054 intended to have four blanks after SYSTEM TYPETMON and SYSID, but ended up with five, so SYSID became length Dec 3, 1997 five instead of four. Thanks to Jim Wertenberger, Medical Mutual of Ohio, USA. Change 15.293 SAS Option YEARCUTOFF=1960 is MXG's default specification CONFIG in member CONFIG, as this makes MXG more robust in its YEAR2000 attempt to protect non-Y2K-compliant dates. In MXG 15.05 YEAR2000 I added code to protect records written in 2000 that do Dec 3, 1997 not have the "century value" in julian dates, or still have only 2 year digits in YYMMDD-type date fields. I thought I could protect non-Y2K-compliant fields after the input of the date, by detecting that the year was pre-1960, and then I could add the number of days between 1900 and 2000 to move the non-Y2K date into the second millennium.
the field has been INPUT, because some date values will be missing after INPUT, because some dates that are valid in 2000 were invalid in 1900: non-Y2K value Informat Y2K date 000229 YYMMDD6. 29FEB2000 '000000000000366F'x SMFSTAMP8. 31DEC2000
day in 1900, and the SMFSTAMP8 is in error because there were only 365 days in the year 1900.
default YEARCUTOFF=1900 to YEARCUTOFF=1960, because then SAS will accept 000229 as Feb 29, 2000; this will also eliminate the need for the MXG protection logic. I had been reluctant to base MXG's support of the year 2000 on any SAS option, believing I could provide safer protection that would function independent of the SAS YEARCUTOFF option's value. However, it now appears that the best choice is to make YEARCUTOFF=1960 the value set in MXG's CONFIG member, and that was done. The SMFSTAMP8 error cannot be eliminated because the YEARCUTOFF option does not apply to those julian date informats, and making it apply is likely to cause more exposure to error than it is worth. However, SAS Institute will consider enhancing the SMFSTAMP, RMFSTAMP, etc., formats to provide this functionality internally, and it may be available (in a future TS-level maintenance release). Fortunately, the logic added by Change 15.167 (that will be removed) has no impact on present dates and thus causes no errors until after 1999. These notes are just for the record: Change 15.167 used 36524 as the constant number of days between 1900 and 2000 for YEARSECS, but it turns out that the number of days to add is not a constant: For dates in 2000: 01JAN1900 + 36524 = 01JAN2000 01MAR1900 + 36524 = 29FEB2000 That '29FEB2000' might look wrong, but the 60th julian date of 1900 was 01MAR1900, and the 60th julian date of 2000 is 29FEB2000, so it is ok! For dates in 2001 01JAN1901 + 36524 = 31DEC2000 which is definitely wrong; a value of 36525 should have been used for years after 2000! Thanks to Nico Lenaerts, SAS Institute, BELGIUM. Thanks to Michel Laublin, GIB, BELGIUM.
ADOCMWUX statements GBL_BYDISK_ID_LIST and GBL_BYLAN_ID_LIST that Dec 1, 1997 caused "unknown metrics" error; the statements should not have been in the example and were deleted. Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM.
ASMTAPES comments in the member said it was ML-15, in fact it was Dec 1, 1997 still ML-14 with only comments changed, and when Started it said it was ML 14! The wrong member was copied into 15.06 and then its comments were edited. This change really is the ML-15 that was promised, and when it is Started it actually says that it is ML-15! Thanks to Glenn Harper, Memorial HealthCare System, USA. Thanks to Mark Smith, First Card, USA.
ADOCNTSM datasets RASPORT (CONNTOTL did not belong in list), Dec 1, 1997 NETWINTR (INTRNAME was not listed), IMAGE (IMAGFILE and IMAGNAME are CHAR 32), and IP (DEVNAM did not belong). Thanks to Bob Gauthier, American Stores Company, USA.
VMAC80A until multiple segments are actually found in RACF data, Dec 1, 1997 and then the (usually unimportant) EV44xxxx variables are added to the KEEP= list for that event. This change adds six sets of EV44xxxx variables for RACFEVNT=13 (six were previously kept for RACFEVNT=10), and clarifies the text of the message printed when new segments are found. All of this, just to save a little disk space! Thanks to Gerald Lawrence, ABN AMRO Bank NV, THE NETHERLANDS.
VMAC16 were too long, causing warning on SAS log but no error. Nov 26, 1997 Thanks to Freddie Arie, Lone Star Gas, USA. ======Changes thru 15.287 were in MXG 15.06 dated Nov 24, 1997====== Change 15.287 Local and Remote IP addresses are now decoded into their VMACCTCP dec.dec.dec.dec format in Clever TCP/IP's SMF record, and Nov 24, 1997 are changed from numeric to character variables.
VMAC30 do not go thru full function startup (examples of JOBs Nov 24, 1997 that create observations in TYPE30_6 are RASP,ALLOCAS, IEFSCHAS,CONSOLE,SMXC,GRS,SYSBMAS,TRACE,PCAUTH,OMVSSTFS), but the interval start times (SMF30ISS,SMF30IST) from which GMT offset is calculated are missing, so SYNCTIME in TYPE30_6 was always on the GMT clock. This change uses a heuristic comparison of SMFTIME and SYNCTIME to correct the hour-part of SYNCTIME if there is a difference (inserted before the %INCLUDE of EXTY30U6): SYNCTIME=SYNCTIME+3600*FLOOR((SMFTIME-SYNCTIME+1800)/3600); but having the real GMT offset in the record would have been better! Thanks to Harmuth Beckmann, Karstadt AG, GERMANY Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
ASMTAPES Monitor has two enhancements: Nov 20, 1997 -Dump suppression. When MXGTMNT intercepts internal ABENDS (usually do to a logically address space changing states, often 0C4 or 0E0 ABENDS), now the SVC dump will be suppressed, unless you enable the 'DEBUG=YES' option, which will cause an SVC dump to be taken. However, a logrec record will be created for all ABENDs, so it will be possible to get some information if required. -Step start date (INITTIME) year 2000 support relocated the date from the ASID's JCT to the JCT Extension in OS/390 Release 1.3 and above. If you are at OS/390 R1.3 or higher, you will need to change the default of 'ES5' to 'ES6' when you assemble ASMTAPES to pick up the step start date from the JCT Extension.
VMACEREP but flag bits indicate that the record was truncated, so Nov 20, 1997 those bits are now tested before the INPUT statement so the STOPOVER abend is eliminated. Change 15.283 Additional CICS DFHSTUP "Shutdown" reports have been ANALCISH added/revised in this iteration: Nov 20, 1997 -CICSMDSA, CICSMS, and CICSMT "Storage Manager Statistics were updated. -CICDS uses CICS release SMFPSRVR for decision logic. -CICAUSS adds new CICS 4.1 fields to detail/summarys. -CICFCR "Files" report is complete. Thanks to Steve Colio, CIGNA, USA. Change 15.282 Variables BYTEREAD and BYTEWRIT in TYPE21 (which is VMAC21 renamed to PDB.TAPES) are now formatted MGBYTES. Nov 19, 1997 Thanks to Chuck Hopf, MBNA, USA. Change 15.281 Support for Landmark's The Monitor for CICS/ESA 2.0, a ANALMONI completely INCOMPATIBLE reformatting of their records. EXMONARQ You must now use program TYPETMO2 instead of TYPETMON to EXMONAWT process the new records, but the MONITASK dataset that EXMONCMX MXG creates should be compatible as only a few old EXMONDBD variables were removed by LANDMARK, although there are EXMONDSA many new ones. EXMONDSP Landmark notes that the TD,TF,TM,TP,TS,TT,T2 and TX data EXMONEXP is based on CICS statistics, while the TR record is part EXMONIDS based on CICS stats and part based on data collected by EXMONIRQ TMON; the TR record contains much of the non-volatile EXMONIWT data previously written in the TI record. The MONISYST EXMONMRO dataset may also be compatible, but some variables may EXMONSYS have moved to the TR-record datasets, and some variables EXMONT2 may be spelled differently if I did not recognize them! EXMONT2E
EXMONTSK The meaning of the TI interval data has been changed. EXMONTDQ Previously, data was posted to the interval as it was EXMONTFI collected, leading to a highly accurate picture of the EXMONTMC activity during that interval, but increasing the EXMONTP collection overhead. Instead, in Version 2.0, the TI EXMONTPD data is collected by rolling up the TA (Transaction End) EXMONTPG event records into the interval in which they ended, so EXMONTR the accuracy of each interval is lost! Landmark claims EXMONTS "over time this results in the same statistics, but the EXMONTSQ distribution across intervals may be different. In a busy EXMONTTR CICS region the difference will be very small. In a EXMONTX small test region discrepancies may be more noticeable". EXMONTXN I seriously question the utility of interval data that EXMONUSR does not represent the interval. It is not the EXMONUTG busyness of the region but the long-running EXMONXMC transactions that end from time-to-time that corrupt IMACTMO2 their interval data, so all of the datasets created TYPETMO2 from the TI record may be inaccurate. VMACTMO2 Nov 19, 1997 Thirty MXG datasets are created from the new records: Record Description TA - Transaction Performance Record TD - Transient Data Interval Record TF - File Interval TI - Transaction Activity Interval Record TM - MRO/ISC Interval Record TP - Program Interval Record TR - Region Interval Record TS - Temporary Storage Interval Record TT - Terminal Interval Record TX - Transaction Interval Record T2 - DB2 Interval for CICS Record Yüklə 28,67 Mb. Dostları ilə paylaş:
|