* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
caused INPUT STATEMENT EXCEEDED because that segment was 82 bytes in prior records. A LENLEFT test to protect was added, but removing the +2 appears to realign subtype 1. -FERRET subtype 4 record removed the +6 bytes at start. Thanks to Bruce Sloss, PNC Bank, USA. CHANGE 30.065 Vendor segment for ETFR ID=80 SMF record caused MXG to VMAC80A have INPUT STATEMENT EXCEEDED RECORD. Previous FRI=02 Apr 18, 2012 had an extra byte (in 2004 when ETFR segment was last updated!) that is not there now, DO Group bypassed. Thanks to J. Grasing, Metropolitan Life, USA.
VMAC115 ten variables with log statistics for each of up to four Apr 18, 2012 logs in the MQLOG dataset. Thanks to Joseph J. Faska, Depository Trust, USA. CHANGE 30.063 The SMF 117 subtype 'IMFL' new variable SM17ACCT with the VMAC117 'ACCOUNT*ORIGIN' is input and kept when it exists in the Apr 17, 2012 WebSphere 7.0.0.3 SMF record. Thanks to Fabio Ottaviani, EPVTECH, ITALY. ====== Changes thru 30.062 were in MXG 30.02 dated Apr 15, 2012========= CHANGE 30.062 TYPE70 variable ENHDATAR='ENHANCED*DAT*ARCHITECTURE?" is VMAC7072 now created from Bit 7 of SMF70PRF. Apr 12, 2012 Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. CHANGE 30.061 BETA93 subtype 25 records support is revised to match the VMACBETA data records. The documentation for 4.1 release is wrong, Apr 12, 2012 as there are not 256 reserved bytes at the end, which caused INVALID DATA FOR BETASTRT messages, and support for the 4.2 was wrong, causing INPUT STATEMENT EXCEEDED RECORD LENGTH errors. CHANGE 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, only for DB2 V10. EXTMD2BA Completely restructured records with new dataset names EXTMD2BB and new variable names, so your reports will have to be EXTMD2BC revised to use new MXG dataset names and variable names. EXTMD2BD The new product suffix is TMD2, replacing TMDB, so you EXTMD2BE will need to change your input DDname to //TMD2IN and EXTMD2BF your MXG %INCLUDEd program to TYPETMD2 or TYPSTMD2. EXTMD2BG
EXTMD2BH DDDDDD MXG MXG SIMILAR TO EXTMD2BJ DATASET DATASET DATASET OLD TMDB EXTMD2BK SUFFIX NAME LABEL DATASET EXTMD2BL
EXTMD2DA TMD2BA TMD2BA SET CURRENT SQLID EXTMD2DB TMD2BB TMD2BB End of Identify EXTMD2DC TMD2BC TMD2BC End of Signon EXTMD2DE TMD2BD TMD2BD Authorization Failure EXTMD2DW TMD2BE TMD2BE Explicit GRANT/REVOKE EXTMD2IB TMD2BF TMD2BF DDL on Audited Object EXTMD2ID TMD2BG TMD2BG Write on Audited Object EXTMD2IG TMD2BH TMD2BH Read on Audited Object EXTMD2II TMD2BJ TMD2BJ Utility started EXTMD2IP TMD2BK TMD2BK Utility Change EXTMD2IT TMD2BL TMD2BL Utility End EXTMD2PK TMD2DA TMD2DA INTERVAL SYSTEM STATISTICS TMDBDA EXTMD2QS TMD2DB TMD2DB Thread Accounting Data TMDBDB EXTMD2SD TMD2DC TMD2DC DB2 Command Activity EXTMD2SL TMD2DE TMD2DE Exception Definition/Event EXTMD2ST TMD2DW TMD2DW DB2/IRLM Messages EXTMD2TB TMD2IB TMD2IB Interval BP Statistics TMDBDAB EXTMD2TD TMD2ID TMD2ID Interval DDF Statistics TMDBDAF EXTMD2TG TMD2IG TMD2IG Interval GBP Statistics IMACTMD2 TMD2II TMD2II Interval IFCID Statistics TYPETMD2 TMD2IP TMD2IP Interval Data Set Statistics TYPSTMD2 TMD2IT TMD2IT Interval IFI Trace Dest VMACTMD2 TMD2PK TMD2PK Thread Package Accounting TMDBDBK VMXGINIT TMD2QS TMD2QS SQL Analyzer Statistics Apr 10, 2012 TMD2SD TMD2SD System Deadlock Detail TMD2SL TMD2SL System Deadlock/Timeout Victim TMD2ST TMD2ST System Timeout Detail TMD2TB TMD2TB Thread BP Accounting TMDBDBB TMD2TD TMD2TD Thread DDF Accounting TMDBDBF TMD2TG TMD2TG Thread GBP Accounting All datasets have been extensively validated with test data records, but with 10,000 new lines of source code, there is some possibility of overlooked items. The original VM/XA MONWRITE support was also 10K lines and took 150 hours across 10 days. This project took only 5 days and about 50 hours, in part because you can teach an old dog new tricks, but also because the vendor "$$" aggregation file was used to generate each INPUT line for each variable, with its INFORMAT and LABEL; most of the rest of the time was spent comparing each line with the DSECTS to find the reserved fields that were not in the $$ file and to find the undocumented bytes added for fullword alignment. MXG previous support for pre-V5 TMON/DB2 did not support any of the 'Bx' records (because no one sent sample data records indicating they wanted those records supported!), but since ASG Technical Support provided samples of EVERY record type, ALL records, including the records that are new in V5 (DB2 Command, Deadlock/Timeout, DataSet Status, and the new Interval and Thread data) are supported and ALL have been data-tested (so hex-containing strings, the times and datetimes should be correctly formatted). Check with ASG Customer Support that you have all PTF's installed; not all datetimestamps were converted to the local time zone, and some alignment corrections in new records.
BLDSMPDB the datasets for weekly and monthly processing. In the Apr 9, 2011 case of monthly it was looking at the WEEK LIBNAME rather than the WEEK1 LIBNAME. On ASCII this was not a problem since both WEEK and WEEK1 existed albeit pointing at the same directory, but on zOS that was not necessarily the case. VGETSORT was changed to point at WEEK1. -When monthly/weekly was not being run and AUTOALOC was set to NO, BLDSMPDB displayed a message that WEEK and month LIBNAMES contained a date range that could have been in error or not even existence. Message is now suppressed when AUTOALOC=NO. -Value of SORTEDBY is forced to NO when the length of MXGNOBY is greater than 0 to suppress the BY statements in WEEKLY/MONTHLY processing to optimize performance. Change 29.008 removed BY processing for WEEK/MONTH in old WEEKBLD/MONTHBLD logic, so BLDSMPDB is consistent.
VMAC71 that were overlooked: Apr 2, 2012 SMF71L7M='MIN 1MB*FIXED*FRAMES*NOT IN USE' SMF71L7X='MAX 1MB*FIXED*FRAMES*NOT IN USE' SMF71L7A='AVG 1MB*FIXED*FRAMES*NOT IN USE' SMF71TLS='TOTAL*NUMBER OF*LOGICAL*SWAPS' -SMF71LFA, added in MXG 30.01 was incorrectly aligned. -And, starting with z/OS 1.13 the Swap Placement Section does not exist, so the below 66 variables won't exist, so you could DROP them all from your TYPE71 dataset when all your systems are at that level, with this statement in the //SYSIN stream that builds your TYPE71 dataset: %LET MACKEEP= MACRO _KTY71 DROP= SWAPTO PHYAUXTO LOGEXTTO LOGAUXTO PHYEXTTO EXTAUXTO SWAPTI PHYAUXTI LOGEXTTI LOGAUXTI PHYEXTTI EXTAUXTI SWAPWT PHYAUXWT LOGEXTWT LOGAUXWT PHYEXTWT EXTAUXWT SWAPAS PHYAUXAS LOGEXTAS LOGAUXAS PHYEXTAS EXTAUXAS SWAPRS PHYAUXRS LOGEXTRS LOGAUXRS PHYEXTRS EXTAUXRS SWAPDW PHYAUXDW LOGEXTDW LOGAUXDW PHYEXTDW EXTAUXDW SWAPVR PHYAUXVR LOGEXTVR LOGAUXVR PHYEXTVR EXTAUXVR SWAPNQ PHYAUXNQ LOGEXTNQ LOGAUXNQ PHYEXTNQ EXTAUXNQ SWAPEX PHYAUXEX LOGEXTEX LOGAUXEX PHYEXTEX EXTAUXEX SWAPUS PHYAUXUS LOGEXTUS LOGAUXUS PHYEXTUS EXTAUXUS SWAPNS PHYAUXNS LOGEXTNS LOGAUXNS PHYEXTNS EXTAUXNS % ; Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE, due to FORMATS insertion of new fields and increases in lengths of some VMACBVIR existing fields, impacting BVIR30 and BVIR32 datasets). Apr 1, 2012 -New variable in dataset BVIR30: AVGCPUSE='CPU*USAGE*PERCENT*AT END OF*INTERVAL' -New variables in dataset BVIR33: DVMECC00='00*MEDIA*TYPE*CONTAINER*COUNT' 5 more new variables DVMECC07='07*MEDIA*TYPE*CONTAINER*COUNT' DVMTC010='POOL 01 MEDIA 0*MEDIA*TYPE*CONTAINER*COUNT' 254 more new variables DVMTC327='POOL 32 MEDIA 7*MEDIA*TYPE*CONTAINER*COUNT' -FORMATS was updated for new media types JC, JY and JK. Thanks to Louis Deledalle, BNPPARIABAS, FRANCE Thanks to Perry Lim, Union Bank, USA.
TYPETMS5 first DSNB record could have wrong values for variables VMACTMS5 DSNBUSRU DSNBTMSI DSNBECAT DSNBABND DSNBISCA DSNBDFXU Apr 4, 2012 DSNBWSCA DSNBDFLT because those variables had values from the TMSREC-DSNB. Now, the DSNB values are temporarily stored, the DSNB for the TMSREC DSN is created with those variables populated from the corresponding TMSREC variables, and then the DSNB variables are restored from temp storage. -The values for DSNBECAT and DSNBWSCA in the DSNB created from the TMSREC were reversed. -Value for TRTCH 'D0'x set DEVTYPE of 3590 but it's 9840, and some additional DEVTYPE values were enhanced to show the EF3/EF3M/EF3X/EE3/EE3M/etc descriptor text. -In diagnosing the error, I also observed an inconsistency in MXG logic for TMSREC observations that have SCR='Y', i.e., Scratch List VOLSERs: MXG did not create the pseudo DSNB observation for the TMSREC DSN for scratched volumes but all of the real DSNB observations are output, with no flag they are on a Scratch Volume, as that is a TMSREC and not a DSNBREC attribute. Now, that pseudo DSNB obs is created for SCR='Y' volumes, and new variable SCRFLAG is created in DSNBRECD so DSNBs on Scratch volumes can be identified. Thanks to Scott Rowe, Social Security Administration, USA.
FORMATS several new variables, two of which are decoded by new VMAC102 formats. VMACDB2H -Cosmetic: VMACDB2H updated to prevent two "MISSING" value Mar 28, 2012 calculation messages. Thanks to Paul J. Larsson, Aetna, USA. Thanks to Victoria Lepak, Aetna, USA.
VMAC73 new FICON Extended Data segment when SMF73PTI=0, which Mar 29, 2012 occurs for CHPIDs that are not ONLINE. The new MXG code failed to test SMF73PTI before the division (even though all other divides where!). Because TYPE73 observations WERE only output if ONLINE='Y' and VALIDPTH='Y', these segments that caused the divide by zero were not output, so there was no impact on the contents of TYPE73 dataset. All SMF73PTI divides are now protected. -HOWEVER: The IBM Channel Path report does list CHPIDs that are OFFLINE but have VALIDPTH='Y', so the logic in VMAC73 is changed so that observations with EITHER the ONLINE='Y' OR the VALIDPTH='Y' are output, in case you actually need to see that a CHPID is offline. This will cause a small increase in the number of observations that are output in TYPE73 (256 CHPIDs are possible; in this site's data, 59 were online and valid path, and 7 more were valid path only that are now also output). Thanks to Christine Ya DeClercq, DEXIA, BELGIUM.
VMACVMXA that is a one-byte flag, and one in VXMTRPAG & VXSTOATC Mar 21, 2012 which is a four byte field containing PAGE or SPOL, but Apr 2, 2012 the second was truncated to one byte by the first. Since CALTYPE in VXSYTSPT is a flag that is unlikely to be used I have renamed it to CALTYPEP to eliminate truncation. -Variable HFQUCT in VXBYUSR wasn't properly deaccumulated. Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY. Change 30.052 Some packed decimal variables notably TPTDBIO were not VMACIMS protected for a full hex-zero field value; the needed VMACIMSA "double question mark" has been inserted in each INPUT. Mar 21, 2012 Where the value is hex zero (because IBM did NOT prime the field as a valid PD field) there is no impact on the value of those variables as they will be a missing value with or without the ??, but this change will eliminate the INVALID DATA message and associated hex record dump. Thanks to Paul Volpi, UHC, USA.
EXSV34ES Only SYSVIEW IMS records with that APAR can be read with EXSV34SU this update; revisions to subtypes 34 and 35 were made. IMACSVIE -New SV34ESS and SV34SUMM datasets are created. VMACSVIE -Change 29.273 found LTERM names 'FDFFFFFF'x, which is the VMXGINIT indicator the transaction originated in MQ and entered Mar 30, 2012 IMS via OTMA: in this case, there isn't an LTERM, but the Apr 2, 2012 next 8 bytes is the TPIPE name (e.g. CSQ800B9, which is Apr 26, 2012 in LUNAME field), so that TPIPE name is now used for the Jun 4, 2012 LTERM name. Some records for OTMA transactions have the LTERM name for TCP/IP port number. MXG keeps the hex value in IMTR_TRN_LTERM_HEX and stores LUNAME into LTERM. -In IMS V9, DBIOTIME and LOCKTIME fields are only valid in records from DBCTL subsystems, so those fields are set to a missing value when they are not valid. -Jun 4: two variables are no longer divided by /4096 : IMTR_CLK_MPP_CPU MQRR_OBJ_INTERVAL Thanks to Martin Trinkler, CSC, ENGLAND Thanks to Arthur G. Hurlston, CSC, ENGLAND Change 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT, due VMAC85 to new value of R85PVRM='1130'. Mar 20, 2012 Thanks to Joachim Sarkoschits, DATAEV eg, GERMANY. Change 30.049 An extra semi-colon in the non-graphics PROC PLOT caused ANALCNCR an error and was removed. Mar 19, 2012 Thanks to Steve Dyck, Canadian Depository, CANADA. Change 30.048 If you specified a 9-character SAS date literal value, eg VGETDDS 12MAR2012, only the first 7 characters were used, causing Mar 19, 2012 the constructed Julian Date to be incorrect as 2020072. Thanks to Brian Harvey, HCL America, USA. Change 30.047 Support for BMC Mainview for MQ Version 5.1 (INCOMPAT). EXBBMQAL MXG did not protect for changed segment lengths so this IMACBBMQ update is required to read 5.1 data records. The new VMACBBMQ RTIN='EA'x record has not been tested, but it will create VMXGINIT observations in new dataset BBMQALTS; some variables will Mar 18, 2012 be changed to datetime variables instead of character when test data is available.
UTILBLDP creation of CICSTRAN, which requires //CICSTRAN to exist. Mar 18, 2012 -If CICSTRAN was suppressed, ASUMUOW/ASUMCICX were still invoked, causing errors. -New values for suppress of DB2STAT CICSSTAT were added so you can separately suppress the statistical datasets. Thanks to Chip Parsons Ingram Books, USA. Thanks to Paul Volpi, UHC, USA. Change 30.045 Debugging PUT _N_= CPUUNITS= CPUTCBTM= removed; added for VMAC30 testing of Change 29.025. Mar 14, 2011 Thanks to Murali K. Inuguru, CSC, India. Change 30.044 -Updates to D062, D063, D060, VWRP, D059, D057, VWVS. VMACNTSM -VMware.Guest.CPU EXNTDTAL VWGCUSPC doesn't exist, removed. EXNTDIRS VWGCSWTM /*SWAP*WAIT*(MILLISECONDS) */ added. EXNTSRMD -VMware.Host.CPU - the two Core utilization fields IMACNTSM VWHCCORA and VWHCCORB were mislabeled as CPU utilization VMACNTSM Pending newdata/newnames updates to QLSS QLSE VMXGINIT QLSS: MSSQL:SQL STATISTICS Mar 11, 2012 QLSE: MSSQL:USER SETTABLE Apr 15, 2012 New objects are now supported in Apr 15 iteration: NTDTAL DTS.ALERTEVENT - 4 DTAL.... vars NTDIRS DIRECTORYSERVICES - 164 DIRS.... vars NTSRMD SERVICEMODELSERVICE 3.0.0.0 - 33 SRMD.... vars User-found corrections after Mar 11 iteration: vmware_guest_virtualdisk - keep D0590007-13. vmware_host_storagepath - length of D0630009 changed to $128. This is actually the concatenation of three 32+ byte worldwide names (WWN). In my data they are delimited by periods but I'm not sure that will always be the case so let the user parse. VMware.Host.Aggregate - Add VWGCVMGU to keep list VMWARE.GUEST.RESCPU - ELSE removed, dropped host/guest. VMware.Host.CPU - Changed VWHCCPU to integer VMWARE.HOST.MEMORY - vwhmtotc was too large Thanks to Jim Quigley, ConEd, USA.
VMACRMFV ASIRNM and ASIRDE can have hex zero values, because IBM Apr 13, 2012 relocated the fields; SVPDCL is now 144 vs the documented and expected length of 76. Now, ASIRNM is tested for hex zero and the INPUT moved when found true. -Same change made for ZRBENC for ENCRNM and ENCRDE. -Compatibility fix for RCDSDI field in RCD table record. In older versions of ASMRMFV the offset to the RCDSD (Subsystem Delay) section of the RCD record can be incorrect causing an INPUT LENGTH EXCEEDED error and VMACRMFV termination. This fix recalculates the value of RCDSDI using other known valid fields. -RCD table flag variable RCDEFLAG is input as character, but is actually a hexadecimal value. Format $HEX2. is added for this variable for a correct display. NOTE: Variable RCDSDPH contains the decoded value of RCDEFLAG for ease of use. -Compatibility fix for ASIRNM/ASIRDE variables in ZRBASI file and ENCRNM/ENCRDE variables in the ZRBENC file. The Service Class data extension used to build these files can have a length of 144 bytes instead of the documented length of 76 bytes. This caused VMACRMFV to input the following Report Class data extension incorrectly so that these fields had bad values. This fix accommodates a length of 144 or 76 for the Service Class extension. -The indexing variable to input the RCDSD array entries was _I_ when it should have been _J_. The _I_ subscript was already being actively used. -Length checks used to validate input for the Service Class and Report Class data extensions in the RCD table were too short. Thanks to Matthew Chappell, Dept. of Transport Main Roads, Australia Change 30.042 -SMF AUDIT REPORT. The existing _RPTID report in BUILDPDB ANALID is significantly enhanced, and new variables are created FORMATS in the PDB.SMFRECNT to provide more detail of counts and IMACSMFF percentages of records and bytes in your SMF data. Each VMACID obs summarizes an ID.SUBTYPE (described by new $MGSMFID VMACSMF format), but records with Subsystem or Product Version VMXGINIT (DB2A V10, CICSPROD TS4.2, RMF 1.12) are reported at that Apr 14, 2012 level of detail. Plus, all obs have the min/max SMF time, May 12, 2012 and any compressed records (DB2,CICS) are flagged! May 28, 2012 -The temporary WORK.ID dataset is created and summarized Jul 4, 2012 to create the PDB.SMFRECNT used for the report, and the May 6, 2013 new variables increase its size, but it is temporary, so only //WORK space is used. For BUILDPDB, the INCREASE in work space required is 25 CYL per Million SMF records. When %ANALID(PDB=SMF) is executed standalone, 60 CYL of //WORK space is needed per Million SMF records. That small increase in BUILDPDB is because the old ID dataset was compressed by default when it should not have been; compression doubled its size (due to the small number of variables), but even the new ID is 9% larger if compressed, so the COMPRESS=NO Dataset Option is used for the WORK.ID dataset to minimize its space requirement. -If work space is an issue, you can disable creation of the WORK.ID dataset with %LET SMFAUDIT=ZEROID in //SYSIN. -If you want the original ID dataset without new variables and you are not changing the MACRO _KTYID, then you would use %LET SMFAUDIT=NO; in //SYSIN. -If you want to add new or drop existing variables in the ID dataset, or you want to change the MACRO _KTYID, you MUST use the SMFAUDIT=YES default, and use MACRO _KTYID to KEEP new or DROP old variables, and you must add the COMPRESS=NO option in your replacement MACRO _KTYID as shown below. To create new variables, your SAS code to create them would be in MACRO _ETYID, as shown in this syntax example (and as documented in member DOCMXG): %LET MACID= %QUOTE(MACRO _KTYID DATE TIME DROP=SMFTIME COMPRESS=NO % MACRO _ETYID DATE=DATEPART(SMFTIME); TIME=TIMEPART(SMFTIME); FORMAT DATE DATE9. TIME TIME12.2; OUTPUT _WTYID; % );
RUN; Note that %QUOTE() must be used; %STR() fails. -The new Audit Report goes to PRINT by default, but it can be redirected to ODS, on ASCII with this //SYSIN syntax: %LET MACKEEP=%QUOTE( MACRO _RPDBID %ANALID(ODSTYPE=HTML,ODSPATH=E:,ODSFILE=ANALID.HTML); % ); %INCLUDE SOURCLIB(BUILDPDB); or on z/OS, you would use this syntax: %LET MACKEEP=%QUOTE( MACRO _RPDBID %ANALID(ODSTYPE=HTML,ODSPATH=MY.PDSE,ODSFILE=ANALID); % ); %INCLUDE SOURCLIB(BUILDPDB); -You can also produce the SMF AUDIT REPORT directly from an SMF file using: %ANALID(READSMF=YES,PRINT=YES,PERCENTS=YES,PDBOUT=PDB) to create all reports and the PDB.SMFRECNT dataset, and additional arguments ODSTYPE=,ODSPATH=,ODSFILE= can be specified on the %ANALID invocation for ODS/HTML output. -VMACSMF was revised to create variable SUBSYSTEM for DB2, CICS, MQ records (100-102,110,115-116), for 26's (JES2/3) for 30s (JES3,TSO,STC,OMVS,etc.), for 6's (JES2/JES3/EXTW PSF/PRINTWAY/CADI/BUNDLE/SAR/EXD), and PRODVERSION for DB2 (V10), CICS (TS/4.2), RMF (ZV011300), and MQ (7.10). This means that those variables are populated when the IMACFILE/&IMACFILE exit is taken, so you can use them to select those records by SUBSYSTEM/PRODVERSION either for MXG processing, or if you want to write SMF records out to a separate SMF file; see comments in IMACFILE. Note May 6 2013: other attributes, such as COMPRESSED and DB2 ACCUMAC status have been added to the report but this text may not always be timely. -Format $MGSMFID maps IBM SMF TYPE numbers and Subtype to describe each record/subtype. User SMF records will be counted by ID and subtype (if the subtype bit is on in the USER record's SMF header), but with no explanation, or counted just by ID if the subtype bit is NOT on in the Yüklə 28,67 Mb. Dostları ilə paylaş:
|