* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
EXOMCBOT are three different subtypes (100,101,102) of the user EXOMCDCT SMF record, and each subtype has sub-subtypes, and the EXOMCDLI subtype 100 sub-subtype 4 has still additional subtypes. EXOMCENQ This code has been compared with hex dumps of subtype 100 EXOMCFCT records, but only syntax checked in execution as no data EXOMCFIX records have yet been received for testing. EXOMCIDM EXOMCJCT
EXOMCPCP EXOMCRTA
EXOMCSYS EXOMCTIT
EXOMCTRA EXOMCTRL
EXOMCVIO EXOMCVSA
EXOMCVVS IMACOMCI
TYPEOMCI VMACOMCI
Nov 8, 1991 Change 09.146 This change significantly enhances MXG's processing of IMACICDA optional CICS data gathered with EMPs. Previously, MXG IMACICDB member IMACICDL decoded IBM local DL/I counters, member IMACICDL IMACICDB decoded IBM DBCTL counters, and member IMACICUS IMACICDU was used to set the length of any remaining user data. IMACICOB The MXG order of processing those segments was not under IMACICOC user control. This change externalizes the processing IMACICOL into new member IMACICDA, which can be used to match the VMAC110 MXG order with the order your CICS programmer set in her Oct 3, 1991 CICS MCT table. IMACICDA can also be used to identify which APPLIDs have which data segments, if not all are the same. Comments in IMACICDA describe how to use the enhancement, but this change did NOT change the previous MXG order (DL/I, UserChar, DBCTL). The change should be transparent to users already using the existing IMACIC.. members to decode those data. The real reason for this enhancement now was that it is now used to add support for additional CICS data that is created by Omegamon for CICS Version 550. The additional data are now supported by the new IMACIC.. "Omegamon" members listed below.
IMACICDU User counters/clocks/character data. (Note that the length of the user data is still defined, and can be decoded, in IMACICUS). IMACICDB IBM DBCTL counters, CICS/ESA only. IMACICOC Omegamon OMEGBSC (Basic) segment, CICS/ESA only. IMACICOL Omegamon OMEGDLI (DL/I) segment, CICS/ESA only. IMACICOB Omegamon OMEGDB2 (DB2) segment, CICS/ESA only. Note that while the order of segment processing is now set in IMACICDA, it is still required that you remove the comment block in each member you want to enable. See the comments in each member itself. Thanks to Barry Pieper, First Bank Services Minneapolis, USA. Change 09.145 Support for Omegamon for CICS Version 550 type 110 SMF IMACEXCL record EXCLUDE logic (used ONLY by Omegamon for non-ESA VMAC110 CICS, e.g., CICS 2.2 and earlier) has been added to MXG Oct 3, 1991 IMACEXCL (itself new in MXG 9.2). Candle keeps only 31 of the standard 60 IBM fields, and Candle reorders them!
you an "Invalid TASKNR" error with MCTSSDCN=34. (The exclude/reorder is optional in Omegamon, but your CICS person must be extremely careful with Omegamon with CICS Version 2, as the type 110 record that is created by Omegamon is independent of the type 110 IBM CMF record - both can be simultaneously created if both are turned on, which can happen and has caused duplicate accounting of CICS transaction counts and resources under CICS Version 2 regions. The problem does not occur in CICS/ESA, as Omegamon does not create a type 110 record under CICS Version 3 - it simply adds data (EMPs) to the end of the IBM CMF record as described in Change 9.146). The IMACEXCL member was originally added in MXG 9.2 to support Shared Medical Systems exclude logic, and it now has been revised to provide support not only for these Omegamon exclude logic, but now can be used for any CICS system with excluded/included fields. Note that the three EMPs that Omegamon can also create in CICS/ESA are separately supported by Change 9.146. Note also that there is also an Omegamon CICS user SMF record (that Candle unwisely defaults to ID=255, which is the same default as their unrelated Omegamon for MVS audit record!). That new CICS SMF record is supported in Change 9.147. (The unrelated audit record support is in member TYPEOMAU/VMACOMAU/IMACOMAU.) Thanks to Jim Shumaker, American Express Phoenix, USA.
VMACDCOL changed by APAR OY36364/UY55804, but MXG Change 8.285 Oct 1, 1991 was also in error. Before APAR, IBM used a track size of 47968 (3380) or 58786 (3390) bytes, which is the unformatted track capacity. But every track really has a record R0, and users complained about DCOLLECT values. IBM's APAR now uses the formatted track size available after R0, the familiar 47476 (3380) or 56664 (3390)! But when I validated the earlier number and found the numbers were larger than expected, I assumed that the values documented as "KB" were "thousand-bytes", and not "kilo-bytes", and thus Change 8.285 incorrectly used a factor of 1000 to convert raw values into "bytes". Now the truth is know; DCOLLECT does store Kil0-bytes and the correct conversion factor should have been 1024. 1.These values must be multiplied by 1024 instead of 1000 (they are listed in the order in which they appear): DCDALLSP DCDUSESP DCDSCALL DCVALLOC DCVFRESP DCVLGEXT DCVVLCAP UMDSIZE UMALLSP UMUSESP UMRECSP UBDSIZE 2.Two other variables were also in error, but unrelated to the above error. Variables DCDBKLNG and UMBKLNG are block length of datasets, and should not have been multiplied at all. Delete the respective lines which erroneously multiplied them by 1000. The following table shows the values stored and reported by MXG (after this change has been made to VMACDCOL), before and after the above IBM APAR is installed. (Note that after the APAR but without this change, MXG showed the 3380D capacity as 587MB!). Before APAR After APAR Device Tracks Kbytes MB Kbytes MB
3380E 26550 1243701 1214 1230945 1202 3380K 39825 1865552 1821 1846417 1803 3390-2 33390 1916859 1871 1847666 1804 3390-3 50085 2875289 2807 2771500 2706
Thanks to Mr. Plaacht, RWG, GERMANY. Thanks to Stuart Buck, Procter and Gamble Brussels, BELGIUM.
EXCMA00X datasets, one for each subtype. The support is written EXCMA01X in the "Subtype-Level Processing" architecture, which EXCMA02X allows individual datasets to be created from selected EXCMA03X subtypes, or all twelve datasets can be simultaneously EXCMA04X created. See examples in the comments at the beginning EXCMA05X of member VMACCMA. CMA-SPOOL is a product of SCA. EXCMA06X
EXCMA07X EXCMA08X
EXCMA09X EXCMA0AX
EXCMA0BX IMACCMA
TYPECMA VMACCMA
Sep 30, 1991 Thanks to Charlan Ledbetter, Anderson Consulting Dallas, USA. Change 09.142 TMON/MVS creates invalid records (if the data record is VMACTMVS larger than the CI size of the VSAM dataset TMON/MVS Sep 30, 1991 uses, the logic record is arbitrarily broken down into "spanned" physical records that do not conform to normal spanning, that have incorrect counts of how may real segments are in a "spanned" record, and that can be spanned right in the middle of a field!). MXG can only recognize and delete these defective records, but the DELETE; statement after the MXG error message was lost. The spanned record was recognized, the error message was printed on the log, but MXG still failed with INPUT STATEMENT EXCEEDED RECORD LENGTH message. This change put the DELETE; statement after the error message. Additional failures occurred when "trashed" records were created by TMON/MVS; these records had julian dates of 1989 and their "triplets" (offset, length, number)had zeroes for offset and/or length. MXG previously only tested the triplet-number, which was insufficient protection for these defective records. Now, MXG uses all three triplet fields, and the record length to (hopefully) more robustly detect and delete defective data records. Finally, MXG now can recognize if you have tried to process compressed records without having installed the MXG-provided de-compression exit (in MXG member EXITMON6 for Version 6, EXITMONI for Version 5), and the messages in this case are much cleared. Note that until Landmark chooses to create valid records, the data in their "spanned" records will be deleted. Thanks to William Padilla, Farmers Group Insurance, USA.
APAR/PTFs Contains an Incompatible Change to Type 30 Records" and Sep 29, 1991 OY33312 proceeds to state that it will reverse OY25606, and will change the length of SMF30EOR back to 2-bytes, etc. Don't worry about it; OY33312 has no effect on MXG processing of the type 30 record. The APAR affects only assembly programs using IBM macros which reference the DSECT fieldname SMF30EOR, but the APAR does not change the location of any fields that MXG reads; MXG did have to add code to support OY25606 (Change 8.081), but that code works fine with or without OY33312. Thanks to Susan Marshall, SAS Institute Europe, GERMANY. Change 09.140 The author of this I/O report found these corrections: ANALPATH Line 014900 should be XDUR = MAX(XDUR,SDUR); instead of Sep 29, 1991 containing a + sign. Lines 016700 and 016800 should use XDUR instead of SDUR in the denominator (calculating GTSIOPS and GTATTPS). Thanks to Cindy Batson, Hewitt Associates, USA. Change 09.139 RMDS records with RMDSORG='D' were incorrectly decoded, IMACRMDS causing "INPUT STATEMENT EXCEEDED RECORD LENGTH" error. VMACRMDS in VMACRMDS, change line 043700 to read Sep 29, 1991 ELSE IF RMDSORG='B' OR RMDSORG='D' THEN DO; change line 044500 to read RMDSDEST $CHAR19. (instead of 17), insert after line 044700 a new line with IF RMDSORG='D' THEN INPUT RMDSOWNR $CHAR8. @; and change line 045900 to read: ELSE IF RMDSORG='V' THEN DO; Before the change, RMDSORG='D' was processed with 'V'.) In verifying this error, the code in VMACRMDS was restructured and renumbered, and comments made clearer that RMDS Version 3 and Version 4 are identical. Thanks to Steve Lottich, The University of Iowa, USA.
DIFFDB2 IBM made incompatible changes in type 100 (Statistics, FORMATS DB2STAT0/1 datasets) and in type 102 (Trace, T102Snnn), VMACDB2 but existing MXG programs should have no problems, as VMACDB2H long as you install MXG 9.4+ and update the MXG Format VMAC102 library. You may want to exploit some of the new data, Sep 29, 1991 as described in the following notes:
VMAC30 Variable CPUERROR is now retained from the base record. Sep 29, 1991 (It is a bit map character variable, but since it was not input in the multi-dd record, it assumed a value of '4040'X, potentially causing confusion). EXECTM is now missing in the interval multi-dd records; recalculation of EXECTM is performed only if not multi-dd record. The JELAPSTM is now set missing in the multi-dd record. Thanks to Diane Eppestine, Southwestern Bell, USA.
FORMATS originally used to identify Standard/Tumble Duplex, and VMAC6 MXG format $MG006DU decoded '80'X or '40'X values. But Sep 28, 1991 now, additional bits are used, invalidating the single Nov 14, 1991 value hex decoding. SAS 6.07 supports bit testing for formats, but SAS 5.18 syntax errors. MXG has replaced format $MG006DU for variable DUPLXUSE with $HEX2., and you should use the variables (STDUPLEX/TMBUPLEX) instead. (All of the bits of old variable DUPLXUSE are now used to set individual variables). Thanks to Vickie Wong, Manufacturers Life, CANADA.
ANALDBTR after Change 9.104 was installed, because one more typo Sep 28, 1991 was missed. Line 161000 must be E064TM instead of the E063TM variable name. Thanks to Barry Bluestein, Union Carbide, USA.
VMAC22 fields to several records, but most are not significant. VMAC23 IBM changes are compatible.SMF manual now GG28-1628-2. VMAC30 a.TYPE22 added new bit value in TYPE22_1. VMAC40 b.TYPE23 support in MXG was incorrect. Fields added by VMAC71 earlier APAR were not INPUTed because the test was for VMAC90 the wrong length (also, order of new variables was not Sep 28, 1991 correct). Code has now been corrected, so the new data on SMF buffer statistics is now useful! c.TYPE30 contains new 8-byte jobclass JOBCLAS8 (left justified). Until it's clear that it's needed, MXG has decoded but not kept the field. However, if the 1-byte existing variable JOBCLASS is blank and the new JOBCLAS8 is non-blank, the first byte of JOBCLAS8 will be stored in variable JOBCLASS. Do you see a need for 8-bytes? This field was added by APAR OY42532. d.TYPE40 contains two new fields, TDDRCIND/TDDRCTOT which count the index and number of records in a sequence of records, but I can't figure why they are needed, and especially IBM states at the beginning of section that "IBM recommends you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40" its unclear why any change to type 40 was made! e.TYPE71 record was not changed, but since RECLAIMS no longer exist in 4.2.2, the four fields which formerly counted reclaims (PVTNPREC,PVTVAMR,PVTCAREC,LPARECLM) will now always be zero. Member VMAC71 was enhanced by adding SMF71xx field names in comments adjacent to the MXG variable name to map MXG names to IBM names. f.TYPE90 now supports subtypes 19, 20, and 21 (which were in 4.2.1 but not decoded by MXG - SET APPC, SET ASCH, & SET SCH respectively), and supports the new subtype 22 (SET CNGRP) added by 4.2.2.
VMAC6156 SMF records (61,65, or 66) create observations in the Sep 28, 1991 TYPE6156 dataset. Thanks to Tony Curry, Manufacturer's Hanover, USA. Change 09.132 Typographical errors printed in NEWSLETTER TWENTY have CHANGES been corrected in the MXG SOURCLIB members. Errors were: NEWSLTRS a.Newsletter TWENTY correctly stated that NOIMPLMAC must Sep 28, 1991 be specified in CONFIG, but then should have said that "IMPLMAC should never be used in ANY program." instead of "NOIMPLMAC should never be used...." b.In Change 9.066 text USERFMTS should have been IMACFMTS. c.Several references to NPM 4.1.1 should have been 1.4.1. Thanks to Pat Russell, Group Health Cooperative, USA.
CONFIG all of the MXG recommended options (added: ERRORABEND CONFIG07 MACRO DQUOTE FIRSTOBS=1 OBS=MAX NOSOURCE NOSOURCE2 Sep 28, 1991 NOMACROGEN NOMPRINT NOMLOGIC). The new SAS 6.07 option CODEPCT=120 was added only to CONFIG07; this option will avoid a second pass of SAS compiler for very large MXG programs (like a heavily enhanced BUILDPDB) and will eliminate an unnecessary and confusing SAS message. Note that options in the CONFIG file can be overridden by the the JCL OPTIONS= parameter. For example, to print source statements, you can print the entire source program with: // EXEC SAS607,OPTIONS='SOURCE SOURCE2 MACROGEN', // CONFIG='MXG.SOURCLIB(CONFIG) Thanks to Pat Russell, Group Health Cooperative, USA. Change 09.130 SAS Version 6 Compatibility. Options TLS= and TPS= do ANALTMS5 not exist in Version 6. (They were used to set the line Sep 28, 1991 size and page size of your terminal, and were set to 132 and 60 respectively in an OPTIONS statement in this ANAL member. That OPTIONS statement was deleted.) Thanks to Chuck Hopf, Primerica, USA. Change 09.129 Variable SPMSEXTL in the KEEP= list for dataset SPMSCED VMACSPMS should have been spelled SPMSEXTE. Variable SPMSDSN Sep 28, 1991 should be added to the KEEP= list for dataset SPMSEXT so you can match Extent data (SPMSEXT observations) to their Definition data (SPMSCED observation). New Amdahl PTFs for SPMS 1.2 are supposed to fix some data problems but STARTIME is completely wrong in records that span midnight; problem is being discussed with Amdahl now. It has also been noticed that the SPMSATDC, allocated track count delta, can be negative when less tracks are allocated at the end than at the start of interval. Thanks to Richard R. (Dick) Sziede, PRC Inc, USA. Change 09.128 -MXG 9.3 only. Change 9.080 incorrectly deaccumulated the DIFFDB2 DB2STAT0/1 variables QBnTCBA and QBnTPID; eight lines Sep 26, 1991 with those names must be deleted. QXCRRALS is spelled Oct 3, 1991 QXCRALS. QISE.... variables RCUR,RHIG,RLLM,RMAX, RDLM, and RSTG must be changed to QIST.... prefix. -MXG 8.8 and later. Several sequence counter variables have been incorrectly deaccumulated. For DB2STAT0, delete lines DIF'ing QWHSWSEQ, QWSBWSEQ, QWSnISEQ, QWnBWSEQ. For DB2STAT1, delete DIF'ing of QWHSWSEQ. (Do not delete DIF'ing of variables ending in TSEQ, nor the two statements SEQCHECK=DIF(...).) Thanks to Barry Bluestein, Union Carbide, USA. Thanks to Pete Shepard, Ashland Oil, USA.
VMACHSM dataset HSMFSRST; now it is. Sep 9, 1991 Thanks to Peter Giles, DSS, AUSTRALIA. Thanks to Colin Norton, DSS, AUSTRALIA.
VMACCMF non-zero offset and non-zero length but with a zero for Sep 8, 1991 number of segments was found. The CHECKSUM logic did not check for existence of segment before trying to read the record. Only the Device Type Segment has thus far had zero number, and changing line 00089700 to now read IF C00DTYPN GT 0 THEN LINK CMFCKSM; will circumvent this specific error. However, the MXG change will protect each triplet by creating a variable CMFWNUM set equal to the number of segments (immediately following CMFWPTR which is set equal to the offset), and then executing the subsequent LINK only if CMFWNUM is greater than zero. There are 12 triplets to protect. Thanks to Peter Giles, DSS, AUSTRALIA. Change 09.125 This Cache DASD analysis report uses both TYPECACH and ANALCACH TYPE74 data, but did not delete type 74 data from tapes! Aug 20, 1991 Insert after PDB.TYPE74; IF DEVICE=:'34' THEN DELETE; to exclude tape devices from Cache DASD reports. Thanks to Jim Cummings, First Interstate Bank of Oregon, USA.
VMACOMAU some time, and defaults to SMF ID=255. However, their Aug 20, 1991 new CICS V550 product now creates a different user SMF record, which also defaults to ID=255, causing sites using VMACOMAU to fail, since the new CICS user records don't look anything like the Audit Record. You must change the V550 SMF record ID (in Candle's OC$GLOB SMFID= parameter in their OCDATA install dataset) to a different SMF record ID. MXG support for the new V550 User SMF record is discussed in Change 9.147. Thanks to Dean Bolick, Belk Stores Services, USA.
UTILCICS which have MNSEGCL values greater than 4, was not added Aug 20, 1991 to UTILCICS when VMAC110 was updated in MXG 9.2. Now, this member will skip over these segments instead of printing ERROR.VMAC110.1 messages with MNSEGCL=209! Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA. Change 09.122 For IMS measurement with Boole & Babbage's IMF product, TYPECIMS the processing of Chained Transactions (at the end of Aug 20, 1991 member TYPECIMS) should have also recalculated the response time variable, RESPNSTM, using the ACTLARRV time of the chained transaction. Insert after 008600: RESPNSTM=ENDTIME-ACTLARRV; Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
IMACDB2 was incorrect for CICS connection. The CORRNAME should Aug 20, 1991 have been SUBSTR(QWHCCV,5,4) instead of (QWHCCV,9,4). The comments describing the decoding of QWHCCV into the CORRNAME/CORRNUM were also incorrect for CICS, and have been revised and clarified. Thanks to ???, UNI Storebrand, NORWAY.
XMAC7072 to the TYPE72 (CPUHPTTM,CPUIIPTM,CPURCTTM) are actually VMAC7072 in micro-second units, and not 1024-microsecond units, Aug 16, 1991 as documented in the microfiche for IRAWAMT! MXG Change 9.070 is thus off by 2%; the 1.024 factor added by that change must be removed (fortunately, by comparing these CPU times with their counterparts in type 30, I knew the 1000 factor was wrong, but believed IBM when they said 1.024 instead of 1.000!). Therefore, delete the three lines multiplying these times by 1.024. Thanks to Peter Doane, Com/Energy Services Company, USA.
VMACACF2 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error. Aug 14, 1991 The record has a parm length of 1 byte, but there is no ACFAPARM field in the record. C A could not see an obvious code error, and required the Australian site to open a problem, but not fix yet exists. For now, change updated when CA responds. The circumvention for now is lines 038900 and 039100 to read: ... 200 AND (COL-1+ACFAMPLN LE LENGTH) THEN ... Thanks to Francis Han, Office of State Revenue, NSW, AUSTRALIA. Change 09.118 Support for Software AG's NET-PASS user SMF record is EXTYNETP added by this change, which captures response time IMACNETP (average, and three distribution buckets) as well as Yüklə 28,67 Mb. Dostları ilə paylaş:
|