* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Jul 6, 1994 into the PDB.PRINT dataset; now it is. Thanks to Tom Parker, Hogan Systems, USA. ====Changes thru 12.084 were included in MXG 12.02 dated Jul 4, 1994==== Change 12.084 New features/enhancements to VMXGSUM were transparently DOC added to this powerful MXG summarization utility. VMXGSUM - A dataset name in the INDATA= string can now be a fully Jul 1, 1994 qualified SAS name like with "INDATA=PDB.JOBS," or macros can be used, like with "INDATA=_DAY._DSET,". - It is no longer necessary to use a DROP DATETIME; statement, nor do you need to assign the real variable name in an assignment statement. (The DATETIME= option set up an internal variable named DATETIME). Now, if DATETIME=VARIABLE, and VARIABLE appears in the ID list, and the variable name is not DATETIME, then MXG inserts VARIABLE=DATETIME in the logic, and drops DATETIME. - New options allow specialized use of summarization that are described in detail in member VMXGSUM: CLASS = Allows specifying CLASS and keeps _TYPE_ so that multiple outputs can be created. MEANOPTS= Allows passing options to the PROC MEANS. ORDER = Allows insertion of LABEL statement to force alphabetic order in the output dataset vars. INCODE1 = Continuation of INCODE= in case the 32K byte SAS limit (including blanks!) is too small. INCODE2 = New exit for code insertion after the normalization phase on the input side. OUTCODE1= Continuation of OUTCODE=, see INCODE1. OUTCODE2= New exit for code insertion before the de-normalization phase on the output side. - Although these internal changes were implemented in a transparent manner, so your existing programs that use %VMXGSUM should not need any changes, all of the MXG members that invoke it were cleaned up. Now redundant DATETIME= references were removed, all invocations now contain INVOKEBY="member" argument to make it easier to tell which member has executed %VMXGSUM, and invocations were collimated for clearer reading. Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY, who suggested several of the new options, and who provided sample implementation code.
VMXGDUR ignored without any warning; now a warning message is Jul 1, 1994 printed on the log.
GRAFTMNT were useless since they were designed for daily reports. Jul 1, 1994 This revision supports TREND data base reporting.
ANALUSAG existing TYPE72 data to calculate the "bands" for usage Jul 1, 1994 based pricing of IBM software products. For TYPE89 the real product name is used; the analysis based on TYPE72 uses the workload definition in IMACWORK to name the "product". This report will be revised when IBM makes their report format available.
ANALBLSR pattern of utilization of a VSAM cluster by multiple runs ANALDSET of the same job changed, because average value was used. Jul 1, 1994 This revision uses the sums to accurately calculate the percentage of I/O attributable to a given component. Also, it turns out that turning on BLSR suppresses the Buffer Count in TYPE64 dataset, so those reports were eliminated, as they were useless! Thanks to Freddie Arie, Enserch Corporation, TEXAS.
READDB2 buffer pools in the building member VMACDB2. This change ASUMDB2A adds that support to the READDB2 utility and to the TRNDDB2A DB2 Accounting summary and trending members. VMAC102 Jul 1, 1994 Change 12.078 Using ANALDB2R with PDB= on tape was inefficient; it ANALDB2R could cause three passes of the tape, especially when Jul 1, 1994 ACCOUNTING reports were requested and neither ASUMDB2A nor DB2ACCT was found on the first tape volume. The logic was changed: if we see the PDB= points to a tape dataset, we now look only for the PDB.DB2ACCT dataset, unless you explicitly tell us to use the PDB.ASUMDB2A (by specifying USEACCT=ASUM option in your %ANALDB2R invocation). The old logic looked first for ASUMDB2A, and if not found then looked for DB2ACCT, requiring multiple passes of the PDB= when on tape. While our example JCL in JCLPDB6 does build the PDB.ASUMDB2A, we can't guarantee you did so, so we by default go for PDB.DB2ACCT. (The PDB.ASUMDB2A is smaller and the preferred source, so if it exists it is wise to specify USEACCT=ASUM for PDB=tape). This change does cause new messages on the log: NOTE: DATA SET ... HAS NOT BEEN DEALLOCATED ... NOTE: LIBREF PDB HAS BEEN DEASSIGNED. PDB LIBNAME WAS CLEARED TO CHECK DEVICE TYPE. because to detect if the PDB= points to tape, we must first open the DDNAME as an INFILE and then clear it!
GRAFTRND removed; if the normalization of CPU time or the Jul 1, 1994 predicted workload growth exceeded 100%, the workloads disappeared from the graph as they passed 100. Change 12.076 If SASGRAPH=NO was specified when you invoked GRAFWORK, GRAFWORK the numbers for CPUTM and % CPU were cumulative totals Jul 1, 1994 rather than the values for individual observations. Also, values of EXCPs, IOTM, and MEMR were added to Thanks to Tom Bell, Rivendel Consultants, USA.
VMAC30 MULTIDD='Y' records, but they are not, causing MXG to Jun 30, 1994 input values in APPC variables. This is an IBM error, and APAR OW07036 now has PTFs UW09744-UW09746. If you use TYPE30_4, TYPE30_5 or PDB.STEPS to analyze APPC resources, you can delete observations with MULTIDD='Y' and the APPC resource analysis will be valid, but any EXCP counts in those MULTIDD records will be lost. However, this MXG fix eliminates the error, and will work even after IBM fixes the problem: - After the @; following the input of @101+OFFSMF EXTRADD insert these two lines: IF SUM(0,NRUREC,NRCOMP,NRCPU,NRSTOR,NRPERF,NROPER)=0 AND SUBTYPE NE 1 THEN MULTIDD='Y'; - After the END; after the DO group that sets OFFAPPC, LENAPPC and NRAPPC equal to OFFAPPCC,LENAPPCC,NRAPPCC, insert this DO group: IF MULTIDD='Y' THEN DO; OFFAPPC=.; LENAPPC=.; NRAPPC=.; END;
Thanks to Bill Keller, West Publishing, USA. Change 12.074 Several DCOLLECT flag variables that were set to 0 or 1 VMACDCOL for NO or YES are now formatted with MGLMSYN and their Jun 30, 1994 labels now end with a question mark to clarify that they are YES/NO values. The variables are these: DSCDFACC DSCDFAVL DSCDFGSP DSCDFSDR DSCFDIRB DSCFDIRR DSCFIAD DSCFSEQB DSCFSEQR DSCSYNCD Thanks to Joseph J. Faska, Depository Trust, USA.
VMAC6 RLSELEFT should be FORMATed $HEX16. instead of $HEX8. Jun 29, 1994 (the FORMAT statement is the first occurrence of this variable and thus determines the variable's length). The error occurs only if you have modified JES2 to create the print release time as described in Change 7.137. Thanks to Andy Vick, Allied Dunbar Assurance, UK.
VMACACF2 error because DB2 and NEXTKEY segment logic was wrong. To Jun 29, 1994 circumvent (with no data loss), change the statement INPUT ACVMFSEC $EBCDIC18. @; to read INPUT ACVMFSEC $EBCDIC8. @; The actual code change was more extensive. Additionally, ACF2 SMF record subtype 'D' printed a note: RECORD TYPE D, EXCESS DATA AT END SKIP=7 on the log. This had no impact (NEXTKEY data was not read, but is not kept) but logic for this subtype was also corrected. Thanks to Russell Ochocki, Investors Group, CANADA.
TRND70PR 0; replicate occurrences of LPAR 1 variables and change 1 Jun 28, 1994 to zero to include LPAR 0 in TRND70PR (only Amdahl's MDF uses LPAR zero). Thanks to John Chan, The Toronto Hospital, CANADA.
FORMATS record. The record format was incompatibly changed by VMACACHE the 1.6 release. Note that if you run a 3990-6 in Basic Jun 27, 1994 mode, you can't tell that it's a mod-6, because REPORLVL=03. If you enable the 3990-6 in Enhanced mode, REPORLVL=06 and the mod-6-only fields will be non-missing. Thanks to Diane Eppestine, Southwestern Bell, USA. Thanks to Scott Ashby, Wachovia Operational Services, USA.
EXNDMCT to misspelling in member EXNDMCT. All occurrences of Jun 23, 1994 NDMST in that member should have been NDMCT. Thanks to Freddie Arie, Enserch Corporation, TEXAS. Change 12.069 VM/ESA MONWRITE processing has caused UNEXPECTED/INVALID VMACVMXA CONTROL RECORD and PROBABLE DATA LOSS DUE TO MONWRITE Jun 23, 1994 FAILURE when the end of data was at the end of block with Jul 6, 1994 a 1.13 record; the MXG logic was not sufficiently robust. To correct the MXG error, find the second occurrence of BYTELEFT=BYTELEFT-MRHDRLEN; and insert these four lines after that statement: IF BYTELEFT LE 0 THEN DO; BYTELEFT=0; NRCRRECS=NRCRRECS-1; END; Thanks to Ricky Valeroso, City of New York - CDCSA, USA. Change 12.068 Boole & Babbage CICS Statistics record subtype 0BB02x has VMAC110 been suppressed by recent IBM CICS changes, causing these Jun 23, 1994 special records to not be written. Boole's PTFs BPC2347 and BPC2348 change their subtype value to 00B02x, and MXG test was changed to IF SUBTYPE=0BB02X OR SUBTYPE=00B02X to support either value. Thanks to Bill Gecci, Boole and Babbage, USA
BUILDPDB automatically in BUILDPDB/BUILDPD3. This change was made BUILDPD3 in MXG 12.01, but the change was not noted in CHANGES. Jun 23, 1994 Change 12.066 INFOPAC variables REQSTART and REQEND may be incorrect VMACIPAC for some subtypes - changing the test IF SMFIPSTP NE 1 Jun 23, 1994 THEN to read IF SMFIPSTP NE 4 has cured the problems. Thanks to Ron Bleeden, Jewel, USA. Change 12.065 Variables INTBTIME & INTETIME will be missing in interval VMAC30 TYPE30_V/PDB.SMFINTRV observations which have MULTIDD='Y' Jun 23, 1994 if you are at MVS/ESA 4.2 or earlier. The GMT corrections following setting MULTIDD='Y' in VMAC30 must be executed only if GMTOFF30 is non-missing: IF GMTOFF30 GT . THEN DO; INTBTIME=INTBTIME+GMTOFF30; INTETIME=INTETIME+GMTOFF30; END; Thanks to Tom Parker, Hogan Systems, Inc, USA. Change 12.064 No IPLS/TYPE0 observations with MVS/ESA 5.1 SMF data (but VMAC0 MXG did print an error message on the log), or a short Jun 22, 1994 type 0 record could still cause an INPUT STATEMENT EXCEED Jul 19, 1994 message, because the tests for LENGTH were incorrect. -In MXG 11.11, change the line reading IF LENGTH GT 31 ... to read IF LENGTH-OFFSMF NE 31 AND LENGTH-OFFSMF NE 56 .. -In MXG 12.01 or 12.02, the first LENGTH test should read: IF LENGTH-OFFSMF NE 31 AND LENGTH-OFFSMF NE 56 THEN DO; and the second LENGTH test should now read: IF LENGTH-OFFSMF GE 56 THEN and the INPUT of SYSPLEX should be @49 instead of @39. This text was revised between 12.02 and 12.03. Thanks to Tom Parker, Hogan Systems, Inc, USA. Thanks to Mike Skopec, Platinum Systems, USA. Change 12.063 ACF2 variables LIDCDATE,LIDDXPDT,LIDIPDAT and LIDADATE VMACACF2 can contain hex zeros, causing INVALID DATA messages. By Jun 23, 1994 inserting double-questionmarks between the variable name Jul 19, 1994 and the &PD.4. input format, the messages and hex dump will be suppressed and the variables still set to missing when these dates do not exist. This change was revised; the first two variables were corrected in MXG 12.02, the final two were corrected in MXG 12.03. Thanks to Phil Seale, Central Regional Council, UK.
DIFFDB2 variable QTPKALLA, which was already in the DIF() list. Jun 22, 1994 Without this change, QTPKALL will contain wrong values. Thanks to Tom Parker, Hogan Systems, Inc, USA. Change 12.061 PDB.JOBS variable RESTARTS may be incorrect for a small BUILDPDB number of jobs on the day you implement MXG 11.11, due to Jun 22, 1994 change 11.269, which renamed MULTIDD to MULTIDD5 for the SPIN30_5 logic, but didn't protect existing observations in SPIN30_5 on the first execution. If there were no MULTIDD records in the SPIN.SPIN30_5, there is no error. If the SPIN.SPIN30_5 dataset that you are going to use for the initial run with MXG 11.11 has the variable MULTIDD instead of MULTIDD5, and if there are any observations with MULTIDD='Y', and if those jobs are matched up by the first execution of BUILDPDB, the count of RESTARTS will be incorrect, but the count will be ok on all subsequent days. If you really want to correct this obscure error, you should rename variable MULTIDD in your SPIN.SPIN30_5 dataset to MULTIDD5 and then run your first MXG 11.11 BUILDPDB execution. This might not have been noticed, but it happened to a TSO session, and RESTART greater than 1 should not occur for TSO! Thanks to Tom Parker, Hogan Systems, Inc, USA.
IMACPDB had to change IMACPDB, because it (incorrectly) limited Jun 22, 1994 the number of fields to three. Since MXG 8.8, member IMACACCT is where you control how many account fields you keep, so this change only revises IMACPDB so it now has ACCOUNT1-ACCOUNT9 and SACCT1-SACCT9 specified; that way, your definition of kept account fields in IMACACCT will always be in control. Thanks to Tom Parker, Hogan Systems, Inc, USA.
VMAC6 SUBSYS='JES2'. Because it may be important to know which Jun 22, 1994 subsystem created the type record, MXG now sets variable SUBSYS='VPS ' if UCS=:'VPS'; Thanks to Chuck Hopf, Primerica, USA.
ANALTALO (which replaces the MXG Tape Mount Monitor, ASMTMNT) has ASMTAPES been fixed and has been running at two MVS/ESA sites, one ASUMTALO with both SMS and MIM, for two weeks without any ABEND! BUILDPDB The monitor creates an SMF record for each tape drive BUILDPD3 allocation event, so actual tape drive usage is measured, BUILD002 even for dynamically allocated drives, and it creates an GRAFTALO SMF record (same ID, different subtype) for each tape TRNDTALO mount event, so human and silo efficiency is measured. Jun 17, 1994 MXG member TYPETMNT creates three datasets from the SMF record: TYPETALO for Tape Allocation, TYPETMNT for Tape Mounts, and TYPETSWP for Tape Error Swaps. Both TYPETMNT and TYPETSWP are already automatically created in the PDB by BUILDPDB/BUILDPD3; now PDB.TYPETALO will also exist in your PDB library. Members ASUMTALO/TRNDTALO provide the summarization and trending logic, while ANALTALO/GRAFTALO provide sample printed and graphical reports, and the CPU cost of the monitor is minimal. See Change 12.105. Thanks to Bob Kinney, Kaiser Permanente, USA. Thanks to Chuck Hopf, Primerica, USA. Thanks to Bill Fairchild, Royal Software Associates, USA.
VMACDCOL were not in earlier APARs: Jun 17, 1994 Dataset DCOLDSET variables DCDBDSZ DCDCCSID DCDCUDSZ DCDDDMEX DCDEXFLG DCDOVERA DCDUDSIZ Dataset DCOLCLUS variable DCANSTAT Dataset DCOLMIGS variable UMSDSP Thanks to John Maher, Home Savings, USA.
EXTYMEML MEMOLIST. Code was originally added as member XMACMEMO IMACMEMO in MXG 12.01A, untested, but now has been verified and VMACMEMO has replaced VMACMEMO in MXG 12.03. Jun 15, 1994 Jul 7, 1994 Thanks to Jukka Suhonen, VTTK, FINLAND.
ANALRMFR spelled right, causing uninitialized variable messages Jun 15, 1994 and non-printing of the summary report.
VMACSMF thus were not in the LENGTH 8 list, but if you were to Jun 14, 1994 keep them, the LENGTH DEFAULT=4 would cause truncation of their datetimestamp values, so they are now added to the LENGTH 8 list in macros _SMF and _SMFTEMP in VMACSMF. Thanks to Graeme Yeandle, British Telecom, UK. Change 12.053 Division by Zero was not protected for the calculation of VMACNSPY T1RSPPC-T4RSPPC when TRANSNO was zero; that block of code Jun 14, 1994 has now been protected. Thanks to Jim Wertenberger, Blue Cross Blue Shield of Ohio, USA. Change 12.052 MXG 12.01 only. The OUTPUT _LDB2ACC in exit member EXDB2ACB EXDB2ACB should have read OUTPUT _LDB2ACB instead. (Only VMACDB2 if you used new Buffer Pools would there have been any Jun 12, 1994 actual problem). See Change 12.033. Unrelated, I changed the ID=0 statement before IMACACCT's %INCLUDE in VMACDB2 to a "faker" for better cosmetics. Thanks to Chuck Hopf, Primerica, USA.
VMACDCOL it needs to be multiplied by 1024. Insert a line for Jun 12, 1994 DCDNMBLK immediately following DCDSCALL=1024*DCDSCALL; Additionally, add variables DCAHURBA DCAHARBA and DCAASP to the MGBYTES format list, to be consistent with other variables that measure space allocated/used. Thanks to Mark Mustoe, Nestle Foods, USA.
ANALDSET IEBUPDTE step. Replicate the two "30OM" lines and change Jun 4, 1994 "30OM" to "30MU". Thanks to Freddie Arie, Lone Star Gas, TEXAS. Change 12.049 TCP APAR PN34837 added 8 undocumented bytes to the TELNET VMACTCP Server record - the datetimestamp of LOGF. Variable Jun 3, 1994 TELLOGFT now contains that value. Thanks to Barry Pieper, Norwest Technical Services, USA. Change 12.048 INVALID NUMERIC DATA 'SAT' can occur in ASUM70PR if you ASUM70PR modified IMACRMFI using the example in comments that uses IMACRMFI the variable named "DAY". Unfortunately, changes made to Jun 3, 1994 VMXGDUR (which is invoked internally by ASUM70PR) now use the variable named "DAY" as a numeric variable, causing the error message. Since the problem only arises if you have modified IMACRMFI, you can change "DAY" in IMACRMFI to "DAYSHIFT" to eliminate the conflict. I have changed the example in comments to now show "DAYSHIFT". Thanks to John Chan, The Toronto Hospital, CANADA. ===Changes thru 12.047 were in MXG PreRelease 12.01 dated Jun 1, 1994=== Change 12.047 The RMF-look-alike CPU Activity report may show BUSY TIME ANALRMFR of zero (but the Summary CPU times are correct) due to Jun 1, 1994 incorrect logic. Change: Jun 2, 1994 IF CPEF(I) NE . THEN DO; to IF CPEF(I) GT 0 THEN DO; then 35 lines later, change IF PEFT(I) NE . THEN ... to IF PEFT(I) GT 0 THEN ... then 19 lines later, change IF LPARNAME =: ' ' THEN DO; to IF LPARNAME =: ' ' OR TOTEFV LE 0 THEN DO; On the Summary Report, the "DASD RESP" was incorrect; MXG included both Tape and DASD in its calculation (but on Device reports the device and LCU detail was correct). The DASD RESP fix was not included in the Jun 1 tapes. Thanks to Linda Carroll, American Software, USA. Change 12.046 Variables TSO2SWAP TSO3SWAP TSO4SWAP TSO2TRAN TSO3TRAN TRNDRMFI and TSO4TRAN were left out of the NORM1= argument list, May 25, 1994 and were incorrect in the TREND.TRNDRMFI dataset. Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY. Change 12.045 "Performance Management in a DFSMS/MVS World" GG66-3252, VMAC42 by IBM's J.P. Burg is an excellent discussion of use of May 25, 1994 the new SMS data in type 42 SMF records. Six variables that he uses in that manual are now created in TYPE42DS (data set detail) and TYPE42SR (storage class) datasets: DASDMPL CACHRATE DASDRATE HITPCT CHITPCT CIOPCT Take a look at John's analysis and discussion!
ANALRACF progress - the PROC TRANSPOSE still raises an error. The May 24, 1994 text of this change will be revised when report is fixed. Sections WPDBRACF,WRACCMDS, and WRACLINK were revised. Change 12.043 The "Candidates to be moved" report of tape data sets is ANALTMS5 revised so that tape GDGs will be reported as the root May 24, 1994 name, without the GooVoo, and the estimate of tape feet will include all volumes in the GDG. Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
ANALMNTS updated to report on 3490 tape drive counts; however, it ANALTAPE will never be as accurate as ASMTAPES analysis, when that May 24, 1994 Tape Allocation monitor is fully validated! The archaic ANALMNTS, which can only calculate average tape mount time, and which has been effectively replaced by ASMTMNT, was also updated to recognize 3490 tape mounts. Thanks to Richard S. Ralston, Whirlpool Corporation, USA. Change 12.041 Recognition of TCP/IP event type in SMF type 118 record VMACTCP was based on the 4-byte string test, but TELSERVER value May 24, 1994 of 'LOGN' and FTPSERVER value of 'LOGNSEQ' looked same, so the logic was revised to use the length of the record (38-44 is API, 72-86 is TELNET, 194-200 is FTP). While there is a subtype value in the record, it is not fixed (you specify it, with different parameters, in different TCP/IP files, with different syntax, so for me to use it you would have yet another MXG table to update to tell me what you chose!), so I chose to use record length and Yüklə 28,67 Mb. Dostları ilə paylaş:
|