* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
-STID=121 +4 bytes added at end, one new variable in the CICXQ1 dataset compatibly. DFHXQS1D. -The APAR did not list the STID=24 nor STID=121 changes that were uncovered by MXG's "Skipped Data" messages. -The APAR text also indicated that the SMDCC DSECT was changed, but I can find no difference nor new data. -The APAR text also indicated that the MNCBS DSECT was changed, but I am unable to find that DSECT, nor have I found any prior reference to DFHMNCxx DSECTS. -That APAR text documents that APPLNAME=YES enables two new EMPs, DFHAPPL.1 and DFHAPPL.2, that you can use to move 4 and 8 bytes of user data; unfortunately, I've not yet found where that data will be moved into the SMF 110 record. Let me know if you find where IBM puts it! Note that new DFHMNRDS (Transaction Resource Class) data also in this APAR was added by MXG Change 20.200. Thanks to MP Welch, SPRINT, USA.
ANALCNCR is no longer used; it remains defined only so that any Oct 16, 2002 existing %ANALCNCR invocation with KEEPIN= will not fail. All input variables are now kept, and the existing KEEP= option on the DATA statement will keep only the variables that are needed, to minimize the work space required. Thanks to Chuck Hopf, MBNA, USA.
UTILEXCL The %INCLUDE statement UTILEXCL creates should have been Oct 16, 2002 IMACICDU, which inputs the temporary USRSTRNG variable, and then it includes member IMACICUS. All notes telling you to EDIT member IMACICUS (to set the length, etc.) are still correct and unchanged. Thanks to Victoria Lepak, Aetna, USA.
VMACDB2 Starting with DB2 Version 6, IBM's documentation in the Oct 16, 2002 DSNDQWAC copybook states that "SRB times are no longer set by DB2", and because QWACBSRB and QWACESRB fields were always zero, the original MXG calculation logic: IF QWACBSRB GT 0 AND QWACESRB GT 0 THEN DB2SRBTM=QWACESRB-QWACBSRB; was never executed and DB2SRBTM was always missing, as is documented in the ADOCDB2 member. However, new data from DB2 V7 (connected to CICS V2.2, which may be the factor) show non-zero values for both BSRB and ESRB, causing the unexpected non-missing (and negative) value in DB2SRBTM. MXG is now changed to force DB2SRBTM to always be a missing value, as was originally documented in MXG Change 19.094, no matter what values are found in the ESRB/BSRB.
in the ESRB/BSRB fields to see if this is new data that's undocumented, or if it's just random noise!
QWACESRB is nonzero for all connection types, not just CICS. For CICS Attach (QWHCATYP=4), QWACASRB, QWACBSRB, and QWACESRB may be cumulative (like QWACBJST, QWACEJST). Thanks to Siegfried Trantes, IDG, GERMANY.
VMXGUOW records with new (internal) TIMESTMP variable. Oct 15, 2002 Nov 4, 2002 Change 20.220 Variable STC28TIM in STCVSM28 from STK's User SMF record VMACSTC was input as &PIB.8. but it should have been &PIB.4. (and Oct 15, 2002 that caused the subsequent ST=28 variables to be wrong). Thanks to Nathan Walsh, STK, USA. Change 20.219 ASMTAPES ML-26. This revision is the circumvention that ASMTAPES lets you EXCLUDE your VTS devices from the Mount-Scan (to Oct 14, 2002 eliminate the high CPU cost of recovery from 0E0 ABENDS; Nov 2, 2002 see Change 20.214), while still scanning for Allocates to record the job's JESNR/READTIME/etc and populate them in the PDB.TYPETALO dataset for drive utilization measures. And by using dataset PDB.ASUMTAPE instead of the original PDB.TYPETMNT dataset, each mount event will be recorded because ASUMTAPE merges PDB.TYPETALO and IBM's TYPE21 to capture the mount event, although the MNTTM duration will be missing for DEVNRs excluded from the Mount Scanning.
text file that is used during Assembly of MXGTMNT. The ML-26 has been tested under z/OS 1.3, and it contains additional enhancements: One condition under which READTIME was incorrect was found and corrected. New messages are printed by MXGTMNT at startup: TMNT018I - displays interval setting at initialization TMNT020I - acknowleges the existence of EXCLUDE DD TMNT021I - displays list of devices that are excluded New diagnostic command (F MXGTMNT,DIAG) will display a series of informational messages: TMNT025I - count of cross memory ABEND recoveries followed by one line per tape device with UCB address, monitoring status, current job name, and current volser. Status shows if the DEVNR is enabled for Mount/Alloc/Both. Any DEVNR not in the list is not monitored. The ML-26 revision does not solve the problem of missed VTS mounts, and won't solve all problems with missing job fields in PDB.TYPETALO and PDB.ASUMTAPE when allocation duration is too short for MXGTMNT sampling. We are now looking for an exit that would capture mounts and miss none and not require cross-memory services to find the mounting job's identity and information, but there is no guarantee we'll be successful. Regretably, ML-26 early tests show it still uses the same and significantly higher CPU time that ML-25 uses, even when both mount scans and allocate scans were excluded, so we still have no fix, as of 2Nov02. Change 20.218 RACF USRSEKTN (Security Token, SMF80DTP=53) is decoded FORMATS with new TOKxxxxx variables added to TYPE80nn datasets VMAC80A that contained variable USRSEKTN. New data found in SMF Oct 12, 2002 80 record from z/OS Secure Way Security RACF Server (with Oct 21, 2002 SMF80RVM=7706), with keywords UID, HOME, and PROGRAM are now realized to be Extended-length Relocate Sections with SMF80RL2 offset and SMF80CT2 count of 3, whose existence is documented in the SMF manual (previously unnoticed) but whose contents are not documented. The one record found with these keywords all have Data Type SMF80TP2=301 and are heuristically decoded. Because they were found after the last "normal" Relocate Section, which happened to be SMF80DTP-53, I thought they were part of USRSEKTN, and gave them variable names of TOKUID, TOKHOME and TOKPROG. For now theyu are kept only in the TYPE8013 (ALTUSER command) dataset, while I await documentation from IBM RACF Support to see if there are other data in these Extended-length Relocate sections. Thanks to Peter Skov Sorensen, JN-data, DENMARK.
VMACTMDB of &PIB.4. because SQLCODEs can be negative values. Oct 8, 2002 Thanks to Richard Schwartz, State Street Bank, USA Change 20.216 INPUT STATEMENT EXCEEDED was circumvented by changing the VMACVIOP input of VIOPDCA,VIOPBND, and VIOPBNI from 4 to 2. Oct 7, 2002 Thanks to Michael E. Friske, Fidelity Systems, USA. =======Changes thru 20.215 were in MXG 20.06 dated Oct 7, 2002========= Change 20.215 This user contributed code has been in MXG since 17.17; IMACAAAA it reads a Solaris flat file log from ddname SUNSLOG, EXSUNSOG but it was never listed in a change, nor in the IMACAAAA IMACSUNS "list of all products" member, nor documented in any way. TYPESUNS Freddie's QA program detected this, and many, omissions: TYPSSUNS Long ago (on a NEC 286 notebook and a 12 hour run) he Oct 6, 2002 wrote a SAS program to read the MXG Source Library looking for specific text (i.e., a smart parser), and found code that he thought might be wrong, because he had seen me correct similar code in earlier CHANGES. For example, a duplicate variable name does not cause an execution error in a SAS program, but is a true programmER error (not a programmING error - they do not exist) when a separate variable name was needed. That text scan of the MXG Source now looks for scores of exceptions (e.g. DATETIME formatted variables not stored in 8 bytes) and for inconsistencies between the contents of documentation members and reality (do all members listed in IMACAAAA exist in the MXG Source?).
the consistent structure of the VMACxxxx members that create MXG datasets, and the consistent macro names for the data-set-related _L/_W/_E/_B/_Sdddddd macros, (and by telling me to fix my code when I'm careless) he compares the documentation in comments with what happens when the program is run. For example: _Edddddd /* EXdddddd OUTPUTS DATASET */ is examined to verify that "DATASET" is the actual dataset created when that statement is executed. The SAS error-detection during the MXG QA Execution, followed by Freddie's Source QA Program provides the Quality Assurance to MXG users that the newest version is better than the last and most likely error-free. If you contributed the VMACSUNS, let me know to cite you, or if this is useful, let me know so I can update this text as to what Sun log, etc. Thanks to Freddie Arie, TXU, USA. Change 20.214 This is documentation of the status of of ASMTAPES ML-25. ASMTAPES If you have Virtual Tape devices, ML-25 uses a lot more Oct 4, 2002 CPU time (30 min per day vs 30 secs) than ML-19, but if you have no VTS devices, there was no increase in cost: - When you have VTS devices with their very fast scratch mounts, 0E0 ABENDs occur when MXGTMNT Cross Memory's to get the JOB/JESNR/READTIME/etc from the job's ASID, but finds the job issuing the mount has already gone away. - When ML-19 encountered an 0E0 condition during the UCB scan for mounts, it recovered, but then quit for that interval, and did not scan the rest of the UCBs for a mount condition, nor did it even start the scan of UCBs for allocations. This caused many TYPETMNT/TYPETALO events to be missed (i.e., no SMF record written), and 0E0 recoveries could fill SYS1.LOGREC, and made it look like MXGTMNT was not scanning 4-digit UCBs! - ML-25 recovers from each mount UCB with a 0E0, (but it still writes a record when appropriate, although the ASID-related variables will be missing), and then scans all UCBs for allocations, so it should see a lot more allocaations, since allocations are usually much longer than mounts. ML-25 also prevents the 0E0 LOGREC write. And the DDNAME in TYPETMNT can be wrong, like JOBLIB! - STROBE showed that the increase in CPU time is in the IBM recovery modules, which are now being invoked many more times than before, and we can't rewrite IBM code. ML-26 is in development as a short-term circumvention that will let you skip the UCB scan for mounts for VTS devices (you'll specify the device addresses to be skipped), which should significantly reduce the 0E0 recovery CPU cost, but the UCBs will still be scanned for allocations. Due to a (presumed) longer duration of allocation than mount time, we should have very few 0E0 recoveries for allocations. While the TYPETMNT record won't exist for the skipped VTS UCBs, TYPETALO data will exist and it contains ASID info. Not only is TYPETALO sufficient for measurement of tape device utilization, but also member ASUMTAPE combines the TYPETMNT, TYPETALO, and TYPE21 to create the PDB.ASUMTAPE dataset that records each mount-dismount event, even for VTS mounts without a TYPETMNT, and the ASID fields from will populate the ASID variables into PDB.ASUMTAPE for mount analysis (but with MNTTM missing for skipped UCBs). This "ML-26-to-be" might be avaliable in early November. It's availability will be posted to MXG-L when tested. Once the ML-26 is available, we intend to go continue our investigation of a permanent fix, to be exit-driven rather than sampling UCBs, and hope to locate an exit that runs in the mounting job's address space, which would remove the 0E0 exposure, but that is clearly a non-trival and major re-design of the MXG Tape Mount and Alloc Monitor. Change 20.213 Support for APAR OW52396 (COMPAT) for Ficon Switches adds VMAC74 meaning for existing bits in R747PTFL and R747PSFL, which Oct 3, 2002 are already formatted $HEX2. to expose all flag bits. No change was made to VMAC74. Change 20.212 Support for APAR OW56162 for SMF type 64 new VSAM EOV SMF VMAC64 that is written when there is a record management catalog Oct 3, 2002 update request. Variable SITUIND='CATALOG UPDATE' is set from SMF64RIN bit 7 for this new event; this record will not contain any extent information.
VMACNDM an invalid NDM Statistics SMF record (it also wrote a Oct 3, 2002 message to SYSLOG to let you know it knew it messed up), that was only 24 bytes long. MXG now tests the length of the NDM record and avoids the ERROR, instead printing an ERROR message on the MXG log that an invalid NDM SMF record was found and deleted. This text will be updated when a resolution is provided by NDM's vendor. NDM is now called Connect Direct. Thanks to Jim Petersen, Washington Mutual, USA. Thanks to Rick Ramirez, Washington Mutual, USA.
VMACDB2 because the two tests for LENQWAC 224 AND QWHSRELN 7 Oct 3, 2002 should have tested QWHSRELN LT/GE 6 instead of 7. Thanks to Terry L. Berman, DST Systems, Inc, USA. Change 20.209 VGETDSN now detects that the requested DDNAME is not VGETDSN allocated, printing a message on the log. Oct 3, 2002
VMACTPMX had to be changed to SPACERQ, because variable name SPACE Oct 2, 2002 was already defined in TYPE1415 as a character variable. If you combined TPMX and 1415 SMF records processing in the same step, you got a strange "INFORMAT PIB UNKNOWN" error.
Thanks to Lawrence Jermyn, Fidelity Systems, USA. Change 20.207 Variable MODULE was increased from $32 to $64 because the VMACNTSM length of the module path was found to exceed 32 bytes. Oct 1, 2002 Thanks to Xiaobo Zhang, ISO, USA. Change 20.206 Support for SMF 94 subtype 2, and subtype 1 enhancements EXTY942 adds many valuable VTS variables to existing TYPE94 data EXTY942P set and creates new TYPE942 dataset with Volume Pooling FORMATS Statistics added by IBM Field Change 4001. VMAC94 VMXGINIT
Sep 30, 2002 Change 20.205 Support for z/OS 1.4 (COMPATIBLE) has only minor changes FORMATS to the SMF manual text and one new variable in TYPE74CA: VMAC74 -Variable R7451RTY added to TYPE74CA dataset identifies VMAC79 the RAID Rank Type of RAID-5, JBOD, or RAID-10. Note Sep 30, 2002 that JBOD is 'Just a Bunch of DASD'! -SMF records 63, 67, and 69 pages now clearly state they do not exit because VSAM catalogs no longer exist. -SMF71LIC (HIUICMN) documents that UIC values can range from 0 to 2540 seconds; Don Deese clarified that those larger values are for systems with all central (i.e., no expanded storage), while 0 to 254 seconds is recorded for systems that have expanded storage. -R793CPUU in TYPE793 set missing if it 7FFFx or 00FFx, and "PERCENTAGE" is added to its label. -R793CUT should not have been TIME12.3, as it contains the MVS Utilization (MVS Non-Wait) as a percentage of the interval length; it is the same as R793CUU if not LPAR. -These TYPE79A variables are documented as reserved (maybe was an earlier release): R79AMPLT,R79AGOOU,R79ATCTL, R79ATYPE, and R79AMSO. Change 20.204 Support for SMF 120 Subtype 7 and 8 from WebSphere FORMATS Application Server V4.0.1 for z/OS and OS/390 creates new EXT120WA datasets: EXT120WI TYP120WA - Web Container Activity - subtype 7 VMAC120 TYP120WI - Web Container Interval - subtype 8 VMXGINIT These data were added by APAR PQ59911. Sep 30, 2002 Thanks to Randy Shumate, LEXISNEXIS, USA. Change 20.203 Variable PONBR should have been kept in the QAPMPOLL VMACQACS dataset for OS/400 5.1 Collection Services; now it is. Sep 29, 2002 Thanks to Raymond Dunn, CIGNA, USA. =Attended 35th Reunion of the NESEP (Navy Enlisted Scientific =Engineering Program) Class of 1967 at Purdue University. Change 20.202 Support for BMC's Mainview for DB2 THRDHIST file. The TYPSTHST type 'K' record contains a beheaded SMF 101 accounting VMACDB2 record. This new TYPSTHST member reads the THRDHIST data Sep 23, 2002 and creates all of the DB2 Accounting datasets (DB2ACCT, DB2ACCTB, DB2ACCTG, and DB2ACCTP) in the PDB library. Member TYPSTHST defines macro _THRDHST to decode the BMC header and uses it in place of the standard _SMF macro, so that the MXG code in VMACDB2 can be used to decode THRDHIST records. However, when there are more than 10 packages, THRDHIST puts extra package segments in a new area at the end of their record. Reading the additional package segments could not be done within VMACDB2 code, so it was necessary to create a copy of the QPAC logic from VMACDB2 in the TYPSTHST member, and to invoke that code in the EXDB2ACC exit redefinition in TYPSTHST. So now, anything I or IBM does to the QPAC logic in VMACDB2 must be repeated in TYPSTHST! -One additional IF statement to reset OFFSMF for THRDHIST had to be added in VMACDB2 to support this change. Thanks to Mr. Globisch, R+V, GERMANY. Thanks to Mr. Peters, R+V, GERMANY.
EXTMVWG TMVS records are completely revised, a new header in all EXTMVWGS records, and reordering of fields within the existing FORMATS segments, so you must have this change for TMVS V3 data. VMACTMVS All existing datasets have been fixed and tested. These VMXGINIT new subtypes: MC,XC,XD,XS,X2,X3,X4,XP, and XW will be Sep 23, 2002 supported in the order you request. Comments in member Oct 1, 2002 VMACTMVS list the record subtypes and TMVS version and Oct 17, 2002 which MXG datasets are populated by which TMVS version. Oct 21, 2002 Note: The support for TMON/MVS V3.0 and later is now Nov 4, 2002 back in TYPETMVS/TYPSTMVS. (Do not use TYPETMV2). Nov 4: RETAIN M8 (-8); statement inside MACRO _TMVS was relocated; it was not in the IMACTMVS example, and if you redefined IMACTMVS for Compressed Data you got M8 UNINITIALIZED and STOPOVER ABEND. Thanks to Yves Terweduwe, CIPAL, BELGIUM Thanks to Michael Stark, 5-3 Bank, USA.
EXCICRDS Added by CICS APAR PQ63143 and documented in DFHMNRDS, EXCICRDF this new CICS SMF 110 Subtype 1 MNSEGCL=5 creates these IMACCICS two new datasets: VMAC110 CICSRDS - Resource Class Data - Transaction data VMXGINIT CICSRDFI - Resource Class Data - File Details. Sep 21, 2002 There is one observation in CICSRDS for each transaction whose data is collected, and one observation in CICSRDFI for each FILENAME that was accessed by the TRANNAME in the CICSRDS dataset. The transaction data is in the CICSRDS dataset, and the File information is in CICSRDFI to minimize the disk space for these data; it may be necessary to merge the two datasets for some reports. This new data (finally!) allows you to track what files had how much activity (counts AND durations) for each CICS transaction. As both datasets can be large, neither are sorted by MXG by default, and both are written to the //WORK file. To instead write both to the "PDB" ddname, you can use %LET WCICRDS = PDB; %LET WCICRDF = PDB; before your %INCLUDE SOURCLIB(TYPE110) or (BUILDPDB). Note that to create this new files-used-per-transaction data, you must change the IBM default FILES=0 in DFHMCT. Change 20.199 This example program read SAT.TYPE70PR twice and failed WEEK70PR to read FRI.TYPE70PR at all, causing the WEEK.TYPE70PR Sep 21, 2002 dataset to be incorrectly build. Thanks to Michael Marcus, Affilliated Computer System, USA. Change 20.198 These MONIDBDS variables, from old versions, should not VMACTMO2 not have been created and can be dropped in _KMONDBD FORMATS FILEADIN FILEUPRP FILEGET FILEBROW FILEOPCL FILEDEL Sep 21, 2002 FILESRV (but they are still kept by default, so any existing reports you have won't fail with VARIABLE NOT FOUND). And the field that was used to create those variables is new variable FILEACM, decoded by new format $MGMONAM., to describe the access method that was used for this file: (ISAM,BDAM,VSAM,QSAM,RMTE,DL/I,DB2,DCOM) Thanks to Richard Jay Schwartz, State Street Bank, USA.
VMAC30 REND (Reader End), causing INVALID READTIME messages. Now Sep 21, 2002 the READTIME=REND if READTIME is blank.
VMACEXC2 now prints variables ABEND and CONDCODE and a hex dump of Sep 21, 2002 the first three instances; these messages should be sent to support@mxg.com for examination. This message occurs when MXG reads a type 30 with a DD segment in the TIOT with an unknown Class/Type value. This has been caused by - errors in your installation's SMF exit code, which can accidentally overwrite data in the type 30 before the record is actually sent to the SMF data set. The step termination exit is often used to print step resources on the job's SYSMSG, and that exit code has been found to overlay these fields in the past, (but usually the DDNAME is still valid). The "your" code may have been provided by a vendor; for example, CA's job scheduling product changes the values in SMF records in SMF exits. - an overlay of the TIOT by the executing program in this job. Often, the step will have ended with an ABEND, of a SYSTEM 5xxF or 9xxF, if other control blocks were also overlaid. If there were EXCPCNTs in this segment, they can't be put in the correct EXCPdddd/IOTMdddd bucket, since I don't Yüklə 28,67 Mb. Dostları ilə paylaş:
|