* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Line 089400 Change MIN=MINSMF MAX=MAXSMF; to MIN=MINSMF MAX=MAXSMF SUM=X1 DURATM; Thanks to Jan van Lent, Fokker, NETHERLANDS.
IMACDOS the location of the RECID and the OFFSET that need to be Apr 26, 1989 set in IMACDOS. IMACDOS now defaults to DOS 2.1.7. VSE Version OFFSET value RECID @xx value 3.1.2 0 @43 2.1.7 8 @51 2.1.3 16 @59 Earlier 0 @43 Note that processing DOS data usually requires the JCL LABEL parameter of (,NL) or (,LTM). Thanks to Bill Sikora, EDS Auburn Hills Mi, USA. Thanks to Barry Debenham, Cigna Services, ENGLAND. Change 07.025 Cache DASD SMF record variables RWRATIO and READHR could VMACACHE be non-zero even though there was no activity to a device Mar 9, 1989 because they were not reset missing from the prior device segment in the same record. Insert two new lines: 051410 ELSE RWRATIO=.; 051510 ELSE READHR=.; to reset when the denominators are zero. Thanks to Ray Dickensheets, Yellow Freight System, USA. Change 07.024 IDMS 10.2 Performance Monitor data written to Journal and TYPEIDMJ not to SMF was not correctly handled. There is a header Mar 9, 1989 of 20 bytes when data is written to the IDMS journal that is not in the SMF format data. Change to read 001100 INPUT +20 PMSTYPE PIB1. (and make sure IMACIDMS was updated with the same value set by #PMOPT RECID= in your IDMS gen.) Thanks to Mike Eisenhart, York International, USA. Change 07.023 The PROC DATASETS NOLIST; DELETE DUMMY. _DSET; in the old MONTHBLD definition of _MNTHBLD is not acceptable to SAS. The full Mar 8, 1989 dataset name is not supported in the DELETE statement. In place, and also at the end of the new definition which follows the old definition, the correct syntax added is: PROC DATASETS DDNAME=DUMMY NOLIST; DELETE _DSET: All this simply keeps the DUMMY library at minimum size. Thanks to Pat Stockel, New Jersey Educational Computing Network, USA. Change 07.022 Reading SMF data with the CMS version of SAS will cause a VMACSMF DMSSOP0363 Code 04 OPEN error. The CMS Version of SAS is Mar 8, 1989 limited by IBM's CMS OS Simulation code, which does NOT support LRECL=32760, even though SMF records can contain a real LRECL of 32760. MXG Version 6.6 did change the LRECL value in _SMF macro in VMACSMF from 32756 to 32760 precisely because we encountered STOPOVER abends when SMF data with real LRECL=32760 was encountered. If you must process your SMF data under CMS SAS, you will need to change the LRECL in the _SMF macro to 32756, and try it. If the actual SMF data contains records actually 32760 bytes LRECL, you will STOPOVER abend, but if there are no records that long you will be home free. If you do have actual LRECL=32760 physical records, there may be no immediate solution, but please call. (The IBM limit is described on page 172 of SC19-6209 for VB and VBS support under CMS Release 4). I have an open problem with IBM on this IBM limitation. Thanks to J. D. Hill, CyCare Systems, USA.
REXXTEST name for the FILEDEF in line 000523. Change MONWRITE to Mar 7, 1989 MWINPUT (and also in line 000524 change DIKS to DISK). Thanks to J. D. Hill, CyCare Systems, USA. Change 07.020 CICS sample reports for AMXT and CMXT task delays could ANALCICS require lots of work space because all CICSTRAN variables Mar 7, 1989 were kept. This change keeps only the needed variables. Remove semicolon from line 043300 and insert new line: 043310 (KEEP=APPLID TERMINAL STRTTIME ENDTIME TRANNAME); Thanks to Janet Davis, Anchor Systems, USA. Change 07.019 IBM documents SMF type 30 triplets (offset,length,number) VMAC30 as present if "number" is non-zero, but one site found a Feb 20, 1989 record with length=0 and non-zero offset and number. (In addition, the offset put this section in the middle of the EXCP section!) Though this is probably an APARable IBM problem, it caused MXG a STOPOVER abend. As a result, MXG added a nonzero length test to each test for offset and number, and then compares the record length to the offset+(length*number)-1 to protect MXG from yet another potential IBM data error. Whenever a bad triplet is found MXG prints an error message on the log, then deletes the bad record and continues processing the SMF data. Added Apr 5, 1989: ACCT section variable NRACCT does NOT count the number of sections of length LENACCT, instead NRACCT is the count of accounting fields within the one account segment of length LENACCT. Test for ACCT is thus offset+length-1. Thanks to John Brown, Performance Systems Incorporated, USA. Change 07.018 The variable DEVICE for a Channel-to-channel adapter VMACUCB was OTHER. This minor change now sets DEVICE='CTC'. Feb 15, 1989 Add new line 004110 ELSE IF DEVCLASS=41X THEN DEVICE='CTC'; Thanks to Bill Mullen, BGS, USA. Thanks to Rodney L. Reisch, General Electric Plastics, USA. Change 07.017 Type 80 SMF records for RACF Version 1 Releases 8.1 and FORMATS 8.2 were already supported by MXG 6.6! There is only one VMAC80 new flag field and three new values of RACFQUAL (204-206, Feb 15, 1989 whose meaning can easily be deduced from Table 1 in the Appendix 10 of SC28-1343-4) added by RACF 1.8, and none are significant. This change creates variable RACFRE2 and adds three values to the MXG MG080QU. format.
VMACVMON DRPCANUS, DRPPOPUS, and RPCUMUS in VMONUSRD and VMONUSRS Mar 8, 1989 and their values in VMONPERF. DRPCANUS and DRPPOPUS were never de-accumulated and have always been wrong. In VM HPO (version 4.2 and version 5, although documented only for version 5) the user class record was incompatibly changed by IBM, affecting the other user class variables input after DRPPOPUS. This should be low impact for most VM/370 HPO sites (unless, of course, you need the data!).
Release 5 HPO, which have also been found (almost exact, missing only the new VMACNT field) in HPO 4.2 data. I don't yet know the PTF which made the 4.2 changes. Move line 246700 to after 248600 Change line 246800 GE to EQ Replicate lines 246800 to 248100 Change line 248110 EQ 178 to GE 192 Copy 246200 to 246500 after 248110 Change 248111 from PIB4. to PIB8. Remove @133 @135 @137 from 248112 thru 248114 Change @139 PPSTSWUS PIB2. (line 248120) to @145 PPSTSWUS PIB4. Change line 248130 from PPSTPPUS PIB2. to PPSTPPUS PIB4. b.This part applies to both HPO releases and corrects the DPRCANUS and DRPPOPUS variables (and eliminates their meaningless average and maximum value variables DRP...AV and DRP...MX). New Lines: 315910 DRPCANUS=DIF(DRPCANUS); 315920 DRPPOPUS=DIF(DPRPOPUS); 319910 IF . LT DRPCANUS LT 0 THEN LOGON=1; 319920 IF . LT DRPPOPUS LT 0 THEN LOGON=1; 322810 DRPCANUS=.; 322820 DRPPOPUS=.; Line 328700 (follows /*AVG), DRPCANUS DRPPOPUS. This line must be moved immediately following 329400 (DEFRQ). Line 330800 change X12 to X10. Lines 331000 and 331200, remove DRPCANAV DRPPOPAV. Line 331500 remove X11 X12. Line 331800 add DRPCANUS DRPPOPUS after DEFRQ. Lines 333900 thru 334200 (Labels for DRP...), delete. Line 338100 remove DRPCANAV DRPCANMX DRPPOPAV DRPPOPMX Thanks to Ron Roberts, The Equitable Life Assurance Society, USA. Change 07.015 This new member will be incomplete in your source library ANALALL even though the complete member is on the source tape! Feb 15, 1989 The member (to read SMF and print all records from a job) contains IEBUPDTE ./ control cards, which were processed (unexpectedly) by IEBUPDTE in creating your MXG.SOURCLIB! Had you looked at the IEBUPDTE log, you would have seen a IEB816I message for ANALALL, followed by three IEB816I messages for IMACJBCK, IMAC30DD, and IMACINTV which were actually part of ANALALL! (Later in the log you would see the real IMACJBCK,IMAC30DD,IMACINTV create with IEB817I.) To create the ANALALL member, copy the source tape to a sequential dataset on disk (IEBGENER,FB,80,6160), with SPACE=CYL(1) and DISP=(,CATLG,CATLG). The job will ABEND with B37, but the one cylinder data set will contain the ANALALL member. Then use your editor to block copy the lines between ./ ADD NAME=ANALALL & ./ ADD NAME=ANALAUDT. I have changed the "./" to "XY" and added comments to change them back to avoid the problem in the future. Change 07.014 The Assembler parameters OJB/OBJECT and SYSLIN/SYSGO may EXITMONI be different for different levels of ASM. Assembler XF Feb 15, 1989 (IFOX00) used SYSGO and OBJ. Early Assembler H (IEV90) required SYSLIN and OBJECT, and if OBJ was used, NOOBJECT was set (with no condition code) and no object deck was created, causing the LINKEDIT step to fail. An old PTF (PP29236) to ASM H allows either OBJECT or OBJ (probably as a result of ASM XF user complaints), even though only OBJECT is actually documented for ASM H. This change is for info only, and was revised after Newsletter FOURTEEN. Thanks to John McAlpine, CSX, USA. Thanks to Bob Rutledge, CSX, USA. Change 07.013 This is an interesting problem. Three separate STOPOVER VMACVMON abends were encountered on three different VM/SP records Feb 15, 1989 that were shorter than expected. The culprit turned out to be an error in VM Systems Group's VCOPY Product (a replacement for IBM's CMS COPYFILE command). This site used IBM's COPYFILE to copy VM/Monitor data. COPYFILE has has an option "TRUNC" (although IBM's default is NOTRUNC) that truncates blanks (X'40') when a fixed length file is converted to a variable length file (to save DASD space). When VCOPY replaced IBMs COPYFILE, its default of TRUNC and a coding error in VCOPY (now fixed by Fix Co0263) had truncated all X'40's at the end of VM monitor records! If you have VCOPY, you can either request the fix from the vendor, change their system wide default to NOTRUNC, or specify NOTRUNC on the COPYFILE statement to avoid the unexpected data trunction. Hopefully, you will not encounter the problem, but the MXG circumventions made (before the truth was known) were left in place! Change line 212800 to read: INPUT @9 USER : $8. @; /*MN098UID*/ Change line 216400 to read IF LENDATA GE 1 AND LENDATA+19 LE LENGTH THEN Insert two new lines after 229400: 229410: @; 229420: IF LENGTH GE 40 THEN INPUT Thanks to Steve Smith, Hammermill Paper Co, USA. Change 07.012 MVS/ESA TYPE1415 data now uses three bits of SMF14RIN to VMAC1415 indicate ILIB managed data set (Bit 0 on), Trunc macro Feb 15, 1989 issued (Bit 1 on) and/or Null segment encountered (Bit 3 on). MXG read byte one of SMF14RIN as variable RECIND1 & byte two as RECIND2, but kept only RECIND1 (because all bits in RECIND2 were formerly reserved). This change adds RECIND2 to the KEEP list for TYPE1415.
IMACPDB type 30 SMF records capture three new CPU measures: VMAC30 VMAC434 CPUHPTTM - Hiperspace CPU. The CPU time used to read from VMACSMF and write to hiperspaces by this step/job. Feb 15, 1989 CPUIIPTM - CPU I/O SLIH time. The CPU time used by the Second Level Interrupt Handler in servicing I/O requests for this step/job. CPURCTTM - Region Control Task CPU Time. The RCT handles QUIESCE and RESTORE and thus predominately is involved in SWAP management. This CPU measure should significantly help TSO capture. All three CPU measures are NOT captured in the RMF TYPE72 performance group data, nor are they in the type 4 or 34 step records. While the CPUHPTTM is a new measure of an MVS/ESA-only activity (movement in/out of hiperspaces), the CPUIIPTM and CPURCTTM now capture CPU times that have been THE major contributor to uncaptured CPU times: I/O interrupt handling and TSO swap processing.
(289-036) use the sum of ALL CPU measures (the three new, plus the two TCB measures AND the two SRB measures). For those of you who have had trouble convincing your bosses to use TCB plus SRB for billing, etc., you can use this example from big blue! Note that IBM refers to "five" CPU fields, but there are really seven fields now.
TYPE434 (and hence in PDB.STEPS and PDB.JOBS) no longer exist in MVS/ESA. In their same location are three new MVS/ESA only variables: CREADMIS - Incorrect CREADS. Number of misses when an attempt to read data from an expanded-storage-only hiperspace failed because the data was not found (was variable RECLAIMS) HIPAGINS - Hiperspace pageins from auxiliary storage into processor storage (was variable COMRECLM). HIPAGOUT - Hiperspace pageouts (was variable LPARECLM).
without error), but for MXG to be "Capable" (i.e., to create the new CPU fields in TYPE30 and PDB.JOBS/STEPS data sets, and to create the three Hiper-related fields you must make the following changes: -In member VMAC30: -Add the three CPU variables (CPUHPTTM,CPUIIPTM,CPURCTTM) and the Hiper variables (CREADMIS,HIPAGINS,HIPAGOUT) to: -KEEP list for TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6. -LABEL statement. c. CPU vars only to FORMAT statement for TIME12.2 format. -Delete the CPUTM=SUM( ... ); statement, line 056800. -Insert the following seven lines after line 057500: IF LENCPU GE 56 THEN INPUT CPUIIPTM PIB4.2 CPURCTTM PIB4.2 CPUHPTTM PIB4.2 @; CPUTM=SUM(CPISRBTM,CPITCBTM,CPUHPTTM,CPUIIPTM, CPURCTTM,CPUSRBTM,CPUTCBTM); -Insert these lines after line 062000 (contains @;): (Note that in the MXG implementation this change is more extensive; variable MVSESA is now created by VMACSMF for MVS/ESA. This change avoids that additional Edit.) IF MVSXAFLG='....1...'B THEN DO; /* MVS/ESA */ CREADMIS=RECLAIMS; HIPAGINS=COMRECLM; HIPAGOUT=LPARECLM; RECLAIMS=.; COMRECLM=.; LPARECLM=.; END;
CPUIIPTM,CPURCTTM,CREADMIS,HIPAGINS,HIPAGOUT) to: -The _PDB30_4 definition at lines 013200-013300. -The _SUMSTP definition at lines 017700-017800. Thanks to Dave Greene, Kwasha Lipton, USA.
ANALDB2R reports for all plans, all ids, etc.) was removed in MXG VMAC102 6.6 (but not specifically documented) because you might Feb 17, 1989 have "ALL" as a plan name, etc. Now, to create reports for "all" of something, use the default (by specifying no value for the argument). In ANALDB2R: Line 235800 and 235900 must be reversed so DB2COUNT+1 precedes the CALL SYMPUT statement. Line 254300 should be QWPZTOUT and line 255100 should be QWPZISWI. (They are reversed). In VMAC102: Insert new line after 081900: QWPZTRSZ=QWPZTRSZ*4; Thanks to Ervin Claxon, Ashland Oil, USA.
VMACVMXA "Range is Repeated" error message in attempting to create Feb 16, 1989 the temporary Format which maps Device Information to the RDEVSID value. Duplicate RDEVSID values do exist in the VXMTRDEV data set, but MXG's logic to remove duplicate values incorrectly included BEGINMTR in the BY statement. FIX: Remove BEGINMTR from both BY statements in lines 678500 and 678800. Thanks to Ray Dickensheets, Yellow Freight System, USA.
BUILDPDB records. If a job which is still in the execution queue Mar 11, 1989 after it has been executed (eg., a job which encountered a DSENQ conflict that was canceled and requeued, or any job processed by the MVS Throughput Manager product) is spool transfered and reloaded, two purge records will be created (one at offload, one after real execution) and both contain non-blank values for SYSEXEC. A non-blank SYSEXEC separated the "real" purge record (for PDB.JOBS) from the multiple NJE purge records (into PDB.NJEPURGE). If two (or more) purge records with non-blank SYSEXEC are found in the same BUILDPDB run, duplicate observations in PDB.JOBS were built. The use of just SYSEXEC to identify "real" purge records is insufficient. Part of this fix is a guarantee that only one "real" purge record is used by MXG, even if multiple are found. The other part of the fi selects the purge record created at offload by JES2 Spool Transfer program (DEVNAME, Transmit Device Name beginning with OFF) into the PDB.NJEPURGE data set. If your site does not use Spool Transfer, you have no exposure. FIX: 1.BUILDPDB. Insert new line after 014200: 014210 DEVNAME=:'OFF' OR Add JPURTIME to the end of the BY list at line 023500. Insert new line after 023600: IF LAST.JESNR THEN OUTPUT; 2.IMACPDB Add DEVNAME to line 008600 (inside _PDB26J2 macro). Thanks to Don Friesen, B.C. Systems, CANADA.
MONTHBLD error. In making the member more comsmetically appealing, Feb 14, 1989 the invocations of _MNTHBLD ended up ending in column 72. Since the next line starts with MACRO, SAS combined the end of one line with the beginning of the next to create the string _MNTHBLDMACRO, which SAS cannot recognize! FIX: Delete the blank before the percent sign in each line than ends with _MNTHBLD in column 72. Thanks to John Mattson, National Medical Enterprises, USA.
BUILDPDB in BUILDPDB but was left in a DROP list in BUILDPDB/3 and BUILDPD3 not added to the BY list in WEEKBLD. This caused PRENTIME WEEKBLD to not exist in PDB.PRINT and caused WEEKBLD to ABEND. Feb 9, 1989 FIX: 1.BUILDPDB: remove PRENTIME from DROP statement line 048300 2.BUILDPD3: remove PRENTIME from DROP statement line 048700 3.WEEKBLD: add PRENTIME to line 003200 between PRINTIME and OUTDEVCE. Thanks to John Mattson, National Medical Enterprises, USA. Thanks to Gary Ruedinger, Response Graphics, USA.
VMAC102 STOPOVER ("Input exceeded record length") for DB2 1.3 or Mar 11, 1989 earlier records.
163910 @; IF QWT02R1L GE 302 THEN INPUT Add PIB4. after QW0087FR in line 144400. In subtypes 15,17,18,22,53, and 58 incorrect calculations caused the input to end before all fields had been read. Change ENDPROD to ENDPRODA in lines 098200,250800, and 255600. Change OFFPROD to OFFPRODA in lines 160200,166400, 260400, and 263900. Thanks to Jan-Ake Christoffersson, Gotabankendata, SWEDEN. Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
VMAC28 NPMSUBTY for the ENABLE NSA event record. Feb 7, 1989
Thanks to Michelle Buchecker, IBM Boulder, USA. Change 07.003 JCL for HSM processing included non-existent testing name JCLHSM of XMXGHSM. Feb 7, 1989
Thanks to Billy Westland, Candle Corporation, USA. Change 07.002 MXG variable CPUTM in the CIMSTRAN data set from IMF data VMACCIMS from Boole & Babbage did not include all CPU variables, Feb 7, 1989 and the variable was not in the KEEP list. Also, SERIALIO was not protected if it overflowed its two byte counter. FIX: 1.Insert new line 002410 (after 002400) containing CPUTM 2.Add CPUCOPTM,CPUMOPTM, to the SUM function arguments in line 044000. 3.Add CPUCOPTM,CPUMOPTM,CPUSBFTM,CPUSDLTM,CPUSOPTM, CPUDB2TM to the SUM function arguments in line 070400. 4.Change LE 12 to LE 13 in line 065900. Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA. Thanks to Agneta Bergsten, SPP, SWEDEN. Change 07.001 TREND data base code fixes. Always specify SAS Options GRAFTRND MACRO and DQUOTE when using %MACROs. GRAFTRND will only TRNDJOBS produce first and last pair of graphs if MXG Version 5.5 TRNDRMFI PDBs were used (because SU_SEC variable did not exist in TRND72 RMFINTRV until 6.6). When a macro variable is set by data PDBTREND value in a data step, a RUN; statement seems required at VMXGSUM the end of the data step to actually set the macro value. Mar 9, 1989 FIX: 1.GRAFTRND: Change all occurrences of OTHRn (ten separate times for n=0,1,...,9) to OTHn (without the R). Line 007800 add OTH6CPU OTH7CPU OTH8CPU OTH9CPU Insert two new lines: 011310 RUN; 017110 RUN; 2.TRNDJOBS line 002300 Add NUMJOBS after SUM= (before IWT) 3.TRNDRMFI: Insert new line after 001200: 001210 %INCLUDE SOURCLIB(VMXGSUM,VMXGDUR); Line 001400 add (IN=INWEEK) after WEEK.RMFINTRV Lines 002600,29,32,35,38,41,44,47,50,53,56,59,62,65,68,75 add BATCNT TSOCNT IMSCNT CICSCNT OTHRCNT OTH0CNT OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT OTH7CNT OTH8CNT OTH9CNT TRIVCNT to respective line. Lines 011400,115,117,119,121,123,125,127,129,131,133,135 137,139,141,143 change / ....TRAN to / ....CNT respectively. Insert new line after 014500: 014510 IF INWEEK THEN DO; Insert new lines after 014700: 014710 END; 014711 IF SU_SEC =. THEN SU_SEC=.; 014712 IF PARTNCPU=. THEN PARTNCPU=.; 014713 BATCNT=BATTRAN*DURATM; 014714 TSOCNT=TSOTRAN*DURATM; . (one for each of the 16 ...CNT variables added . in lines 002600-007500 above) 014727 OTH9CNT=OTH9TRAN*DURATM; 014728 TRIVCNT=TRIVTRAN*DURATM; After line 15400 insert DROP BATCNT TSOCNT IMSCNT CICSCNT OTHRCNT OTH0CNT OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT OTH7CNT OTH8CNT OTH9CNT TRIVCNT; Yüklə 28,67 Mb. Dostları ilə paylaş:
|