* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Jun 4, 1997 -The "DW" record INPUT was realigned, DWWLRTME was changed Jun 24, 1997 from TIME8 to HH &NUM.2 and DWWLRDAT's JULIAN input was revised so the code will work under EBCDIC or ASCII SAS, and the variable text is now correctly input. -The "DE" record has the common header; the test IF LMRKREC='DA' OR LMRKREC='DB' THEN INPUT was expanded to also test OR LMRKREC='DE'. Thanks to Tricia Dudley, SAS Institute Cary, USA. Thanks to Luc Gariepy, Regie des rentes du Quebec, CANADA
VMAC102 -The +2 after QW0125MR must be +1. This error affected Jun 5, 1997 only variable QW0125NR. -The DO OFFSET=QWT02R2O in the IFCID 125 section was replaced with DO _I_=1 to QWT02R2N logic from IFCID 172. Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Thanks to Harmuth Beckmann, Karstat AG, GERMANY.
VMAC42 MAXRSPTM and MAXSRVTM (Max Response/Service Time) to data Jun 3, 1997 set TYPE42DS. Other minor changes were made.
VMACTAND Documentation indicates compatibility, in that new data Jun 3, 1997 fields are added at the end of the record, but you will Jun 20, 1997 still find it INCOMPATIBLE, because you will have to change the LRECL of each MVS dataset into which the data records are sent when you install the versions with new data. Initially, it appears there is no problem with D42, but I need to review the later three systems and will update this note when I know more. Thanks to Tim Crocker, AT&T Universal Card Services, USA. Change 15.110 Enhancements so MXG Tape Mount records that will be in VMACTMNT ML-14 of ASMTAPES (see later Change) are coded now: Jun 2, 1997 -New variables are added to TYPETMNT: DEVFLGS, UCBSTAT, UCBFL1, UCBSTAB, DDNAME, STEPNR, ALOCSTRT, and TMNTMAIN. -Existing unpopulated variables will be populated by the changes in ASMTAPES at ML-14: READTIME, INITTIME -Variable JESNR now supports 5-digit JES numbers. -The interval start value did not replace ALCSTIME with the interval-start time for interval records created if a job spans a day boundary; in error, the allocation timestamp of the original allocation was stored. Thanks to Mark Kemig, VF Services, Inc, USA. Change 15.109 Format MGBYTRT (bytes-per-second) truncates on the left FORMATS (1099KB/Sec prints as 99KB/Sec) because the DEFAULT=8 in May 30, 1997 the PICTURE MGBYTRT statement must be DEFAULT=10. After making that change, you need only to re-build your format library by %INCLUDE SOURCLIB(FORMATS); (with the //LIBRARY DD allocated with DISP=OLD under MVS). Thanks to Leigh Ann Payne, Wachovia Operational Services Corp, USA.
VMACDCOL to 'USE HARBC/HURBC*INSTEAD OF*HARBA/HURBA?' to flag that May 29, 1997 variables DCAHARBC and DCAHURBC, according to IBM, should be used for VSAM space (high RBA) allocated and used in place of DCAHARBA/DCAHURBA variables. Also, variables DCAHARBC and DCAHURBC are now formatted MGBYTES. In merging DCOLDSET and DCOLCLUS for VSAM datasets (to get HLQ classifications by storage group with accurate allocated/used statistics), John noted that sometimes, the High Used RBA was greater than the Allocated Space (i.e., DCAHURBC GT DCDALLSP). Chuck tracked this to obs for the Index component for VSAM datasets which used IMBED or REPLICATE; it appears that the index bytes that are imbed/replicated in the Data Component are being counted in the RBA for the Index Component, causing it to appear to have more "used" than "allocated". Thanks to John Astle, National Australia Bank, AUSTRALIA. Thanks to Chuck Hopf, MBNA, USA. Change 15.107 New TYPE8025 dataset is now created for RACF Event 25, EXTY8025 RACF RVARY Command. Variable RACFTYPE was removed from IMAC80A the KEEP= list, as it contained the TYPE value of only VMAC80A the last segment in a type 80 record. (Variable TYPSTRNG May 29, 1997 lists all segment types found in each record). Thanks to Joseph J. Faska, Depository Trust, USA. Change 15.106 Support for APAR OW20921 which created TYPE42VT dataset EXTY42VT with response time statistics like TYPE42SR, but for the IMAC42 VTOC, VTOC Index, and VVDS for each volume. This APAR VMAC42 also added stripe count and flag variables to TYPE42DS. May 28, 1997 In the new TYPE42VT, there are occasional observations with AVGIOQMS less than zero (-.127 maximum), indicating that the data is not exact. Thanks to Tim Vanderhoek, Fidelity Systems Company, USA. Change 15.105 Variables in dataset QAPMAPPN read in after ANDBE8 were VMACQAPM wrong; the offset 1464 was incorrectly repeated in two May 27, 1997 lines. Subsequent offsets have now been corrected. Variable ATCSDR is INPUT @558 vice @588 now. Thanks to Freddie Arie, Lone Star Gas, USA.
VMACPW -VMACPW: TOIOOPCT should have been TOIOPCRT, first VMAC102 SWINOPCT is now SWINCTCT and first SWOUOPCT is SWOUCTCT. VMACSTRS -VMAC102: second QW0221AN was removed May 26, 1997 -VMACSTRS: second TOTSERV was removed Thanks to Freddie Arie, Lone Star Gas, USA. ===Changes thru 15.103 were included in MXG 15.02 dated May 23, 1997=== Change 15.103 Support for RACF data for OMVS RACF using IBM's IRRDBU00 EXRAC120 unload utility creates two new datasets, thanks to this EXRAC270 user-contributed enhancement. New datasets are: IMACRACF Dataset Description VMACRACF RACF0120 Group OMVS Data May 22, 1997 RACF0270 User OMVS Data Thanks to Ben Cowan, University of Nevada System, USA.
EXFTEKIC three new datasets: EXFTEKID Dataset Description EXFTEKGL FILTEKIC IC Command Link Task Record IMACFTEK FILTEKID ID Data Transfer Task Record TYPEFTEK FILTEKGL GL Global Statistics Record VMACFTEK This is preliminary; the Global record is not complete. May 22, 1997 Thanks to Joseph J. Faska, Depository Trust, USA.
VMXGCOMP lists datasets in one and not in the other, and then May 22, 1997 generates PROC COMPARE on all datasets that are common to both Data Libraries. The observations compared are limitable via an option. Thanks to Chuck Hopf, MBNA, USA. Change 15.099 A new macro that resets the setting of most SAS Options VMXGOPTR (those whose name is 8 bytes or less and which can be May 22, 1997 changed after SAS Initialization). The current setting is kept so that MXG can change it and then reset it to the original value (Change 15.098 uses it in VMXGSUM to reset the OBS= option). Documentation is in the member. Thanks to Chuck Hopf, MBNA, USA.
VMXGSUM to examine SAS Options to detect that OBS=n (as opposed May 22, 1997 to the default OBS=MAX) was specified. OBS=0 causes the PROC CONTENTS (used to determine which variables to keep) to have no observations, so the list of kept variables is wrong. (Even OBS=n will cause trouble, if n is less than the number of variables to be kept). With this new enhancement, VMXGSUM detects the OBS=value, sets OBS=MAX for the Keep-Variable-Create phase, and then resets OBS to its original value. This greatly improves MXG QA runs, which use OBS=0, by eliminating unnecessary messages! Additionally, VMXGSUM now allows use of USER= and the TEMP01/TEMP02/TEMP03 options. Thanks to Chuck Hopf, MBNA, USA. Change 15.097 RACF "SKIPPED SEGMENT RACFEVNT=xx:desc RACFTYPE=nn ...." VMAC80A messages are normally harmless; they indicate that your May 22, 1997 RACF record contained a segment (RACFTYPE=SMF80DTP=nn) that MXG did not know about in creating TYPE80A dataset. (The event causing the type 80 record is RACFEVNT, which might not even be an event of interest to you!). You can look at Table 2. Relocate Section Variable Data in Chapter 4 in "RACF Macros and Interfaces" SC23-3732 to see a) is the DTP value documented, and b) do you care! If the segment contains data of interest, when I get a hex dump of a record with the new segment, I will decode the segment and add new variable(s) to the event dataset; if the data is of no interest, I add logic: WHEN (91) DO; /*FOUND IN 27:GENERAL AUDIT, NO DOC*/ INPUT +RACFDLN @; END;
to member VMAC80A to bypass the segment without notice. (the example skips the un-documented DTP=91 value found). Thanks to Bruce Hewson, CITICORP, SINGAPORE.
VMACNSPY -Variable APLUIDR in VMACNSPY is now format $HEX8 (the VMACLMS length was only two bytes because $HEX4. preceded its VMACOMCI INPUT statement). VMACRMDS -Variable TDBSYS in VMACLMS is now initialized to a value May 21, 1997 of 'TMS ' so the kept length is eight bytes. Variable ISITSL in VMACLMS is LENGTH $3, and the INPUT @53 is changed to ISITSLX, as are following five IF's. -Variable EWAITDC in VMACOMCI was removed from $NOTRAN informat list (because INFORMAT was seen before INPUT, variable had kept length of only one). -Variable RMDSFORM is set LENGTH $9 because later code INPUTs as 9, but first occurrence was for 8. Thanks to Chris Weston, SAS Institute Cary, USA. Change 15.095 Support for DB2 Version 5.1.0. FORMATS New formats $MGD022A, MGD022Q, and $MGD221M were added. VMACDB2 Type 101 Record (DB2ACCT) Compatibly changed. VMAC102 Eight new variables added: May 21, 1997 QWACSUCV='THIS CPU SU_SEC*SERVICE*UNITS PER*SECOND' QXCOORNO='PARGROUPS*EXECUTED*COORD PARM NO' QXCRGTT ='CREATE*GLOBAL*TEMPORARY*TABLES' QXISORR ='PARGROUPS*EXECUTED*REPEAT*READ' QXSTREOP='REOPTIMIZATION*OCCURRENCES' QXXCBPNX='PARGROUPS*INTENDED*RUN*DATASHARE' QXXCSKIP='BYPASSED*DB2S*NOT ENUF BUFFERS' QBGADG ='CF UNREGISTER*PAGE*REQUESTS' Type 100 Subtype 0. DB2STAT0. Compatibly Changed. One new Q9STxxxx variable, three QDSTxxxx variables, and six QXxxxxxx variables added. Type 100 Subtype 1. DB2STAT1. Compatibly Changed. Twelve QBGLxx variables added. Type 100 Subtype 1. DB2GBPST. Compatibly Changed. Twelve QBGLxx variables added. Type 100 Subtype 2. DB2STAT2. Compatibly Changed. One variable, QDBPXSQT, added. Type 100 Subtype 3. DB2GBPAT. Compatibly Changed. One variable, QBGBGAS, added. Type 102 Record. Only IFCIDs listed have been validated. IFCID 022. INCOMPATIBLY changed. Record restructured Fifteen new variables added. IFCID 221. INCOMPATIBLY changed. INPUT STATEMENT EXCEEDED Record restructured. Ten new variables added. IFCID 222. Compatibly changed. Three new variables. However, MXG created Pipe Duration in variable QW0222SM by subtraction, but now IBM uses that name, so Pipe Duration time is now calculated in variable QW0222PD. IFCID 231. Compatibly changed. Five new variables. Thanks to Ted Blank, IBM, USA. Change 15.094 -Variable R723TYPE was kept as LENGTH $23 because it was VMAC7072 not in the LENGTH $1 statement, so SAS took it's length VMAC110 from the MGRMFTY format. Now it is kept as LENGTH $1. VMAC74 -Variable LDGDSAIN was listed both as $1 and $2, but is May 21, 1997 now only in the $1 list. -Variable R744QSIZ is now formatted MGBYTES; the variable R744QFLG is formatted $HEX2. and added to $NOTRAN. -Variable MCDFLG3 (IF '1.......'B, DATASET is KB) is now input @291 MCDFLG3 &PIB.1. in the MCD section, formatted HEX2., labeled, and kept. Thanks to Neville Wright, Telstra, AUSTRALIA. Thanks to Lindsay Oxenham, Telstra, AUSTRALIA. Change 15.093 Comments were revised to explain why the error messages: JCLPDB6 ERROR: ALL VALUES MISSING FOR PLOT OF xxx May 21, 1997 ERROR: THERE ARE NO VALID OBSERVATIONS FOR VARIABLE yyy may print on the SAS log when you run the JCLPDB6 sample job to build the PDB, and why they actually tell you the BUILDPDB run was successful. (Briefly, they are from the ANALxxxx members, and to have gotten that far is to have successfully built the PDB library; they occur because of "shotgun" reports that include old and new variables so everybody gets some sample report output.) Thanks to Robin Mitchell, SmithKline Beecham, USA.
CICINTRV in MXG 15.01 (last minute changes to add READTIME were May 20, 1997 tested but not migrated); now I realized that the change was redundant, as CICSSTCK is logically the READTIME! Note that the DURATM variable in PDB.CICINTRV is the sum of the durations of the discrete intervals that were summed into this observation, and might not be the delta between COLLTIME values. MXG defaults to HALFHOUR, but if you are only recording USS records, and you took the IBM default interval, your records will be written every three hours, so PDB.CICINTRV will have an obs with the COLLTIME of the half hour preceding the end of that interval, but the DURATM value will be the 3 hours represented by the actual data in that observation. Thanks to Ben Cowan, University of Nevada System, USA.
IMACPDB to macro _PDB26J2 in IMACPDB so that they will be kept in May 20, 1997 dataset PDB.JOBS. The ACTBYTES is the total number of bytes of SYSOUT text that was created by each job, and is useful in determining the JES2 Track Group Size. Thanks to Clark Jennings, Reynolds Metal, USA. Change 15.090 -Support for Microsoft Windows NT 4.0 Service Pack 2 which EXNTACSR INCOMPATIBLY inserted a null field in the Process record, EXNTCNFI and support for Version 5.0 of MS Exchange, which added EXNTCNIN (need I say INCOMPATIBLY) eight real fields and 33 null EXNTHTIN fields to MSEXCHDS and MSEXCHPR datasets. NRDATA count EXNTMSIM was corrected for MSEXCHDB dataset. EXNTMSIP -Support for NTSMF Version 2.0. Change 15.027/MXG 15.01 EXNTMSWB did not (in spite of saying so) handle the new records. EXNTWBPR -Support for several new datasets (new objects): EXNTWSPR Dataset Object IMACNTSM ACTVSRVR Active Server Pages VMACNTSM CONTINDX Content Index May 20, 1997 CONTINFI Content Index Filter HTTPINDX Http Contents Index MSEXCHIM MS Exchange Internet Mail Service MSEXCHIP MS Exchange Internet Protocols MSEXCHWB MX Exchange WEB Component WEBPROXY WEB Proxy Server Cache WINPROXY WinSock Proxy Server -Of the 68 objects now supported, all but 16 have been tested with data records.
VMAC94 record. SMF94VR3 should be +2 vice +1, while variables May 17, 1997 SMF94VDC,VDX,VDN and VDA should be &PIB.1. vice &PIB.2. This only affected the new section added for VTS. Thanks to Pat Quinette, Principal Mutual Life Insurance Co., USA
ANALDDCN "./" IEBUPDTE control cards for several IMACxxxx members, PROCSRCE so when you unloaded the IEBUPDTE file to create your MXG May 8, 1997 SOURCLIB, those "./"s created those IMACs from ANALDDCN (and by design they DROPed most variables from type 30s). But fortunately, the real "./" cards for those IMACxxxx members were found later on in the MXG tape, so they successfully replaced the incorrect members, so your SOURCLIB was correctly built!
ZNALDDCN, your SOURCLIB would have been wrong!). It used to be that IEBUPDTE set a CC=4 when a new member replaced an existing member, but no longer; the IEBUPDTE set CC=0. The only clue is in the print message "IEB816I MEMBER NAME FOUND IN NM DIRECTORY. TTR IS NOW ALTERED" (but IEB messages print to the //SYSPRINT DD, which is DD DUMMY because it is hugh (1,005,099 print lines, 126 MB, because IEBUPDTE prints all 980,991 lines of MXG 15.01, plus 8 lines of IEBxxxx messages and blank lines for each of MXG's 3,200 members, plus pages and the JES log!).
input while creating the IEBUPDTE format file, so this error should not be seen again. Thanks to Freddie Arie, Lone Star Gas, USA. ===Changes thru 15.087 were included in MXG 15.01 dated May 6, 1997=== Change 15.087 QA tests for MXG 15.01 generated these corrections: JCLQAJOB -CICINTRV. Variables SDGTSUPR/SDGTTKN were misspelled and May 6, 1997 are now SDGSSUPR/SDGSTKN. -VMACDALO. Variables DALODDN/CODE/JFCB are now labeled. -DIFFDB2. Variables PREVGN,DIFDB21,PREVBPID are dropped, and dropped only once. -VMACIMS. Many unlabelled variables are now labeled, and LABEL statements consolidated. Change 15.086 Support for World Wide Web Proxy logs in Common Log TYPEWWW Format to track an installation's access frequency and May 4, 1997 destinations for URLs and IP addresses via the WWW is provided in this user contribution, which is based on Dan Squillace's CMG96 paper. Comments in TYPEWWW by Brian document his approach to decoding the log into new MXG dataset TYPEWWW. Thanks to Brian Farley, Reliastar Life Insurance Co., USA. Change 15.085 A new utility for ASCII platforms that produces a hex UDUMPEBC dump like the LIST; statement on MVS, with characters May 4, 1997 decoded as EBCDIC rather than ASCII (so you can read the hex dump of your SMF record on your PC!). This utility was written and contributed by Dan (but I actually made it into a %MACRO with arguments!). Thanks to Dan Kaberon, Hewitt Associates, USA.
CLMXGSAS
May 4, 1997 Thanks to ???, ????, USA. Change 15.083 Documentation. The discussion of why you get fractional ADOC26J2 priorities in variable ONPRTY in PDB.JOBS or TYPE26J2 now May 4, 1997 matches the code in VMAC26J2. The old documentation said that MXG FLOORed ONPRTY to an integer, but it never did; ONPRTY has always been a real, rather than an integer. Thanks to Brian Sanger, Eagle Star Group Services Ltd., ENGLAND Change 15.082 Support for Boole and Babbage IMF 3.2 (for IMS 6.1) is VMACCIMS already in place in MXG. The changes were a) increase May 4, 1997 in maximum DBD segments in a record (from 50 to 500, and associated record length increase) but MXG always reads whatever segments are in the record, and b) IMF 3.2 now supports the year 2000 (by documenting dates as yyyyddd) but MXG support was also already in place for that too! No code was changed by this change. Change 15.081 This user contribution is a revision of TYPEIMS7 (which IMACIMSD reads IMS log records 07/08 for transactions and BMPs), TYPEIMSD for IMS DBCTL, because TYPEIMS7 threw away DBCTL events. May 4, 1997 The documentation of the significant logic necessary to capture IMS DBCTL from the IMS log is provided also by Bruce, in the comments in member TYPEIMSD. Thanks to Bruce Galle, Talbots, Inc, USA.
VMACSTRS enhancements in Release 3.3.6 accidentally failed to May 4, 1997 INPUT some variables from the earlier version.
ASUMUOW unit of work, but IRESPTM was kept from the last CICS May 4, 1997 transaction physically encountered, rather than the first (initiating) transaction. The ENDTIME should have been a MAX() rather than MIN(), and QWHCATYP is now in the DROP list as it is unneeded after first step. Thanks to Tom Elbert, John Alden, USA.
FORMATS value of 11 decimal or 0Bx was found. (I now know that May 4, 1997 the 0Bx value is for "DB2 Utilities" and the MGDB2TY May 9, 1997 format that decodes QWHCATYP was updated May 9, 1997, but at the time, the value 0Bx was not in the format.) Why did MXG print 41 when the value was actually '0B'x? Because there was a logical error in the MGDB2TY format for undefined values; the OTHER format was $HEX2, but it should have been HEX2, because QWHCATYP is a numeric variable! Using $HEX for a numeric variable in the OTHER operand of PROC FORMAT is a SAS "feature" that prints not the hex of the data value, but rather prints the hex of the internal representation of the numeric value (as stored by each platform). Since numerics are internally stored as floating point numbers, the '41'x printed was the hex value of the first byte of MVS's internal value of '41B00000'x, where the '41' is the exponent and 'B0' is the mantissa. But under Windows, a '00' was printed, because Intel stores eleven as '00002640' with its exponent in the last byte. In any event, using HEX2 instead of $HEX2 correctly shows the 0B value under MVS or Windows. (This was the single instance of $HEX for a numeric in FORMATS.) Thanks to Roman Jost, Gjensidige, NORWAY. Change 15.077 The MXG Tape Allocation Monitor records had new fields ASUMTALO added in ASMTAPES in MXG 14.14 that are now INPUT into VMACTMNT tape allocation dataset TYPETALO by member VMACTMNT: ZSUMTALO ALEERROR='ALLOCATION*ERRORS*RECORDED' May 3, 1997 RESGROUP='RESOURCE*GROUP*NAME' RPT
SRV TMNT008I='TMNT008I*MESSAGE*ISSUED?' TMNTTYPE='TYPE*OF*MOUNT*OR ALLOCATION*EVENT' WLMNAME ='WORKLOAD*NAME' XMEMABND='CROSS*MEMORY*ABENDS' In addition, ML-12 added the new subtype 5 interval-end record (to keep track of long-running allocations) but MXG 14.14's VMACTMNT skipped over the subtype 5 record. With this change, VMACTMNT now OUTPUTS the subtype 5 into TYPETALO, and this requires a new ASUMTALO member that exploits these interval observations to improve the accuracy of counts if you have long-running allocations. This logic is more accurate than prior ASUMTALO, but may not be perfect until the ASMTAPES ML-14 monitor provides time-synchronized subtype 5 records. I have copied the MXG 14.14 ASUMTALO member into ZSUMTALO and modified it Yüklə 28,67 Mb. Dostları ilə paylaş:
|