* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
ESSPRTY ='PRTY*IN*ESS' ESSWRITR='WRITER*NAME*IN ESS' GROUPID ='GROUP ID' NAME ='NAME' ROOM6 ='ROOM6' TITLE ='TITLE' Thanks to Todd Wright, CSC, AUSTRALIA. Change 18.137 Variable CUTSHEET='Y' in dataset TYPE6 and PDB.PRINT was VMAC6 incorrectly decoded; the wrong bit was tested. It should Jun 21, 2000 have been IF OPTBIT='..1.....'B THEN vice '.1......'B. Thanks to Peter Robinson, IGM-GSA, AUSTRALIA. Change 18.136 The RECTYPE=5 Deleted Data Space Release records were put VMACICE in ICEBRGDR instead of ICEBRGDE, because the statement in Jun 21, 2000 the RECTYPE=5 DO group should have been _EICEDEL instead of _EICEDRV (i.e., the comments were correct). Thanks to Nick Johns, J. Sainsbury, ENGLAND.
MONTHBLD TYPE30MU dataset (but WEEKBLDT was correct!). All were WEEKBLD changed to match variables in the _STY30MU sort macro Jun 12, 2000 that is used in BUILDPDB: READTIME JOB JESNR INITTIME SUBTYPE PRODOWNR PRODNAME PRODQUAL PRODID SMFTIME Thanks to Michael Creech, ALLTEL, USA. Thanks to Ed Billowitz, Medical College of Virginia Hospital, USA. Change 18.134 Support for OS/390 R2.10 (INCOMPATIBLE). VMACEXC1 -TYPE30 DD segment has new 8-byte SMF30XBS field for large VMAC1415 tape block size that requires revised VMACEXC1 to read. VMAC16 Processing V2.10 data with old MXG will cause INVALID VMAC30 DEVICE DATA error messages, with trashed DDname, because VMAC7072 of this INCOMPATIBLE change to SMF type 30. VMAC71 Note: A common symptom of using an MXG version without VMAC73 this change to read OS/390 R2.10 or later SMF is VMAC74 ***ERROR.VMACEXC2.2 INVALID DEVICE DATA message VMAC78 that has TEMPLSEG=30 in that message text. VMAC79 This note was added Jun 20, 2001. Jun 10, 2000 -TYPE1415 has new 8-byte BLKSIZE field for large tape blocksize, and the CCSID Information added in 2.7 is now decoded into new variables SMF14CFG/USR/TPE/LBL. -TYPE16 had only cosmetic changes. -TYPE30 new variables added to 30_4, 30_5, 30_V, 30_6 datasets: SMF30ASP SMF30CCP SMF30CPR SMF30CSP SMF30JPN SMF30SME SMF30SPR -TYPE70 new variable SMF70DSA -TYPE70PR new variables SMF70ACS SMF70BDA SMF70CSF SMF70ESF SMF70MAS SMF70MIS SMF70NSA SMF70NSI SMF70ONT SMF70SPN SMF70STN -TYPE71 new variables ESAMEMOD SMF71AFB SMF71AHI SMF71AVI SMF71HRS SMF71HWS SMF71MFB SMF71MHI SMF71MVI SMF71VRS SMF71VWS SMF71XFB SMF71XHI SMF71XVI -TYPE72GO new variables R723PRCP R723PRST -TYPE73 new variable SMF73SFL -TYPE74 new variable TIMFACNO -TYPE74PA new variable R742PIOT -TYPE74CA new variables R745DCID R745LFRE R745LKBF R745LKBR R745RBYF R745RBYS R745RRID R745VBYW R745VFLG R745VNTR R745VNUM R745VSER -TYPE74?? new subtype 7, two or three datasets, but need test data to decide on structure of datasets created. Code is in place for Global/Switch/Port sections. -TYPE78IO new variables R783CUBM R783DPBM R783MCDF R783MCMN R783MCMX R783PTM -TYPE791 new variables R791RLG2 R791RCL -TYPE792 new variables R792FXAB -TYPE79E R79EEPTM R79EDPBM R79ECUBM R79EMCDF R79EMCMN R79EMCMX
ADOCORAC is modified based on Oracle technical feedback. For the VMACORAC Batch/TSO connections (CONNID='BATCH' OR CONNID='TSO'): Jun 9, 2000 CPUTM=SUM(CPUTIMER,CPUCICTM,CPUTCBTM,CPUSRBTM); and for all other connections, CPUTM=SUM(CPUTIMER,CPUCICTM,CPUXMETM); Further discussion of Oracle data is in member ADOCORAC. Thanks to Yvonne McDonough, USDA, USA. Thanks to Leslie Arndt, USDA, USA.
VMXGSUM operands. AUTONAME is a new feature in SAS Version 8, Jun 8, 2000 and when specified with PROC MEANS/SUMMARY, new variable names are longer than 8-bytes and are suffixed with the statistics (VARIABLE_SUM instead of VARIABLE). With this change, AUTONAME can be used with VMXGSUM. Why use the AUTONAME option? If you wanted to sum PDB.JOBS to get the min/max/mean/sum/std of CPUTM/SELAPSTM/IOTMTOTL, the VMXGSUM invocation without AUTONAME would be: %VMXGSUM(INDATA=PDB.JOBS, OUTDATA=JOBSSUM, SUMBY=JOBCLASS, SUM=CPUTM SELAPSTM IOTMTOTL, MIN=MINCPU MINELAP MINIOTM, MAX=MAXCPU MAXELAP MAXIOTM, MEAN=MEANCPU MEANELAP MEANIOTM, STD=STDCPU STDELAP STDIOTM, INCODE=
MINCPU=CPUTM; MINELAP=SELAPSTM; MINIOTM=IOTMTOTL; MAXCPU=CPUTM; MAXELAP=SELAPSTM; MAXIOTM=IOTMTOTL; MEANCPU=CPUTM; MEANELAP=SELAPSTM; MEANIOTM=IOTMTOTL; STDCPU=CPUTM; STDELAP=SELAPSTM; STDIOTM=IOTMTOTL; ); But with AUTONAME specified, only this is required: %VMXGSUM(INDATA=PDB.JOBS, OUTDATA=JOBSSUM, SUMBY=JOBCLASS, AUTONAME=YES, SUM=CPUTM SELAPSTM IOTMTOTL, MIN=CPUTM SELAPSTM IOTMTOTL, MAX=CPUTM SELAPSTM IOTMTOTL, MEAN=CPUTM SELAPSTM IOTMTOTL, STD=CPUTM SELAPSTM IOTMTOTL );
longer need to equate the new variables in the INCODE= operand as they are built automatically using the variable name suffixed by the statistic. This can also result in the bypassing of a data step or two depending on the invocation; in this example, two data steps are bypassed and all that is left is a PROC SORT and a PROC MEANS, but you are then left with long variable names!
ASUM70PR PR/SM segment with LPARNAME='Inactive',LPARNUM=0, and Jun 7, 2000 LPARCPUS=0, but LPARNUM=0 was previously used to identify the LPARNAME='PHYSICAL' obs. These records have missing values for durations, so there was no error in PDB.ASUM70PR numeric values, but variable LP0NAME had 'Inactive' (yes, in mixed case) instead of PHYSICAL. The change is to delete these observations as ASUM70PR reads them, but they will still exist in the TYPE70PR dataset, as they are really there in the type 70 SMF record. Change 18.130 Tailoring in EXDB2STS to create variables in DB2STATS did EXDB2STS not work, because the exit was not included properly. VMACDB2 -In VMACDB2, the OUTPUT _LDB2STS ; statement was replaced Jun 2, 2000 with _EDB2STS to invoke the EXDB2STS exit, and -In EXDB2STS, the _WDB2STS must be OUTPUT _LDB2STS. The DB2STATS data set is different because it is created not during the SMF processing, but in subsequent data steps (after de-accumulation of DB2STAT0 and DB2STAT1, which are then merged to create DB2STATS). As a result, the EXdddddd member outputs to the final destination "_Ldddddd" macro instead of the "_Wdddddd" work file. Additionally, any variable that is created in EXDB2STS exit member will be kept in DB2STATS, and thus there is no need to update the _KDB2STS macro, as it is never referenced (but now a comment in VMACDB2 explains!). Thanks to Mr. Chiarle, Gruppo Miroglio Tessile, ITALY. Change 18.129 IBM Websphere SMF type 103 subtype 2 record contained VMAC103 an undocumented 4-byte reserved field between CONNSNLA Jun 2, 2000 and RTDNSMAX caused the subsequent min/max/avg response Jun 7, 2000 fields to be incorrect. The field was not in the -03 manual but was added in SC31-8690-04. In addition, the -03 had the 7 ERRORnnn fields ahead of the 4 ERRLVnnn, but the -04 manual has the ERRLVnnn first, so MXG was revised to match the revised documentation. Some thread wait variables are now "IBM internal", but MXG still inputs that field into the original variable names. Thanks to Rex Elbert, SPRINT, USA.
VMACEDGS the volume record, because the data was located +62 from Jun 1, 2000 where MXG expected, but since the record level value in the record is still 01, I don't know if this record was always this way, or was changed between versions. New variables were added by SMS 1.5 to both the EDGSVREC and EDGSDREC datasets that are supported by this change. Thanks to Pat Osborne, DND/DGISDS/DIOM, CANADA. Change 18.127 Comments only, but message TMNT010E RC=0028 is written by ASMTAPES MXGTMNT when there is an SMF buffer shortage (or all SMF May 31, 2000 datasets are full). The RC in MXGTMNT's TMNT010E is the return code from the SMFWTM macro (documented in the SMF Manual, GC28-1783-09) and thus this message appears on your SYSLOG when MXGTMNT tried to write a mount or an allocation record, but found it couldn't. The list of all SMFWTM return codes was added in comments. Thanks to Herb Strazinski, US Bank, USA.
VMACNTSM and was repeated incorrectly five times that are changed May 31, 2000 to NTDIST, NTIACC, NTIACS, NTIATC, and NTIATS. These typos caused BLDNTPDB to see duplicates in &MXGDSNS. Also _KNTACSR was misspelled once as _KNTACRS. Thanks to Greg Jackson, National Life of Vermont, USA. Change 18.125 Extra observations were created in TYPE746B (HFS Global VMAC74 buffers) and R746GBF/R746GBNF were negative, because the May 30, 2000 DO R746GSBN=1 TO SMF746FN should have been TO SMF746BN. Also, variable R746GSB, R746GSBF, and R746GSBP are now formatted MGBYTES. Thanks to Alan Deepe, Perot Systems, ENGLAND. Change 18.124 BUILDPD3 fails "BY VARIABLES NOT SORTED WORK.TYPE25" when BUIL3005 two jobs with the same READTIME and JOB are executed with May 29, 2000 the second JESNR first. MXG's heuristic algorithm merges Jun 1, 2000 TYPE30_1 with TYPE25 to add JESNR into the TYPE25 dataset (because IBM still has not added JESNR to the TYPE25), but previously, the output dataset was in order by JESNR. This unexpected out-of-sequence execution is corrected by adding PROC SORT DATA=TYPE25; BY READTIME JOB JESNR; to ensure the TYPE25 is now in the expected order. This is the first instance I have seen that confirms that the two jobs can be read-in in the same .01 second READTIME, but MXG addition of JESNR in BUILDPDB/BUILDPD3 was done knowing that someday the reader would be fast enough to create two jobs of same job name with same READTIME. Thanks to Ron Lundy, Navistar, USA.
FORMATS Statistic segment with dozens of new variables, added by VMAC94 APARs OW42071 and OW42073. Code has not yet been tested May 25, 2000 as records are not yet available. Thanks to Greg Kent, IBM Global Services, USA.
ASUMTCPT concurrently logged on, using TYPETCP/TYPSTCP to first May 24, 2000 create the TYPETCPT dataset. Thanks to Charlie Sticher, University of Georgia, USA. Change 18.121 Bad offset for second HFS filename caused INPUT EXCEEDED VMACTCP error; the record is wrong and being investigated, but May 24, 2000 logic was now added to prevent reading off the record, while we open a problem with IBM. Thanks to Michael Creech, Alltel, USA.
RMFINTRV That change (in MXG 18.03 and later) is now required for VMAC7072 OS/390 R2.7 or R2.8 if APAR OW41317 is installed (and 2.9 May 24, 2000 which includes the APAR). That APAR added multi-system May 30, 2000 enclave fields that were incorrectly read by MXG. While R2.9 generates error messages, R2.7 and R2.8 do not; both create bad values (negative, asterisk, etc) in TYPE72GO observations for periods two and higher. RMFINTRV sums the TYPE72GO data, so data in RMFINTRV will also be bad without this change; this is just an alert, as nothing in RMFINTRV was changed. This change is really just to update the text of 18.071, as that change only mentioned Release 2.9. A cosmetic change (LENSCS test from GE 448 to GE 460) that has no execution impact was made in VMAC7072. Thanks to Jane Huong, Cigna, USA. Thanks to Steve Colio, Cigna, USA.
EXTY1082 type 108 records now create two new datasets: EXTY1086 Dataset Description IMAC108 TYPE1082 Domino Server User Activity VMAC108 (IP address of user, Notes User Name, Type VMXGINIT of connection, CPU time, Bytes Read/Written May 23, 2000 an interval record). May 31, 2000 TYPE1086 Domino Server Database Activity (Database name, index ops, replicates, docs added, docs deleted) In addition, the _Sdddddd sort macros for all TYPE108x datasets were revised for duplicate SMF record removal. These new data are a good start to tracking Domino Server activity to users and causers, but it is still incomplete and provides only resource measurements, with no counts of user activity other than bytes, and no intersect of which databases were used by which users when! The good news is that IBM is listening and we will continue to see enhancements in the SMF 108 records as Domino Server is finally a mainstream product for mainframes! The type 108 SMF record's product has had these names: Domino Server R5.0.3 Lotus Domino Server R5.0.2 Domino Server R5.0/R5.0.1 Lotus Domino R5 Lotus Notes Domino Server The MXG-L Archives contain several discussions of Domino Server: IBM Redbooks SG24-2083 (Install, Customization, Admin) and SG24-5149 (Performance Tuning and Capacity Planning) have both been recommended, especially the USS customization and installation in SG24-2083.
Thanks to Stella Lim, United Air Lines, USA. Change 18.118 Support for Type 42 RLS Subtype 19 has been revised and EXTY42X2 validated; two datasets are now created: IMAC42 Dataset Description VMAC42 TYPE42X1 VSAMRLS Local Buff Mgr SYSPLEX Totals VMXGINIT TYPR42X2 VSAMRLS Local Buff Mgr SYSTEM Details May 18, 2000 However, these two datasets have lots of data, and in keeping the IBM field name as part of the prefix of each variable name for the 16 buffer pool with six measures per buffer pool got messy, but here is the table of the variable name prefixes for the Buffer Pool measurements: IBM Buffer Pool Megabytes Buffer Pool Extents Array LOW HIGH CURR LOW HIGH CURR "JOE" SMFJOF SMFJOG SMFJOH SMFJOJ SMFJOK SMFJOL "JRL" SMFJRJ SMFJRK SMFJRL SMFJRN SMFJRO SMFJRP "JPY" SMFJPZ SMFJQA SMFJQB SMFJQC SMFJQD SMFJQF There are sixteen variables for each of these prefixes and their suffixes are 01-09,0A-0G, so SMFJOF01 is the Low Size (in Megabytes - note that MXG Labels & Formats for the Megabyte variables have been converted from the min/max/current count of buffers to the size of that buffer pool in bytes, and is formatted to print KB/MB/GB with the MGBYTES format) of the 2K buffer pool, and SMFJOL0G is the current number of extents in the 32K buffer pool. Labels identify the pool size. This is valid data, but may be enhanced as the data is viewed and used. APAR OW44739 (May 30, 2000) acknowledges that the SMF manual for V2R5 and V2R6 subtype 19 documentation was wrong and that the V2R7 and later are correct. Thanks to Edward McCarthy, IBM GSA, AUSTRALIA.
TYPEMWUX TYPEMWUX member. May 18, 2000 Thanks to Bart Decat, KBC Belgium, BELGIUM. Change 18.116 Two occurrences of AND SV30ALN GE 1 THEN must be changed VMACSARR to AND SV31ALN GE 1 THEN and to AND SV32ALN GE THEN as is May 18, 2000 obvious from the other variables in those statements. Thanks to Ian Mackay, RBS, UK. Change 18.115 Assembly of ASMTAPES under OS/390 R2.8 or 2.9 with ASM H: ASMTAPES IEV122 ERROR ILLEGAL OP-CODE FORMAT MACRO STCKCONV, due May 17, 2000 to IBM error (APAR OW39924, macro STCKCONV has blank line at sequence number 10075000 - remove or commend out blank line. Or use the High Level Assembler instead of ASM H, which tolerates the blank and is IBM's recommended ASM Thanks to Scott Wigg, USBank, USA.
VMACTMO2 which would cause a problem only if you were to merge the May 17, 2000 MONITASK and DB2ACCT datasets; UOWTIME is INPUT from the first six bytes of UOWID; it is only a token for matching DB2ACCT to MONITASK/CICSTRAN, but it needs to be kept as LENGTH 8, as it is everywhere else in MXG except this one member. (It was also not formatted as DATETIME21.2, but rarely is the time value of UOWTIME useful; the truncated value wraps every few weeks and from some originations is completely off from current time, but that's ok for a token. Thanks to Freddie Arie, Texas Utilities, USA. Change 18.113 The SELDSN macro did not list ASUMCEC after ASUM70PR, JCLMNTH but MONTHBLD expected to create MONTH.ASUMCEC. Added May 17, 2000 ASUMCEC to the list of datasets. Thanks to Freddie Arie, Texas Utilities, USA. Change 18.112 Variable NSPYTIPL is now formatted DATETIME21.2 and kept VMACNSPY as LENGTH 8 instead of the default 4 (which can truncate May 17, 2000 a datetime variable by as much as 255 seconds). Thanks to Freddie Arie, Texas Utilities, USA. Change 18.111 RMF variable MVSLEVEL from RMF 70 is now kept in the VMXGRMFI RMFINTRV dataset. May 16, 2000 Thanks to Marc Matthys, Hudson Williams, BELGIUM. Change 18.110 -NTSMF object SNA ADAPTER SNADLC* has an Instance Field EXNTCOTI that is now decoded when it is present. EXNTTN32 -Support for COM Transaction Integrator object in the new IMACNTSM COMTRNIG dataset. VMACNTSM -Support for TN3270 Server object in the new TN3270SV VMXGINIT dataset. May 15, 2000 Thanks to Tom Aaslet, SMT, DENMARK. Thanks to Richard P. Clarke, Freemans PLC, ENGLAND.
MONTHBLD that your Weekly PDB is built on Monday morning), and new MONTHBLS member MONTHBLS expects that your Weekly PDB is built on May 15, 2000 Saturday instead. The actual weekly job doesn't care when it is run; it simply combines the last seven dailies to create a Weekly PDB thru that morning's daily PDB, but the MONTHBLx has to know what is your first day of week. Thanks to Larry Heath, Shaw, Inc, USA. Change 18.108 Variable SVCCIO inserted between SVCCKERN and SVCCSEM4. VMACSVCC However, 75% of Peregrine's elapsed times are zeroes, and May 13, 2000 many records that should be there aren't! Open problem.
VMACNOAM variable NOAMCOLN=INPUT(NOAMCOLL,&PIB.4.) is the numeric May 15, 2000 value of NOAMCOLL, which is now input as $CHAR4. with $HEX8. format, and the non-Y2-compliant 0yymmddF NOAMMIGD "Object Migration Date" is now protected with a 1960 window.
Thanks to Peter Skov Sorensen, Jyske Bank, DENMARK Change 18.106 Inconsistent macro names were used in BLDNTPDB and in the BLDNTPDB TRNDNTIN trending for NTSMF. The Macro _LASUMNT in the May 13, 2000 BLDNTPDB member was changed to _LSUNTIN to be consistent with the TRNDNTIN naming conventions. Thanks to Greg Jackson, National Life of Vermont, USA.
ANALRMFR three enclave fields (AVG ENC/REM ENC/MS ENC) added in May 13, 2000 the TRANSACTIONS column. -Workload Activity Report was updated for APAR OW41317: goal mode, REPORT=WLMGL,RPTOPT=WGPER, the PERIOD summarization and calculations were revised to remove SYSTEM from all BY statements. -Device Activity Report was updated for APAR OW31701: Add column MX to DASD ACTIVITY REPORT to show the number of UCBs that were active for PAV devices. -Channel Activity Report was updated for APAR OW35586: columns for Ficon data transfer rates and Bus Utilization were added.
CONFIGV8 V8.0 TS MO, TS M1, and V8.1 cannot be safely used. You JCLQAJOB may get errors when you write or read; or worse, datasets JCLUXRE6 created from tape datasets can have trashed labels. MONTHBLD See "SAS Technical Notes" in Newsletter THIRTY-SEVEN for MXGSASV8 a technical discussion of the errors (also on homepage). VMXGINIT Instead of using the V8SEQ engine, until these errors are WEEKBLD corrected by SAS Institute, you must change the default WEEKBLDT tape engine so that the V6SEQ engine is used, by either: May 13, 2000 - adding SEQENGINE=V6SEQ to your CONFIG member, or - using MXGs revised CONFIGV8 member with that option, or - adding OPTIONS SEQENGINE=V6SEQ; in every job's SYSIN input stream, or - adding ,OPTIONS='SEQENGINE=V6SEQ' to each // EXEC SAS or // EXEC MXGSAS JCL statement for each job. Also, MXG members WEEKBLDT and MONTHBLD, which create tape format datasets on temp DASD, will fail, as they contain LIBNAME TAPETEMP TAPE ; statements that force the V8SEQ engine even when SEQENGINE=V6SEQ is set, so "TAPE" in those LIBNAME statements was replaced with a new macro variable &TAPENGN, set to V6SEQ by VMXGINIT.
example to use for SAS Version 8, as I discovered that SAS member BATCHXA in the SAS CNTL library is now named BATCH, and the MXGSASV8 example now uses member CONFIGV8 (instead of CONFIG) for execution under SAS V8. (Confused? CONFIG08 was for SAS 6.08, not SAS V8) SAS Institute opened SAS Note 002651 and found that the LABEL error applies to all platforms where TAPE engine is supported, so they are aggressively attacking the error. July 26 update: SAS ZAP Z8002651 now exists for SAS V8.0 and V8.1, and the error is corrected in SAS V8.2. With that zap, you can change the CONFIGV8 to V8SEQ, but since I can't detect if that ZAP is installed. Thanks to Dan Riggs, Wachovia, USA. Thanks to Ron Adkins, Wachovia, USA. Thanks to Alan Lankin, Towers Perrin, USA. Thanks to Chuck Hopf, MBNA, USA. Thanks to MP Welch, SPRINT, USA Change 18.103 IMS log processing, MXG 18.03 only, IMS 6.1 only (whew!): TYPEIMSB WARNING: UNINITIALIZED VARIABLE _IMSVERS message because Yüklə 28,67 Mb. Dostları ilə paylaş:
|