* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Cullinet apparently has PTFs now to fix their broken records. There may still be sequence problems with their PTFs, but MXG will reconstruct the real logical record even when the segments arrive out of order! (Segmenting is necessary because their journal record size maximum is 256 bytes, but the total SMF data is 500-600 bytes.) Make sure you have installed the January, 1988, Cullinet maintenance tape to avoid any problems, and validate! d.An MXG error in IHDRTYPE=10 subtraction was also fixed. Thanks to Bob Rutledge, Sherwin Williams Paint, USA. Thanks to Gayle Bartel, Pizza Hut, USA. Thanks to Rodney L. Reisch, General Electric Silicon Division, USA. Change 06.004 TYPERTEJ processes IDMS Performance data from a Journal Jan 12, 1988 File (TYPERTE reads the same data from SMF). TYPERTEJ was TYPERTEJ off by two bytes, and did not format/length SMFTIME. Change line 17 from +2 to +4 temporarily fixes the error; several additional cleanups were also added. Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Jan 11, 1988 should be exchanged (lines 1511-1512). VMAC110 b. CICS 1.7 increased OPERATOR from 3 to 4 bytes and SIT from 2 to 4 bytes. MXG correctly read in these variables, but their stored length is set by its first occurrence (in 1.6 code!) To correct, insert after line 244 : INFORMAT OPERATOR SIT $CHAR4.; Thanks to Mark Bercov, Canadian Occidental Petroleum, CANADA. Thanks to Richard Evans, Mervyn's, USA.
Jan 7, 1988 transaction ABEND. The corrupted records confuse the MXG TYPEMONI test for compressed record format (which formerly issued a SAS ABORT ABEND 99, to terminate the job). With this change, neither bad records nor compressed data without the EXITMONI will cause an ABORT. The first twenty bad records will be hex printed on the SAS log, but the job will proceed to read all other records in the input file. Thanks to John Leath, Fleet Services, USA.
Jan 7, 1988 data sets. MXG used DSBUSY (SMF75USE) in this calculation VMAC75 but NRSAMREQ (SMF75REQ) must be used because swap data XMAC75 sets use multiple IORBs. The IBM description (SMF manual, SMF75REQ) and RMF footnote for the equation for AVGSWPMS, (which allude only to multiple exposure devices) will be revised to include swap data sets as well. While only the swap service time was in error, this change protects the future by also using NRSAMREQ in AVGPAGMS calculation.
LASTCHANGE: Version 6 =========================member=CHANGE05================================ /* COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS */ This is MXG Version 5.5, the production release of MXG Version 5. MXG Software Status as of December 17, 1987, thru Change 5.173. What's new in Version 5. 1. MVS 2.2 support. - New type 36 ICF Export/Import SMF record. - New type 41 Data-In-Virtual SMF record. - Changes in existing SMF/RMF records. 2. VM/SP Release 5 support. 3. SAR Accounting record support. 4. SAR Type 6 record support. 5. DASD storage measurement system (dynamically read all VTOCs). 6. IDMS 10.1 Performance Monitor record (new data sets) support. 7. ACF2 user SMF record support. 8. DB2PM validation and reports. 9. IMS log processing re-designed and supported for IMS 2.1. 10. STOPX37 user SMF record support. 11. RMF Cache Reporter validation and enhancement. 12. CICS 1.7 cleanups, enhancements, and more decoding. 13. DFSORT Release 9 support. 14. VM/Monitor summarization. 15. Vector Processor measurement. 16. TYPE64X data set for VSAM extents. 17. SYSLOG JES3 processing and JES2 SYSLOG example. 18. EDP Auditor Reports from RACF type 80 data. 19. Eight CPU engine (3090-800?) C.E.C. Support. 20. Online Business Systems WYLBUR Accounting SMF record support. 21. TSO/MON Version 5.1 support. 22. Extended Storage measurement enhanced. 23. 3480 tape drive error counting in TYPE21 added. 24. Separate counts of 3420 and 3480 tape drives in type 30 and PDB. 25. VSAM VVR Type 60 record decoded. 26. NETVIEW modifications to NLDM record supported. 27. RMDS support. 28. SYNCSORT user SMF record support. 29. CINCOM SUPRA log record support. 30. VM Account LOGOFF record support. 31. ROSCOE 5.5 SMF Account record support. 32. IMF 2.3 support for DDNAME level I/O counting. 33. NETSPY support. 34. OMEGAMON EPILOG 1000 support. 35. Externalized BUILDPDB macro definitions in IMACPDB. 36. HOGAN FPS transaction function code data support. 37. CICS 1.7 EXCLUDE option "support". 38. IDMS Performance monitor from IDMS journal file supported. 39. Landmark's SPECIAL 78 zap (adds CICS 1.7 MRO fields) support. 40. Naming conventions established for MXG's use of "New style" macros. 41. Elimination of excess tape mounts for monthly and weekly jobs. What did not get completed in MXG Version 5.5: 1. VM HPO Release 5 has not been tested. IBM documentation indicates no change in the data, but no user has confirmed this to be true. 2. BUILDPDB enhancements (which will use the new macro facility) to more easily control variable selection (eg, XA only, etc.) were not completed. IMACPDB externalized the controls for you to give you control without the additional complications and naming conventions needed when we actually do this enhancement. It is still planned. 3. The MVS Tape Mount Monitor code is not yet operational. The ASM source code (ASMONTAP) is on this library, but needs modifications. One volunteer will examine the code next spring. 4. TYPE64 data (see technical note, below) has not yet been added to ANALDSET algorithms to resolve the incorrect type 64 counts. 5. IMS log processing puts waiting for input transactions in IMSMSGOT
likely require changes to MXG software. IBM dates given below are the availabilty date in the IBM announcement. We always hope to provide MXG support by availability date, if we can get both documentation and test data in time. We will likely repeat the strategy of the past two years: a spring newsletter to announce when the pre-release of the next MXG version is available, and a production MXG version shipped to all customers in the fall. a. March, 1988. Expected availability of VM/XA SP1, with a complete new set of monitor records, new format, and zero compatibility with current VM/SP VM/Monitor data. IBM says there will be no VM MAP for this new VM/XA monitor, but MXG will be there. b. May, 1988. PTF to MVS 2.2 which adds VIO activity fields to TYPE71 data (this PTF permits VIO to be directed to Extended Storatge). c. Unknown. PTF to add JOB and READTIME which IBM left out of the new MVS 2.2 Type 41 (Data In Virtual) SMF record. d. December, 1988. Expected availability of VM/SP Release 6, with many new data elements added to existing VM/SP VM/Monitor. This release includes the new VM Shared File System, which creates new data.
the FACOM OSIV/F4 MSP operating system. f. Unknown. Other rumored impacting events may be CICS 2.1, a new DB2 release, and DOS/VSE Power record changes. The 5.1 tape was tested for forty days and nites at forty sites. The 5.2 tape has been executing at over 75 sites since August. All problems reported were fixed in the 5.3 tape, sent to an additionaly 30 sites. The 5.4 tape was the final pre-release before production, ans was sent to an additional 30 sites. As promised in Newsletter TEN (June, 1987), MXG Version 5 production was built before the end of Fall, 1987 (which ends December 21, 1987). Merry Christmas!!!
The changes described in this member are already in this MXG version. They are listed below, after the technical notes. You must read each description of all changes to ensure that you understand their impact on your installation. Changes thru 5.99 were on the 5.1 pre-release, the 5.2 pre-release include changes thru 5.125, 5.3 was thru 5.143, and changes through 5.165. Changes 5.1 through 5.74 were printed in Newsletter TEN, and changes 5.75 through 5.166 were printed in the Newsletter ELEVEN. Changes 5.167 through 5.173 were added after the newsletter went to press. COMPATIBILITY EXPOSURES:
new member IMACRMFI, instead of being defined inline. 2. VM/Monitor users must read Change 5.133. The meaning of VMONDEV data set variable CNTVIOCT was altered. A new macro, _INTRVL, is defined in IMACVMON which must be changed if the interval between VM/Monitor records is not the one minute default set by MXG. 3. BUILDPDB/3 users who have modified those members will find IMACPDB now contains (hopefully) all the definitions to allow you to locate your tailoring external (in IMACPDB) instead of internally.
Note: The PTF or APAR numbers were provided by some system programmer who has actually installed this fix, but sometimes the number will no longer be valid; IBM supercedes and replaces PTFs, and one APAR often has several PTFs for the same logical problem. Use this information only to search INFO/MVS for more information and exact status. HOT PTFs: MVS:
outstanding constraint that the SMF interval (for type 30s and 32s) had to be greater than JWT. These PTFs apparently are already in MVS 2.2, and the documentation still recommends that the Interval duration be greater than JWT, but experimental system programers have reported that that recommendation is no longer a requirement. Don't take my word on this, but I think it's probably true.
BLKSIZE of the SMF data. Requested through SHARE in the CME project in 1973, it has finally been acknowledged in APAR OY07209 and implemented in PTF UY12002. MVS 2.1.3 and 2.1.7 do not write type 7 records when SMF recording is lost! Fix is PTF UY12608. For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of performance problems if you do not install OY01085. Your CE should have caught this one for you. MXG NL TEN misprinted this PTF number.
PTF UZ46460 and UZ48888-UZ48891. Critical, must be installed ASAP. Incorrect SMF EXCP data, especially 30s, introduced by bad UZ45011, fixed with UZ47837 (pre-reqs UZ47834-UZ47837 and UZ50314-UZ50316). Noted loss of VSAM counts in type 30, was fixed by UZ47837.
DFP Versions 1.1.1, 1.1.2, or 2.1 if you have installed the PTFs for APAR OZ96798, and you have NOT corrected the PTF-in-error condition described by APAR OY02500. The SMF data loss condition is cause by a problem in VSAM introduced by OZ96798 PTFs. Message IEE978E: SMF NOW HAS nnnnn BUFFERS will be issued after the initial number of SMF buffers are used up, but there is no other external indication that all SMF records have been permanently lost. Incorrect counting of some tape mounts in type 30 records. After the installation of UZ50959, tape mounts issued with message IEC501E (Look ahead mount message) are not counted. Mounts with messages IEC501A or IEC233A continue to be correctly counted. APAR OZ97886 describes the problem, accepted by APAR OZ97617 which has the fix. The problem primarily affected multiple volume mounts; only the first volume mount was counted in the type 30. HOT PTFs: VM: Concatenated MACLIBs on different mini-disks will fail; only the first MACLIB in the concatenation will be searched until PTF VM24283 is installed. As long as the MACLIBs are on the same mini-disk, there is no problem with concatenation (as suggested for the MXG SOURCLIB and USERID SOURCLIB libraries). Technical Notes, MVS: a. Counting allocated tape drives. The following is a revision of a note originally in MXG Newsletter TEN: Counting of tape drives (TYPE30_4 or PDB.STEPS variables TAPEDRVS, TAPE3420 and/or TAPE3480) is affected if the job step dynamically allocates tape drives. For example, DB2MSTR dynamically allocates a drive every time the recovery data is backed up. If each allocation happens to get a different tape drive, the step record for DB2MSTR would contain a different DEVNR (old UCB address) for each tape, which MXG would count as a large number of tape drives. Only a few jobs actually use dynamic allocation (thank goodness), but they tend to be long running DBMS, which wreak havoc on the number of tape drives perceived by ANALTAPE to be in use. You must use the type 40 (Dynamic Allocation) record to find those jobs that dynamically allocate tape drives, and exclude their step records before processing STEPS with the MXG ANALTAPE program. Otherwise, it will appear the job step had all those tapes for the entire time the step executed. You can use the MXG Exit Facility to add type 40 processing, and in the exit (EXTY40) and use: IF DEVICE='3420' or DEVICE='3480' THEN OUTPUT TYPE40; to only create observations for tape devices. VMAC40 reads in a 40 and calls VMACEXC1, which decodes DEVCLASS, DEVTYPE, and DEVNR for each UCB segment. VMACEXC1 then calls VMACUCB to decode DEVCLASS and DEVTYPE (hex) into DEVICE (char); the value '3420' or '3480' is set for tape devices. Since SMF offers no option to create type 40's just for tape, you still have to create all type 40 records, but this use of the EXTY40 exit allows you to keep only tape observations in TYPE40.
The MXG Supplement noted that the I/O Interrupt Counts in TYPE70 were observed to be greater than the 3090 IOP I/O Activity in TYPE78IO. It was pointed out that IBM notes (in LY17-5500) that both TYPE78IO and TYPE70 count SSCH (i.e. SIOs) and RESUMES, but that TYPE70 additionally counts PCIs, Device End following Channel End, and Unsolicited Interrupts. The difference has been seen as 12-14% more in TYPE70. Is this a useful indicator of anything? c. SMF TYPE64 (VSAM I/O) counts. VSAM counts (EXCPs, SPLITS, etc.) in type 64 records are wrong if the VSAM file is concurrently opened. These counts are the "change since open". Four jobs which concurrently opened the same VSAM file and then read 9000 blocks, showed 9000, 18000, 27000, and 36000 EXCPs in their type 64 records. The type 30 SMF record EXCP counts are correct. The type 64 record has always been this way; only recently did a user investigate the data. MXG will be enhanced to de-accumulate TYPE64 data, as ANALDSET does to de-accumulate TYPE1415 data. You could find a CASPLIT count in a type 64, but the actual split may have been caused by a separate job. You must sort all accesses to the same VSAM file by open time and examine the end time for potential overlap and perform you own de-accumulation.
In creating tape copies of MXG Version 4.4, we used SYNCSORT's free, fast BETRGENR replacement for IEBGENER. Since BETRGENR copies one cylinder at a time, the 833 blocks of 6160 bytes each required only 11 Start IO's, each SIO transferred 550KB of data in .44 seconds (you can hear the voice coil humm that long), but there was then a delay of about .6 seconds for the next SIO to commence (again, heard at the tape drive). As a result, while the channel capacity is 1.25 MB/sec, even with the transfer of 550KB per SIO, the effective channel capacity was only 550KB/sec, or only 44% of IBMs stated capacity. This was in a dedicated processor with no other work in progress.
data transfer took 11 seconds for the 11 SIOs, but the physical loading of the tape, the swap in to reply (tapes are NL) and the rewind and the unload time total just about one minute elapsed time. Because we were waiting on the computer (THE definition of bad response) we allocated more tape drives and found that with two tape apes (us), and four tape drives, we could create 100 tapes per hour. Increasing the tape drive count to six drives increased our production to 163 tapes per hour. Note at this rate of 163 5.5MB tapes written per hour, the tape channel was still only utilized at 250KB per second, or only 20% of the peak transfer capacity. The peak-to-sustainable rate here was 5 to 1.
any peak rate) as a measure of capacity, without determining the actual sustainable transfer rate. IEEE Computer magazine recently had a good discussion with regard to the ratio between peak mega-flop rate and achievable mega-flop rate on super computers, reporting typical ratios also in the 5 to 20 range. Each job executes 255 copy steps. All steps except the first recorded .40 or .41 TCB seconds and .03 SRB seconds on a 3090-200. With 5.5MB of data per step, this 13 MIPS (speed) processor is moving data at 13.4 MB per second. This is quite close to the one byte per one instruction rate first noted on page 842 of the MXG book!
SRB seconds, or 1.12 total CPU seconds apparently because the CPU time for operator response to allocation recovery is captured in the step. Each job enters allocation recovery because its specific UCB address is offline at job initiation. The IEF244I - "Unable to allocate" message set up the IEF238D - "Reply Device Name or Cancel" WTOR and the R,99,181 reply apparently records .68 CPU seconds in the step record.
built so only one mount is needed, but require a reply to confirm the VOLSER. With the UCB in VOLSER, the reply is fast and accurate.)
Several sites have noticed approximately 10% more EXCPs are counted in the type 30 subtype 4 (TYPE30_4 data set) record than the EXCPs in the step type 4 (or type 34) for the same step. The type 30 is correct, and the additional count in type 30 is due to the EXCP count to dynamic allocations, which are captured in 30s but never were captured in the 4 or 34 records. As described on page 628 of the MXG book, if you used 4s or 34s, you had to use the 40s also. This is only one more reason why the type 30 SMF record has (since 1978) always and all ways been better than the type 4/34 records. It's even worse for the 4s and 34s now. In MVS 2.2, IBM turns on a new flag bit in 4s and 34s to tell you that the EXCP data on this step is incomplete in the 4/34 record and you must use the type 30 for this step. (This happens for any step with more than 1651 DD cards). STOP USING 4's and 34's! (MXG's BUILDPDB has always used only type 30s.)
Step termination data shows that the SMF CPU TCB time in the SMF type 30 can be slightly greater than the RMF CPU TCB time in RMF service units in both the SMF type 30 and the RMF type 72 record for that step. The step recorded 8.13 CPUTCBTM seconds in TYPE30_4, but CPUUNITS in the step record (converted to CPU seconds) showed only 8.08 seconds. This step executed in a unique performance group, and the TYPE72 CPUTCBTM was also 8.08 seconds for the interval in which the step executed. This is not statistically significant, but an IBM expert suggests this occurs because RMF gets it service unit values (CPUUNITS,SRBUNITS) from the job data during step termination. This is why the CPUUNITS in the type 72 data matched. However, after the service units have been passed to RMF, the job is still in termination and the SMF clock is still accumulating true CPU time for the step. The extra CPU time recorded in the SMF step record may be due to SMB processing (putting those termination messages on your SYSLOG listing) or it could be installation code executing in SMF exits (perhaps to print the job costs on the "banner page" in SMF exit IEFU83 or IEFU84). At this site, there appears to be a fixed cost of .05 TCB seconds per step termination which is not recorded in the TYPE72 CPUTCBTM, but which is recorded in the TYPE30 CPUTCBTM. Even at 1000 steps terminating each hour, this would be only 50 additional TCB seconds for each 3600 seconds, or only about one percent.
The Contiguous Slot Allocation algorithm, the very efficient way of transferring up to 30 page frames contiguously with one SIO and with minimal arm movement, was introduced for page data set I/O with MVS/370 SP 1.3 in the late 70's. Recently, several authors have concluded that the algorithm will perform well only if the maximum number of slots in use is less than 25% of the slots allocated. When the page data set is full, the algorithm can not perform well, because it can not find contiguous free slots. This greatly increases the search time, which can negate the positive performance of the algorithm. For MVS/370 VSCR, IBM had recommended minimizing the number of slots allocated to relieve MVS/370 VSCR because a small amount of CSA is used for each slot allocated. With only 50K-60K virtual storage saved, real paging is likely a more serious problem, and thus a larger page data set allocation may still be advised. In early MVS/XA there also was a real problem with large page data sets causing excessive seek times, but that design error was fixed in MVS 2.1.2. You can use the MAXUSED and SLOTS variables in TYPE75 to see if you might have a problem, and could plot the percent used versus the service time (AVGRSPMS from TYPE74) for each paging volume to confirm its real impact. It is clear that an Yüklə 28,67 Mb. Dostları ilə paylaş:
|