* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
OUTDEVCE to create variable DEVICE in TYPE6, setting DEVICE='PRINT' (if OUTDEVCE starts with 'PRINT' or 'PRT' or contains '.PR', or UCS starts with 'VPS, or setting DEVICE='PUNCH' (if OUTDEVCE starts with 'PUN' or contains '.PU'). If no match is found in OUTDEVCE, then MXG sets DEVICE='EXT WTR'. The APAR not only changes the contents of variable DEVICE in TYPE6, but BUILDPDB uses the value of DEVICE to decide if NRLINES are put in variables PRINTLNE, PUNCHCRD, OR EXTWTRLN in both the PDB.JOBS and PDB.PRINT data sets. The total of those three variables will still be correct, but you cannot trust PRINTLNE to contain print lines; all of the lines printed could end up in variable EXTWTRLN. If the breakout is important to your site, you will have to first create a table look up mapping VTAM LUNAME to the type of device, and use that table in member EXTY6 to set DEVICE= to the correct device type for your site. As long as you use the SUM(PRINTLNE,PUNCHCRD,EXTWTRLN) for TYPE6 or PDB.PRINT analysis/billing, there is no error. Thanks to Susan Marshall, SAS Institute Europe, GERMANY. Change 09.082 Interlink's product SNS/vt is actually the ANET product VMACILKV from Teubener Associates, and is also marketed by Mitek Jul 17, 1991 (now Open Connect Systems) as Telenet Client Fullscreen! By whatever name, however, the disconnect record has a bug (CONECTIM does not contain a date) that is now fixed in their release 322. Thanks to Dan Barbatti, Southwestern Bell St. Louis, USA.
IMACEPIL Candle's utility as RECFM=U, even though the records are Jul 16, 1991 actually internally VB, with BDW=600 and RDW=LRECL=596. The only problem with RECFM=U is that when written to a tape data set, lots of space is wasted between these 600 byte records. Sites have, therefore, chosen to change the output RECFM of the Candle dumping program to specify VB, reducing storage on tape from 5 volumes to a single volume, but this creates an additional BDW/RDW on the tape, a "VVBB" RECFM! MXG has always handled these two formats; if the output is dumped with RECFM=U then OFFEPIL=0 is specified in IMACEPIL, and if the output is dumped with RECFM=VB, then OFFEPIL=4 handles the extra four bytes on each record, but only now do I realize in which case which offset is specified in IMACEPIL! Thanks to Myron Highfield, Square D, USA. Change 09.080 Some new DB2 variables in DB2STAT0/DB2STAT1 were not DIFFDB2 deaccumulated. QLSTx, QWTRx, QW2x-QW5x, Q9STCTRI,J,K,L Jul 16, 1991 in DB2STAT0, and QBnTCBA,QBnTPID,QISERx,QXCRRALS,QXDRPAL QXMRMIAP,QXMSMIAP,QXNSMIAP in DB2STAT1 are now correct. Thanks to Elliot Weitzman, Orxy Energy Company, USA.
BUILDPDB the same DDNAME appears multiple times in a step record. BUILDPD3 The NODUP option was removed from the PROC SORT of the Jul 11, 1991 TYPE30_D into the PDB.DDSTATS to prevent unintentional deletion.
VMACCMF could be missing, and SAS treated the value as zero. In VMXGHSM SAS Version 6, however, a missing value for one of the Jul 10, 1991 DO loop variables raises a syntax error and terminates execution. This problem was simultaneously encountered in two unrelated members on the same day! a.In VMXGHSM, before the DO C= 1 TO MPCDGNCT; insert IF MCPDGNCT=. THEN MCTDGNCT=0; Unrelated VMXGHSM corrections were also made. MCDCLU should have been spelled MCDDLU. INPUT MCTFRAG PIB2 should have been PIB2. (with a period). DCRDATEX should have been DCRDATE. MCVLSPCT should have been INPUT as PIB4.2, and the subsequent DMS function deleted, as it was not PK4. DSRTIME should have been INPUT as PIB4.2, and the subsequent DMS function deleted, as it was not PK4. b.In VMACCMF, before the DO on _I_, insert IF CMFWPTR=. THEN CMFWPTR=0; IF CMFCHKTG=. THEM CMFCHKTG=0; and four lines later, change IF CMFCHKRM NE 0 .... to read IF CMFCHKRM GT 0 .... Thanks to Ray Dickensheets, Yellow Freight System, USA. Thanks to Bill Dempster, UOP, USA.
IMACCICS only used in MXG testing and should have been removed. Jul 9, 1991 All of the installation controls for EXCLUDE processing are contained in member IMACEXCL. Thanks to Tim Cartwright, University of Wisconsin Madison, USA.
CONFIG from MXG's CONFIG member. It caused no execution error, Jul 4, 1991 but confused users who tried to figure out what it was. It should not have been in CONFIG in the first place! Change 09.075 This is a document change, pending IBM answers. The two VMAC42 fields SMF42LFW and SMF42CFW are now acknowledged by IBM Jul 4, 1991 to be accumulators and not counts for the interval. They have not yet acknowledged this as a bug or a feature! Thanks to Joseph J. Faska, Depository Trust, USA
VMACCMF RETURN; statement inserted immediately before the label Jul 4, 1991 CMFCKSM: statement. Thanks to Bill Dempster, UOP, USA. Change 09.073 Change 8.213 gave an example for using INSTREAM DDNAME CHANGE08 to create the _DAY macro for copying yesterday's PDB to Jul 4, 1991 the correct day-of-week PDB, but the example failed to execute. First, the OPTIONS NOTITLE; statement should be deleted (that options no longer exists). Second, the PRINT option in the FILE INSTREAM statement should be NOPRINT. Third, a blank is required after _DAY in the quoted string: 'MACRO _DAY ' to be written to INSTREAM. The example has been corrected in member CHANGE08 so you could copy it for execution. Finally, under SAS 6.06+. WEEKDAY=UPCASE(PUT(TODAY,WEEKDATE3.)); is required because the PUT function returns mixed case. Thanks to Mark Steeley, Anthem Insurance.
VMAC7072 incorrectly subtracted CPUWAIT0 in lines 134620,134660. XMAC7072 The obvious typing error should have subtracted CPUWAIT2 Jul 4, 1991 and CPUWAIT3 respectively, and came in MXG 8.8. Thanks to Helmut Kirrmaier, Comparex Mannheim, GERMANY.
VMAC41 SMF41SRC was non-zero, but should also have been set to Jul 2, 1991 missing with an ELSE clause. Without the ELSE clause, if the record had classes with no activity, the prior class value for VLFHITPC was carried forward. Thanks to Dan Squillace, SAS Institute Cary, USA. Change 09.070 TYPE72 new CPU variables CPUHPTTM,CPUIIPTM CPURCTTM, VMAC7072 added by MVS/ESA 4.2, are wrong. Lines 157900-158200 XMAC7072 must INPUT these three variables as PIB4.6 instead of Jul 2, 1991 PIB4., and then each variable must be multiplied by 1.024 after the input statement. This error also made the variable CPUTM, as it includes these three. Note: see revision in Change 9.120.
VMACOMAU from Candle, OB270S10 to capture the DB2 Subsystem ID if Jun 30, 1991 an Omegamon DB2 command is being audited; otherwise you will not know which DB2 subsystem was the object of the Candle command that was issued. Even with the ZAP, the subsystem ID is not put in the right place; instead of in being in MXG variable OMSUBSID where it belongs, the ID value is stored in MXG's variable OMSTEP. No change was made to MXG to move it to the right field, Candle has not called, and the zap and this note may be enough. Thanks to Wayne Cope, Belks Stores, USA.
VMACIDMS in error. TASPAGRD contains 'FFFFFFFB'x, which MXG sees Jun 30, 1991 (inputing at PIB4.) as 4,294,967,040, and the Cullinet report (no, they have not changed the report header yet) shows a negative 4. Separately, the TASIMWT wait time duration is sometimes greater than the delta between the STARTIME and ENDTIME. No MXG change was made to deal with what appear to be IDMS errors. Stay tuned. Thanks to Elizabeth Stronge, Michelin Tier Corp, USA.
TRND72 could not know which performance groups were control and Jun 30, 1991 which were report (unless you resorted to an external table or format). This change added PERFRPGN to the ID statement so it will now exist in trended TYPE72 data. Thanks to Seymour J. Metz, EDS, USA. Change 09.066 SAS 6.06 does not support concatenated Format libraries FORMATS (since they are now SAS datasets, which still cannot be IMACFMTS concatenated). New tailoring member IMACFMTS is created Jun 30, 1991 to allow you to put your installation's VALUE statements in this separate member of your USERID.SOURCLIB. The member IMACFMTS is %INCLUDEd at the end of MXG's member FORMATS so that your formats will be placed in the same data library as the MXG formats. One suggested use was to define performance group mapping in this member. Thanks to Seymour J. Metz, EDS, USA. Change 09.065 DASDMON/ASTEC load counts RLDCNT and RDLCNT in VMACDMON VMACDMON should have been input PIB4.2 instead of PIB4., though Jun 30, 1991 there was no clue in the DSECT documentation. Only the observed very large values and comparison with Legent's reports uncovered their documentation error. Thanks to Greg Scriba, First National Bank of Chicago, USA. Change 09.064 This significant user contribution is a 15-member PDS in ANALRACF member ANALRACF that will analyze the use of MXG TYPE80 VMAC80 observations for the use of RACF commands with SPECIAL Jun 30, 1991 or OPERATIONS authority. Documentation and flow of the programs are contained in member ANALRACF. Three new variables were added to the TYPE80 KEEP= list, NRSET, RACFDAT1, and RACFVRMN, to support these reports. Thanks to Duncan McKellar, Inland Revenue (UK), ENGLAND. Thanks to Neil Campbell, Inland Revenue (UK), ENGLAND. Thanks to Dave McLaughlin, Inland Revenue (UK), ENGLAND. Change 09.063 Yet another problem with IMS Input Queue time was found. TYPEIMS Out of 22,000 transactions, type 35x log records for 18 VMACIMS transactions contained the LTERM value in the NODENAME Jun 29, 1991 field, causing the 35x (ENQTIME) to not be matched with the 01x (ARRVTIME) record. These 18 records all have an ENQFLAG=0Cx and FLAG2=ACx, and had CLBNAME=LTERM and 16 bytes later, the NODENAME needed was found in the "Input subpool name" part of IBM's QLNQLNID (and, as usual for IMS, there is no indication in the IBM IMS DSECT of this condition). MXG has again been patched to support this IMS variation. Another change, unrelated, had been left out of the MXG 8.8 changes; for Multi-Transactions per schedule, the CONDCODE was propagated into all IMSTRAN observations; now it is blank until the final one. And occasional negative service times for Multi-Trans and WFI transactions were corrected by not re-setting the ENDTIME to an incorrect earlier value. I always want to think each IMS fix is the last one, but I have little doubt that there will be future discoveries. But then even IBM's IMSPARS is frequently unable to correctly count transactions, and frequently can't figure out the time stamps that MXG can locate in the log records, so it is clearly not straightforward to decode the IMS log, in which the records are written out of order by time! I do believe there have never been errors in MXG's IMS resource capture (CPU, DLI, counts, etc.), and only in the Input and Output Queue times have there been wrong calculations, and statistically few in number. This does suggest STRONGLY to avoid using average values for the analysis of IMS response, service, and queue times. One large value can completely distort the average value, but counting the percentage that completed in a specific duration will not be so affected, and is much safer to report. Even at its very best, though, the IMS log is NOT the recommended source for IMS analysis; at best it provides only one single measure of CPU time for each program schedule (which might represent hundreds of real transaction), and that CPU time cannot be subdivided into Message Region, DB2 services, DL/I services, etc., which can and are captured currently by third-party IMS monitors which write discrete transaction records for analysis. Sites to whom IMS is a significant workload, and especially sites with WFI, Fast Path, or lots of multi-trans per sked activity should invest in an IMS monitor until IBM decides to provide transaction-level resource and response time recording in the IMS log. Thanks to Lindsay Dawe, Mobil Oil, AUSTRALIA.
VMAC110 all releases of CICS from 1.5 thru CICS/ESA 3.2.1. Jun 28, 1991 In fact, due to IBM's ETP program, MXG 8.8 contained support for CICS/ESA 3.2.1, and thus you do NOT need to install a new release of MXG just for CICS/ESA if you have already installed MXG 8.8. Versions of MXG before MXG 8.8 will fail with CICS/ESA 3.2.1 records, because 3.2.1 records were changed incompatibly (CICS version SMFPSRVN was changed from an EBCDIC field containing 31 to a PK2. field containing 321). That incompatibility is actually beneficial; finally we can recognize the version, release, and modification-level of CICS. The other changes between last fall's CICS 3.1 and 3.2.1 are minor, but a new timestamp, taken at CICS startup, was added to the type 110 record, used to collect all records from a specific execution of a CICS region. It would really been useful if IBM had stored, not the STCK value when CICS started, but instead had copied the READTIME of the CICS job (which already exists) because then CICS SMF could be directly MERGED/JOINED with the other SMF records (like 14,15, and 64 I/O records) that have contained READTIME for the "Job Log" since day 1 of SMF data! Oh, well, something's better than nothing!
EX028INA added by this last-minute change (the product became EX028INB available today, and I received the IBM documentation EX028INC two days ago!) which has been syntax tested, but has EX028IND not actually read any SMF records with the new data EX028EV3 segments. Prior versions of MXG should not fail with EX028EV4 the new records, but the SAS log will contain many EX028EV5 MXG notes that unexpected subtypes 0B, 72-77x, 90-96x, EX028NTN and FAx were found. Eight new NPM datasets are created, VMAC28 but none of the existing data sets appeared to have been Jun 27, 1991 changed after a brief review of the new documentation. MXG documentation of the new datasets is in comments at the beginning of member VMAC28. IBM's documentation is on pages 285-411 of NPM Installation and Customization, SH20-6361-5.
GRAFTRND SASGRAPH=NO and SASSTAT=YES. Line 038700 should be Jun 27, 1991 DATA=PERCENTS instead of DATA=PRED1, and line 044800 should be DATA=TIMES instead of DATA=PRED1. Thanks to Jim Ray, National Council on Compensation Insurance, USA.
ANALTMS5 records worked fine in small shops, but with a large Jun 26, 1991 number of devices and volsers, they ran out of virtual addressability (i.e., virtual memory), because a CLASS statement was used. The CLASS statement needs storage in virtual memory for every possible combination of the class variables data values; it creates all possible answers in virtual memory, and then decides how many of the answers you really wanted. With three variables in a CLASS statement, if each variable has 100,000 unique values (e.g., a TMC catalog of 100,000 tapes VOLSERs), there are 10**15 cells needed per statistic calculated! One of the historic virtues of the SAS System, in my opinion, was that by being what I called "data driven", SAS could solve problems that broke the back of these "memory driven" algorithms. As long as you could first afford to PROC SORT your data, you could summarize and analyze any number of groups with a PROC MEANS with a BY statement. Being "data driven" is the solution to this ANALTMS problem. By changing the "CLASS" to "BY" following the two PROC SUMMARY statements you change the architecture from "memory driven" to "data driven", and the virtual memory is now independent of the number of by groups in your data. Although the TMS.TMS dataset was already built SORTed, so in general you do not need an extra sort to summarize, I chose to ensure the sort order by inserting PROC SORT before the PROC SUMMARY. However, a PROC SORT was required for the second PROC SUMMARY, but its input dataset was already a summarized temporary data subset of the original TMS.TMS dataset. Since PROC MEANS now actually invokes PROC SUMMARY, this reminder is not about PROC SUMMARY itself, but rather it contrasts the "in memory" CLASS statement algorithm to the "data driven" BY statement implementation. For MXG data, the BY statement implementation is recommended, as we DO have many possible unique values, and being "data driven" not only uses fewer CPU and I/O resources, but of perhaps even greater importance, being "data driven" means that your daily production reports use exactly the same amount of virtual memory every day, and they will not awake you at 3am because today's data happened to have more unique values then your test job (you know, the one you tested in a 4MB region yesterday afternoon!)
RMFINTRV RMFINTRV directly from SMF records did not have the BY Jun 26, 1991 list correct for TYPE70PR dataset, causing SAS to think there were duplicate records. The BY list now matches its BUILDPDB counterpart. Thanks to Chuck Hopf, Primerica, USA. Change 09.057 Semicolons were missing at the end of lines 032300 thru VMACTMS5 032500 in VMACTMS5 and lines 019700 thru 019900 in VMACTMS, after support for CA/1 Release 5 was added. Jun 26, 1991 Thanks to Chuck Hopf, Primerica, USA.
EXFTP01X transfer program) User SMF record creates eleven FTP... EXFTP02X MXG data sets, one per subtype, from FTP R1.0. EXFTP03X The FTP support uses the new "subtype-level-processing" EXFTP04X MXG architecture, which will be used for all future EXFTP11X development, and eventually will be retrofitted into all EXFTP12X of the existing products which create record subtypes. EXFTP21X The specification and naming conventions of this new MXG EXFTP22X architecture is presently contained in member VMACFTP, EXFTP23X but these initial descriptions will be elaborated into EXFTP24X a formal MXG architecture specification member later. EXFTP25X "Subtype-level-processing" is completely compatible with FORMATS the existing MXG "record-level-processing" architecture, IMACFTP and most sites won't even notice the difference, but for TESTUSER records with lots of subtypes, the change is required to TYPEFTP maximize the flexibility and optimize the construction VMACFTP of MXG programs in the future. Jun 24, 1991 FTP just happened along at the right time! Thanks to Stephen Bell, Bunchungszentrale der westfalisch, GERMANY.
VMAC78 78 subtype 3 records because line 171600 should have Jun 23, 1991 been @; instead of just a semicolon. At the same time, the ?? format modifier were added to the input for the IODFDATE/IODFTIME variables to eliminate the INVALID DATA messages. Mini-tutorial on SAS hex dumps: The hex dump produced by this error was not for a type 78 record, but instead contained a type 74 record. The PUT _ALL_ list of variable=value after the dump showed the _N_ value of 4, but the number on the hex dump CHAR line was 5! The _N_= value is the accurate indicator, and shows when the error occurred, and only if the _N_= value equals the hex dump's record number, do you know the dumped record is the problem record. Why did SAS dump the next record? I don't know why, but for some logic errors, SAS reads into the next data record before realizing it has switched records, and so when it goes to dump the record currently in its buffer it has already gone past the problem record. Thanks to Tom Parker, Hogan Systems, USA. Change 09.054 MXG 9.1 corrections for MVS/ESA 4.2 in Change 9.001 were VMAC7072 inconsistent. Part b was in XMAC7072 but not VMAC7072, XMAC74 and parts d and e were in VMAC74 but were incorrect in Jun 23, 1991 XMAC74. Only MVS/ESA 4.2 records were affected. Thanks to Diane Eppestine, Southwestern Bell, USA. Thanks to Dan Barbatti, Southwestern Bell, USA. Change 09.053 The PROC DATASETS DDNAME=VMXGVVDS ... should have been ANALVVDS PROC DATASETS DDNAME=MXGVVDS Jun 21, 1991 Thanks to Ray Dickensheets, Yellow Freight System, USA. Change 09.052 SAS 6.06 Usage Note 2066 discusses an unfixed error that VMAC37 causes the SAS CHARCODE option (see SAS 6.06 Language ANALDBTR guide page 741) to unexpectedly replace characters that ANALPDSM are inside a comment block. In VMAC37, a ?- inside a BUILDPDB comment block was replaced by an underscore, reducing BUILDPD3 the source line by one byte, which moved the line number TESTUSER from column 73 to column 72, causing a syntax error! VMACACF2 MXG did not know of this vulnerability and just happened VMACTEST to have the ?- in a comment. Nine other MXG members had VMAC110 either ?- or ?) pairs in comments, and all have been now VMXGHSM changed to avoid the exposure until 2066 is fixed, Yüklə 28,67 Mb. Dostları ilə paylaş:
|