* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Thanks to Esther Remiro, La Caixa, SPAIN. ====== Changes thru 29.262 were in MXG 29.07 dated Nov 24, 2011========= Change 29.262 First MXG 29.07 Only, and only if IMACEXCL is tailored to VMAC110 read exclude fields. WARNING: UNBALANCED QUOTES message Nov 23, 2011 was printed, BUT ALL DATASETS WERE CREATED CORRECTLY. There were no unbalanced quotes, but 29.07 had introduced new " &CICXLTR " syntax into the existing PUT '***ERROR' statement printed when MXG detects there are excluded fields that are not supported in your IMACEXCL tailoring; the enhancement prints your selection statements from the current IMACEXCL member in use to help error resolution. And for reasons I know not now, that macro reference was the cause of the spurious warning. Now SYMGET('CICXLTR') is used to retrieve the text for the PUT statement. Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
VMAC0 "true" IPLs datasets WORK.TYPE0 and PDB.IPLS to have ZERO Nov 23, 2011 observations since that change in MXG 29.06. That this error was accidentally discovered when trying to diagnose the unbalance quote warning in Change 29.262, by counting the two comment tokens ( /* */ ) separately to see if the counts are equal (because often unbalanced quote errors result from unbalanced comments, or new comments wrapping around commented text) suggests that few sites have IPLs that needed to be reported! -An incorrect pair of single quotes was changed to single quote in optional IMACICBB code, discovered the same way when counting quotes. The pair was inside the comment block, and it's been there a long time; either tailoring users caught it and fixed it when enabling that optional CICS segment, or nobody uses this optional segment. Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
VMACDB2H records created records with INVALID HEADER values that EXITCICS caused STOPOVER ABEND. This change thought the SMF data Nov 23, 2011 was valid and added protection for the "truncated" data Dec 18, 2011 segments, but that protection, while safe, was not needed and the problem in the SAS INFILE exit code in EXITCICS is being investigated by SAS Technical Support. The DB2 V10 compressed records can be uncompressed using the IBM utility program xxxxxxx until the problem is resolved, but this is most strange as MANY sites are successfully reading compressed DB2 (and CICS!) records with EXITCICS.
DB2 V10 record with INVALID HEADER caused STOPOVER ABEND. The ID=101 SUBTYPE=1 record had invalid offsets that are now protected. The starting INPUT location was compared with the LENGTH of the record, but in this case, while the start offset happened to be less than the LENGTH, the length of data to be input was beyond the LENGTH, causing the STOPOVER ABEND. Now both the start and end of each of these truncated name fields is validated and an error message "INVALID DB2 RECORD QWHC=...." printed. This text will be updated when an APAR/PTF is known. Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS. ====== Changes thru 29.259 were in MXG 29.07 dated Nov 21, 2011========= Change 29.259 Cosmetic. Diagnostic PUTLOG statement in IFCID=140 code VMAC102 was left and printed A_N_= nnn .... on the SAS log for Nov 18, 2011 each IFCID=140 record, but no other impact. Thanks to Stephen Hoar, Lloyds Banking, ENGLAND. Change 29.258 Comparison of I/O Connect Times in RMF 74 and SMF 30 show BUILD005 DEVCONTM SMF74CNN - DEVICE CONNECT TIME 2,058,143 sec BUIL3005 SMF30AIC - DASD CONNECT 2,150,200 sec IMAC30IO IOTMTOTL SMF30TCN - ASID IO all ASIDs 1,482,821 sec VMAC30 IOTMTODD SMF30DCT - DD IO all ASIDS 1,253,434 sec Nov 18, 2011 IOTMNODD MXGcalc - TOTL not in DDs 229,387 sec RMF DEVCONTM and RMF SMF30AIC match quite closely, but that "hardware" IOTM captured in RMF and in SMF30AIC is much larger (2150200-1482821= 677,379 sec) than the IOTM that is captured in SMF30TCN, Address Space IOTM Total. To investigate, variable in TYPE30/JOBS/STEPS/SMFINTRV IOTMNOCA='CONNECT*TIME*NOT CAPTURED*IN IOTMTOTL' is created to see if the cause of this uncaptured IOTM can be identified/correlated. This text will be updated when more is known (including my asking IBM). Some initial investigation with different data shows -Of 9881 records with non-zero SMF30AIC, 1867 had a negative IOTMNOCA, but only 40 were more than -10 sec and the max negative was 2 jobs at -3 minutes. MOST OF THESE WERE PROGRAM=DSNYASCP although our old friend IFASMFDP had instances of -37, -17 and -12 sec. -Of the other 7119 with positive IOTMNOCA, 592 were greater than 3 seconds, AND ALL WERE PROGRAM=BPXPRFC. which is the first step of an OMVS Spawned Address Space Substep. This suggests that the use of I/O by USS-OMVS is ONE source of NOT-Captured IOTM in 30s. There are many OMVS I/O counters in the OMVS segment in SMF 30s, but none have the I/O Connect Time. -But, a third sites data looking at DB2 and ADABAS jobs shows large positive uncaptured values for ADABAS but for DB2 jobs, large negative uncaptured, i.e., time in SMF30TCN is LARGER than the time in SMF30AIC. -This issue is under discussion with IBM z/OS folks; I think that IOTM for USS is captured in AIC but not in IOTM, and there are errors in which address space records IOTM when there are "partner" database ASIDs, but the total IOTM are correct. We'll see!!
DB2JOB01 13:29:00.16 0:09:08.14 0:02:49.97 -378.16 DB2JOB01 13:44:00.16 0:07:51.57 0:01:34.28 -377.29 DB2JOB01 14:14:00.17 0:10:44.91 0:00:23.18 -621.73 DB2JOB01 14:29:00.21 0:10:22.25 0:00:55.89 -566.35
ADABAS71 13:29:00.09 0:01:40.57 0:08:55.19 434.61 ADABAS72 13:29:00.09 0:03:54.11 0:16:02.57 728.45 ADABAS72 13:44:00.04 0:03:32.12 0:16:39.49 787.37 ADABAS72 13:59:00.02 0:03:05.23 0:16:01.69 776.46 ADABSD72 14:14:00.07 0:02:48.06 0:15:40.71 772.64 ADABSD72 14:29:00.05 0:02:05.13 0:11:20.71 555.58
VMAC110 CICS 8-byte time durations, so it was a little too large! Nov 17, 2011 Thanks to Robert C. Crawford, USAA, USA. Change 29.256 Change 29.120 revisions to ASUMVMXA were not included in ASUMVMXA that change until today. Nov 17, 2011
VMACVMXA were left in //WORK, and dataset macros _LSUMIOD/_LDEVTOT VMXGINIT were not defined nor were &PSUMIOD nor &PDEVTOT; all are Nov 16, 2011 now defined and used so they now default to //PDB. _RPT36 was revised to use _LDEVTOT as its input dataset. Thanks to Scott Barry, SBBWorks Inc, USA. Change 29.254 IMF variable ARRVTIME has resolution to only one decimal VMACCIMS place, but "newer" variable TRNARVTH time has two decimal Nov 19, 2011 places, so ARRVTIME is now revised to use the DATE part of original ARRVTIME but with TRNARVTH's value for TIME. Thanks to Ken Jones, Xwave, CANADA.
VMACXAM eliminated warning messages about new segments, and most Nov 14, 2011 new data fields are decoded, and this level set has been validated with data records thru MXG's QA job stream. Thanks to Douglas C. Walter, Citigroup, USA.
VMAC120 than the (strange) duration units that MXG decoded. Also, Nov 14, 2011 the MXG code caused INVALID ARGUMENT messages if executed on ASCII; those fields had not been translated to EBCDIC before they were used in the INPUT function. -The undocumented SM120XZ field is the CPU time that has been offloaded by WebSphere to zIIP engines, and it is so labeled now. Thanks to Millard Stephens, FMR, USA. Thanks to Warren Cravey, FMR, USA. Thanks to Raj Ramachandran, IBM, USA.
EXNTDTSA adds three new objects that create three new datasets: EXNTVMWA dddddd dataset description EXNTVWVS NTDTSA DTSALRTR DTS.AlertRecipient IMACNTSM NTVMWA VMWAREh VMWARE VMACNTSM NTVWVS VMWHVSPH VMWARE.HOST.VSPHEREREPLICATION VMXGINIT -Existing VMWARE objects were INCOMPATIBLY changed by the Nov 12, 2011 insertion of a separate field for the 2nd instance field. Previously a single field contained both instance values, separated by a '::', that MXG parsed in the two instance variables. MXG now detects NRNAMES=2 and uses separate fields when they exist, but that new NRNAMES value causes error messages (and no observations output), if you read NTSMF V4 (new) records with MXG prior to 29.07. These segments have two fields stored for xxxxINST/INS2 VWGC VWHC VWGD VWHD VWGN VWHN VWHS These segments have one field that is still parsed to populate the two xxxxINST and xxxxINS2 instances: VWGA VWHA VWGM VWHM VWGS -New variables xxxxVMHO (VM*HOST), xxxxCPU (CPU*NUMBER), xxxxVMGU (VM*GUEST) are created from new fields added at the end of many existing VMWARE records. -Many new variables were added to existing VMWARE datasets in Version 4, too many to list here, but you can find all in VMACNTSM after the text "ADDED BY CHANGE 29.251" in the KEEP= list for all datasets. Change 29.250 Windows SEVEN restricts writes to the root, program file, VMXGPRNT and other directories. VMXGPRNT writes text/code to file Nov 10, 2011 TMPPRNT and then %INCLUDEd TMPPRNT, but the MXG default file C:\MXGTEMP.SAS was in the root directory, so it was restricted from access. The circumvention was to change filename TMPPRNT to INSTREAM, which is the MXG ddname specifically designed (and used internally by MXG) to dynamically create SAS code and/or MXG macro definitions "instream" and then %INCLUDE them. TMPPRNT was never needed, but the original contribution was left asis. FWIW: Even with the error, all datasets were printed; The error prevented the printing of the variable name along with its label, which is the ONLY reason you want to use VMXGPRNT/VMXGPRAL, and why I saw the error, as I use VMXGPRAL all the time, especially to understand all of the variables in a new dataset I've just built. Change 29.249 TYPSXAM example to create and sort all datasets to PDB TYPSXAM did not sort all fifty-six datasets. The structure of Nov 10, 2011 MXG support for XAM is different because XAM has five INFILEs that create fifty-six datasets. Each infile has a macro pair _TXAMfff and _SXAMfff where _TXAMfff reads infile fff to create all fff datasets and _SXAMfff sorts the fff datasets to the PDB. But, the _SXAMfff macros have not been updated in a long time so the newer XAM datasets were not in the XAM PDB data library. The simple resolution is to replace the five _SXAMfff macro invocations in TYPSXAM with the _SXAM product sort macro that sorts ALL of the XAM product's datasets (and all of the _Sxxxx product sort macros are validated to sort all datasets as part of MXG's robust QA jobstream). An additional problem is avoided: the _SXAMDEV token name is used for both the data set sort token and for the _SXAMfff "infile fff" token. Using _SXAM and not using the _SXAMfff tokens avoids a major redesign and new (INCOMPATIBLE) naming conventions. Thanks to Debbie Mattos, Lockheed Martin, USA. Change 29.248 INVALID ARGUMENT TO SUBSTR in SYSLOG IEC205I message text VMACTMNT in ASMTAPEE/MXGTMNT tape mount/syslog monitor SMF record. Nov 9, 2011 Parsing to INPUT the mmm after TOTALBLOCKS=mmm into the SYSLBLKS variable in TYPESYMT dataset expected 16 bytes and failed when there were fewer characters for mmm. Now the parse stops at the first blank character. This change in format of the IEC205I message occurred after PTF UA90604, in APAR OA90604, which included IFG0194J, which contains message IEC205I. The prior PTF level was UA60149. APAR OA38051 now documents: Unnecessary information on the third line of IEC205I Characters *HAS will appear after spaces and it was these unexpected characters instead of blanks that led to this MXG circumvention change. Thanks to Clayton Buck, UniGroup, USA. Change 29.247 Support for ZEN FERRET, ZEN IMPLEX and ZEN OSA user SMF EXFERSAW records from William Data Systems GmbH products. EXZOSAEV -VMACMPLX - ZEN IMPLEX V5.1 adds two new variables FORMATS ESMFHCMN (CPC*NAME) and ESMFHLNM (LPAR*NAME) to its IMACFERT header (COMPATIBLY) and those variables are kept in all IMACZOSA ZEN IMPLEX datasets. VMACFERT -VMACZOSA. Support for ZEN OSA MONITOR V1.3 SMF record, VMACMPLX creates TYPEZOSA dataset with separate observations for VMACZOSA each value segment in each SMF record. All four subtypes VMXGINIT (CHAN,LPAR,I/O,QUEUE) have the same record structure with Nov 10, 2011 a fixed suite of OSA descriptors and one or more value Dec 16, 2011 segments; MXG creates a separate observation for each of the value segments in each SMF record. Variable ZOSARESC, the resource name is EBCDIC text in the I/O and QUEUE record, but because it is a hex string in the CHAN record it's value is instead kept in variable ZOSARESH. -VMACFERT. Support for ZEN FERRET V2.3. INCOMPATIBLE. -Datasets FERRETCP, FERETEE, FERETRT datetime field was 1 changed from mm/dd/yy to ddMONyy, so prior MXG versions will fail due to this INCOMPATIBLE change. -Two new fields have been added to the RTP and CP data section, a flag byte which indicates the type of history and a field showing the transmission priority. -Support for new Session Awareness Section creates new FERRTSAW dataset, although some minor issues have just been opened. -The key section for SAW has PLU and SLU, but those fields are also in the data segment -Offset value to SAW is 106, but segment starts in byte 109; the offset value should be 112, and three less to get to the SAS byte location of that offset. Thanks to Bruce Sloss, PNC Bank, USA. Thanks to Ronald Delp, PNC Bank, USA.
BLDSMPDB compiler error was caused when %UPCASE(&PDB) was used: Nov 8, 2011 "ERROR: A character operand was found in the %EVAL function or %IF condition where a numeric operand is required. The condition was: %upcase(&runday) eq %upcase(&pdb) and %length(&rerun) ne 0 " because that DASH was not "masked" and was thus seen as a mathematical minus and not a part of the filename. This is obscure, to say the least, but SAS documents that neither %UPCASE() nor %STR() macro functions mask special characters, and that %QUPCASE() should be used instead. But in this specific test, the UPCASE() was never needed as both arguments were previously LOWCASED() which DOES mask special characters. But the &RUNDAY EQ &PDB test cannot be used because that dash will still look like a minus sign, so the circumvention/re-design now uses IF %QUOTE(&RUNDAY) EQ %QUOTE(&PDB) to mask the DASH and successfully compile. Thanks to Mitchell Loren, Los Angeles County Education, USA.
VMACTMS5 when a non-TMC file is read, but that PoundSign was not Nov 8, 2011 recognized with some character sets, so the test is now shortened to TMSCTL='TMSCTL' to avoid a false positive. Thanks to Akre Trond Maurita, EDB, NORWAY.
VMACTMO2 -TMON/CICS V3.3 increased MRO's TAMRSYID field from 4 to 8 Nov 10, 2011 bytes, to hold the IPIC CONNID. Unfortunately, while MXG does use segment length to keep aligned with each of the repeated MRO segments, inserting 4 bytes (instead of new 8 bytes at the end) shifts/trashes the TAMRxxxx variables in the MONIMRO dataset due to this INCOMPATIBLE change, but there are no error messages nor condition code set, so V3.3 is INCOMPATIBLE ONLY IF YOU USE MONIMRO dataset; MXG Version 29.07 is required for V3.3 only for MONIMRO. And, fortunately, MONIMRO is very rarely used in reports. TMON records with earlier MXG versions will not cause errors nor ABENDS, just bad data in one seldom used -TAMRFLG1 and TAMRFLG2 fields are listed in V3.3 as new but were previously input and kept in MONIMRO dataset. -The DSECT for the header showed an optional, inserted 40-byte extended-common-header segment, that would have made all V3.3 records incompatible, but, fortunately, that segment will NOT exist in V3.3 records. And, more fortunately, MXG is updated to support its existence, so if/when it appears in a future record, it won't be an incompatible change. Change 29.243 Calculation of ESTSCP1M had (0.57*(0.1*RNI)) but that was ASUM113 a typo, now corrected to (0.57+(0.1*RNI)). MXG's error VMAC113 caused very small values in ESTSCP1M. Nov 2, 2011 Thanks to Dave Cogar, Wells Fargo Bank, USA.
VMAC102 option COMPRESS=YES was changed to COMPRESS=NO (which Nov 1, 2011 causes SQL text to be broken into 100 byte chunks that Nov 3, 2011 are output in dataset T102T14x instead of T102S14x), the DB2 Audit variables QW0140TX,QW0141TX,QW0142TX,QW0145TX were only readable text in the last segment or if there were less than 100 bytes of SQL text, because MXG's logic for this "chunking" algorithm was written long ago and it was only validated back then on z/OS. MXG INPUT those fields with $EBCDIC100, but that INPUT should have been with $CHAR100, and then the INPUT function with $EBCDIC informat does that translation to readable text. And variable QW0124T's INPUT was also corrected. Thanks to Lars Fleischer, SMT Data, DENMARK. Thanks to Jorgen Lund, SMT Data, DENMARK.
JCLSPLIT ID=102 records in "B" DB2 output file, and then failed to Oct 28, 2011 add 102 to the NOTYPE list in the "E" group (ALL OTHER), so all 102s were output in both "B" and "E" output files. The 102 is now added to the NOTYPE list in "E". Thanks to Jennifer D. Ayers, WVOT Data Center, USA. Change 29.240 The length of new variable SM1209FH could not be changed VMAC120 as described in Change 29.081. That text was rewritten. Nov 8, 2011
VMAC7072 all of the RMF datasets, from STARTIME. VMAC71 VMAC73
VMAC74 VMAC75
VMAC76 VMAC77
VMAC78 VMAC79
Oct 27, 2011 Thanks to Frank Lund, EDB ErgoGroup, NORWAY. Change 29.238 Change 25.142 and Change 28.211 identified USER SMF VMACARB VMAC's using "MACRO _xxxxID nnn%" instead of "MACRO VMACDLMN _IDxxxx nnn%" but those changes did not revise those VMACDMON members to use the more-recent-and-preferred _IDxxxx VMACHURN syntax. All VMAC's are now updated to support both forms VMACM204 of the _ID macro to tell MXG what SMF record number to VMACNSPY process as product xxxx, but only to be consistent, just VMACPDSM in case we needed to generate them internally in MXG. VMACRMDS Note that using UTILBLDP is recommended to read multiple VMACROSC SMF records, and by using it's USERADD=xxxx/nnn argument VMACRTE set the SMF IDs, you do not need the _ID definitions in VMACTSOM your IMACKEEP tailoring. VMACVVDS -But some inconsistencies in _IDxxxx macron names exist: VMACWYLA Arbiter can write each of its subtypes with a separate VMACWYLB SMF record ID (_IDARB00-IDARB0C). VMACX37 VMACM204 has _IDM204L and _IDM204S for Log/Since-Last. Oct 26, 2011 VMACTSOM has _IDTSOMC and _IDTSOMS for Command/System. VMACHSM has _IDHSMDS and _IDHSMD1 for Daily/FSR Stats. VMACHBUF was in 25.142 but had been updated to _IDHBUF. VMACWYLB was in 25.142 but had been updated to _IDWYLB. Change 29.237 The calculation of ZIPUSED and ZIEUSED did not include ASUMMIPS the divide by CAPZIPRT*100. Oct 24, 2011 Thanks to Bernhard Bablok, Allianz Managed Operations, GERMANY. Change 29.236 SMFSRCH is a VERY slick new tool to print all SMF records COMPALL that contain a specific "LOOKFOR" character text string. COMPALLN All SMF records are scanned for the "LOOKFOR" text SMFSRCH - using IF INDEX(_INFILE_,"LOOKFOR") syntax - TYPESMF and selected SMF records are written to the temporary VMXGGETM DDNAME/filename of MXGTEMP, from where TYPESMF program VMXGPRAL reads them to create every possible MXG dataset that can VMXGSRCH be built from SMF records, including "USER" SMF records. Nov 11, 2011 Then, ONLY the observations in those datasets that have a variable containing the "LOOKFOR" text are printed. (This extra filtering is needed because some datasets created from the selected records won't contain that "LOOKFOR" text. Consider if LOOKFOR=USERID, TYPE 30-4 records with that USERID will be selected and TYPE30_D dataset will have many observations, one per DD name, but the USERID field is not kept in dataset TYPE30_D, so this final filtering prevents those unwanted "false positive" observations from being printed.) The selected SMF records can be kept by making //MXGTEMP a permanent dataset, and the selected MXG-created SAS datasets can also be kept. -The //MXGTEMP DD may need to be added to your JCL. -SMFSRCH creates all possible datasets that can be created from IBM or USER SMF records. IBM fixed-numbered records are automatically output, but only the USER SMF records that have a "MACRO _IDxxxx nnn % definition in IMACKEEP or in IMACxxxx will create observations (BUT: you can use the USERADD=xxxx/nnn argument to tell MXG the nnn you use for product xxxx and those datasets can be populated). Yüklə 28,67 Mb. Dostları ilə paylaş:
|