* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
TYPEIMS, and the conditional tests were restructured. Thanks to J. Cary Jones, Philip Morris, USA.
ASMVTOC for DASD management and measurement. They replaced the JCLDASD functional but slow %VMXGVTOR and %VMXGVTOC programs VMXGVTOF (which used SAS and CVAF) to read the DASD VTOCs, with ANALVVDS ASMVTOC, a very fast assembly program that extracts the Aug 25, 1990 VTOC data into a flat file. JCLDASD is a jobstream to execute ASMVTOC (and MXG's pre-existing ASMVVDS program) and it uses VMXGVTOF and ANALVVDS (which were originally named MPXGVTOC and MPXGVVDS in PreReleases) to manage, measure, and recover DASD space. This has only been repackaged before addition to MXG 8.3, but it has been running at Philip Morris for some time. Note, however, that it is now Merrill Consutants, and not Philip Morris who is now responsible for problems! Thanks to Tuanhung Doanvo, Philip Morris, USA.
JCLUXREF two JCL members, one for 5.18, the second for 6.06, and JCLUXRE6 the reporting ANAL.... members have finally been added TESTANAL into the test stream! Aug 25, 1990
ASUMVMON This circumvention was made before it was known that SAS TRNDCICS ZAP Z6060916 corrected the problem. The %VMXGSUM macro TRNDJOBS is invoked by these members, and should generate a line TRNDRMFI SAS code for each variable in the NORMn= list, but this TRNDTMNT error caused %VMXGSUM to terminate the scan early and the TRNDVMON code generated was wrong, yet there was no error message! Aug 24, 1990 The error was discovered because the scan truncated the name of a variable, causing that variable to surface on the list of variables without labels in the QA jobstream! By moving the NORMn= variables in the 2nd and subsequent lines, the problem seemed to go away, but now that there is a zap for the problem, put it on and don't trust this repositioning circumvention. Thanks to Chuck Hopf, Hopf Consulting, USA.
VMXGFOR See ZAP Z6060571 (which was superceded by Z6060969) Aug 24, 1990 circumvented the need for FORCE on PROC SORTs, but since that ZAP disables this new FORCE "feature", not all sites may choose to disable FORCE. So, for those MXG sorts in which the input and output data sets are the same, this changes adds %VMXGFOR (which has value FORCE under 6.06, and a null value under 5.18)in these 65 members. With this source circumvention installed, the above zap is now optional, instead of required, for MXG. However, this change now makes two SAS options mandatory for execution of MXG. SAS Options MAUTOSOURCE and SASAUTOS=SOURCLIB is now required to locate the %VMXGFOR macro which implemented this change. (These options have always been required for MXG programs which used %MACROs, such as ANALDB2R, but now ALL executions of MXG must use these two options to resolve the location of %VMXG... macros.)
ANALDB2R ANALDMON ANALDOS ANALESV ANALMNTS ANALMONI ANALMPL ANALNAF ANALNPA ANALNPM ANALNPMR ANALNSPY ANALPATH ANALPDSM ANALPROG ANALRRTM ANALSMF ANALSUPR ANALTAPE ANALTURN ANALVARY ANALVM ANALVMDY ANALVMOS BUILDPDB BUILDPD3 DIFFDB2 DIFFROSC DIFFTPX GRAFREGR GRAFRMFI GRAFTMNT GRAFTRND IDMSAPND IDMSJANL JCLHSM JCLTREND PDBTREND RMFINTRV SYSLOGJ3 TYPEDOS TYPEIMS TYPEIMS1 TYPEIMS3 TYPEMONI TYPETMS UTILCICS UTILDUMP UTILPRAL UTILSPAC UTILXRF2 VMACCRAY VMACVMON VMACVMXA VMXGHSM VMXGSUM VMXGVTOC ZRBRPT1 ZRBRPT2 Change 08.113 Incompatible changes in MXG Trending were implemented by DOCTREND this change, for prior users of MXG Trending data sets. GRAFTRND The TREND.RMFINTRV and TREND.TYPE72 data sets have been JCLTREND renamed to TREND.TRNDRMFI and TREND.TRND72 with MXG 8.3. TRNDRMFI All that you need to do is to rename these two datasets TRNDVDEV in your TREND library BEFORE you run the MXG 8.3+ TRND... TRNDVMON programs, using: TRND72
Aug 22, 1990 PROC DATASETS LIBRARY=TREND; CHANGE RMFINTRV=TRNDRMFI TYPE72 =TRND72 ;
new TRNDRMFI, and discover only last week's data is in your trend plots. Have we destroyed your old data? No! It's still sitting in your TREND library, as datasets RMFINTRV and TYPE72, but now you can't rename them, as there's already a TRNDRMFI and TRND72 in your TREND! In this case, you need only combine the old data sets with the new data sets: DATA TREND.TRNDRMFI;SET TREND.TRNDRMFI TREND.RMFINTRV; DATA TREND.TRND72 ;SET TREND.TRND72 TREND.TYPE72; and you will have lost nothing and will be compatible! I apologize for the inconvenience of this change, but the TREND data sets need to be named differently, because the contents (especially TRND72) is quite different than the TYPE72 data set. The consolation may be the new member, DOCTREND, which is a preliminary documentation of which members of the Trend Data Base are built by which members of MXG Software! Change 08.112 Chuck Hopf's excellent paper on generation of DB2PM-like DOCDB2PM reports using ANALDB2R (which Chuck wrote) is now added Aug 22, 1990 to the MXG documentation in DOCDB2PM. Thanks to Chuck Hopf, Hopf Consulting, USA. Change 08.111 NPM 1.3 Subtype 82 (x'52'), and perhaps other subtypes, VMAC28 have BASNCPDT and BASNCPTM values of 0, which cause INPUT Aug 22, 1990 function error when creating BASTIME from those fields. In line 163610, replace THEN with AND, and insert a new line containing BASNCPDT GT 0 AND BASNCPTM GT 0 THEN to eliminate the error message. Thanks to Ross Pover, Immigration & Ethnic Affairs, AUSTRALIA.
TYPEMONI in MONIDBDS and MONIUSER data sets built from Landmark Aug 22, 1990 CICS data.
JCLTRND as a result, the data sets built by the default TREND TESTTRND options are documented (finally) in DOCVER and DOVER08 Aug 21, 1990 in MXG 8.3 and later. Change 08.108 SAS 6.06 Compatibility. Eliminate multiple macro compile. ASUMCICS These members defined %MACROs VMXGSUM and VMXGDUR using ASUMDBDS %INCLUDE logic, but this causes a re-compile each time ASUMDOS that the include is executed. Instead of using %INCLUDE ASUMTMNT statements, these macros will automatically be defined ASUMVDEV only one time by the combination of SAS system options ASUMVMON MAUTOSOURCE SASAUTOS=SOURCLIB (which have always been TRNDCICS recommended in MXG executions using %MACROs). In an TRNDDOS unrelated change, DROP DATETIME was also added to each TRNDJOBS invocation of VMXGSUM to save 8 bytes per observation. TRNDRMFI TRNDTMNT
TRNDVDEV TRNDVMON
TRND72 Aug 21, 1990 Change 08.107 Addition of TREND testing to the MXG QA stream uncovered TRNDDOS a syntax error, and the delete of DATETIME mention above Aug 21, 1990 was also added. Line 001600, delete (DROP=DATETIME) from line Line 002800, change ;'); to '; Insert new line after 002800 DROP DATETIME;);
VMACVMON for date timestamps, but only in the Western Hemisphere, Aug 20, 1990 and only if the Monitor Start Record (0.97) timestamp in GMT was after the 202-day interval midpoint and the local timestamp was before the 202-day interval midpoint, which at most could occur every 202 days. The error only occurs in that one day's execution of MXG. The midpoint datetime of the current 202-day interval was at 04AUG90:03:43:52. If the VM/Monitor was started on that date at 00:00 local time, all Western Hemisphere sites had a GMT of 05:00 or later, and MXG calculated STARTIME 43 minutes too early! Whew! The error is in the heuristic algorithm to decode the 5-byte datetimestamp (only 202 days fit in 5 bytes). and determine the timezone value, which did not protect for the preceding situation. Replace lines 209200 thru 029600 (now and IF (16*MNHTOD ... to END; ) with: IF (COLLTIME-BASETIME) GT 0.75*FFFFF AND 16*MNHTOD LT 0.25*FFFFF THEN BASETIME=BASETIME+FFFFF; ELSE IF (COLLTIME-BASETIME) LT 0.25*FFFFF AND 16*MNHTOD GT 0.75*FFFFF THEN BASETIME=BASETIME-FFFFF; IF 16*MNHTOD GT FFFFFOV2 THEN LASTHALF=1;ELSE LASTHALF=0; Thanks to Frank Putnam, Ryerson Polytechnical Institute, USA. Change 08.105 IDMS 10.2 Batch Jobs ACCOUNT1-ACCOUNT3 fields were not EXIDMTAS decoded, because no sample data had been seen. Now it has Aug 20, 1990 been, and you can decode batch job's account fields into those variables in Exit member EXIDMTAS, which should be copied into your USERID.SOURCLIB and modified therein to contain the appropriate substring operations. For example if your three account fields are 17, 8, and 4 bytes long, you would insert the below example. (Note that the first byte of ACCOUNT1 begins in byte 2 of TASBFLDS): IF TASTTYPE='.1......'B THEN DO; /* BATCH ONLY */ ACCOUNT1=SUBSTR(TASBFLDS,2,17); ACCOUNT2=SUBSTR(TASBFLDS,19,8); ACCOUNT3=SUBSTR(TASBFLDS,27,4); END;
Thanks to Harold L. Correll, Harris Corporate, USA. Change 08.104 CA7 (formerly UCC7) job scheduling package still corrupts VMACTSOM SMF records, as first described in Newsletter TEN, 1986. Aug 20, 1990 CA says 4 sites have reported the problem and they are "looking into it", but have no immediate plan for a fix. CA7 modifies the READTIME of a controlled job by writing a non-zero value in the first byte of its julian date, to flag that this job is under CA7's control. When that job terminates, CA7 is supposed to remove its corruption and restore the valid julian date, before the SMF records are written. CA7 corrects the SMF record in IEFU83, after the record has been built, and only corrects the SMF records that it knows about. CA7 does not know about TSO/MON!! TSO/MON creates SMF records for batch jobs that execute TSO commands, and if that job is under CA7 control, that SMF record contains corrupted READTIME values, causing an "INVALID DATA FOR READTIME ...", a hex dump of the record and several pages of variable=value error messages. Since CA appears incapable of rapid response, and since the error is likely to show up again, this specific fix to CA7s corruption of TSO/MON records can generically be used for any other (future) SMF record corrupted by CA7. a.Locate all occurrences of inputting READTIME SMFSTAMP8. in member (in VMACTSOM, lines 034700 and 068800). Change all occurrences to now read READCA7S $CHAR8. instead. b.Find the @; which terminates the INPUT statement you just fixed (in VMACTSOM, lines 040100 and 072500). Insert four lines after each @; which read: IF SUBSTR(READCA7S,5,1) GT '01'X THEN DO; SUBSTR(READCA7S,5,1)='00'X; READTIME=INPUT(READCA7S,SMFSTAMP8.); END; Note that this fix is only waranteed thru Dec 31, 2099. If CA7 is still corrupting SMF data in the year 2100, (since they are overwriting the century byte of date) the 01 in the algorithm will need to be changed to 02! Thanks to Keith Mo, Empire Blue Cross Blue Shield, USA. Change 08.103 SAS 6.06 Compatibility. VMXGSUM DROP= conflict. ASUMVMON Change 8.089 in MXG 8.2 added DROP=MXGMISS MXGNMISS to TRNDVMON the %VMXGSUM macro, but two members that invoke %VMXGSUM Aug 12, 1990 already contained DROP= arguments, causing syntax errors Aug 21, 1990 (that should have been caught in MXG 8.2 testing), and thus this change only affects recipients of MXG 8.2. But while we were at it, we also removed the unnecessary includes discussed above in Change 8.108. 1.ASUMVMON, delete line 001200 to eliminate %INCLUDE. Line 001600, remove (DROP=WFRENUM DATETIME) Line 003700, change ;); to ; Insert new line after 003700 containing OUTCODE=DROP WFRENUM DATETIME;); 2.TRNDVMON, delete line 001100 to eliminate %INCLUDE Line 001500 remove (DROP=WFRENUM DATETIME) Line 003700 remove ) Insert new line after 003700 DROP WFRENUM DATETIME;); Change 08.102 For the DB2ACCT Accounting data set in a Distributed DB2 VMACDB2 environment, the Distributed Header fields QWSHCCNT, VMAC102 QWHDLUNM, QWHDNETI, QWHDRQNM, and QWHDUNIQ are now added. Aug 12, 1990 In the type 102 trace correlation header, QWHCOPID is now decoded. In both the 101 and 102 SMF records, MXG now looks for all five possible header types. Thanks to Mike Atterberry, Rockwell International, USA.
ANALDB2R was requested, but if the Trace Long alone was requested, Aug 9, 1990 a SORT VARIABLE error occurred. Adding SORTBY=DBT, to the ANALDB2R invocation will make the problem go away, or adding these four lines after line 018980 will fix it: %IF &PMACC02 NE YES %THEN %DO; %LET SORTN = 1; %LET SORT1 = %QUOTE(DB2); %END: Thanks to Cindy Schinker, AgriData Resources, USA. Change 08.100 Support for WSF 3.3.0 and WSF 3.3.4 SMF records from the EXWSFACC WSF sysout archive product from RSD. Five data sets are EXWSFAUD created, WSFACCT, WSFDSN, WSFERD, WSFEVTS, and WSFEVTP, EXWSFDSN from the account record, and data set WSFAUDIT is built EXWSFERD from the audit SMF record. The WSFACCT and WSFERD data EXWSFEVP sets contain the total READ, WRIT, etc counts from all EXWSFEVS of the DSNB sections, and the WSFDSN data set contains an IMACWSF observation for each DDNAME/DSNAME accessed. The WSFERD, TYPEWSF WSFEVTS (Screen) and WSFEVTP (Printer) datasets contain VMACWSF CPU time for WSF processing, unique for sysout archivers! Aug 6, 1990 Member IMACWSF identifies which SMF record is which. Thanks to Victoria A. Lepak, Aetna Casualty and Surety Company, USA. Change 08.099 A plethora of VM/XA changes were discovered in a search VMACVMXA of INFO/SYS using KWS A MONITOR RECORD NEW UPDATE; some Aug 6, 1990 of the documention for these VM/XA changes required the actual script of the PTF, and the documentation leaves a lot to be desired. This is especially sad, because the VM/XA monitor itself was one of the best documented IBM products in a long time. I guess that's the difference between development and maintenance in IBM. 1.VM39921 added variable CALBASE to seven VM/XA datasets (VXSCLADL,VXSCLDDL,VXSCLAEL,VXUSEACT,VXUSEATE,VXUSEITE) to identify if this is the base VMDBK or adjunct VMDBK. 2.VM39196 added variable CALMODE to four VM/XA datasets (VXMTRUSR,VXUSELON,VXUSEACT,VXUSEATE) to indicate the architectural mode (ESA, XA, or 370) of the guest. 3.VM36026 added variable CALIOACT to VXSYTUWT and variable HFIOACT to datasets VXUSEINT and VXUSEITE to count the number of times the user has an asynchronous I/O that was outstanding. 4.VM36104 adds two new VM/XA monitor records, 0.15 (SYTCUG) and 0.16 (SYTCUP), measuring LPAR (Logical Partition) CPU allocation (dispatched) duration. MXG builds two new data sets, VXSYTCUG (per time interval) and VXSYTCUP (per LPAR per time interval). The new data is identical to that in the MVS TYPE70PR SMF data record, and reports on the utilization of ALL of your LPARs on the hardware platform whether they are executing VM, MVS, or DOS. Thanks to Tom Healy, ChemNet Processing, USA.
FORMATS While several additional fields were added to the IMS log TYPEIMS records 07 and 08, because they were added at the end of VMACIMS the log record, MXG 7.7 will not fail with IMS 3.1 data! Aug 6, 1990 Several of the new fields are 8-byte time durations that are not documented as to format in the IMS log DSECTS, and the test data received to data was only from BMPs that had zero values for these durations, so there is still some validation/verification required. The new data fields that have been added are: DBCTL DB I/O measures: DLRIOCNT - DBCTL DB I/O Count. DLRTMEPL - DBCTL DB Locking Elapsed Time. DLRTMEIO - DBCTL DB I/O Elapsed Time. Delays during program scheduling: DLRMINT - Wait time for Intent Conflict with another PSB for scheduling. DLRMPOL - Wait time for Pool Space for scheduling. DLRMSCH - Elapsed time for Schedule Processing (which includes both DLRMINT and DLRMPOL). There is only one 07 record per program schedule, but it describes NMSGPROC transactions, if multiple transacts are executed by a single program schedule. As MXG has had to do before, these new 07/08 fields are divided by the NMSGPROC value and thus each ultimate transaction record in TYPEIMS contains the average count/duration of these new resource measures. What has not been tested for IMS/ESA 3.1 is the data compaction introduced (I think by an SPE to IMS) in MVS 3.1.3. APARs OY19751, OY19854, OY19860, OY19863 are involved, and IBM manual GC28-1057, MVS/ESA Data Compression and Expansion Services describe the new callable macro CSRCESRV which is automatically used by IMS/ESA 3.1 to compress the OLDS and SLDS (System Log Data Set, the input to TYPEIMS). I am still researching if, when, and how the data compression occurs, and would welcome an IMS/ESA log tape with compression in effect so that I can figure out how to decompress it in MXG! Thanks to Hamid Tavakolian, Continuum, USA.
XMAC73 initialized variable LCI as numeric instead of character. Aug 6, 1990 Line 014500 should be IF LCI=' ' then LCI=' '; Only when data from before and after the circumvention is installed, did this cause a conflict. Thanks to Richard Evans, Mervyns, USA. Change 08.096 SAS 6.06 Compatibility. PROC PRINT PAGE option. ANALESV The PROC PRINT option PAGE no longer exists, and it has Aug 3, 1990 been removed from this example report. Thanks to Tom Simons, Matson Navigation, USA. Change 08.095 SAS 6.06 Compatibility. LIBREF reuse as FILEREF. MONTHBLD SAS Version 6.06 still does not properly recognize the Aug 3, 1990 TAPECLOSE=LEAVE or FILECLOSE=LEAVE options when reading or writing tape format SAS data libraries. Just like 5.18 did, a rewind of each tape library is issued after each SAS data set is read/written, whereas the LEAVE options should cause the tape to remain positioned at the end of the SAS data set just read/written on that tape. The problem is only that this causes many tape mounts if the input or output data libraries are multi volumes, and it causes lots of rewinds (and hence longer elapsed times) even if only single volume tape libraries are involved. The problem has been most pronounced in building the monthly PDB (since that has the highest probability to be multi-volume). MXG has provided a circumvention in MONTHBLD for the output tape (ddname MONTH), but changes in the SAS 6.06 language specifications were made. To protect users from accidentally overwriting a SAS data library with a FILE/INFILE statement, SAS 6.06 no longer allows the same ddname for both a LIBREF and FILEREF at the same time. The following circumvention is required in MONTHBLD to free the LIBREF name so it can be reused as a FILEREF (and, of course, the syntax only works under SAS 6.06 so that version-dependent macros are required so that the modified MONTHBLD executes under either 5.18 or 6.06!).
1.Before the second "MACRO _MNTHBLD" definition, insert these two new compatibility macros: %MACRO V6COMPEN; %IF %SUBSTR(&SYSVER,1,1) GE 6 %THEN %DO; LIBNAME TAPETEMP TAPE ; /*6.06+ TAPE ENGINE*/ %END;
%MEND; %MACRO V6COMPCL; %IF %SUBSTR(&SYSVER,1,1) GE 6 %THEN %DO; LIBNAME TAPETEMP CLEAR; /*6.06+ CLEAR*/ %END;
%MEND; 2.Inside the second "MACRO _MNTHBLD" definition, after the OPTIONS OBS=MAX; and before the DATA TAPETEMP._DSET; insert (note double percent sign):
IF _BEGIN LE ZDATE LE _END; and before the DATA _NULL_; insert (note double percent sign):
VMAC79 records that were actually LRECL=32760 bytes were dumped VMAC79 with an incorrect LRECL=32756 specified in the SMF dump Aug 3, 1990 or copy program. The correct LRECL=32760 must be used. MXG detected and deleted the defective SMF records, but did not note on the log this had been done. The type 79 subtype 1 record with 32760 bytes occurs only when there are 331 or more address spaces active. This change now reports when bad records have been found and reports that they were deleted. Insert after line number 017100 (the end of MONITOR II Control SECTION):
IF SMF79ASS GT 0 AND SMF79ASL GT 0 AND SMF79ASN GT 0 AND L79EXPD GT LENGTH THEN DO; N79BADAS=1; IF N79BADAS LT 10 THEN PUT ' EXPECTED ' L79EXPD ' BYTES, BUT LOGICAL DATA IS ONLY ' LENGTH ' BYTES IN RECORD. RECORD DELETED.'; END; Thanks to Ken Trayes, General Electric Capital, USA. Change 08.093 The 8.2 PreRelease copy of VMACZRB has now been validated VMACZRB by the original author of the RMF III processing support, Aug 3, 1990 who discovered that all X'04' must be changed to $ and all X'52' must be changed to "not" signs. Guess what MXG source code went from EBCDIC to ASCII and back to EBCDIC! To avoid future character set conversion problems, I have further changed all "not-symbol equal signs" to " NE ". (In printing this change, which was down loaded from MVS to PCDOS, the "not-symbols" were converted and printed as "caret" symbols! Please do not use not-symbols!) Thanks to Dick Whiting, Precision Castparts, USA.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|