* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
-For the IBM IEF_VOLUMEMNT exit, we seem to capture every mount that is issued with an IEF233A mount message, and we appear to capture no mount that is issued with any of the other messages, in particular, the IEC501A message that is issued for second-volume mounts of a multi-volume tape dataset. IBM Support confirmed that is correct for their exit; it is taken only for Allocation's mounts, and those OPEN/CLOSE/EOV mounts (the IEC501x messages) do not go thru that exit. I hope to propagate the jobstuff from the first mount into the second mount for these multi-vol mounts, but there are also IEC501A mounts that are the first and only mount for a job, so I need more test data from the ML-37 monitor with SYSLOG data to fully resolve what is and is not captured in the IBM exit, and how the logic in ASUMTAPE can be enhanced further. -Revised Jun 15, 2006: For the STK UX01 exit, STK Support has now installed our ASMHSCEX and have captured 100% of all HSC-controlled tape mounts, both to virtual and to real tape devices, in several tests in their labs by Sun Technicians. -For IBM, SYSLOG data goes a very long way to resolve. True, you do NOT know the actual duration of the mount (TAPMNTTM will be missing if MXGTMNT missed the mount) and the READTIME variable will be missing, so you cannot directly MERGE the ASUMTAPE back to the PDB.JOBS for any simple match for billing, but almost all of the jobstuff that we got from the MXGTMNT data is now picked up from the SYSLOG data, so the PDB.ASUMTAPE with these changes is of far better quality than it every as been before. -But expect revisions to the ASUMTAPE program after more test data has been received; early adapters of this new code are requested to send their SMF records (the MXGTMNT user-SMF record, AND the SMF type 21 dismounts) so that the new data can be better understood; member SENDATA in MXG 23.09 has the instruction (and new ip address) to send SMF data to our ftp site. -The Tape Allocation subtypes that create TYPETALO data is still sampled, so job-related data can be missing in that dataset; I hope to be able to merge the job-stuff from this new PDB.ASUMTAPE dataset into those missing variables in PDB.ASUMTALO, in a later enhancement. -Additional documentation notes: This enhancement makes the MXGTMNT program in ASMTAPEE, the "MXG Tape Mount, Tape Allocation, Tape Swap, Tape Allocation Recovery, and SYSLOG message monitor". The messages captured in the "MXG-owned" subtype eight are these that needed for tape mount event events:
IEF501A - OPEN/CLOSE/EOV, MULTI-VOL, or DEFERRED MOUNT IEF501E - 2nd+ Volume for OPEN/CLOSE/EOV "Look Ahead" ==> 3 seconds -- IOS070E - MOUNT PENDING sss IECTMS6 - DEVNR,VOLSER,IS APPROVED FOR TRTCH CHANGE IECTMS9 - DEVNR,VOLSER, DSNAME17 at OPEN ==> actual time to mount ==> TAPMNTTM IEC705I - TAPE ON DEVNR,VOLSER ==> duration tape was mounted ==> TAPMTDTM TMS014 - Copy of IEC502E or IEF234E message IEF502E - Intermediate Volume KEEP IEC234E - Last Volume KEEP and these additional messages are captured in subtype 8 to identify causes of known tape mount delays:
IEF235D - JJJ STEP WAITING FOR VOLUMES IEC205I - VOLUME LIST
records, which include the JOB, JESNR, SYSTEM, ASID, and the EVENTIME (same .01 second resolution as SMFTIME).d
the sequence of SYSLOG mount-related event records: 233A 234E 233A TMS6 TMS9 705I TMS014 234E 233A TMS6 TMS9 705I TMS014 502E for first vol 501A TMS6 TMS9 705I TMS014 502E for intermediates 501A TMS6 TMS9 705I TMS014 234E for final volume or 501E TMS6 TMS9 705I TMS014 234E for final volume 233A 070E TMS014 502E 690D 235D 705I 234E New dataset TYPESYSL (SYSLOG Messages) can be populated with any SYSLOG messages you chose to ask MXGTMNT to capture in subtype 9. At present, you must EDIT the name table in the ASMTAPEE and re-assemble, but ASMTAPEE will be revised so you can use the console MODIFY command to turn on or turn off capture of any SYSLOG message. I plan to create an ANALSYSL program to decode those SYSLOG messages that you decide to capture, so let me know what messages you find important and useful.
VMAC7072 25 LPARS. To be investigated. Check text of this change Nov 28, 2005 in the final MXG 23.09 that will be dated Nov 30, 2005. No change made yet, await test data with split records. Change 23.298 MXG 23.08 would fail if you did not have a //INSTREAM DD VGETENG in your JCL Procedure (there is one in MXGSASVn example), Nov 28, 2005 because VGETENG was changed to require the use of that DD in the "mainstream" RMFINTRV processing, or would fail if you used UTILBLDP and then %INCLUDE INSTREAM; to execute the program built by UTILBLDP, with FILE INSTREAM IN USE error. Both errors were introduced when revisions added the use of //INSTREAM in VGETENG; both are corrected by backing out the use of //INSTREAM in VGETENG. That addition was yet another attempt to improve the accuracy of VGETENG's logic to "GET" the ENGINE of a LIBREF. Originally, this was to avoid a second tape mount, but knowing the library is on tape when we are going to read with a VIEW, we can avoid a second read of the full (possibly multi-volume) tape dataset. However, is just not possible to know the media of an un-referenced DD, so we must revert to the original logic that can only identify a tape that has been previously referenced in this step. So you could force that reference with a LIBNAME statement, or a DATA _NULL_; SET DD.XX; STOP; if you see there are multiple mounts on syslog. In the case of VMXGSUM, which does not use the VGETENG logic, we are still investigating if we can detect and eliminate the second read with a VIEW when the input is on tape. Thanks to Scott Barry, SBBWorks, Inc, USA.
VMACAIX
Nov 23, 2005 Thanks to Long N. Nguyen, Department of Home Security, USA. Change 23.296 Macro _STY30U6 deaccumulates TYPE30_6 into PDB.TYPE30_6, VMAC30 but it did not protect for wrapping of the four-byte Nov 22, 2005 RESIDTM and ACTIVETM fields, which wrap at 1221 hours. Additionally, ACTIVETM was not deaccumulated, but now is. The created variable UPTM contains the original ACTIVETM before deaccumulation, but UPTM will reset to zero every 51 days or so. -Noted and corrected: INTETIME and SYNCTIME in TYPE30_6 were on GMT rather than local time if GMTOFF30 non-zero. Thanks to Jean-Denis Lacourse, CGI, CANADA. Thanks to Robert Petel, CGI, CANADA.
VMACDB2 QGBADG QBGAP1 QBGAP2 QBGAP3 QBGAS1 QBGAS2 Nov 22, 2005 QBGAS3 QBGAU1 QBGAWS although their sums were kept in DB2ACCT. All variables are now kept in DB2ACCTG. Thanks to Steve Olmstead, Thomson BETA Systems, USA. Change 23.294 TMVSCI dataset variable CIJN was off by four bytes, which VMACTMVS caused wrong values in it and the subsequent CI variables Nov 22, 2005 that track storage. In addition, the percentage field's Nov 5, 2005 values were all off by a factor of 100, as I missed the precision of that field in the TMVS documentation. Thanks to Richard Jay Schwartz, State Street Bank, USA. Change 23.293 The MXG Trending default INTERVAL=WEEK, is replaced with TRND72GO INTERVAL=&INTTRND, with macro variable INTTRND defaulting VMXGINIT to WEEK, i.e., the INTERVAL= value is externalized so it Nov 22, 2005 can be changed with %LET INTTRND= whatever ; before your %INCLUDE SOURCLIB(TRNDxxxx); statement (where "whatever" is one of the valid values defined in VMXGDUR). Only the TRNDxxxx members that had INTERVAL=WEEK, were changed; a few don't use the INTERVAL= argument (instead using a date/time variable in their SUMBY= argument) and a few had INTERVAL=DATE, left unchanged. TRNDCICS/CICX have INTERVAL=&TRCIINTV, but the %LET TRCIINTV=WEEK; is inside those two members, so it couldn't be externally changed. Now, INTERVAL=&INTTRND, is specified and the useless reference to TRCIINTV is removed. Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
VMAC30 maximum count of 2 gig to a new maximum of 4 gig. The VMAC32 field counts the step's lifetime total EXCPs (blocks or VMAC33 SSCHs, depending on the Access Method used); the original Nov 14, 2005 APAR text and title erroneously said "2 gigabytes". If the count is now over 4 gig, (4,294,967,295), the APAR stores 'FFFFFFFF'x and turns on a new bit to indicate the count exceeded the maximum. MXG creates EXCPERR='Y' if that bit is on, and sets EXCPTOTL to a missing value. The variable name is EXCPTOTL in SMF 30s and PDB datasets and in SMF 33s, but was named EXCPS in TYPE32.
EXNDMHW Subtype Description EXNDMNM HW HIGH WATER MARK STAT RECORD - supported IMACNDM NM Unknown - Header only until I get the DSECT VMACNDM VMXGINIT
Nov 13, 2005 Thanks to David Kaplan, Depository Trust, USA. Change 23.290 Deaccumulation of the VXSYTEPM dataset was still wrong; VMACVMXA four byte wrap was not protected, but IBM has created a Nov 12, 2005 new "architecture" that needed additional logic. For each device's first instance, CALINIT='Y' and the contents of that "initial" record is all zeros, so it is deleted. However, the second record must also be deleted, as it does not start from zero, but has some large non-zero values that must be used in the DIF() but the observation after the CALINIT='Y' instance must then be deleted also. And since records with CALINIT='Y' are deleted, there is no reason to keep that variable in VXSYTEMP dataset. Thanks to Melanie Higching, British Telecom, ENGLAND. Change 23.289 For RMF intervals with DURATM less than one minute, MXG's VMXG70PR summarization into PDB.ASUM70PR didn't store the second Nov 10, 2005 interval's DURATM in SYSDUR, which caused values over 100 percent in PCTCPUBY and the LPCTnBY value for that LPAR. Change 23.070 documented these very short RMF intervals (created when a WLM Policy Change was made), and dataset PDB.ASUMCEC was corrected by that change, but 23.205 was and additional revision, and it reinstated EXCECTIM exit to force the STARTIME for all three datasets created by the ASUM70PR/VMXG70PR program to the nearest minute, both for cross-CEC timing issues, and to consolidate these RMF short intervals. But the logic for PDB.ASUM70PR/ASUM70LP to set SYSDUR was based on IF FIRST.LPARNUM, but that didn't "see" the second instance with same STARTIME. By adding DURATM as the last BY variable in the BY in INCODE=, and by setting SYSDUR from IF FIRST.DURATM, the summary DURATM is correct for those two datasets, which also corrects the percentages based on DURATM. -The WLM Policy Change was installed at 10:32:06, and the STARTIME and DURATM of the adjacent RMF records were: STARTIME DURATM hh:mm:ss hh:mm:ss 10:15:00 00:15:00 10:30:00 00:00:20 10:30:20 00:01:46 10:32:07 00:12:52 Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.
VMAC7072 MXG variable LPARCPUX, in the LPARNAME='PHYSICAL' segment Nov 10, 2005 which processor counts, especially for NRIFACPU, NRIFLCPU Jun 6, 2006 and NRICFCPU will always be zero; investigation with BMC is in progress. Jun 8, 2006 update: The error was only in the first level of CMF support for the z9, and was corrected by CMF APAR BAM9572, PTF BPM9543. Change 23.287 Usability enhancement for selective output of DB2 data. READDB2 You can choose which datasets are to be created, which Nov 10, 2005 observations are to be output, and even which variables Nov 16, 2005 will be kept in any of the created datasets: Nov 22, 2005 SELECTION CRITERIA: SMFBEGIN= DATE/TIME CONSTANT FOR BEGINNING OF TIME RANGE SMFEND = DATE/TIME CONSTANT FOR END OF TIME RANGE SYSTEM = SYSTEM(S) FOR WHICH DATA SHOULD BE SELECTED PLAN = PLAN(S) FOR WHICH DATA SHOULD BE SELECTED AUTHID = AUTHID(S) FOR WHICH DATA SHOULD BE SELECTED CORRID = CORRELATION ID(S) WHICH SHOULD BE SELECTED CONNID = CONNECTION ID(S) WHICH SHOULD BE SELECTED DB2 = DB2 SUBSYSTEM(S) WHICH SHOULD BE SELECTED CONNTYPE= CONNECTION TYPE(S) WHICH SHOULD BE SELECTED PACKAGE = PACKAGE NAME (FOR DB2ACCTP DATASET ONLY) DATASET CRITERIA: DB2ACCT= Any of the below syntax DB2ACTB= " DB2ACTP= " =YES - DATASET IS CREATED WITH ALL OBS/VARS =NO - DATASET IS CREATED WITH 0 OBS =KEEP/VAR1 VAR2 VAR3.. - DATASET IS CREATED AND KEEPS ONLY THE LISTED VARIABLES =DROP/VAR1 VAR2 VAR3... - DATASET IS CREATED AND DROPS ALL THE LISTED VARIABLES Thanks to John W. McAlinney, Vanguard, USA.
VMXGGETM 102 trace records to contain the "IFCID" because that is Nov 9, 2005 the "logical" subtype for the 102s that don't have an SMF subtype in the SMF header. That change also stores IFCID for subtype in the 100 and 101 records, even though they do have SMF subtypes, because DB2 documentation refers to IFCIDs and not to SMF subtypes. These are the values that were changed, but not documented. IFCID: 1 2 202 3 239 Rec.Sty: 100.0 100.1 100.2 101.0 101.1 This change only added documentation notes in the member. Thanks to Daniel T. Cannon, The Hartford, USA. Change 23.285 VM Accounting datetimes were incorrect; Change 23.109 had TYPEVM used the record LENGTH to identify the date format, but Nov 9, 2005 that test was not sufficient, and I can find no other way Nov 11, 2005 to discriminate safely between MMDDYY or YYMMDD than to Nov 15, 2005 have you tell me in a new MACRO _DATEVM with values: _DATEVM Date Format 1 MMDDYY (Default) 2 YYMMDD
The default format is the IBM MMDDYY format; you can use this syntax to change the macro value if needed: //SYSIN DD * %LET MACKEEP= MACRO _DATEVM 1 % : %INCLUDE SOURCLIB(TYPEVM); Nov 15: LENGTH=LENGTH restored to the INFILE statement. Even though it can't be used for date-discrimination, it is needed to identify some VM data records. Thanks to Wah Chu, SIAC, USA.
VMAC6 sometimes, in tcp/ip "Printway" file transfer records, Nov 7, 2005 which are SMF 6 records written by PSF for "print" output that was sent via tpc/ip to an ip address. That decimal value results when SMF6NLR contains 'FFFFFFFF'x is the SMF record. -These TYPE6/PDB.PRINT tcp/ip records have SUBSYS='TCP', and only variable SMF6BYTES can be used for print bills or printer resource measurements. -They do not have the PSF-APA segment, so SHEETPRN and the other fields from that segment are all missing. -Why NRLINES is someimes bad and sometimes has reasonable values is unknown (query pending to IBM), but NRLINES has never been recommended (see the PRINTERS section in the MVS/ESA RESOURCE ACCOUNTING" article in NEWSLTRS. -But because that large value is confusing and could mess up your old print billing system with it, I have chosen to test for the 'FFFFFFFF'x field value, and now set the variable NRLINES to a missing value for those instances. -PDB.PRINT variable TOTLINES is the equivalent of NRLINES. Do not use the old PRINTLNE/PUNCHCRD/EXTWTRLN variables, because there is no safe way to identify which kind of device was at the destination, and they are archaic in any case. TOTLINES is their sum, and the field to use, if you still must have some count of "linew". -Note that in non-TCP records for PSF, NRLINES can also be wierd when the SMF6PRMD printer mode is "DATA" and not "LINE", but at least those records have valid SHEETPRN in their PSF-APA segments. -Note for back-level-MXG users: SUBSYS='TCP' was added in MXG 22.08 (Change 22.153), but SMF6BYTE has been input since Change 13.328, and it will be non-missing only in tcp/ip print records, so it could be used alternatively to identify these records. Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY. Thanks to Philip Matthei, State of New York, USA. Change 23.283 Support for ASG-Landmark TMVS Version 3.2 has confirmed VMACTMVS that any changes made were COMPATIBLE, but I won't take Nov 3, 2005 time to compare all of the DSECTS to look for new data until a user finds a need for it. The last change in MXG was prior to MXG Version 20.20. See Change 23.294 for internal record changes in 3.2. Thanks to Richard Evans, Worldspan, USA.
VMAC26J3 should have been a LINK statement. The GOTO caused the Nov 3, 2005 RETURN statement after the label to be a DELETE statement so the rest of the record was never read nor was the exit for the OUTPUT every called for that record. This behaviour of the RETURN statement only occurs when there are OUTPUT statements in the SAS data step. If there are no OUTPUT statements, a RETURN after GOTO causes all datasets in the DATA statement to be OUTPUT. With the LINK statement, the label is called, but RETURN brings the program back to the statement after the LINK, so the rest of the record is read and OUTPUT. Thanks to Dave Falzon, EDS Ottawa, CANADA.
TESTIBM1 when JCLTESTx is run. TYPE79 now sorts the TYPE79xx data Nov 2, 2005 (to deaccumulate) to the PDB library, but the TESTIBM1 program's PROC MEANS still expected those data in WORK. TESTIBM1 was changed to find TYPE79xx in the default PDB. Thanks to Bernd Klawa, Stadwerke Bielefeld GmbH, GERMANY. Change 23.280 DB2 Package Data could STILL be wrong, if any of these VMACDB2 fields are longer than the original un-truncated length: Nov 1, 2005 variable label was now Nov 2, 2005 QLACLOCN='LOCATION*NAME' $16 $16 Dec 13, 2005 QPACLOCN='LOCATION*NAME' $16 $16 QPACCOLN='PACKAGE*COLLECTION ID' $18 $18 QPACPKID='PROGRAM*NAME' $18 $18 QPACASCH='NESTED*ACTIVITY*SCHEMA*NAME' $8 $17 QPACAANM='NAME*OF*ACTIVITY' $18 $18 In the observed case, QPACASCH was increased to 16 bytes and contained 'SYSPROC.S1BNLERP' as one example value. For now, I've increased the default length of QPACLOCN to $17, pending an understanding of whether the increase was made by the installation or by IBM. The revised code inputs them all with $VARYING128, which is the maximum documented length With MXG's COMPRESS=YES default, they could be changed to default $128 length, but that could dramatically increase the size of the DB2ACCTP dataset if you have turned off COMPRESS=YES, so I chose to leave the other above fields in their original stored lengths. The original text contained this next statemnt: Insert Mar 27, 2013: THIS 2006 statement is false in sas version 9: "You can change the stored length by the addition of: LENGTH QPACxxxx $nn ; in the EXDB2ACP exit; SAS uses the last LENGTH statement to set the variables stored length." SAS uses the FIRST instance of the character variable to set its length, and prints a WARNING that first length if a LENGTH statement with a different length os found. SEE NEWSLETTER SIXTY - SECTION 7.1. CHANGING VARIABLE LENGTH. end of Mar 27, 2013 Insert. -Dec 13, 2005: HOORAY, package date WAS FIXED in November; this is only additional documentation about package data: In DB2 V8 data, in dataset DB2ACCTP, QWACBSC and QWACESC variables (begin/end datetimes), are now always missing, because V8 creates only SMF 101 Subtype 1 IFCID=239 data. In V7 and earlier, IFCID=0003, Subtype=0 records (first ten packages) did populate those variables, but IFCID=239 records always had BSC/ESC missing for the 11th-plus package.
Thanks to Tory Lepak, Aetna, USA. Change 23.279 Support for VTCS 6.0 and 6.1 SMF records (COMPATIBLE). FORMATS These new variables are created, but only CTP appears to VMACSTC be new in 6.1 records, all other variables below do have Nov 1, 2005 real values in 6.0 SMF records: Dataset STCVSM13: STC13CTP='CARTRIDGE*TYPE' decoded by $MGSTCCT format: '0000'X='0000X:S-CART 400MB' '0001'X='0001X:E-CART 800MB' STC13HST='ORIGINATING*HOST*NAME' STC15MNR='MOUNTED*WITHOUT*A RECALL?' STC15MRC='MOUNTED*AFTER*A RECALL?' Dataset STCVSM14: STC14CTP='CARTRIDGE*TYPE' decoded by $MGSTCCT format: STC14HST='ORIGINATING*HOST*NAME' STC14ULN='MVCS*TO*UNLINK' In the 6.0 data tested, STC14DSN was always blank; STK is investigating why. -Variables 13FLG,14FLG,13HID,14HID,13SEQ,14SEQ,13VTI,14VTI and STC13OID are archaic and always missing; those fields only existed prior to version 5.0. Thanks to Ruth Whitney-Parker, CitiGroup, USA. Thanks to Nathan Loewenthal, CitiGroup, USA. Change 23.278 This change was implemented in Change 23.300 and its text was relocated into that change. Change 23.277 Two new job status variables are created from new bits in VMAC26J2 SMF26IX2 (old PRPRTY variable): Oct 31, 2005 UNSPUNJB='JOB WENT*THRU*UNSPUN*IN ITS*LIFETIME?' JOEPURGE='JOE*PURGED*DUE TO*PSO/SAPI?' Thanks to Leendert Keesmaat, UBS AG, SWITZERLAND.
VMXG70PR always zero after Change 23.021, due to incorrect logic. Oct 31, 2005 This error was only in PDB.ASUMCEC; those variables were correct in PDB.ASUM70PR. -Also, ASUMCEC variables IFAUPTM, IFAACTTM, and IFAWSTTM were not formatted with TIME12.2 format. Thanks to Wayne Bell, UniGroup, Inc, USA.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|