* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
====== Changes thru 26.120 were in MXG 26.04 dated Jun 4, 2008========= Change 26.120 The CICSEXCE Exception Report examples have been useless ANALCICS for years, as the individual wait/counts have not been Jun 4, 2008 been populated. Only these variables are populated in the CICSEXCE dataset: ENDTIME EXCMNBTR EXCMNCPN EXCMNFCN EXCMNNID EXCMNNPX EXCMNNSX EXCMNRIL EXCMNRIL EXCMNRIX EXCMNRLU EXCMNRPT EXCMNRTY EXCMNSRV EXCMNTCN EXCMNTRF EXCMNTYP EXCMNURI EXCMNURI EXWAITTM LUNAME OPERATOR STRTTIME TASEXCNR TASKNR TCLASS TERMINAL TRANNAME TRANPRI TRANTYPE USER
A new report totals EXWAITCN and EXWAITM and calculates the AVGWAITM for each APPLID EXCMNTYP EXCMNRTY EXCMNRIX has been added to the examples in ANALCICS. Thanks to Robert Carter, PNC Bank, USA. Change 26.119 Variable LCU is added to TYPE74CA, by converting CSSSID VMAC74 from character to numeric, and variables CUSERIAL and Jun 4, 2008 CUVENDOR are created by substring from R745CCMT. On IBM RMF reports, they print "CUID"-"CSDEVN" value and "SSID"-"CSSSID" value (now, "SSID"-"LCU" value). Thanks to Steven Olmstead, Northwestern Mutual, USA. Change 26.118 Almost cosmetic; the TEST parameter (which writes MXGTMNT ASMTAPEE data to a flat file, instead of to SMF) did not work. Jun 4, 2008 This first ML-42 was never distributed see Change 26.136. Thanks to Alexander Raeder, ATOSORIGIN, GERMANY. Change 26.117 Dataset TYPE747C was missing almost all observations; the VMAC74 output statement was outside the DO loop over CUs. And, Jun 4, 2008 variable R747SDEV is now KEPT in TYPE747C so it can be matched up with TYPE747P observations. Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
VMAC23 SMF Statistics Records: Jun 4, 2008 SMF231RF='FIRST*REFERENCE*FAULTS' SMF23NFR='FIX*REQUESTS*BELOW*2GM' SMF23NGR='GETMAIN*REQUESTS*ISSUED' SMF23NIO='TOTAL*I/O*OPERATIONS' SMF23NRF='NON-FIRST*REFERENCE*FAULTS' SMF23PBG='PAGES*BACKED*DURING*GETMAINS' SMF23PFX='FRAMES*FIXED*BELOW*2GB' SMF23SRB='SRB*DISPATCHES' SMF23TCB='UNLOCKED*TCB*DISPATCHES' SMF23SFG='STATISTICS*SECTION*FLAG' The SMF23SFG bits 0 thru 8, if on, indicate that the value in the corresponding nine variables were limited to four bytes internally and could have wrapped if the value was more than 4x10**9; MXG inputs all nine fields as eight bytes.
VMAC7072 The correct sequence is SYSPLEX SYSTEM SYSNAME ... but WEEKBLD SYSNAME was not always present, and in some cases it was MONTHBLD SYSNAME, in others it was the &MXGSYSN macro variable Jun 3, 2008 name (needed only way back in Version 23 to protect for earlier MXG versions). Unless you have duplicate SYSTEM names in a SYSPLEX, the SYSNAME is identical to SYSTEM, so its insertion will not have any impact on the actual sorted order. (Of course, if you have multiple SYSTEMs with the same SYSTEM name, then the SYSNAMEs will be different, so there is a SMALL chance this could cause a NOT SORTED condition when you combine dailies into weekly/monthly PDB libraries). Thanks to Brian Crow, BT, ENGLAND.
VMACVMXA protect the 6.24 correctly. May 30, 2008 Thanks to Sharon Moir, JPMorgan Chase Bank, USA. Change 26.113 Variable IORATE=DVTSAMPA/DURATM is now created in the VMACRMFV ZRBDVT dataset. May 30, 2008 Thanks to Rodger Foreman, Acxiom, USA. Change 26.112 MXG 26.03: TYPE70 variables CPUMVSTM, PCTMVSBY, SHORTCPS VMAC7072 and PLCPRDYQ are missing if not on a z10 processor; the May 30, 2008 support added for SMF70PAT (CPUPATTM, parked time) failed to protect those calculations when CPUPATTM was a missing value. Fortunately, you can recalculate from PDB.TYPE70: CPUMVSTM=CPUUPTM-MVSWAITM; IF CPUUPTM GT 0 THEN PCTMVSBY=100*CPUMVSTM/CPUUPTM; IF PCTMVSBY GT 0 AND PCTCPUBY GT 0 THEN DO; SHORTCPS=PCTMVSBY/PCTCPUBY; PLCPRDYQ=100*(PCTMVSBY-PCTCPUBY)/PCTMVSBY; IF . LT PLCPRDYQ LT 0 THEN DO; SHORTCPS=1; PLCPRDYQ=0; END;
END; Thanks to Charles Savikas, DCF State of Florida, USA. Change 26.111 -Support for TMVS Release 4.1, INCOMPATIBLE due to fields EXTMVCN inserted in the "JD" records. Many new variables for the EXTMVCNM zIIP and zAAP engines are created in the Job records. EXTMVCNP -The code is enhanced to full "standard" structure, with EXTMVCNS the _Vdddddd macros created, and the _Sdddddd sort macros EXTMVCO now invoking PROC SORT NODUP to remove duplicates instead EXTMVCOF of being simple DATA steps. EXTMVCOH -Redundant variables with STARTIME, ENDTIME and DURATM are EXTMVCOP removed. EXTMVCOS -Thirty new datasets are created, for all of the possible EXTMVCY record types, and all datasets for which I have data EXTMVCYD records are populated and duplicate-removal-validated. EXTMVEC -New IHDRTMVS exist allows deletion of unwanted record EXTMVES types. EXTMVHC EXTMVHM
EXTMVHS EXTMVMC
EXTMVMCL EXTMVMCV
EXTMVRG EXTMVX1
EXTMVX3 EXTMVX4
EXTMVXC EXTMVXD
EXTMVXN EXTMVXO
EXTMVXP EXTMVXS
EXTMVXW IHDRTMVS
IMACTMVS VMACTMVS
VMXGINIT Jun 2, 2008 Thanks to Sam Bass, McLane Co., USA.
VMXGRMFI there are no TYPE72GO observations that match the TYPE70 May 28, 2008 observations. The resultant PDB.RMFINTRV observation has PCTOVHD and CPUOVHTM and CPUTM missing values. Thanks to Chuck Hopf, Bank of America, USA.
ADOCDB2 the MGDB2RC format, and value 40 should have been ABNORM. FORMATS May 22, 2008 Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM. Change 26.108 CICS optional IMS data segment with CMODNAME='USER' and UTILEXCL CMODHEAD='SCHDPDS' or 'SCHDTIME' or 'CALLDLI' is now May 22, 2008 recognized and is supported by the existing IMACICDL member. Previously, all IMS segments had the values of 'PSB WAIT', 'PSB SCHD', 'DB CALL', and 'DB IO' for those fields, and these unexpected text fields cause MXG to NOT identify IMACICDL as needed when UTILEXCL ran. Thanks to Robb Hermes, Sentry Insurance, USA. Change 26.107 INPUT STATEMENT EXCEEDED with SMF 80 with new ASSIZMAX VMAC80A value in TOKDANAM; that field is not INPUT as TOKASIZM May 21, 2008 and kept in all TYPE80xx datasets with extended data. Thanks to Clayton Buck, UniGroup, USA. Change 26.106 Enhancement for AF/OPER SMF record support. VMACAFOP These variables are now INPUT and KEPT in all datasets: May 19, 2008 AFOMATNR AFOMATTY AFOTRNAM AFOCPUTM AFOEXECN AFOCONSN The AFOCPUTM is now input as &PIB.4.3. Thanks to Joseph J. Faska, Depository Trust, USA.
VMAC7072 R723CSUP='UN-NORMALIZED*ZIP*SERVICE*UNITS' May 19, 2008 because it contains the zip service units before their normalization back to the same scale as the CPUUNITS. The variable ZIPUNITS contains the normalized service units. ZIPUNITS and R723CSUP are different ONLY if the CP engine speed is less than the ZIP engine speed. Thanks to Bret Hoesly, Telephone & Data Systems, Inc, USA. Change 26.104 Variable SMF70PMU was not divided by NRSAMPLE and its VMAC7072 label was incorrect. It now is May 19, 2008 SMF70PMU='AVG BLKED*DISPATCH*UNITS*PROMOTED' Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY. Change 26.103 INPUT STATEMENT EXCEEDED ID=42 SUBTYPE=15 when there were VMAC42 more than one S2 segment. MXG logic for LENGTH test was May 19, 2008 corrected. Thanks to Dan Case, Mayo Clinic, USA. Change 26.102 TYPETASK='J ' occurred in TYPETMNT/TYPESYMT because the VGETJESN VGETJESN logic when there is no SUBSYS, and the JCTJOBID May 19, 2008 contains 7 digits did not set TYPETASK='JOB'. Thanks to Brian Felix, Wachovia Corporation, USA. Change 26.101 The ending semicolon in the %VMXGVERS(VMXGFOR,xx.yy); VMXGFOR statement caused a syntax error; that ending semicolon May 17, 2008 is not only not required, in this instance it was wrong:
a semi-colon at the end. These types of semi colons are never required, since the macro processor knows to execute the macro when the tokenization sees the right parenthesis. In this particular scenario, what happens is that that trailing semi colon gets returned to the input stream to the datastep - in the middle of the proc sort statement, which is why is complains at DATA= being a Statement that is not valid or out of order. Thanks to James Hein, Erie Insurance, USA. Thanks to Chris Weston, SAS ITRM, USA.
VMACNMON INPUT STATEMENT EXCEEDED RECORD LENGTH error. The header May 16, 2008 had only 7 fields, causing the error, but the actual MEM data records are valid, so the handling of the header is revised to protect for the invalid record. Thanks to Angelo Pezzella, SAS Italy, ITALY. Change 26.099 Variable ELAPSTM is now calculated instead of missing. VMACORAC
May 16, 2008 Thanks to Bret Hoesly, Telephone and Data Systems, USA. Change 26.098 Support for Informatics STAT user SMF record. EXIFOCLI Five datasets are created from the user SMF record: EXIFODB2 IFOLIS INFOLISN INFORMATICS LISTENER EXIFOEXC IFOEXC INFOEXCP INFORMATICS EXCEPTION EXIFOFIL IFOFIL INFOFILE INFORMATICS FILE EXIFOLIS IFODB2 INFODB2 INFORMATICS DB2 IMACINFO IFOCLI INFOCLIE INFORMATICS CLIENT TESSUSR1 The datetimestamps of the INFO variables are still on the TYPEINFO GMT clock, because there is no GMT offset in the records. TYPSINFO The delta between the END (GMT) and SMFTIME (Local) can VMACINFO not be used, because END is missing in many records. The VMXGINIT vendor has been requested to add a GMT offset field so May 21, 2008 the GMT datetimestamps can be converted to local zone. Thanks to Elizabeth Griesse, Securian Financial Group, USA. Change 26.097 Divide-by-zero for denominator CPUCPLEN is now protected. VMACRMFV
May 13, 2008 Thanks to Betty Wong, Bank of America, USA. Change 26.096 -Variables QW0227FG and QW0227PG were always missing; the VMAC102 test for QWT02R1L should have been 17 and not 21. May 13, 2008 -Variables QW0226DB and QW0026OB are now $HEX4. format. Thanks to Karthik Vinayagam, Morgan Stanley, USA. ====== Changes thru 26.095 were in MXG 26.03 dated May 11, 2008========= Change 26.095 -ML-41 of ASMTAPEE the MXG Tape Mount Monitor corrects the ASMTAPEE JOB Name to use MDBGJBNM in the SMF records it writes for May 10, 2008 WTO SYSLOG events; some records had HSM instead of VTCSS. The new ASUMTAPE logic in Change 26.083 corrects the JOB when it is not the same as SYSLJOB, but this corrects the SMF records created by MXGTMNT monitor. -The Allocation Recovery Event subtype created by MXGTMNT was not correct for the (typical, usually automated) WAIT event. ML-41 corrects the logic for that subtype, so the observations in TYPEARCV contains job info and the delay to that job due to insufficient tape devices, which is what an Allocation Recovery Event describes. -Some general performance enhancements were also made. Thanks to Chuck Hopf, Bank of America, USA. Change 26.094 ERROR: LIBRARY PDB IS NOT IN A VALID FORMAT FOR ACCESS CONFIGV9 METHOD SASV6SEQ. May 9, 2008 occurs if OPTIONS SEQENGINE=V6SEQ or TAPENGN=V6SEQ are in effect; you can use PROC OPTIONS to display the value of those options. SEQENGINE is defined in CONFIGV9, and TAPENGN is defined in VMXGINIT; both default to V9SEQ (or V8SEQ if still using SASV8), but either option can be changed with a %LET XXXX=VnSEQ, so searching your MXG tailoring libraries for V6SEQ should locate that text.
as the last datasets in the //CONFIG DD, so that any SAS option I specify in CONFIGV9 will override the default SAS options specified in its .CFG file. However, there are only these options that are in both the SAS BATW0 and the current MXG CONFIGV9 members: Option SAS Value MXG Value BUFNO 3 2 BLKSIZE 6144 MEMLEAVE 512K 10M SEQENGINE TAPE V9SEQ NLSCOMPATMODE NONNLSCOMPATMODE NLSCOMPATMODE THREADS THREADS NOTHREADS
JCLTESS9 were not added to support CONTROL-M support. JCLTEST9 JCLTEST8
JCLTESS8 May 9, 2008 Thanks to Bernd Klawa, Stadwerke-Bielefeld, GERMANY.
VMAC74 was zero in an interval when the device was Varied. The May 9, 2008 divide is now protected. Thanks to Leendert Keesmaat, UBS, SWITZERLAND. Change 26.091 Mis-alignment of the CS Server by four bytes caused very VMAC111 large values in some variables in CTG SMF 111 CS Server May 7, 2008 records. The VMAC111 in 26.03 did not contain this Jun 3, 2008 change. Thanks to Ray Dunn, CIGNA, USA.
VMXGSUM if OUTCODE= was specified; Change 26.065 COPYed, rather May 7, 2008 than MOVEd the LENGTH statement to after the SET, so the WARNING was still printed. As a result, MXG 26.03 is now the required MXG Version to eliminate the WARNING in MXG delivered code. Thanks to Bruce Widlund, Merrill Consultants, USA.
EXCTM065 Separate programs, TYPECTMU for Unix, TYPECTMZ for ZOS EXCTM100 read the "flat" log files to create new datasets. EXCTM101 From Unix data, TYPECTMU/TYPSCTMU reads CTMLUNIX to EXCTM133 create these datasets: EXCTM134
EXCTM203 DDDDDD DATASET DESCRIPTION EXCTM206
EXCTM207 CTM065 CTMU5065 CTL-M UNIX MESSAGE ID 5065' EXCTM208 CTM100 CTMU5100 CTL-M UNIX MESSAGE ID 5100' EXCTM209 CTM101 CTMU5101 CTL-M UNIX MESSAGE ID 5101' EXCTM210 CTM133 CTMU5133 CTL-M UNIX MESSAGE ID 5133' EXCTM211 CTM134 CTMU5134 CTL-M UNIX MESSAGE ID 5134' EXCTM212 CTMUOT CTMUOTHR CTL-M UNIX OTHER MESSAGE ID' EXCTM213 From ZOS data, TYPECTMZ/TYPSCTMX reads CTMLZOS to EXCTM216 create these datasets: EXCTM217 EXCTM219 DDDDDD DATASET DESCRIPTION EXCTM281 EXCTM511 CTM203 SEL203I CTL-M ZOS MESSAGE ID SEL203I,220I,221I EXCTM65A CTM206 SEL206W CTL-M ZOS MESSAGE ID 206W FORMATS CTM207 SEL207E CTL-M ZOS MESSAGE ID 207E IMACCTMU CTM208 SEL208I CTL-M ZOS MESSAGE ID 208I IMACCTMZ CTM209 SEL209I CTL-M ZOS MESSAGE ID 209I TYPECTMU CTM210 SEL210E CTL-M ZOS MESSAGE ID 210E TYPECTMZ CTM211 SEL211W CTL-M ZOS MESSAGE ID 211W TYPSCTMU CTM212 SEL212W CTL-M ZOS MESSAGE ID 212W TYPSCTMZ CTM213 SEL213W CTL-M ZOS MESSAGE ID 213W VMACCTMU CTM216 SEL216W CTL-M ZOS MESSAGE ID 216W VMACCTMZ CTM217 SEL217W CTL-M ZOS MESSAGE ID 217W VMXGINIT CTM219 SEL219I CTL-M ZOS MESSAGE ID 219I May 6, 2008 CTM281 SEL281I CTL-M ZOS MESSAGE ID 281I CTM511 JOB511I CTL-M ZOS MESSAGE ID 511I CTM65A CTM64AI CTL-M ZOS MESSAGE ID 65AI CTMZOT CTMZOTHR CTL-M ZOS OTHER MESSAGE IDS Thanks to John Toohey, IBM, AUSTRALIA. Change 26.088 Support for sub-subtype '0200' MQ segment creates two new EX112MQC datasets from SMF 112 records: EX112MQT DDDDDD DATASET DESCRIPTION IMAC112 112MQC T112MQCO OMEGAMON CICS MQ DETAIL VMAC112 112MQT T112MQCT OMEGAMON CICS MQ TOTALS VMXGINIT There are also '0001' MQ Segments for which I do not yet May 5, 2008 have a DSECT, to be added when documentation received. May 9, 2008 May 9: Still no documentation for 0001 record, and the 0200 documentation is wrong; there are 25 4-byte counters in the segment, but the DSECT from 2007 documented only 8 pair of 4-byte clock/counters. For now, first 8 counters have the 8 labels from the 2007 documentation, the rest a counter number. Thanks to Ray Dunn, CIGNA, USA. Change 26.087 Flag variable UBFLAG1 in DCOLBKUP was decoded into these VMACDCOL variables, but they were not kept until now: May 5, 2008 UBINCAT UBNOENQ UBBWO UBNQN1 UBNQN2 Thanks to Michael Friske, Fidelity Systems, USA. Change 26.086 Support for AF/Operator SMF Record creates four datasets: EXAFOPEX DDDDDD MXG MXG EXAFOPFI DATASET DATASET DATASET EXAFOPIM SUFFIX NAME LABEL EXAFOPMA IMACAFOP AFOPEX AFOPEXEC AFOP EXEC TYPEAFOP AFOPFI AFOPFILE AFOP FILE TYPSAFOP AFOPIM AFOPIMMED AFOP IMMED VMACAFOP AFOPMA AFOPMATCH AFOP MATCH VMXGINIT
May 5, 2008 Thanks to David Kaplan, DTCC, USA. Change 26.085 Variable SMFTIME was not in the BY list for TYPE70PR and WEEKBLD TYPE72MN in WEEKBLD, but was in the BY list for MONTHBLD. May 5, 2008 The BY list in WEEKBLD was updated. The absence of the SMFTIME variable caused a NOT SORTED condition when the clocks were set back one hour on April 6. Thanks to Peter Krijger, ANZ National, NEW ZEALAND. Change 26.084 Enhancements to HSM sample reports adds a new REPORT6, a ANALHSM time-interval summary of MIGRATE/RECALL/BACKUP activity. May 2, 2008 about every tape mount event. Additionally, new filtering parameters are created in the RPTFILT1-RPTFILT6 macros. Thanks to Scott Barry, SBBWorks, Inc, USA. Change 26.083 Major rewrite of ASUMTAPE corrects errors and supports ASUMTAPE SPIN logic to create PDB.ASUMTAPE with EVERYTHING May 2, 2008 possible about every tape mount event. May 8, 2008 May 10, 2008 THIS IS AN INCOMPATIBLE CHANGE: You MUST delete your old SPIN.SPINMOUN dataset before you implement this revised ASUMTAPE algorithm.
"complete" tape mount events, and most "incomplete" mounts but there were cases with only a single SYSLOG event (notable, from our friends HSM and DMS that do their own unique thing!) in which the output was not always correct or complete. In addition, as documented, ASUMTAPE never implemented the full "SPIN" logic to hold incomplete events for the next execution of ASUMTAPE. The TYPESYMT processing of SYSLOG records was reinvented, using the SYSTEM JOB JESNR DEVNR sequence, rather than the insufficient DEVNR DESCENDING EVENTIME sequence that was incapable of full protection for these end cases. -May 10: Final logic errors due to LASTDEVN being kept in SPINSYSL cleaned up match up of "full" vs "SPLIT SPIN" so observation counts again matched before and after tests. -The unique DSNAMEs in the input TYPESYMT and TYPETMNT were compared with the output DSNAMEs in PDB.ASUMTAPE and many were blank, and some were wrong, as SYSLDSN is only populated in IEC233A,IEC705I, and IEC501A/IEC501E SYSLOG messages; the blank values in the other records overlaid DSNAME. Now, all observations that had DSNAME in TMNT or SYSLOG have non-blank DSNAME. Some events can never have a DSNAME (e.g., HSM only-234E KEEP); variable MNTHAVE identifies which SYSLOG records were found for this mount event, and can be used to identify those cases where the DSNAME is always blank. Thanks to Paul Naddeo, FISERV, USA. Thanks to Scott Barry, SBBWorks, Inc, USA. Thanks to Pat Jones, DST, USA. Change 26.082 The old IEFU84 sample SMF exit failed with z/OS 1.7 and IEFU84 z/OS 1.9; the addition of $CADDR after $HCCT in the ASM May 1, 2008 code eliminated the ASMA044E UNDEFINED SYMBOL messages for symbols C@XMXSRB, and CADDR, thanks to excellent ASM sleuthing by Dean. Thanks to Dean Gambill, Lowe's Companies, USA. Thanks to Jim Horne, Lowe's Companies, USA.
DAILYDSR DAILYDSN or DAILYDSR programs, so it was removed from JCLDAYDS that JCL example. Apr 30, 2008 -The DAILYDSR example for using DFSMS/RMM instead of TMS did not create the DCOLCLUS dataset from DCOLLECT data. Thanks to Diane Eppestine, IBM Global Services, USA. Change 26.080 MXG 26.01 wrongly changed QPACAAFG INPUT to $CHAR2. as I FORMATS thought it contained hex text. The $EBCDIC2 input is now VMACDB2 restored, a hex zero value is converted to blanks, and Apr 29, 2008 its $MGDB2PK format enhanced to decode that blank value: VALUE $MGDB2PK ' '='BLANK:NOT DEFINED' '01'='01:STORED PROCEDURE' '02'='02:USER DEFINED FUNCTION' '03'='03:TRIGGER EXECUTING' ; Thanks to Glenn Bowman, Wakefern, USA. Change 26.079 Variable IFAHONOR could be blank when it should have VMAC7072 been 'Y'; typo in logic was corrected. Apr 25, 2008 Thanks to William Wailun Wong, HSBC, HONG KONG Change 26.078 MXG 26.02 VMXGSUM caused VARIABLE NOT FOUND if variables VMXGSUM that do not exist in the input dataset were named in one Apr 24, 2008 of the output lists (eg., in SUM= ). This support was accidentally deleted. This would happen if you used an unmodified MXG ASUMxxxx member that listed all variables to be summed, but you had dropped variables from the input dataset. (Think ASUMDB2A which sums all DB2ACCT variables). Thanks to Jim Kovarik, Aegon, USA.
VMAC30 record had IFAUNITS greater than CPUUNITS, citing APAR Apr 29, 2008 OA24836 as the IBM correction. But even with that APAR, imprecision in zAAP and CP Service Units caused small negative deltas equivalent to a few hundredths's of a CPU second, as confirmed by IBM Support, who pointed to new SMF updates documenting these service unit issues, and recommended the CPUUNITS and IFAUNITS be recalculated based on the proportions of the CPUTCBTM and CPUIFATM, when the subtraction returned a negative value. In so doing, I discovered that all test cases with negative deltas actually had CPUTCBTM=0, i.e., they were tasks Yüklə 28,67 Mb. Dostları ilə paylaş:
|