* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
EXSTCHSC for HSC 1.1.0. This change adds support for that new FORMATS subtype, and creates a new STCHSC data set, with some VMACSTC 60 new variables. New $MGSTCxx. formats were also Aug 2, 1990 created to decode several variables.
VMACMDF variables, DOMMIN,DOMTGT,DOMMAX,DOMNORM,DOMATGT,DOMUTIL Aug 1, 1990 were missing. 1.In lines 011700 thru 012300, where these variables were INPUTed as ?? PD4.2, they should instead be PIB4. 2.Insert six new lines, after 014200, to convert these six fields to their screen values: DOMATGT=FLOOR((((DOMATGT)/GBLELTM)+5)/10); 014210 DOMMAX =FLOOR((((DOMMAX )/GBLELTM)+5)/10); 014220 DOMMIN =FLOOR((((DOMMIN )/GBLELTM)+5)/10); 014230 DOMNORM=FLOOR((((DOMNORM)/GBLELTM)+5)/10); 014240 DOMTGT =FLOOR((((DOMTGT )/GBLELTM)+5)/10); 014250 DOMUTIL=FLOOR((((DOMUTIL)/GBLELTM)+5)/10); 014260 Thanks to Vince Loeffler, Searle, USA. Thanks to Martin Tavener, Reed Travel Group, ENGLAND. Thanks to Myron King, The Equitable, USA. Change 08.090 These extensive validation corrections to ACF2 support VMACACF2 correct the ARE processing, and clean up several other Aug 1, 1990 minor bugs. This replaces the temporary fix for the ARE that was made by Change 8.002, and this fix should have been in PreRelease 8.2, but got lost temporarily! 1.Lines 010400-010500, remove ACEEMLTH ACEELDNM ACEVLOFF & ACEFLDVL, as they do not exist. 2.Line 011700, ACLMAMFS should be ACLMAFMS. 3.Lines 032600,032700 change ACTMFTOD to ACSMFTOD. 4.Line 035900, change PIB8. to TODSTAMP8. 5.Lines 037300-037400 can be deleted. 6.Line 046200 can be deleted. 7.Line 016010 inserted after 016000 naming all five of the ACJ..... variables in ACF2TR. 8.Line 062000 (ACVMFRT PIB1.), insert new line after containing +1 9.Lines 049100-055900 were completely re-written to properly decode the ARE segments. Thanks to J. R. Dravnieks, Ladbroke Computer Services, NETHERLANDS.
VMXGSUM erroneous counts if all variables in the MIN=,MAX=,MEAN=, Jul 31, 1990 or SUM= macro arguments contain missing values. Replace three lines 034900-035100 (now reading): %IF %LENGTH(&FREQ) NE 0 %THEN %DO; N=&FREQ
%END; with these two lines: NMISS = MXGNMISS N = MXGMISS Change line 035300 to read: DATA &OUTDATA (DROP=MXGMISS MXGNMISS); Insert the following after line 035600: %IF %LENGTH(&FREQ) NE 0 %THEN %DO; &FREQ = SUM(MXGMISS,MXGNMISS); %END
VMACDB2 subtype 1 data record with a subtype field of zero, which Jul 30, 1990 caused MXG to STOPOVER abend. Although the real cause of the error was a bad record (that was immediately fixed), this change was added to enhance MXG to be more robust and to avoid the STOPOVER even in the face of bad data! It's unlikely you will need to install this insurance: 1.Line 086200 should be LENQLST PIB2. vice OFFQLST PIB2. 2.After line 088700 ( IF QWHSLEN GE 52 THEN ...), insert: IF QWHSNSDA LT 13 THEN OFFRSV3=.; 088710 IF QWHSNSDA LT 12 THEN OFFQJST=.; 088720 IF QWHSNSDA LT 11 THEN OFFQLST=.; 088730 IF QWHSNSDA LT 10 THEN OFFQSST=.; 088740 IF QWHSNSDA LT 9 THEN OFFQVAS=.; 088750 IF QWHSNSDA LT 8 THEN OFFQVLS=.; 088760 IF QWHSNSDA LT 7 THEN OFFQWSD=.; 088770 IF QWHSNSDA LT 6 THEN OFFQ9ST=.; 088780 IF QWHSNSDA LT 5 THEN OFFQ3ST=.; 088790 IF QWHSNSDA LT 4 THEN OFFQWSC=.; 088791 IF QWHSNSDA LT 3 THEN OFFQWSB=.; 088792 IF QWHSNSDA LT 2 THEN OFFQWSA=.; 088793 3.After line 125400 ( IF QWHSLEN GE 52 THEN ...), insert: IF QWHSNSDA LT 7 THEN OFFEDM =.; 124510 IF QWHSNSDA LT 6 THEN OFFQTXA=.; 124520 IF QWHSNSDA LT 5 THEN OFFQIST=.; 124530 IF QWHSNSDA LT 4 THEN OFFQBST=.; 124540 IF QWHSNSDA LT 3 THEN OFFQTST=.; 124550 IF QWHSNSDA LT 2 THEN OFFQXST=.; 124560 4.After line 165700 ( IF QWHSLEN GE 52 THEN ...), insert: IF QWHSNSDA LT 6 THEN OFFR5 =.; 165710 IF QWHSNSDA LT 5 THEN OFFQTXA=.; 165720 IF QWHSNSDA LT 4 THEN OFFQBAC=.; 165730 IF QWHSNSDA LT 3 THEN OFFQXST=.; 165740 IF QWHSNSDA LT 2 THEN OFFQWAC=.; 165750 Thanks to Benny Maynard, BiLo, Inc, USA. ==============Changes thru 8.087 comprised MXG PreRelease 8.2=========== Change 08.087 Lines 046800 thru 047100 should have denominator TRANSNO VMACNSPY instead of TOTRSPNO for calculation of T1RSPPC-T4RSPPC. Jul 20, 1990 If this DO group was entered (not likely), missing values were calculated because TOTRSPNO was missing. This only affected the NSPYLU data set values. Thanks to Marty Quinlan, Virginia Power, USA.
DOC not have ZDATE, some $MG.. formatted variables that were Jul 20, 1990 length 8, some DATETIME variables that were not length 8, and many variables with no label. Uninitialized variable messages were also detected and corrected, and the TREND data base code was added to the MXG Validation/Cross reference testing.
JCLVSAM JCL to build a VSAM ESDS data set that is needed only for Jul 20, 1990 MXG testing of RMF III (VMACZRB) code. Thanks to Jeannie Hopf, Hopf Consulting, USA. Change 08.084 This is a significant internal revision to DB2 reporting ANALDB2R from SMF trace data. Previously, you had to update/edit Jul 20, 1990 member IMAC102 to tell MXG what trace classes had been enabled. If you did not update IMAC102 correctly, MXG would create zero observations in T102Snnn datasets, even though there were SMF records for IFCIC nnn in your SMF file. Now, when you specify PDB=SMF in ANALDB2R, the program is smart enough to know which datasets are needed and ANALDB2R no longer uses IMAC102 to control T102S... datasets. (Note: IMAC102 is still needed if you use the TYPE102/VMAC102/BUILDPDB method of processing DB2 trace type 102 records; this change applies only to ANALDB2R, and only when PDB=SMF is specified to read SMF data.) Additionally, macro variables corresponding to macro names constructed by IMAC102 were added to ANALDB2R to allow you to select specific trace class(s), using the syntax of DB2TC1=YES as the argument when you invoke the %ANALDB2R report macro. Documentation (comments in the member itself) was added to describe the new parameters, and also to list which trace classes must be enabled for each report group. The member was renumberd.
VMACVMXA incorrect (but this should not affect most users, as this Jul 20, 1990 detail dataset is not typically used; instead VXDEVTOT and VXSUMIOD are used and their values were correct). But now, even these variables are always correct. Dataset VXPRCPRP variable HFUSERZ is now formatted 5.1 and multiplied by 100, as it is a percentage, not a rate. Thanks to Dick Whiting, Precision Castparts, USA. Change 08.082 Support for APAR OY32638 which (finally!!) adds PROCSTEP IMAC30 to the type 30 record datasets, and to the PDB.STEPS data VMAC30 set in your PDB. This procedure stepname has been wanted Jul 20, 1990 since OS/360. However, what is still wanted and still not provided in any SMF record is the actual name of the JCL procedure that was executed by the user on the EXEC card! Change 08.081 Support for APAR OY25606/OY33312, which (incompatibly) VMAC30 added a new 4-byte field (SMF30EOS) to replace the 2-byte Jul 14, 1990 existing SMF30EOR. Without this change, MXG variable EXTRADD will contain a value of 61682, but as that is not actually used by MXG, the incompatibility is one of principle rather than one of fact. The EXTRADD field had to be expanded from half-word to full-word to keep count of the number of extra DD segments in additional SMF type 30 records that can be written if the new DDCONS(NO) option is specified. See extensive discussion in IBM's Washington Systems Center Flash Number 9027, and further notes in the next MXG newsletter. Inserted to correct: IF OFFPROD-3-COL GE 6 THEN INPUT @105 EXTRADD PIB4. @; Thanks to George Scott, Rockwell International Corporation, USA. Change 08.080 Support for ORACLE SMF Record. The data set ORACLE is ANALORAC built from the SMF record ID specified in IMACORAC EXORACLE (which should be copied into your USERID.SOURCLIB and IMACORAC changed therein). A set of sample reports are also in TYPEORAC ANALORAC. This user contribution was reformatted and VMACORAC has been tested with a small sample of ORACLE data. Jul 7, 1990 Thanks to David Henley, Signet Bank/BISYS, USA. Change 08.079 Significant validation of RMF III VSAM records is in this VMACZRB user enhancement. In addition to corrections in VMACZRB, TYPEZRB new members ZRBCHECK will check the integrity of these ZRBCHECK datasets produced by VMACZRB, and member ZRBMXIDX now ZRBDLYBT summarizes and builds an index for the datasets that are ZRBMKIDX built from VMACZRB, and member ZRBDLYBT reads the index Jul 7, 1990 and summarized datasets to produce delay reasons for batch jobs. VMACZRB0 is a backup of previous VMACZRB. Thanks to Roland Rashleigh-Berry, National Westminster Bank, ENGLAND.
TRNDJOBS An extraneous comma after line 002900 works under 5.18 Jul 4, 1990 but is flagged as an error under 6.06. This comma is after the last macro argument, immediately preceding the close parenthesis, and was not required, so its gone. Thanks to M. Cambier, Credit Lyonnais, FRANCE. Change 08.077 The variable ACCESS should have been created in the exit ANALDSET for TYPE64, but was not. Insert new line after 007300 Jul 4, 1990 setting ACCESS='VSAM'; Thanks to John R. Grout, Midlantic National Bank, USA. Change 08.076 Further validation of Trending uncovered incorrect code ASUMCICS in these ASUM.... members (that take detail data like ASUMJOBS CICS transactions, JOBs, etc. and summarize in groups). ASUMTMNT 1.Response buckets in ASUMCICS were off by one bucket. In Jul 4, 1990 lines 009900 thru 010500 change LE to LT, and in line 010700 change RESPMAX=RESP to RESPMAX=IRESPTM. 2.Similarly, in ASUMJOBS change lines 003600 thru 004200 from LE to LT. 3.Similarly, in ASUMTMNT change lines 002400 thru 003000 from LE to LT. Thanks to Jim Hinkel, Weyerhaeuser Company, USA.
VMXGVTOC is located at the very beginning of the volume. This Jul 4, 1990 change added about 30 lines to recognize that situation. Thanks to Uriel Carrasquilla, Vancouver Stock Exchange, CANADA. Change 08.074 Preliminary support for IBM System Managed Storage (SMS) EXDCOCLU utility program DCOLLECT, that creates a flat file of EXDCODSN Data Set, Cluster, and Volume information from SMS. This EXDCOVOL significant user contribution creates three MXG datasets, IMACDCOL DCOLCLUS, DCOLDSET, and DCOLVOLS from DCOLLECT output. TYPEDCOL Not all of the variables have been decoded, and the code VMACDCOL may be enhanced in the future with decoding formats. Jul 4, 1990 Thanks to Tom Skasa, General Electric Medical Systems, USA.
VMACVVDS member ASMVVDS and processed by VMACVVDS has uncovered Jun 28, 1990 several errors and additional variables are created. 1.Variables VVRCATSD VVRCOMTP VVRKRQ VVRSELFD VVRSPCFG VVRSPCOP and VVRSSDAT should be added to the KEEP list. 2.These seven new variable's labels should be added: VVRCATSD = 'SELF-DESCRIBING*VVR FOR*CATALOG' VVRCOMTP = 'COMPONENT*TYPE' VVRKRQ = 'KEY*RANGE*QUALIFIER' VVRSELFD = 'SELF-DESCRIBING*VVR FOR*VVDS' VVRSPCFG = 'SPACE*FLAGS' VVRSPCOP = 'SPACE*OPTIONS' VVRSSDAT = 'SEQUENCE*SET*WITH DATA' 3.Add variables VVRALTSP VVRAMSTS and VVRTMSTP length 8 to the LENGTH statement at line 012900. 4.Add variables VVRALSTP VVRAMSTS and VVRTMSTP to the FORMAT statement at line 014300 with DATETIME21.2; 5.After line 016500 (before the END; before 'D8'X), insert IF VVRFLAG='.1......'B THEN VVRSELFD='Y'; IF VVRFLAG='..1.....'B THEN VVRCATSD='Y'; IF VVRFLAG='....0...'B THEN VVRCOMTP='D'; /* DATA */ ELSE VVRCOMTP='I'; /* INDEX */ 6.Change SMFSTAMP8. in 024100, 024200 and 029100 to TODSTAMP8. 7.Change test '....1...'B for VVRA1IUP in line 024900 to instead test '.....1..'B. 8.After line 026000 (after IF VVRAIXFG ...), insert IF VVRSPCFG='11......'B THEN VVRSPCOP='CYL'; ELSE VVRSPCOP='TRK'; 9.In lines 030600 thru 031200 the test for VVRDSATR should instead test VVRAMATR. 10.Change all " IB" to " PIB" (binary numbers should be PIBn. rather than IBn. to prevent unexpected negatives.) Thanks to Tuanhung Doanvo, Philip Morris, USA. Change 08.072 SAS 6.06 Compatibility. ID statement different. TRNDRMFI To avoid a very obscure exposure if SU_SEC was missing, Jul 3, 1990 the order is now ID = NRCPUS PARTNCPU SU_SEC STARTIME,
ANALDB2R The first line of an AUTOCALLd macro cannot be non-blank VMXGGOPT in column 72 of the first line of the member, until SAS VMXGHSM ZAP Z6060946 exists. VMXGINIT VMXGVTOR
Jun 29, 1990 Change 08.070 The MXG 7.7 Tape Mount Monitor (in ASMTMNT) does work on ASMTMNT MVS/ESA as well as MVS/XA (and, also for MVS/370!). The Jun 29, 1990 comment in that member is wrong; the code had been tested under MVS/ESA last year. The argument yy of SYPARM(xx,yy) value of SP builds the MVS/370 monitor, using XA for yy creates a monitor that works on either MVS/XA or MVS/ESA. This change only changed the comments, not any real code.
BUILDPDB 1.The contents of the SPIN library are now copied into the BUILDPD3 PDB library at the end of BUILDPDB/3 processing. This is Jul 3, 1990 both for Backup/Recovery and for possible analysis. Should you ever need to back up and recover your PDB jobs you would simply go back to the last successful PDB, and copy (PROC COPY IN=PDB OUT=SPIN; SELECT SPIN:;) the SPIN data sets from that PDB into your SPIN library, and then re-process the input SMF data. In addition, by inclusion of the SPIN data sets in your PDB, jobs which executed yesterday but have not yet purged will be available in the SPIN30_5 (and their steps in the SPIN30_4) data set for timely reporting. 2.Job accounting variables ACCOUNTn and SHIFT were added to the PDB.SMFINTRV data set. SHIFT is defined by your shift definition in IMACSHFT, applied to the interval INTBTIME begin time stamp. This would allow shift by shift charging for your long running jobs, but if you do so, you must be careful to not double charge between the PDB.SMFINTRV and the duplicate data in PDB.JOBS and/or PDB.STEPS. The BUILDPDB logic was slightly altered by this change. Previously, the PDB.SMFINTRV data set was built by sort of the TYPE30_V before the EXPDBSPN exit. Now, the logic is relocated to after all EXPDB... exits, just before the SPIN library is updated. Completed jobs (PDB.JOBS) and incomplete jobs (SPIN30_1) are now merged with the type 30 interval records and output in PDB.SMFINTRV. Unless you used exit EXPDBSPN and expected PDB.SMFINTRV to exist in that exit, there is no compatibility issue. you have used EXPDBSPN 3.TYPE25 data set (JES3 Main Device Scheduled) is now added automatically to the JES 3 PDB built by BUILDPD3. Change 08.068 SAS 6.06 Options are controlled by the DDNAME of CONFIG CONFIG in the SAS606 procedure. The MXG library now contains Jun 28, 1990 the CONFIG member, which has been used in all of MXG's testing discussed in Newsletter SEVENTEEN. It may change as more is discovered in testing SAS 6.06, but it is here so that you will know what options we had changed from SAS's defaults. You may find a separate CONFIGTSO member useful to specify NODMS, NOCENTER, etc., because SAS 6.06 does not automatically recognize the TSO environment. In the production version 8 there will likely be multiple CONFIG... members.
* THESE ARE SUBJECT TO CHANGE AS WE LEARN MORE ABOUT 6.06. * YOU CANNOT USE /* */ DELIMITER FOR COMMENTS IN CONFIG MEMBER NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB FULLSTATS STIMER
SORTDEV=3380 BUFNO=3
MEMSIZE=12M PROCLEAVE=100K SYSLEAVE=100K VMCTLISA=40K VMPAISA=256K VMPAOSA=128K VMPBISA=512K VMPBOSA=128K PSUP=SASXKERN SORT31PL
SYSIN=SYSIN Change 08.067 ANALDB2R reporting was slightly different than IBM DB2PM. ANALDB2R 1.The Accounting Detail showed average instead of total for Jul 3, 1990 Class 3 System Events. Moved variables QWACARNA,QWACARNE from MEAN= at line 015240 to the SUM= at line 015330. 2.The ELAPSED time on the MXG report was the ending minus starting time, instead of the sum of the plan execution durations. Deleted lines 109400-109430 and 117940-117970 DURATM
%IF ....... %ELSE .... ; in both places. 3.Selection criteria in MXG reports incorrectly used ending time stamp instead of start time, causing MXG to report a different set of intervals than DB2PM. Change to read: line 006590 and 015850 IF "&BEGTIME"DT LT QWACESC; line 006620 and 015880 IF "&ENDTIME"DT GT QWACBSC; line 084930 and 110050 IF "&BEGTIME"DT LT QWHSSTCK; line 084950 and 110080 IF "&ENDTIME"DT GT STRTTIME; Thanks to Piara Singh, Ministry of Health, SINGAPORE. Change 08.066 This change supports the new "SRCL" field added to RMF VMAC7072 product section by APAR OY28449 and PTF UY49092. The VMAC71 text of the PTF claims that VMAC73 "the APAR will not impact the customer unless they VMAC74 have private programs that process RMF - SMF records. VMAC75 The customer will have to modify their programs/execs VMAC76 to include the new SRCL field..." VMAC77 but there is NO impact on MXG 7.7. The new field was VMAC78 already a reserved field in the RMF product section, and VMAC79 its value is currently always zero. This change uniformly XMAC7072 renames the reserved field @OFFRMFP+51 as RMFSRCL, but XMAC71 only for possible future use when IBM actually puts a XMAC73 non-zero value in the field (which is suposed to be an XMAC74 indicator of the RMF source level that created the RMF XMAC75 record). Jul 2, 1990 Change 08.065 This announces support for CICS/ESA Releases thru 3.1.1 EXCIC... Monitor and Performance data. Forty seven MXG datasets FORMATS are created from the new Statistics class data, and new IBCICTRN variables were added to CICSTRAN and CICSEXCE. Two data PRCICALL sets no longer exist in CICS/ESA: CICSACCT was always UTILCICS redundant with CICSTRAN, and CICSYSTM's interval data is VMAC110 now contained in (and significantly enhanced) in the 47 VMAC110B new CIC..... CICS statistics datasets. See the technical VMAC110M note in MXG Newsletter SEVENTEEN documenting changes. Jun 30, 1990 a.The new member VMAC110 contains support for all CICS data (1.5,1.6,1.6.1,1.7,2.1,3.1.0, and 3.1.1) concurrently. b.Member VMAC110B is the backup copy of VMAC110 before the 3.1.1 changes. It will not exist in the next prerelease. c.VMAC110M processes only subtype 1 records for CICS/ESA and previous CICS's; it does not process new Statistics structure, but does know about new fields in the CICS dictionary in 3.1.1. It may be needed to avoid a SAS 344 Compiler Limit exceeded error under SAS 5.18 for sites that do not have SAS 6.06 available. d.FORMATS member on MXG 8.2 contains new CICS formats. e.IBCICTRN labels all CICSTRAN variables with the CMODHEAD name from the dictionary. Then, you can PROC PRINT DATA=CICSTRAN SPLIT='*'; %INCLUDE SOURCLIB(IBCICTRN); to print the CICSTRAN monitor data with IBM headings. Useful when you need to talk to IBM about their data! f.PRCICALL will print (with or without SPLIT='*') all 47 new CIC.... data sets and the pre-existing four as well. The OBS= parameter limits print to first 300 obs, but even that can be lots of paper. g.UTILCICS knows about the CICS/ESA dictionary, but has not yet been updated for connectors, as there has been no need thus far for that enhancement. h.See NEWSLETTER SEVENTEEN for initial documentation. Change 08.064 Boole and Babbage's IMS Measurement Facility (IMF/CIMS) VMACCIMS product Release 2.6 supports IMS 3.1 with no changes in Jun 24, 1990 the IMF data records written to the IMS log, so therefore MXG now (and before) supports IMS 3.1 IMF records! Change 08.063 SAS 6.06 Compatibility. SAS/STAT existence and ID. GRAFTRND Added SASSTAT option to indicate you have SAS/STAT. Jul 3, 1990 Added error message if SU_SEC (used to normalize CPU in plots) is missing. Default device changed to PCBATCH. Code was consolidated, enhanced and renumbered. Thanks to Bruce L. Green, Medical Information Bureau, USA. Change 08.062 SAS 6.06 Compatibility. PROC MEANS vs SUMMARY. ANALBNCH Each PROC MEANS NOPRINT execution with an OUT= option ANALBNC1 was located and (DROP=_FREQ_ _TYPE_) was added after the ANALCACH output data set name in the OUT= option, so that these ANALCICS variables (created because 6.06 PROC MEANS now actually ANALDB2R is PROC SUMMARY) are not kept. At the same time, all ANALDMON PROC MEANS statements were re-ordered so that the NOPRINT ANALDOS option immediately follows the MEANS, for consistency. ANALESV ANALMNTS
ANALMONI ANALMPL
ANALNPMR ANALPROG
ANALSMF ANALTAPE
ANALTURN BUILDPDB
BUILDPD3 IDMSREPT
IMACPDB RMFINTRV
VMACCRAY VMACVMON
VMACVMXA VMXGHSM
VMXGSUM VMXGVTOC
XPAII Jul 3, 1990 Change 08.061 SAS 6.06 Compatibility. PROC COPY GCAT change. GRAFRMFI Replaced use of PROC COPY with the COPY command of PROC Jul 3, 1990 GREPLAY. Deleted GROUPing logic if executed under SAS 6.06. Changed default device to PCBATCH. Change 08.060 SAS 6.06 Compatibility. DROP= validation. VMACVMON Remove MN002RS1,MN002RS2,MN003RSV from DROP= option in Jun 14, 1990 line 361600. Remove INTERVAL from DROP=option in lines 361800, 362000, 362200, 362400, and 362600. Change 08.059 SAS 6.06 Compatibility. Parser error. PROC SORT ANALCICS DATA=_CICTRAN. CICSTRAN fails with a 201 error, but it Jun 14, 1990 accepts _CICTRAN.CICSTRAN or _CICTRAN . CICSTRAN syntax. SAS 5.18 didn't care about blanks before or after the delimiter period in a full data set name. Will not be repaired until SAS 6.07. Thanks to Dennis Longnecker, Admin. for the Courts, WA. State, USA.
JCLTREND to be inserted before line 005900 (PROC PLOT) to avoid a Jun 14, 1990 non-sorted condition. Thanks to Tom Elbert, John Alden Life Insurance, USA. Change 08.057 Invalid type 6 SMF records can cause an MXG STOPOVER. In VMAC6 most cases, the record is created by an external writer May 9, 1990 that lies (by storing subsys of 2 instead of 0, making me believe this is a JES-written record), but it can also be caused by an IBM-written record with incorrect data. This change adds an additional test to detect the invalid record and avoids the STOPOVER. Replace the three lines that test SECTIND (lines 022500, 025400 and 028800) with: IF SECTIND='1.......'B AND OFTONXT+35 LE LENGTH THEN DO; IF SECTIND='.1......'B AND OFTONXT+ 5 LE LENGTH THEN DO; IF SECTIND='..1.....'B AND OFTONXT+46 LE LENGTH THEN DO; Even these tests are not sufficient when a SMF6LN3 value says 162 bytes exist, but the record is truncated, as is found in MVS 3.1.3. For this case, an additonal test was added to line 027100 which now reads IF SMF6LN3 GE 162 AND LENGTH-COL+1 GE 124 THEN Finally, all other conditional input statement are now protected similar to line 027100 to test both the LENGTH minus COL plus one, against the data to be inputted. These MXG circumventions for the defective IBM type 6 record are not necessary if you instead install the APAR OY29986 PTF UY49159 for JES 2 3.1.3 causing the error. Thanks to Mark Stafford, PHH Fleet America, USA. Thanks to Diane McCabe, N.J. Dept. of Treasury/OTIS, USA. Thanks to Leatha Harlow, Sperry Marine, Inc, USA.
VMACSYNC value of hex 00 for SIRECFM, SORECFM, causing an "INVALID May 8, 1990 DATA" message and a dump of the input record. Inserting a double questionmark (SIRECFM ?? 1. and SORECFM ?? 1.) the invalid data message goes away. Thanks to Dave Greene, Kwasha Lipton, USA. Change 08.055 RMF Type 79 data validation continues. Formats have been VMAC79 assigned: R791DP HEX4., R791TRTM and R796TOD TIME12.2, May 8, 1990 and R794AFC MGBYTES. INPUT statements were corrected: May 9, 1990 R791TRTM PIB4.3 and R792TDEV PIB4.6. Line 051300 (4096* R793LOUT) was deleted and removed from MGBYTES format, new lines added 040610 R792TDEV=128*R792TDEV; and added 060110 R794AFC=4096*R794AFC;to correct units. A number of other fields which contain memory(pages/frames,etc) measures were inconsistent. They were either not mult. by 4096, not Formatted MGBYTES, or did not have (MB) in their label to indicate they are in units of K,M, etc. They are all now consistent, and they include: 792: FXBL, PNV, PSWP, PVIO CMNI PIN 794: CMNI CMNO CSAI ERTE HSP LPAI MRTE PRVI PRVO PSPI PSPO and VIO Thanks to Diane Eppestine, Southwestern Bell, USA. Change 08.054 RMF Monitor III VSAM dataset records cause STOPOVER with VMACZRB RMF 4.1.1. Since MXG 7.7 supporte RMF 3.4.1, it is not May 7, 1990 surprising that the lengths in the RELINFO: table needed to be changed. However, actual data record lengths do not agree with IBM documentation, and occasional STOPOVERs still occur (possibly because these records can span a physical record). Further research and validation will be done at a later date, but it appears the code can be used if STOPOVER in line 000200 is changed to MISSOVER, and try these values following the label RELINFO: ASISIZE = 120 (IBM document said 114, MXG 7.7 was 88) GEISIZE = 132 (IBM document agrees, MXG 7.7 was 96) SSHSIZ = 264 (IBM document said 260, MXG 7.7 was 240) Thanks to Jim Stebel, Royal Insurance, USA. Thanks to Richard Evans, Mervyn's, USA.
GRAFRMFI before each PROC GREPLAY to isolate potential problems, May 7, 1990 the test for Version EQ 5 was changed to GE 5.
VMAC37 not complete. In lines 017400, 019100, 021300, 022700, May 7, 1990 024800, 025700, 028100 and 032000 add +OFFSMF after -3. Thanks to Herr Lehmann, GRZ Norddeutschland, GERMANY. Thanks to Herr Kumellis, GRZ Norddeutschland, GERMANY.
GRAFTRND and GOUT=TREND.GRAPHS should be GOUT=&TREND..GRAPHS in May 7, 1990 all five places to be consistent with other references. Thanks to Norbert Korsche, OMV-AG, AUSTRIA. Change 08.050 TSO/MON now supports TSO measurement of Batch execution, VMACTSOM and thus JOB $CHAR7. in line 068700 should be changed to May 7, 1990 JOB $CHAR8. TSO Userid's were restricted to seven chars, but batch jobs can be all eight positions. Minor. Change 08.049 Documentation note. Data set TYPE78CF will contain an VMAC73 observation only if a CHPID is online (because NRCUS must VMAC78 be non-zero), but the TYPE73 dataset will contain an obs May 7, 1990 for each CHPID in the record, whether online or not. Why the difference? They were written at different times! To be consistent, I should externalize both tests to the exit members and consistenly keep only those CHPIDS that are online (to minimize the unnecessary data in your PDB) but for now I will leave it the way it is. Thanks to Laurie Maser, Central Illinois Light Company, USA. Change 08.048 Variables ABNDRSNC DIVRREAD DSSIZHWM and TERMNAME were IMACPDB not kept in PDB.STEPS from TYPE30_4, but now were added VMAC30 in macro _PDB30_4 in member IMACPDB, so they are. Also, May 7, 1990 variable DSSIZHWM was added to the KEEP list for dataset TYPE30_V (and thus also will be in PDB.SMFINTRV) Thanks to Diane Eppestine, Southwestern Bell, USA. Change 08.047 ACF2 dataset ACF2JR will have fewer observations with EXACFJR MXG 7.7 than it contained with MXG 6.6, because a test May 4, 1990 in EXACFJR inadvertently deleted SMF records. Remove the temporary fix "IF ACLEMLTH LT 256;" statement and its associated comment. Thanks to Ilana Towery, Houston General Insurance Company, USA. Change 08.046 Pre-release 8.1 shipped to support ESP product. May 4, 1990 Change 08.045 MXG's algorithm to detect the wrap of the 202-day clock VMACVMON in VM/SP failed at 24APR90:08:22:10. MXG's next timestamp May 4, 1990 was 02OCT89:17:40:04, and the rest of the records in that VM Monitor file had the Oct 2, 1989 date, because 16* was left out of line 029400 when Change 6.023 was installed. The test for new interval in line 029400 should read: IF LASTHALF AND 16*MNHTOD LT FFFFFOV2 THEN DO; The incorrect STARTIMEs only occurred on the day of the clock wrap; the next MXG run (or a monitor start event) corrected the MXG error. Thanks to Nancy Ayers, General Electric Lighting, USA.
EXCRA... operating system accounting and performance records. This VMACCRAY support requires SAS Version 6.06+ (because of ASCII May 3, 1990 character variables). Future revisions will support the COS 1.17 changes, and eventually, UNICOS as well. There are 6 CRAYA... datasets built from account records, 16 CRAYP... datasets built from SPM performance records, and the MXG-built CRAYPINT "Interval Performance" dataset built by sum/merging those 16 SPF datasets. These datasets are currently built: CRAYAEJ Label='Accounting Job Termination' CRAYAET Label='Accounting Task Termination' CRAYAFU Label='Accounting BMR Device Utilization' CRAYAGU Label='Accounting Generic Resource' CRAYAPD Label='Accounting Permanent Data' CRAYATA Label='Accounting Tape Data' CRAYPCP Label='SPM CPU Times and Task Times' CRAYPTK Label='SPM Task Requests' CRAYPER Label='SPM Executive Requests' CRAYPMU Label='SPM Memory Utilization' CRAYPDU Label='SPM Disk Utilization' CRAYPDC Label='SPM Disk Channel' CRAYPLU Label='SPM Link Utilization' CRAYPEC Label='SPM Executive Calls' CRAYPUC Label='SPM User Calls' CRAYPPU Label='SPM Preemptable Generic Resources' CRAYP11 Label='SPM JSH Statistics' CRAYP12 Label='SPM Job Class Information' CRAYP13 Label='SPM JSH Request Count' CRAYPIC Label='SPM Channel Interrupts' CRAYPSB Label='SPM System Buffer Utilization' CRAYPINT Label='SPM Interval Performance' Change 08.043 NETSPY Version 3.1 (3.2 is current) can cause a STOPOVER VMACNSPY because the test in line 032300 should be NSPYENTL GE 177 Apr 30, 1990 (the current test was NSPYENTL GE 167). Thanks to David B. Adams, National Life of Vermont, USA. Change 08.042 IMS log processing variable VTAMNODE should be added to VMACIMS the IMS03 and IMS36 dataset KEEP list and removed from Apr 30, 1990 the IMS01M dataset KEEP list. The two occurrences of IF VTAMNODE GE ' ' ... should be changed to now test for IF VTAMNODE NE ' ' .... Thanks to Pete Shepard, Ashland Oil, USA. Change 08.041 EXPLORE/VM second occurrence of CHANBUSY in the LABEL and VMACVMXP INPUT statements (lines 054000 and 056600) should be Apr 30, 1990 changed to CHANBUS2 and variable CHANBUS2 should be added to the KEEP list (line 005700). CHANBUSY is the IPL-proc Channel Busy and CHANBUS2 is the non-IPL-proc chan busy. Thanks to Pete Shepard, Ashland Oil, USA. Change 08.040 MXG 7.7 can have 0 observations in CICS datasets built VMAC110 from CICS 1.7 records. An anticipatory change was added Apr 30, 1990 that used a reserved field, but the field is not always Jun 30, 1990 zero in 1.7 (but it seems okay in CICS 2.1). Either delete line 025320 (IF SUBTYPE NE 0 THEN DELETE;) for the present, or if you have both CICS 1.7/2.1 records and are also testing CICS/ESA 3.1.1, change the logic to:
IF '02' LE OLDVERCI LE '03' THEN SUBTYPE=0; IF SUBTYPE NE 0 THEN DELETE;
is the SMFPSNPS (number of product sections, always '0001'X), and OLDVERCI in CICS 2.1 and earlier will be 'F0F2'X or 'F0F3'X.
Thanks to David Ayresman, University of Louisville, USA. Thanks to Hunter Chang, Sydney County Council, AUSTRALIA. Change 08.039 TYPE6156 variable VOLSERs are wrong when additional VMAC6156 "GOOVOO" entries follow the GOOVOO for this Entry. The Apr 30, 1990 logic to update VOLSER in MXG was incomplete in this instance. a.Add DO; after the THEN which ends statement 019600. b.MOVE lines 019600-019700 to after 020600 (the @;). c.Insert new line 021610 (after 021600, END;) containing END; (to complete the new DO; added above). Thanks to Tim Kearney, Allied-Signal, Inc, USA.
VMAC28 with these changes (mostly to VM:) Apr 23, 1990 a.In FNMINIT FNMPARM A in the NPM MACRO the session parameter was modified to read session=(session,NPMLOG), i.e., to write session data to the NPMLOG as well as the session log. b.In NPMSTRT GCS A the FILEDEF for FMNLOG1 and FMNLOG2 was modified to read FILEDEF FNMLOG1 DISK FNMLOG1 LOG A4 FILEDEF FNMLOG2 DISK FNMLOG2 LOG A4 c.To process the log the FNMLOG1 or FNMLOG2 was copied to a file with a FILEMODE of A1 which was then used as the input for MXG. The FILEDEF for the input file was also specified with FILEMODE A1. d.VMACSMF was copied and modified to create a new macro named _SMF, which is a copy of the _SMF macro, but which deleted the VBS and LRECL options on the INFILE statement in the modified copy. Thanks to W. C. Cronje, Anglo American Corporation, SOUTH AFRICA. Change 08.037 VM/370 variable MN000PPC can be zero if preferred paging VMACVMON is to expanded storage, causing a divide by zero error Apr 23, 1990 in calculation of DRUMUTIL variable in line 116600. That calculation is now precedeed by IF MN000PPC GT 0 THEN. Format MGVM6TY has new value 2420X='2420:3380' added. Thanks to Gary Zolweg, National Semiconductor, USA. Change 08.036 Variable CREATIME in dataset MONITASK has date of END if TYPEMONI a transaction spans midnight. Logic to correct date was Apr 23, 1990 perturbed by Change 7.171. To correct, change line 00503 to read IF CREATIME LE TIMEPART(ENDTIME) THEN instead of IF CREATIME LE ENDTIME THEN. Thanks to Steve Cavill, SAS Institute, AUSTRALIA. Change 08.035 This one is obscure. CICS type 110 records with a error VMAC110 are usually detected by MXG and STOPOVER prevented, but Apr 18, 1990 if the invalid segment happens to be the last segment in a type 110 record, a STOPOVER can still result, because line 032200 (CONNBYTE+DRLENNUM GT BYTELEFT AND ...) should be CONNBYTE+DRLENNUM GT BYTELEFT-38 AND ...). Thanks to Earl Ryan, Life Insurance Company of Georgia, USA.
VMAC6156 and R for type 66, but S and U have been found in SMF Apr 17, 1990 type 66. Now, MXG tests for R, S, or U for either type in creating MXG variable FUNCTION. Thanks to John Mattson, National Medical Enterprises, USA.
VMACTMNT not formatted to HEX4. (add them in line 004600), and Apr 12, 1990 DEVNR should be removed from line 020000. Thanks to Glenn Thompson, Comalco, AUSTRALIA. Change 08.032 VTOC processing variable RECFM should have been $4. in VMXGVTOC line 032000 (instead of $3.), although it is unlikely Apr 12, 1990 to ever see a non-blank in the fourth position. Thanks to Wyman Young, BHP, AUSTRALIA. Change 08.031 DB2 Lock Detail report PMLOK03 fails with a 170 format ANALDB2R conflict error, because variable ELAPSED was previously Apr 12, 1990 defined as a numeric variable. In three lines within the PMLOK03 macro, lines 073560, 073570 and 073780, change the variable name ELAPSED to LOCKTMCH. Thanks to Dennis Longnecker, Wash. Office Admin for Courts, USA Change 08.030 DB2 reporting from GTF (instead of SMF or PDB) failed, ANALDB2R with "GTF is not a SAS library" error. We had failed to Apr 11, 1990 test the GTF option in MXG 7.7. The correction is to change line 002670 from %IF &&PDB&I = SMF %THEN .... to read
%IF &&PDB&I = SMF OR &&PDB&I = GTF %THEN .... Thanks to Cindy Schinker, AgriData, USA. Change 08.029 TSO SPF EDIT subcommand COPY should NOT be used to copy TSO-SPF an MXG member into your USERID.SOURCLIB library from the Apr 10, 1990 MXG.SOURCLIB, because the COPY subcommand of EDIT will renumber the lines! Always use SPF COPY Command (3.3) to copy members without renumbering, so that numbering will be preserved. (It's not clear when this began to happen, nor whether its an IBM design change or an error; if you know more on the subject, let me know!) Change 08.028 ROSCOE Audit records were not being output in ROSCOAUD. VMACROSC Because there is no ROSCOE version identifier in their Apr 10, 1990 record, an ad hoc test (TIME = . ) used to detect earlier versions now prevents testing for audit records. In line 073500, replace the (TIME = . OR ROSREC = '30'X) with (ROSREC='F0'X OR ROSREC='30'X OR 'A0'X LE ROSREC LE 'AB'X) to process those record subtypes. In addition, variables ACCTCODE FORMKEY and USERID were added to ROSCOAUD keep. Thanks to Tom Braswell, Dow Jones & Company Corporate DP, USA.
VMAC6156 record was incorrectly decoded. Correction: Apr 10, 1990 Delete line 015700 (was ICFPSWRD $CHAR32.) Change line 016800 from LENTHIS-87 to LENTHIS-55 Remove ICFPSWRD= from line 017200. Thanks to Brian Kaczkowski, AgriData, USA. Change 08.026 PDB.JOBS variables JINLTIME and JRSTTIME were up to four BUILDPDB minutes (about 255 seconds!) earlier than JSTRTIME! This BUILDPD3 truncation occurs when a DATETIME variable is stored in a TYPEDOS length 4 variable. Because MXG's default numeric length UTILXRF2 is 4, all DATETIME variables must be explicitly named in VMACARB a LENGTH 8 statement, and MXG's QA test member UTILXRF2 VMACROSC is supposed to detect occurrences of DATETIME variables VMACTMVS with length other than 8. Why did this slip thru QA? Due VMACVMON to a logic error in UTILXRF2, only DATETIME variables in VMACX37 more than one MXG-built dataset were tested for length 8! VMAC102 1.Fixing that error uncovered additional DATETIME variables VMAC24 that have now been explicitly set to length eight: VMAC60 VMAC6156 Member Line Number Dataset Variable(s) VMXGVTOC VMACTMVS 073000 TMVSJIST JISTSTOP,JISTSTRT Apr 17, 1990 VMAC24 006500 TYPE24 OFLDTIME BUILDPDB 044100 PDB.JOBS JINLTIME,JRSTTIME BUILDPD3 044500 PDB.JOBS JINLTIME,JRSTTIME VMAC102 411100 T102S100 QW0100SA,QW0100SB VMACROSC 070100 ROSCOHU ROSTERM VMACVMON 213910 VMONSUSP TODSTIME
to detect character variables with a $MG.... format that are also length 8. This causes no error but wastes seven bytes, and results when the formatted variable was not in a LENGTH $1 statement. This new test identified these variables which needed a LENGTH statement: Member Line Number Dataset Variable(s) VMAC60 009700 TYPE60 ENTTYPID VMAC6156 004300 TYPE6156 ENTTYPID
did not contain LENGTH DEFAULT=4 statements, causing numberic variables to be 8 bytes instead of only four. DEFAULT=4 was added in VMACARB, TYPEDOS, and VMACX37, and SMFTIME READTIME JINTTIME 8 was added in VMACX37. In VMXGVTOC, VOLUME $6 was added to the LENGTH statement (VOLUME is returned by SAS's VTOC option as a 30-byte variable, which caused VOLSER to also be thirty bytes!) Thanks to Elliot Weitzman, Oryx Energy Company, USA.
JCLTEST have used IMACKEEP to modify the default KEEP list. There Apr 10, 1990 is no problem with their normal BUILDPDB, etc., but it appears there is another SAS 5.18 internal limit that is encountered. One set of symptoms are ERROR: WORK.DIRMACR REQUIRES MORE SPACE ... with either THE LIBRARY IS IN 16 EXTENTS or THE LIBRARY IS IN nn EXTENTS, AND NO MORE SPACE IS AVAILABLE ON VOLUME. Other failures show up as a DATA SET NOT FOUND when the PROC MEANS or PROC PRINT is invoked, and the SAS LOG shows the program simply stopped building datasets, with no error. Increasing WORK space does not correct the problem. (While not documented in the JCLTEST member, the default JCLTEST requires a max of 12 cylinders work space for any step with MXG 8.2). Nor did REGION size have any effect. When the abend is DASD space related, the SAS message usually indicates DATA SET WORK.DIRMACR WAS AT OBSERVATION 16744450!
macros due to the repetitive include of IMACKEEP in this test jobstep, which exhausts some internal limit for old style SAS macro re-definitions. But since the error is circumventable (run JCLTEST without the sites' modified IMACKEEP), since the error hopefully does not exist in SAS 6.06, and since I haven't taken the time to create a repeatable test for SAS Institute to use to detect and fix their problem, it is left with this documentation note, until time or more errors cause further study! Thanks to Marvin Rockhill, Community Hospitals of Indiana, Inc, USA. Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA. Change 08.024 STOPX37 product SMF record had minor corrections to the VMACX37 SELECTBK and ACTIONBK variables (changed from $CHAR10. Mar 27, 1990 $CHAR8.) and MESSAGE variable (changed from @509 $CHAR144 to @513 $CHAR140.), but no loss of data had occurred. Change 08.023 Lengths of five character variables were truncated due to ASUMCICS incorrect initialization in this summary member for Trend Mar 27, 1990 Data Base. Variables OPERATOR,TERMINAL,TRANNAME,TRANSACT must be four instead of three bytes, and variables SYSID and APPLID must be eight instead of three bytes in their initial statements (where now set equal to 'MXG'). Thanks to Mike Hoevenaars, Toyota, CANADA.
EXTY39EL 1.VMAC37 needed new formats $MG037FE, $MG037FI, $MG037FU FORMATS for variables BRL/BRRFEAER, BRL/BRRFEAIN, BRL/BRRCTRC, VMAC37 which also were added to the LENGTH statement with $1. VMAC39 LABEL for BRLTYPE should be LOCAL instead of REMOTE, and Mar 27, 1990 variables were added to the KEEP list: BRRTYPE, BRLTYPE, BRLMODEL, and BRRMODEL. 2.VMAC39 needed ZDATE added to all KEEP lists, and the existing-but-never-referenced EXTY39EL member for the TYPE39EL (route elements) data set is now referenced. Because TYPE39EL can get large, and because no one has said they actually use the TYPE39EL dataset, the EXTY39EL exit now DEFAULTS to create NO observations TYPE39EL. Thanks to Bruce Widlund, Texas Utilities, USA. Thanks to Doug Drain, National City Bank, USA.
ANALDB2R created by MXG 6.6, causing uninitialized variable error VMXGSUM messages. MXG uses SAS's NOVNFERR (No Error when Variable Mar 27, 1990 Not Found) but when the variable is in a BY statement or Apr 10, 1990 a PROC MEANS control statement, NOVNFERR does not prevent Apr 15, 1990 the error condition. The usual fix would add a statement (IF x=. THEN x=.;) for each variable which might not be in the input dataset (which fakes out the SAS compiler by creating a variable if it does not exist). ANALDB2R was changed (but when it was realized that these "fakes" already existed in the OUTCODE macro argument, and that MOVEing the lines from OUTCODE to INCODE would avoid any retyping (with its high exposure to typing error), and was more robust. The first three reports worked fine. But the DB2 Accounting Detail report added 150 OUTCODE lines to the existing 380 INCODE lines, and SAS died with the "Excessive Parameter Length" Error, because 380 lines do fit in MWORK=28K, but 380+150 lines break the maximum! Yüklə 28,67 Mb. Dostları ilə paylaş:
|