* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Sep 12, 2005 should have been NR43SEGS. Thanks to Bill Arrowsmith, Euroclear, BELGIUM. Thanks to Stephen Morris, National Australia Bank, AUSTRALIA
VMXGUOW ELAPSTM, the total elapsed duration of the DB2 portions Sep 9, 2005 of the Unit of Work, some which could be in parallel, are revised. IRESPTM is now the maximum of the CICSTRAN segments in this unit of work, while ELAPSTM is the sum of the individual elapsed times of the DB2ACCT segments, in the PDB.ASUMUOW dataset built by INCLUDE of ASUMUOW. In addition, new variable DB2IDLE, which was originally created by archaic ANALDB2C, but lost when ASUMUOW was built, is now created. DB2IDLE is the elapsed time from last CICS ENDTIME to the DB2 QWACESC End time, and is the duration when the DB2 thread was idle, but has not ended, presumably for possible thread reuse. DB2IDLE is then subtracted from the sum of the DB2ACCT ELAPSTMs, so the final ASUMUOW ELAPSTM does NOT include DB2IDLE time. -This change can make ELAPSTM smaller than before, for serial transactions that had DB2IDLE time. -This change can make ELAPSTM larger than before, for DB2 Parallel transactions (DBPARTY='P'), because the prior ELAPSTM was start to finish. But since parallel=3 can burn 3 hours of CPU time, the elapsed time must be the sum of the parallel elapsed time, rather than start to finish of the unit of work. -In addition, the _TRANUOW user exit has these additional variables available for examination, etc. HOLDIRSP: MAX of IRESPTM from CICSTRAN HOLDELAP: SUM of ELAPSTM from DB2ACCT HOLDFSTR: Min of CICS STRTTIME start datetime HOLDLSTR: Max of CICS STRTTIME start datetime HOLDFBSC: Min of DB2 QWACBSC begin datetime HOLDLESC: Max of DB2 QWACESC end datetime Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA. Change 23.239 Support for DURATM keywords TENMIN and FIVEMIN. Code had VMXGDUR been added in VMXGDUR, but not in VMXGSUM. Obscure notes VMXGSUM in member VMXGSUM did say that if you use DURATM= with an Sep 9, 2005 unsupported keyword, variable DURATM will not be created. The actuality is that these DURATM= values: SECOND MINUTE FIVEMIN TENMIN QTRHOUR HALFHOUR HOUR THREEHOUR DATE WEEK do create variable DURATM, while these DURATM= values MONTH and SHIFT do not create variable DURATM. Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
UTILBLDP (due to frequent CICS dictionary changes), normally write Sep 8, 2005 their IMACEXCL code to a "flat file" rather than a PDS (avoids need to compress the PDS), adding //IMACEXCL DD to point to that code, and adding %INCLUDE IMACEXCL; using MACKEEP= logic. However, the include of an external DD statement was not supported in UTILBLDP. Now, it is, with the new IMACEXCL= argument. Thanks to Chuck Hopf, MBNA, USA.
VMAC7072 and PDB.ASUMCEC datasets built by ASUM70PR for processors VMXG70PR that populate 'IFA' and 'IFL' in SMF70CIN (only z9 now). Sep 7, 2005 Variables LPnDSA are now labeled. -MXGCIN variable now contains new IFA and IFL values.
VMACENDV their user SMF record. Sep 6, 2005 Thanks to Herb Strozinsky, US Bank, USA. Change 23.235 DB2TCBTM for Rollup observations (DB2PARTY='R') is wrong VMACDB2 and could be less than QWACAJST (the TCB time in DB2). Sep 6, 2005 APAR PQ41012 documented that in rollups the accumulated Elapsed and TCB were in QWACESC & QWACEJST, but only the elapsed time was corrected in Change 22.121. Now, the DB2TCBTM is recalculated when DB2PARTY='R' is set, using: DB2TCBTM=SUM(QWACEJST,QWACSPCP); (The final component, QWACTRTE is added in later.) Thanks to Scott Barry, SBBWorks, Inc, USA.
GRAFWLM graphs of CPU utilization grouped by SYSSTC, SYSTEM, work Sep 8, 2005 with a goal, and work without a goal, to show how much work could or couldn't be managed by WLM. This analysis produces similar SAS/GRAPH stacked bar charts, showing CPU Time and MSU consumed by these groupings from top to bottom: UNCAPTURED SYSTEM SYSSTC
IMP 1 CPU CRITICAL IMP 1
IMP 2 CPU CRITICAL IMP 2
IMP 3 CPU CRITICAL IMP 3
IMP 4 CPU CRITICAL IMP 4
IMP 5 CPU CRITICAL IMP 5
SYSOTHER (All unclassified discretionary work - should have no unclassified work!) DISCRETIONARY (All work classified as discretionary, regardless of importance. Discretionary work is work in a service class period that does not have a goal. An example of the output can be viewed at http://www.mxg.com/samples/grafwlm See comments in the member for usage documentation. Thanks to Peter Enrico, Enterprise Performance Strategies, Inc. Thanks to Chuck Hopf, MBNA, USA. Change 23.233 Several corrections and enhancements to Web Log support: VMACWWW -ELAPSTM, at least for BEA WebLog was way too small; their Sep 2, 2005 "time-taken" field contains 'seconds.fraction' value, but Sep 3, 2005 MXG expected a millisecond integer value. Now, MXG will detect a period in the time field, and inputs ELAPSTM as 'seconds.fraction' when a period is found; otherwise, the field is input and divided by 1000 to get seconds. -Example FILENAME now has LRECL=4096 to match the INPUT $VARYING4096. If LRECL was not specified, LRECL=255 is the default, which causes "ONE OR MORE LINES TRUNCATED". -TRANSLATE(RECORD,' ','09'x); added, because BEA log has a hard tab, '09'x between fields instead of blanks. Dealing with '09'x can be nasty, since it is usually turned into a blank by most editors, and blanked by SAS when input records are displayed, so you often don't even know there's an '09'x value, until your read and display the field in hex, using: INPUT FIELD $CHAR50.; PUT FIELD= $HEX100.; -Change 23.026 protected one of the two URIQVALU=SUBSTR(); now both are protected for URIQVALU=0, which happens when when an = in the URIQUERY string is immediately followed by an &, causing LTOAND=1 and thus causing URIQVALU=0. -Vars BYTES CSBYTES LBYTES SCBYTES now LENGTH &MXGBYLN. Before Change 23.026, CSBYTES and SCBYTES were kept as length $4096 because MXG used CSBYTES=WORD(....); and WORD's is $4096, so CSBYTES/SCBYTES wasted space when SAS compression was not used (COMPRESS=YES is default). That change made them numeric, saving space, but they were now 4-byte length due to MXG's DEFAULT=4. However, byte-containg fields need more resolution, and thus they are now properly set to LENGTH &MXGBYLN. ; -BYTES added to KEEP= list for _VWWWIIS and WWWIIS22 was added to $16 length statement. Thanks to Andrzej Dabrowski, Computing Services, CSIR, SOUTH AFRICA. Change 23.232 NDM dataset NDMPS ('PS'/'SW' records) now has variables VMACNDM PSSDSN='DSNAME' and PSSDSNL='LENGTH OF*DATASET*NAME' Sep 1, 2005 both input and kept, if this is an 'SW' subtype. -Missing value messages were eliminated for DATE fields that are known to have missing values; MXG now tests the DATA field before constructing the DHMS function inputs. Thanks to Tom Neurauter, Fidelity Systems, USA.
VMAC102 QW0225FA QW0225GA QW0225VA QW0225SJ Sep 1, 2005 that report DB2 storage used "Above The Bar". Thanks to Valerie J. Chisholm, Aetna, Inc, USA. Change 23.230 "EXIT-DRIVEN" MXGTMNT Tape Mount Monitor is AVAILABLE!! ASMTAPEE ML-35 should be the FINAL iteration in this major effort ASMHSCEX that replaces the original sampling tape mount monitor Sep 1, 2005 (it sampled the tape UCBs every 1/2 second, working just fine for many years of real tape drives, but sampling now misses many of your very fast VTS tape mounts) with this event driven monitor that instead uses exits to capture EVERY tape mount for real drives, silos, and/or VTS devices, whether mounted by IBM or STK software. -What's now available is this enhancement that supports multiple instances of STK's HSC and/or CSC running in the same system. -The Exit Driven architecture has been available for some time, using the IBM Volume Mount exit for all real tape devices (whether IBM or STK drives), and for IBM VTS. It was the enhancement to use the STK User Exit in their HSC and CSC software, used for STK Silos and STK VTSs, that was extremely difficult to develop, primarily due to the complete refusal of STK to provide any technical help (i.e., STK wouldn't/couldn't tell in which address space their exit was executed!), so MXG's asmguy@mxg.com had to figure it all out without assisance from that vendor. -Both ASMTAPEE and ASMHSCEX were updated by this change. -The solution for multiple HSC/CSC is in the new ASMHSCEX, which now create two exits, SLSUX01 for HSC, and SCSUX01 for CSC, so all you're HSC guru will have to do is to define the appropriate exit to whichever one (or ones) your site is running for your STK Silos and VTSs. -What to do when both are run: There may be a little extra overhead for those sites that run multiple exits on the same system, but that won't affect a site that only runs one exit. Exit 01 in HSC or CSC behave the same; either exit will provide the information we need. With ML-35, you can run any number of those exits, but now, we'll create only one record per tape mount! Asmguy's advice when both are running is to pick one, whichever is most likely to be active all the time, and define the exit to it. If you want to run multiple exits on the same SYSTEM, ML-35 will allow this, but there is additional overhead involved. If you chose to do this, you can just define the exits as you would normally, and no change is required to ASMTAPEE, as it automatically will detect that multiple exits are running, and respond accordingly. -ML-35 ASMTAPEE is NOT compatible with earlier ASMHSCEX. You must use the ML-35 ASMHSCEX with the ML-35 ASMTAPEE. - ML-35 corrected several old ASM coding exposures found by Dick Zieske, mostly dealing with cleanup of CSA when MXGTMNT is cancelled, rather than STOPed, or if MXGTMNT ever ABENDS (which has never happened in production)! - Sampling is still used for Tape Allocation records. Thanks to "asmguy@mxg.com" who has figured out how to use the HSC/CSC exits in spite of complete lack of help from STK. Thanks to Dick Zieske, AIG, USA. Thanks to Steve Martin, Fidelity Systems, USA. Thanks to Paul Naddeo, FiServ, USA. Thanks to Jeff Holst, FiServ, USA. Thanks to Normand Poitras, IBM Global Services, CANADA. Thanks to Dan Squillace, SAS Institute Cary, USA. Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong. Thanks to Shane Dowling, DEWR, AUSTRALIA. Thanks to Scott Chapman, American Electric Power,USA. Thanks to Patricia J. Jones, DST Systems, USA. Change 23.229 Support for DEVTYPE='3592' tape devices. Observations VMACTMS5 were output by MXG for those devices, but variable DEN Aug 31, 2005 was not decoded, causing "DENSITY IS MISSING" non-fatal log messages; more important: variable DEVTYPE was blank. DEN and DEVTYPE are populated by table lookup in the MXG program, after I find out what hex value CA has chosen. Thanks to Todd Wright, CSC Australia, AUSTRALIA.
VMACEREP that had a message shorter than the 96-bytes that MXG had Aug 31, 2005 hardcoded for the INPUT of ETRMESSG. Code was revised. Thanks to Steven Clark, DHL, USA. Change 23.227 The NDMCT dataset contains accumulated NDMCPUTM for multi TYPENDM step processes; deaccumulation is always done by MXG in VMACNDM the "_Sdddddd" macro, the "Data Set Sort" macro, so the Aug 31, 2005 heuristic logic to sequence and deaccumlate adjacent data was added to the _SNDMCT macro. -The TYPSNDM macro automatically sorts the output, but if you have added processing of NDM data to your BUILDPDB, you should replace your PROC COPY; SELECT NDM:; with the "Product Sort" macro _SNDM in your EXPDBOUT member to sort all of the NDM datasets, and deaccumulate NDMCT. -If you are using ITRM, you only need the _SNDMCT "Dataset Sort Macro" in your EXPDBOUT, since ITRM will separately handle the adding of the other NDM datasets to DETAIL. -While the TYPExxxx members normally only write to //WORK, when an xxxx product requires deaccumulation, I add the _Sdddddd data set sort macro (s) to the TYPExxxx member to ensure you don't accidentally use the unaccumulated data, so _SNDMCT was added to the TYPENDM member's code. Thanks to Thomas Clark, SEI Investments, USA.
VMACSTC were in error (see Change 23.125), but did not print a Aug 30, 2005 message on the log that you were missing that PTF. Now it does advise you that records were deleted. Thanks to Chuck Hopf, MBNA, USA.
BLDSMPDB expected. Aug 30, 2005 Thanks to Tom Kelman, Commerce Bank of Kansas City, USA. Change 23.224 Cosmetic corrections found during ITRM dictionary build. VMXG70PR -TYPE70LP: SMF70DSA was not labeled. VMACCMF -CMF27C93: C2795RFL,C2795RTY "THUS:" removed from label. VMACNDM -NDMRJ: NDMJOBNM,NDMRJDSN,NDMSYSRC were not labeled. VMAC79 -TYPE791/TYPE792: R791NFFI,R792NFFI were not labeled. Aug 30, 2005 Thanks to Chris Weston, SAS Institute ITRM Cary, USA.
EXIPAC08 changes in the length of IPSPAGE/IPEPAGE fields in the IMACIPAC subtype 1 record). Other changes in this release: VMACIPAC -New variable IPPACCES='PAGE*ACCESSED*COUNT' in IPAC03. VMXGINIT -Variable IPLOC is now $8; it includes the former reserved Aug 30, 2005 one following byte. Aug 31, 2005 -New subtype 8 creates dataset IPAC08, similar to IPAC03. -But, there still is no change in their VERSION field, so the LENGTH of the record must be used to identify the new data added to the subtype 1 and 3 records. -And, the vendor documentation for Release 6.3 does not document the SMF records they write: The REQSTART and REQEND documentation is unchanged, but records show the values are reversed physically, with END first and START last, and the format of their time part still says 0hhmmssF, but the data shows four-byte EBCDIC numeric HHMM value.
hex dump of their defective record we sent, which shows the START field with 2208 and the END field with 2205, but simply replied that their their dsects were the definitive documentation source.
their code so the records match the "definitive" DSECT, MXG code now tests START versus END and reverses their values if necessary. Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS. Thanks to Debby Blackey, HCA Health Care, USA. Change 23.222 Change 23.216 was updated for APAR OA10346; new values VMAC7072 in SMF70CIX for "IFA", "IFL", are now used to create new Aug 29, 2005 NRIFACPU and NRIFLCPU variables, and the count of those non-"CP" engines is subtracted from variable PARTNCPU. Without this change, PARTNCPU included IFAs and IFLs. MXG variable MXGCIN was also updated with new SMF70CIN. Data from z9 processor was used to validate this change, which also validated Change 23.186, the z9 support. Change 23.221 The default example variable names for the TSO workload RMFINTRV was incorrectly/accidentally changed from the historic Aug 29, 2005 "TSO" to "TSOP" in the RMFINTRV member in MXG 22.07. The example is now corrected so the TSO variables will start with just the historic "TSO" prefix. If you have your own tailored RMFINTRV member, it controlls the names of the variables, so this change would have no impact. However, if you were using the MXG 22.07-23.07 default, this change could cause your reports to fail, since your reports expect TSOP.... variable names, so your best choice is to copy the RMFINTRV from 22.07-23.07 into your tailoring library, and your variables will continue to be spelled TSOPxxxx. I made his reversion because the MXG example reports expect the TSOxxxx variable names. Thanks to Paul N. Ross, Computer Sciences Corporation, USA.
VMAC80A for a valid SMF 80 record that contained no segments. Aug 30, 2005 I noted the "USER IS NOT DEFINED TO RACF" bit was on.
for their "short record" error, because the OFFSET was greater than the LENGTH of the SMF record, but now I am "eating my own words", as the record was completely valid and it was an MXG logic error that wasted both IBM's and this MXG Customer's time: IBM's response was completely accurate and to the point and completely detailed the offset and locations that proved the record was completely valid. It's one of the best written and complete replies I've seen! I had inserted code in MXG to read in a 4-byte test for a vendor product, but I put the input before the group DO _I_= 1 TO NRSET that input the segments that exist. My input was always executed, even when NRSET=0! That IBM reply recommended the use of the count field, which is now done, but I also test LENLEFT GE 4 to make sure there really are 4 bytes left to be read.
because they all had the field, and there were no errors when QA SMF 80s from several sites were read, so the code was released in October, 2003. Since then, billions and bullions of SMF 80 records have been read, and all had one or more segments and no error. I can live with those odds! Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM. Thanks to Victor_Van-Cakenberghe,IBM, BELGIUM Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as &PIB.2., instead of one byte, and variable VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on, Aug 29, 2005 to mark that this GDG member has "wrapped"; i.e., its generation number has exceeded 9999. If GATWRAP is on, GATGEN=GATGEN-32768 to contain the correct Gen number. This discovery was precipitated by IGD07001I ABENDs in production, which occurred when a GDG that had GATWRAP on for some members, and GATWRAP off for others, when that GDG generation number goes from 999 to 1000. Normally, when all members of a GDG have wrapped, the next catalog action turns off the wrap bit in all of the catalog records. For a "normal" GDG, that should happen when the +256th gen is created after wrap, as only 255 members can exist in the catalog. But this site had had a very old application that originally created +1 thru +5 each day, and then deleted +1 thru +4, leaving only +5 in the catalog. However, back when Clinton was President, an application change was made that created only +1 thru +3 and deleted only +1 & +2, so there were 2 old GooooVoo's left in the catalog. When the GDG wrapped, and when the create of +1 would have created G1000V00, those old GooooVoo's still had their wrap bit off, and the production job failed: IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122 Return Code 140: Inconsistent or conflicting arguments were provided. Reason Code 122: Catalog G1000Vxx will cause the GDG to exceed the limit of 10,999. Programmer Response: Clean up the GDG in error then catalog G1000Vxx. The site found Information APAR II07276, which explained how wrap works, but it says to 'see the "Z" page for internal details of the wrap bit interface'.
GDGs that have the same exposure to causing ABENDs. Can I look at the 'Z' page? Does the 'wrap bit' appear in SMF 61, 65, 66 ICF Catalog records?" IBM Level 2 Catalog Support refused to answer the quite valid question, with this answer: "Unfortunately, the 'Z' page in our info APARs refer to information meant for IBM eyes only, for helping us get to problem determination quicker. We are not at liberty to discuss any control block internals that are not provided in our published manuals. As for information in SMF records relating to this, this info would be included in the updated record portion of the SMF record, however we cannot discuss offsets for those either. I am sorry I cannot be more helpful. Please let me know if there are any other questions that I can answer for you."
not convince IBM Level 2 Catalog Support to identify which bit is the "GATWRAP" bit. The ICF Support and Developers hid behind "OCO", Object Code Only, as the reason they could not provide catalog record documentation (but DSECTS are NOT CODE!). So I suggested the site could create a GDG and force it to wrap, and by examining SMF records, we concluded that first bit of GATGEN was the GATWRAP bit.
manuals, and located the very old "MVS/XA Catalog Diagnosis Reference for DFP Release 1.2", which confirmed that the GATWRAP bit was indeed the first bit of the GATGEN field in the 05 Catalog Record!
Thanks to Joseph Stoll, University of Wisconsin Hospitals, USA. Change 23.218 Format $MGDB2PT did not have value for 'R'='R:ROLLUP'. FORMATS
Aug 23, 2005 Thanks to Scott Barry, SBBWorks, Inc, USA. Change 23.217 Typo at line 392 had WEEKBLD instead of _WEEKBLD. WEEKBLDT
Aug 23, 2005 Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA. Yüklə 28,67 Mb. Dostları ilə paylaş:
|