* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Change 10.183 DB2 Statement Number type 102 trace records are decimal ANALDB2R values, but some MXG datasets stored them as $CHAR2. with VMAC102 a $HEX4. format. Now, all statement numbers are decimal Sep 24, 1992 values, to agree with DB2PM and the catalog information. Thanks to Dave Leeker, Southwestern Bell, USA.
VMACOMCI INPUT STATEMENT EXCEEDED RECORD LENGTH. Immediately before Sep 24, 1992 "INPUT ESRES1..." insert "IF SUBTYPE NE 101 THEN" (that header segment does not exist in the subtype 101). After input of SYSEGS PIB4., insert @; SMSEGO=SMSEGO=3;INPUT (this subtype had not occurred in earlier test data). Thanks to David Ehresman, University of Louisville, USA.
ADOCTIRS Reasoning Shell, TIRS. An observation is created in the EXTYTIRS TYPETIRS dataset, containing session times, CPU time used IMACTIRS (both vector and CPU), interactions and ABEND codes for TYPETIRS each time the TIRS subsystem replies or queries the user. VMACTIRS This has been coded but not tested with data. Sep 24, 1992 Thanks to Bill Stoneberg, National-Oilwell, USA. Change 10.180 Support for SIMWARE SIM/XFER VTAM user SMF record added. ADOCSIM For each user transfer session, an observation is created EXTYSIM in TYPESIM dataset, reporting session times and the amount IMACSIM (bytes and blocks) of data sent and received. TYPESIM VMACSIM
Sep 24, 1992 Thanks to Mike Roybal, First National Bank in Albuquerque, USA. Change 10.179 TYPE73 variable ESCACVC (flag that an ESCON converter is VMAC73 attached to this CHPID) was never set to "Y" because it Sep 24, 1992 was misspelled as ESONCVC in one line. Corrected spelling. Thanks to Diane Eppestine, Southwestern Bell, USA. Change 10.178 Support for Hewlett-Packard Performance Collection System ADOCHPCS Now available from HP, the PCS product for HP/UX operating ANALHPRS system creates 4 records from which MXG builds 6 datasets: ASUMHPCS HPCSAPPL - Application resources by interval EXHPCSAP HPCSCONF - Configuration at startup of PCS EXHPCSCO HPCSDISK - Disk activity by device by interval from GLOB EXHPCSDI HPCSGLOB - Global activity by interval EXHPCSGL HPCSLANS - LAN activity by LAN by interval from GLOB EXHPCSLA HPCSPROC - Process activity by process by interval EXHPCSPR It is quite encouraging that Hewlett Packard recognizes IMACHPCS the need to instrument its UNIX platform and now offers JCLHPCS the PCS product to manage HP UNIX systems. TRNDHPCS TYPEHPCS
VMACHPCS VMACHPCS
Sep 23, 1992 Thanks to Chuck Hopf, Hopf Consulting, USA. Change 10.177 Sites still on MVS/XA will need to use ASMTMNTO to create ASMTMNT the MXG tape mount monitor, as it will assemble under XA. Sep 23, 1992 (The "real" monitor in ASMTMNT uses MVS/ESA-only macros to support dynamic device additions). Change 10.176 NETVIEW FTP SMF record timestamps aren't SMFSTAMP8 format VMACFTP but have DATE preceding TIME. (Its not standard format, Sep 23, 1992 but it ain't illegal!) Replace all eleven lines with: xxxxxxxx SMFSTAMP8. with these five lines: DATE PD4. TIME PIB4.2 @; IF DATE GT 0 THEN xxxxxxxx=DHMS(DATEJUL(DATE),0,0,TIME); INPUT Thanks to Herr Timmermanne, Preussen Elektra, GERMANY. Change 10.175 Powerful new "_L" 7 "_K" macros are now defined for each all of MXG MXG dataset, allowing you to completely tailor individual Sep 22, 1992 datasets. You can now ADD or DROP variables, write the dataset to a specific DD (libref), add dataset compression for specific datasets, change BUFSIZE, or even change the name of the MXG dataset! This MAJOR revision to the MXG architecture greatly enhances the flexibility and control for the future. The usage of this new design is described in the second part of this change. The first part of this change discusses the incompatibility of the design. 1. INCOMPATIBILITY of the new "_L" macros. These nineteen IMACs have been changed INCOMPATIBLY: IMACCICS IMACCIMS IMACCMF IMACDB2 IMACDCOL IMACHSM IMACIMS IMACINTV IMACMONI IMACNSPY IMACOPC IMACPDSM IMACROSC IMACSTX IMACTPX IMACZRB IMAC30DD IMAC40DD IMAC434D
make the changes described below, or your job will ABEND!
which set the DDNAME to which certain MXG datasets were written. In the new "_L" architecture, these IMACs define both the DDNAME and DATASET names in one "_L......" macro. For example, IMACICS defined MACRO _CICTRAN CICSTRAN % (which was used with DATA _CICTRAN.CICSTRAN syntax) so that the CICSTRAN dataset was written to the CICSTRAN DD. Now, IMACCICS defines MACRO _LCICTRN CICSTRAN.CICSTRAN % (which is now used with DATA _LCICTRN syntax) so that the CISTRAN dataset is still written to the CICSTRAN DD. For each IMAC listed above that is in your USERID.SOURCLIB library, you MUST copy the new 10.x IMAC member into your MXG.V1010.USERID.SOURCLIB, and set the DDNAME part of the new "_L" macro definition to the DDNAME value from your old IMAC member.
(with the MXG default value) for each of the IMACs that were incompatibly changed:
MACRO _CICEXCE PDB % MACRO _LCICEXC PDB.CICSEXCE % MACRO _CICTRAN CICSTRAN% MACRO _LCICTRN CICSTRAN.CICSTRAN% MACRO _CICYSTM PDB % MACRO _LCICSYS PDB.CICSYSTM % MACRO _CICEOD PDB % MACRO _LCICEOD PDB.CICEODRV % MACRO _CICINT PDB % MACRO _LCICINT PDB.CICINTRV % MACRO _CICREQ PDB % MACRO _LCICREQ PDB.CICREQRV % MACRO _CICUSS PDB % MACRO _LCICUSS PDB.CICUSSRV % IMACCIMS MACRO _IMFTRAN WORK % MACRO _LIMFTRN WORK.CIMSTRAN % MACRO _IMFDBDS WORK % MACRO _LIMFDBD WORK.CIMSDBDS % MACRO _IMFDB2 WORK % MACRO _LIMFDB2 WORK.CIMSDB2 % MACRO _IMFPROG WORK % MACRO _LIMFPGM WORK.CIMSPROG % IMACCMF MACRO _CMF19DD PDB % MACRO _LCMFTRA PDB.CMFTRACE % IMACDB2 MACRO _DB2ACCT PDB % MACRO _LDB2ACC PDB.DB2ACCT % MACRO _DB2STAT PDB % MACRO _LDB2ST0 PDB.DB2STAT0 % MACRO _DB2STAT PDB % MACRO _LDB2ST1 PDB.DB2STAT1 %
MACRO _DCOLCLU WORK % MACRO _LDCOCLU PDB.DCOLCLUS % MACRO _DCOLVOL WORK % MACRO _LDCOVOL PDB.DCOLVOLS % MACRO _DCOLMIG WORK % MACRO _LDCOMIG PDB.DCOLMIGS % MACRO _DCOLBKP WORK % MACRO _LDCOBKP PDB.DCOLBKUP % MACRO _DCOLCPD WORK % MACRO _LDCOCPD PDB.DCOLCAPD % MACRO _DCOLCPT WORK % MACRO _LDCOCPT PDB.DCOLCAPT %
this member would cause a problem, but where it used to be OUTPUT TYPE30_V; it now needs to be OUTPUT _LTY30UV; just to be consistent with the new architecture. IMAC30DD No macro is defined in this member, and it is unlikely that this member would cause a problem, but where it used to be OUTPUT TYPE30_D; it now needs to be OUTPUT _LTY30UD; just to be consistent with the new architecture. IMAC40DD No macro is defined in this member, and it is unlikely that this member would cause a problem, but where it used to be OUTPUT TYPE40_D; it now needs to be OUTPUT _LTY40UD; just to be consistent with the new architecture. IMACMONI MACRO _MONDBDS WORK % MACRO _LMONDBD WORK.MONIDBDS % MACRO _MONHIST WORK % MACRO _LMONHIS WORK.MONIHIST % MACRO _MONMRO WORK % MACRO _LMONMRO WORK.MONIMRO % MACRO _MONSYST WORK % MACRO _LMONSYS WORK.MONISYST % MACRO _MONTASK WORK % MACRO _LMONTSK WORK.MONITASK % MACRO _MONUSER WORK % MACRO _LMONUSR WORK.MONIUSER % IMACOPC MACRO _OPC20 WORK % MACRO _LOPC20 WORK.OPC20 % MACRO _OPC23 WORK % MACRO _LOPC23 WORK.OPC23 % MACRO _OPC24A WORK % MACRO _LOPC24A WORK.OPC24D_A % MACRO _OPC24B WORK % MACRO _LOPC24B WORK.OPC24D_B % MACRO _OPC24C WORK % MACRO _LOPC24C WORK.OPC24D_C % MACRO _OPC24D WORK % MACRO _LOPC24D WORK.OPC24D_D % MACRO _OPC24E WORK % MACRO _LOPC24E WORK.OPC24D_E % MACRO _OPC24F WORK % MACRO _LOPC24F WORK.OPC24D_F % MACRO _OPC24G WORK % MACRO _LOPC24G WORK.OPC24D_G % MACRO _OPC241 WORK % MACRO _LOPC241 WORK.OPC24_1 % MACRO _OPC242 WORK % MACRO _LOPC242 WORK.OPC24_25 % MACRO _OPC246 WORK % MACRO _LOPC246 WORK.OPC24_6 % MACRO _OPC247 WORK % MACRO _LOPC247 WORK.OPC24_78 % MACRO _OPC25 WORK % MACRO _LOPC25 WORK.OPC25 % MACRO _OPC26 WORK % MACRO _LOPC26 WORK.OPC26 % MACRO _OPC27 WORK % MACRO _LOPC27 WORK.OPC27 % MACRO _OPC28 WORK % MACRO _LOPC28 WORK.OPC28 % MACRO _OPC29 WORK % MACRO _LOPC29 WORK.OPC29 % MACRO _OPC30 WORK % MACRO _LOPC30 WORK.OPC30 % MACRO _OPC31 WORK % MACRO _LOPC31 WORK.OPC31 % MACRO _OPC32 WORK % MACRO _LOPC32 WORK.OPC32 % MACRO _OPC33 WORK % MACRO _LOPC33 WORK.OPC33 % IMACPDSM MACRO _PDSMDD WORK % MACRO _LTYPDSM WORK.TYPEPDSM % IMACROSC MACRO _ROSCDDN WORK % - unchanged at present. IMACSTX MACRO _STXINT WORK % - was defined, but never referenced in MXG. IMACTPX MACRO _TPXINT WORK% MACRO _LTPXINT WORK.TPXINTRV % It is remotely possible that you may have used the old syntax in your report/analysis program, and if so, you may encounter syntax errors. The following table lists the old and new syntax for each possible macro that might cause syntax errors. Previous syntax Must be replaced by syntax _CICACCT.CICSACCT _LCICACC _CICEXCE.CICSEXCE _LCICEXC _CICTRAN.CICSTRAN _LCICTRN _CICYSTM.CICSYSTM _LCICSYS _CICEOD .CICEODRV _LCICEOD _CICINT .CICINTRV _LCICINT _CICREQ .CICREQRV _LCICREQ _CICUSS .CICUSSRV _LCICUSS _IMFTRAN.CIMSTRAN _LIMFTRN _IMFDBDS.CIMSDBDS _LIMFDBD _IMFDB2 .CIMSDB2 _LIMFDB2 _IMFPROG.CIMSPROG _LIMFPGM _CMF19DD.CMFTRACE _LCMFTRA _DB2ACCT.DB2ACCT _LDB2ACC _DB2STAT.DB2STAT0 _LDB2ST0 _DB2STAT.DB2STAT1 _LDB2ST1 _DCOLDSN.DCOLDSET _LDCODSN _DCOLCLU.DCOLCLUS _LDCOCLU _DCOLVOL.DCOLVOLS _LDCOVOL _DCOLMIG.DCOLMIGS _LDCOMIG _DCOLBKP.DCOLBKUP _LDCOBKP _DCOLCPD.DCOLCAPD _LDCOCPD _DCOLCPT.DCOLCAPT _LDCOCPT _MONDBDS.MONIDBDS _LMONDBD _MONHIST.MONIHIST _LMONHIS _MONMRO .MONIMRO _LMONMRO _MONSYST.MONISYST _LMONSYS _MONTASK.MONITASK _LMONTSK _MONUSER.MONIUSER _LMONUSR _OPC20 .OPC20 _LOPC20 _OPC23 .OPC23 _LOPC23 _OPC24A .OPC24D_A _LOPC24A _OPC24B .OPC24D_B _LOPC24B _OPC24C .OPC24D_C _LOPC24C _OPC24D .OPC24D_D _LOPC24D _OPC24E .OPC24D_E _LOPC24E _OPC24F .OPC24D_F _LOPC24F _OPC24G .OPC24D_G _LOPC24G _OPC241 .OPC24_1 _LOPC241 _OPC242 .OPC24_25 _LOPC242 _OPC246 .OPC24_6 _LOPC246 _OPC247 .OPC24_78 _LOPC247 _OPC25 .OPC25 _LOPC25 _OPC26 .OPC26 _LOPC26 _OPC27 .OPC27 _LOPC27 _OPC28 .OPC28 _LOPC28 _OPC29 .OPC29 _LOPC29 _OPC30 .OPC30 _LOPC30 _OPC31 .OPC31 _LOPC31 _OPC32 .OPC32 _LOPC32 _OPC33 .OPC33 _LOPC33 _PDSMDD .TYPEPDSM _LTYPDSM _TPXINT .TPXINTRV _LTPXINT
For each MXG dataset, an "_L" ("Library") macro and an "_K" (Keep) macro is now defined in the product's IMAC. For example, these IBM Type 0 SMF record product's macros are now defined in member IMAC0:
MACRO _KTY0 % The naming convention for the "_L" and "_K" macros use the same suffix as the dataset's "EX" (Exit macro). The "EX" members names have one of these forms:EXTYnnnn, EXTYaaaa, EXTYxxyy, EXxxxyyy or EXxxyyyy, where xx/xxx is the product acronym and yyy/yyyy is the suffix for the specific dataset. For example, EXCICTRN is the exit member name for the CICS product CICSTRAN dataset, and thus "_LCICTRN" and "_KCICTRN" are the new macros. The "_L" macro lets you change the DDNAME to which each dataset is written (for example, you can send a dataset to a tape, or to a different DASD volume, which can help with large volume datasets). This is the primary function of the "_L" (Library) macro architecture. Note that in the "_LTY0" default definition, only the dataset name is defined, so the default DDNAME of WORK is used. Changing the definition to MACRO _LTY0 XYZ.TYPE0 % would cause that dataset to be written to the XYZ DDname.
implementation. It is located after the KEEP= list of MXG variables to be kept, and is inside the parenthesis that can contain dataset options, and so it can be used to specify dataset options like DROP= BLKSIZE= and COMPRESS=!
using the macros defined in VMAC0 (for the TYPE0 dataset). The original implementation for dataset TYPE0 was this: MACRO _VAR0 TYPE0 (KEEP=VAR1 VAR2 ... VARn) % MACRO _CDE0 IF ID=0 THEN DO; INPUT .... @; %INCLUDE SOURCLIB(EXTY0); ===> OUTPUT TYPE0; END;
% The new "_L" and "_K" implementation now looks like this: %INCLUDE SOURCLIB(IMAC0); MACRO _VAR0 _LTY0 (KEEP=VAR1 VAR2 ... VARn _KTY0) % MACRO _CDE0 IF ID=0 THEN DO; INPUT .... @; %INCLUDE SOURCLIB(EXTY0); ===> OUTPUT _LTY0; END;
% Examples: a. The _KTY0 macro can be used to DROP unwanted variables. Simply define it as MACRO _KTY0 DROP= VAR2 % and the unwanted variables will be dropped. (It turns out that if a KEEP= and a DROP= option are used for the same dataset, that the DROP= list overrides the KEEP= list!)
MACRO _KTY0 COMPRESS=YES % will compress the TYPE0 dataset. c. You can create new variables (in the Exit member, or in the case of CICS user data, in IMACICUS) and add them to the dataset, and drop other variables at the same time:
MACRO _KTY0 MYVAR1 MYVAR2 DROP= VAR2 % will cause the TYPE0 dataset to contain your new variables and drop old variable VAR2. The earlier implementation of IMACKEEP did permit override of dataset name and the keep list, but it required copying the entire _VAR macro definition into IMACKEEP, and this exposed your site to errors any time a new dataset was added to that product. The new implementation isolates your tailoring to the specific dataset, and addition of new datasets will be transparent to your tailoring.
Change 10.174 The DB2 optimizer's cost estimate, QW0022OS, is input as ADOC102 RB4. (floating point), not the $CHAR4 input format (that VMAC102 was printed as $HEX8.). Now, QW0022OS is a numeric field Sep 22, 1992 instead of character, and contains the cost estimate. Thanks to Frank Ingrassia, IMS Software, USA. Change 10.173 SAS 6.07 option FMTSEARCH=(DD1 DD2 DD3), which supports IMACFMTS concatenation of format libraries, has eliminated the need Sep 22, 1992 for this SAS 6.06 circumvention. The member was kept for compatibility, but is unlikely to be needed now. Change 10.172 Warning "Variable FVOLSER uninitialized" eliminated by TYPETMS5 removing the incorrect reference to FVOLSER in DSNBREC Sep 21, 1992 processing. This was only a cosmetic warning.
VMXGVTOC freespace extent reported (except for the first VOLSER). VMXGVTOF MXG logic was only checking the first volume. This change Sep 21, 1992 restructured several lines of logic, thanks, Chris. The Oct 18, 1992 VMXGVTOC changes were incomplete in the Early MXG 10.2 and were corrected in the PreRelease MXG 10.2 Thanks to Hank Boonstra, GASUNIE NV, THE NETHERLANDS. Thanks to Chris Weston, SAS Institute Europe, GERMANY. Change 10.170 DB2 Trace record IFCID=172 (Deadlock, identifies all of VMAC102 the units-of-work involved in the deadlock, resources they Sep 17, 1992 were contending for, and attributes of their requests) and IFCID=177 (Package Allocation) have now been coded/tested. The only remaining IFCIDs that are not coded are 126-129, 180-182, 186, and 190-195, because none of these subtypes have yet been created in numerous traces. If you observe one of these subtypes, please fax a hex dump of the record so these final DB2 trace IFCIDs can be supported. Thanks to Gary Smith, Southern California Edison, USA. Thanks to Frank Ingrassia, IMS Software, USA.
GRAFDB2 execute; GRAFTRND should have been GRAFDB2, and the ending Sep 17, 1992 parenthesis and final semi-colon were missing. This error was only in the example in comments; there was no error in GRAFDB2 itself. Thanks to Raymond Zieverink, Belk Stores Services, USA. Change 10.168 Support for VSE DOS POWER Version 4.2 accounting records IMACDOS has been found to require only setting OFFSET=24 and INPUT Sep 17, 1992 @67 RECID in the Installation tailoring MACro, IMACDOS. Thanks to Alan Smith, Health and Welfare Data Center, Calif., USA. Change 10.167 IBM APAR OY49717 adds text to SMF type 37 records for the VMAC37 Network Alert Report and the Self Defining Text Message Sep 8, 1992 Report. While there may be multiple Network Alert Report text segments, in this implementation, only the first is kept; these are 200 byte variables, and I don't want to greatly enlarge the size of TYPE37 until a real user tells me this new data is actually useful! If you use the TYPE37 and if it uses enough DASD space to be a problem justifying a re-design (i.e., creating multiple datasets with restricted sets of variables instead of just the one TYPE37 with all possible variables) please let me know and give me your thoughts. Change 10.166 The _LTRccmm macros names were changed to _XTRccmm names READDB2 so as to not conflict with the new _L and _K dataset macro VMAC102 names. (This should have no impact; _XTRccmm macros are Sep 7, 1992 internal lists and are not normally modified by users.) Change 10.165 Support for XCOM 6.2 Version 2.2.2G SMF record. ADOCXCOM Dataset XCOMDATA describes (extensively!) file transfer EXTYXCOM activity, timestamps, and file attributes and sizes for IMACXCOM files transferred by XCOM. Additionally, Neil Colombage TYPEXCOM provided extensive notes about meanings of many variables VMACXCOM that are now found in member ADOCXCOM. Sep 6, 1992 Thanks to Sam Sheinfeld, Kraft General Foods, USA. Thanks to Neil Colombage, British Airways, ENGLAND.
EXCICSAP The SAP product provides the "STCDUMMY SAP Statistics" in IMACCICS either a journal format file (which can be read with MXG's IMACICSA TYPE110J member), or an SMF format type 110 record (as a VMAC110 journal subtype, which can now be read by TYPE110/BUILDPDB VMAC110M members). The CICSSAP dataset will contain observations Sep 6, 1992 automatically if the "user journal type-id" JCRUTRID='SA', so you need only to find out whether the SAP STCDUMMY data was sent to a Journal or to SMF. A SAP "event" can have several CICS transactions, and may last beyond the end of the last CICS event, so SAP's creation of this additional transaction information appears to be a very intelligent architecture to help us measure both CICS and SAP! Member IMACICSA contains the logic to decode their journal segment, but you should not have to do anything to that member; it was externalized only for ease of maintenance. The internal logic of VMAC110 was restructured to process journal segments and to specifically recognize the SAP journal-id. (The logic of VMAC110 is now documented schematically in ADOC110 for those interested.) Thanks to Danilo Gipponi, SAS Institute, ITALY. Thanks to Mr. Eude, Didier Werke AG, GERMANY Thanks to Mr. G. Guarnaschelli, Hoechet Italia, ITALY.
VMACVMXA monitor records first discussed in Change 8.004. The fix Sep 5, 1992 then was to modify VMACVMXA to add " INPUT +4 @; " before the actual input statement, but line numbers have changed, and now the change has been externalized. A new macro in VMACVMXA is now defined, _VCANFIX, with null value (blank) but which is located so that you can process Candle data by the following override in your program: %INCLUDE SOURCLIB(VMACVMXA); MACRO _VCANFIX INPUT +4 @; % _VMTEST since the resultant program will skip over the unwanted, additional record length field. (Note that _VCANFIX was located immediately prior to the INPUT MRHDRDM statement following MACRO _VMINPUT, as suggested in 8.004). Thanks to Phil Henninge, Timken Company, USA. Change 10.162 Support for FACOM PDLF Type 127 SMF record for MSP/EX is VMACF127 provided by this significant user contribution. Many new Sep 5, 1992 variables were added to the TYPEF27D (device statistics, including VOLSER, and pending, connect and disconnect times), the TYPE27S (CPU statistics, including virtual pages in the CSA,PLPA, and NUC above and below the line), and the TYPE27S and TYPE27P (performance Group statistics) both now support eight-CPU-engine statistics. These data bring FACOM up to rough equivalence to MVS/XA in terms of the "RMF-like" PDLF data capture. Thanks to Joan Dobbie, Attorney-General's Office, S.A., AUSTRALIA.
EXAIM6R added. Version 12 incompatibly changed the record, and FORMATS there is no record version indicator, so a new Flag AIMVER IMACFACO was added to IMACFACO to identify which version of AIM MXG VMACAIM6 is to process. Two formats were added and new AIM dataset Sep 5, 1992 AIM116_R is created. The changes were extensive, but the documentation was unclear as to the relationship between the task information sections and the deadlock resource information sections; these MXG assumptions were made:
deadlock-related *resource* information section". - use the pointers to the deadlock resource info sections that were in each task info section rather than the Yüklə 28,67 Mb. Dostları ilə paylaş:
|