* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
UDB2GTF events from the multiplicity of 280-byte spanned segments VMACDB2 in which DB2 data is chunked when sent to GTF. VMACSMF That's the reason why DB2 trace data should be written Jul 11, 1996 to SMF rather than to GTF. When you write to GTF, DB2 must stop and do a physical write to GTF for each 280 bytes of trace data! When trace data is sent to SMF, it is in chunks of 32756 bytes and is done at CPU speed with a Move Character Long from DB2's ASID to SMF's ASID without any physical write delay for DB2. The new MXG utility, UDB2GTF is written in SAS, not REXX, and correctly reads the raw GTF trace data written by DB2 to reconstruct the spanned segments into valid events, but its output is still in GTF format, so you must use TYPEDB2G instead of TYPEDB2, or TYPE102G instead of TYPE102, or you must specify INFILE=GTF with %READDB2, or with %ANALDB2R you must specify PDB=GTF to read the data. But not only was REXXDB2 wrong; the MXG members VMACSMF and VMACDB2 had to be corrected as well. REXXDB2 did reconstruct many DB2 GTF events, but it did not handle all records correctly, and it created invalid records for incomplete DB2 events (when the last segment was not written because trace was restarted). Thanks to G. Bockting, KLM Royal Dutch Airlines, THE NETHERLANDS.
EXIMFTRX support for large IMS transaction volumes creates new IMACCIMS macros _LIMFTRX, _LIMFSRT and _LIMFCHA which can be set TYPECIMS in member IMACCIMS to write temporary copies of IMS data VMXGTAPE to tape during the "CHAINED" part of TYPECIMS logic. In Jul 7, 1996 addition, exit EXIMFTRN was relocated to the final phase of TYPECIMS logic, so you have complete control of the contents of the final CIMSTRAN dataset. (New exit EXIMFTRX for new temporary CIMSTEMP, built in first phase from IMS log, added, but not likely needed.) Comments in IMACCIMS describe how to use temporary tape datasets. Lots of work under the cover in this enhancement. New VMXGTAPE macro created to determine if a dataset name or a libname is on tape. For DASD temporary space, PROC DELETEs must be used to minimize the space required, but PROC DELETEs added for DASD will fail (with ERROR!) when DD points to tape, as SAS does not support Deletion of a tape dataset. This required %MACROs be created and used to decide if the DD name you chose in IMACCIMS points to tape or DASD, and then to conditionally execute PROC DELETE only if DASD. Not too hard, but sure cluttered the code in TYPECIMS! For TAPE temporary spaces, we want to reuse the tape to minimize the number of tape drives to three, but then the dataset name used for the reuse MUST be the same as the first dataset on that tape (if not, SAS would read past that first dataset on tape and only begin writing the reuse dataset after the first dataset, which could cause multi-volume tape when not required. Thanks to Wolfgang Vierling, Vereinte Versicherung, GERMANY. Change 14.152 Support for RMF Type 74 Subtype 5 Cache RMF Reporter CRR BUILDPDB record. This new subtype 5 record replaces the user SMF BUILDPD3 record created by IBM's CRR product. MXG created the BUILD003 CACHE90 dataset from the user SMF record; this support EXTY74CA creates new dataset TYPE74CA, but the variables in that FORMATS new dataset are identical to the old CACHE90 dataset, so IMAC74 you will need only to change references to CACHE90 to VMAC74 TYPE74CA in your CRR report programs. Jul 2, 1996 The subtype 5 record is standard in OS/390 Release 2 and is retrofit in MVS/ESA 5.2.2 by APAR OW18886, in 5.1 by APAR OW19337, and in 4.3 by APAR OW19938. Dataset TYPE74CA is automatically created in your PDB library by MXG's BUILDPDB/BUILDPD3 programs. I considered using CACHE90 as the dataset name in this new support, but any site that had already added CACHE90 to their BUILDPDB would ABEND with this new MXG version, as there would then be two instances of CACHE90, one from VMACACHE and one from VMAC74. 'Tis better for BUILDPDB to run and only have to change your reports than vice versa! Additionally, you may have CRR running on some systems, while you only have the TYPE74CA on some systems, so by using a different name you can process both records. And, there are a few new variables created in TYPE74CA. Thanks to Brian Currah, Performance Associates, USA.
VMAC74 and should have been formatted $HEX2. Jul 2, 1996 Thanks to Mr. Leineweber, Huels AG, GERMANY Change 14.150 Support for DFSORT Release 13 APAR PN71337 (Compatibly) VMAC16 added new variable ICEDSA (Size of DSA in effect) using Jun 29, 1996 an existing reserved field. This APAR also increases the maximum number of SORTWORKs from 32 to 100, but that has no impact on the MXG support.
VMAC57 I discovered that variable NJENJJID had been added to the Jun 29, 1996 JES3 type 57 record; that variable is now created.
ASMIMSLG the 16MB line; increasing the SLOTS after the //CONTROL ASMIMSL5 DD statement avoided expansion, but still abended. The Jun 27, 1996 solution is to move the SLOTS table above the 16MB line (so the GETMAIN is not constrained by your private area). Before the MXGIMSLG CSECT statement, insert (starting in column one): MXGIMSLG AMODE 31 MXGIMSLG RMODE 24 In the GETMAIN statement located 25 lines after the label GETQUEUE, change LOC=RES to LOC=ANY. Thanks to Grant Thomson, Elf Enterprise, ENGLAND. Change 14.147 All MXG JCL examples now specify REGION=0M to allow SAS JCLall to use all virtual storage it needs. See SAS Technical Jun 27, 1996 Note VI.4 in Newsletter THIRTY for discussion. Thanks to Jeff Balch, General Electric Capital Corporation, USA. Change 14.146 All packed decimal fields in IBM's DFSMSrmm records are VMACEDGS now protected with the ?? modifier (to supress error msg Jun 26, 1996 when the record contains nulls for PD fields), and all timestamps set with DHMS() function are now set missing (instead of zero) when they don't exist. The logic for the security record was incorrect and was revised. This change is still open while investigating further recommendations from this "codeshark". Thanks to Willi Weinberger, IDG Informationsvararbeitung, GERMANY.
VMXGSUM the SAS log when VMXGSUM's KEEPALL=NO default option does Jun 26, 1996 its thing (see MXG Technical Notes in Newsletter 30). This change inserted OPTIONS NONOTES; and then OPTIONS NOTES before and after the parsing logic to prevent the printing of these notes on your SAS log. Thanks to Chuck Hopf, MBNA, USA.
EXXSTARB Two datasets are created: EXXSTARO XSTARBAT - Batch Session Printing IMACXSTR XSTARDSN - Batch Session sent to a dataset TYPEXSTR XSTARONL - Online Session VMACXSTR
Jun 26, 1996 Change 14.143 Support for EOS - Enterprise Output Solution for MVS is VMACWSF already contained in MXG under its old acrynym, WSF. The Jun 26, 1996 vendor is RSD - Roger Software Development, Geneva. Thanks to Tim Crocker, ALLTEL Information Services, USA. Change 14.142 CICS Statistics datasets did not contain SMFPSRVR (CICS VMAC110 Version) nor MCTMNTAD (GMT offset), although both were Jun 26, 1996 added to CICSTRAN and CICSEXCE in MXG 13.13. Now, both variables were added to the _CISTCMN macro so that they will now exist in all CICS datasets. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 14.141 The _LHSMxxx macros (which can be used to change the data DIFFHSM Library in which HSM datasets are stored) were not used Jun 26, 1996 in the data steps after the PROC SORTs, so you could not use the IMACHSM to set the location of HSM datasets. The syntax now uses _LHSMxxx macro names throughout. Thanks to Trevor Holland, Bank of Melbourne, AUSTRALIA. Change 14.140 MXGSAS, the JCL Procedure to execute MXG jobs, has been JCLADHOC enhanced with the new TAILORNG= symbolic parameter that MXGSAS allows you to use your own PDS as the first dataset in Jun 25, 1996 the //SOURCLIB concatenation. This new parameter is then used in the new JCLADHOC example, which shows how you can use IEBPUDTE to put your SAS tailoring statements into a temporary PDS (so you don't have to EDIT a real PDS tailoring library) for an ad hoc analysis. Also, you end up with the JCL and SAS code in one single member so you can go back and remember what you did in one place! Thanks to Debbie Gould, Acxiom, USA.
VMAC76 INTRVAVG in TYPE76 dataset. The second equation now is: Jun 24, 1996 IF NRSETS*SAMP_SET GT 0 THEN INTRVAVG=INTRVSUM/(...); Thanks to Bruce Widlund, Merrill Consultants, USA. Change 14.138 DB2 Trace records containing SQL text were inconsistent. VMAC102 IFCID 63 created all of the text in multiple observations Jun 26, 1996 with 200-byte variable (which is unprintable because SAS PROC PRINT truncates instead of wrapping), and IFCIDS 124 140, 141, 142, 145, and 168 kept only the first 200 bytes of SQL statements. Since SQL text has no limit (after all, it is a "program"), I decided to change the length of T102S063's existing 200-byte variable to 100 bytes per observation, and have created six new datasets for the other IFCIDS that contain the SQL text in 100-byte chunks (and the common variables). New datasets T102T124, T102T140, T102T141, T102T142, T102T145 and T102T168 are created, with the 2nd "T" in the dataset name being the indicator that this dataset is for the SQL text. The segment number is in SEGSQLTX and the actual bytes of text in the 100-byte character variable is in the variable LENSQLTX. The first 100 bytes of text are still output in T102Snnn for compatibility. A later change to ANALDB2R will be required to be print all of the SQL text in the Audit Reports, but with this change at least you can PROC PRINT to get all of the SQL statements. Thanks to Mike Majors, Residential Services Corp of America, USA. Change 14.137 Code which was never executed was deleted. The DO group VMAC116 IF QWHCTOKN EQ '0000 ... 00'X was never executed, as the VMACDB2H length of QWHCTOKN is 22, but the hex string was only 16, Jun 24, 1996 and even if it had been executed, it only stored hex zero where hex zero had already been initialized, so that DO group was deleted and the subsequent ELSE DO; and END; statements were deleted around NETSNAME creation. Thanks to Herb Strazinski, Burlington Northern Railroad Co., USA Change 14.136 Variable ZDATE is inadvertently changed to a character TYPEIMSA variable with value 'ZEE OBS...' because the semi-colon Jun 21, 1996 after TRANCLAS='TRANSACTION*CLASS'; must be removed. Thanks to Mr. Lucca, Wiener Staedtische Versicherung, GERMANY Change 14.135 Landmark TMON/MVS spanned records are now valid and can FORMATS be read with MXG. Prior to TMVS 1.3, the spanned records VMACTMVS were invalid, and MXG had no choice but to skip over them Jun 20, 1996 (and print a note on the log that records were skipped). As promised, TMVS 1.3 now writes legitimate records that can be read with TYPETMVS. The only change required is to delete the entire 18 lines of the DO group: IF LMRKFLG1 NE '..00....'B THEN DO; /*SPANNED .... */ --- 16 lines --- END;
Also, format $MGTMVGF now decodes additional bit values (that deal with record structure, and probably no one but me ever need to know!). I also discovered that it and several other formats had been overlooked when the syntax of OTHER=(! $HEX2. !) was changed to OTHER=?< $HEX2. ?> by Change 13.319. Now, all OTHER= are consistent. Thanks to Wim Desmecht, DOLMEN Computer Applications MV/SA, BELGIUM.
ADOCMWUX replaces the HP PCS product. The MXG support for MWA ASUMMWUX is contained in new members with the MWUX suffix instead IMACMWUX of HPUX, so you will have to change to use TYPEMWUX vice TYPEMWUX TYPEHPUX, but the MXG datasets created by MWA are named VMACMWUX the same as their PCS counterparts, and variable names EXHPUXTT were preserved (except for dropped variables), so your Jun 17, 1996 existing PCS report programs should function without error against the MWA-built MXG datasets. The data records read by MXG are completely controlled by the syntax of the HP REPORT command that extracted the data. You must compare the REPORT command syntax in the ADOCMWUX member with your REPORT command (or use the one in ADOCMWUX to generate your data!). If your data was extracted with a different REPORT syntax, then you must change member VMACMWUX as described in ADOCMWUX. The delimiter between HP fields is set in member IMACMWUX. One new dataset, HPUXTRAN, transaction tracker metrics, is created by MWA that did not exist in PCS, hence the new EXHPUXTT exit. Note that the same exit members are used for both PCS and MWA to output the same MXG dataset names! Support for SUN and AIX platforms will be coded when there is a user in need of that support. Thanks to Alfred Holtz, Medco Data Corporation, USA. Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM.
ADOC30 CPUTM between interval and step records was also put in Jun 15, 1996 ADOC30, and related variables descriptions were revised. Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Thanks to Harmuth Beckmann, Karstadt, AG, Germany
CICINTRV i.e., the enhancements described in Change 13.281 are now CICINTRZ the MXG default (and the old CICINTRV is now CICINTRZ). Jun 13, 1996 With this change, only the CICINTRV dataset is built; the CICEODRV CICREQRV CICRRTRV & CICUSSRV datasets are no longer created. The new logic does not impact execution resources: CPU only went up 20 seconds (with a total CPU time of 11min 39sec for both TYPE110 and CICINTRV with 2132MB of SMF data) and WORK disk space only went up by 13 Cylinders (10MB). The increase in virtual storage was only 600K, up to 15204K, but this is still much less than BUILDPDB requires, so this new CICINTRV won't cause your BUILDPDB to die with an 80A ABEND!). A CICS Technical note on the CICINTRV enhancements will soon be written. See Change 14.188 which reverses this. Thanks to Chuck Hopf, MBNA, USA. Change 14.131 Support for APAR PN78083 required no change to MXG. The VMAC42 APAR redefine's PRODLVL's 2 bytes as two 1 byte fields Jun 12, 1996 Product Level, Product Sublevel), but PRODLVL is not even a kept variable, and if it is ever needed in the future, its two bytes can always be individually tested.
TRNDTALO to this member to protect when ALOCSTRT or ALOCEND are Jun 11, 1996 missing. The IF statement in the first data step needs: OR ALOCSTRT=. OR ALOCEND=. to be added, i.e., make TRNDTALO look like ASUMTALO. Thanks to David Childress, Lowe's Companies, Inc. Change 14.129 Support for IMS 5.1 APAR PN76410 extended prefix segment. ASMIMSL5 With this APAR, LOGONID variable in IMSTRAN is missing. Jun 9, 1996 To correct, change ASMIMSL5 after label P001000M to make the code look like this: P001000M DS 0H old CLI 2(R4),X'84' IS THIS THE LU6 SEGMENT old BNE P001000N BRANCH IF NOT (was BNE DROPMAP) LA R4,MSGLU6ND(R4) BUMP PAST THE SEGMENT old B P001000K BRANCH TO TEST FOR RACF old P001000N DS 0H SUPPORT FOR PN76410 new CLI 2(R4),X'86' IS THIS THE EXT PFX SEGMENT new BNE DROPMAP BRANCH IF NOT new USING MSGEPHDR,R4 new TM MSGEPFL1,MSGESEC IMBEDDED SECURITY SEGMENT? new BZ DROPMAP BRANCH IF NOT new LH R2,MSGEPTL LNGTH OF ALL EMBEDDED SEGS new AR R2,R4 END OF EXTENDED SEGMENT new P001000P LH R1,0(R4) LENGTH OF THIS SEGMENT new AR R4,R1 NEXT SEGMENT new CR R4,R2 HAVE WE REACHED END ? new BNL DROPMAP BRANCH IF YES new CLI 2(R4),X'88' SECURITY SEGMENT? new BNE P001000P BRANCH IF NOT new DROP R4 new USING MSGSEC,R4 new MVC LOGONID,MSGRACUS MOVE IN THE LOGONID new MVC ORGENT(8),MSGSAFNM MOVE IN ORGENT/INCONT new DROP R4 new B DROPMAP new EJECT old Thanks to Grant Thomson, Elf Enterprise Caledonia Limited, SCOTLAND.
VMACITRF (unique sort key) to all ITRF datasets, and SAPTRN (SAP Jun 9, 1996 internal transaction code) to ITRFMSG dataset. See IMS Technical Notes for additional ITRF experience. Change 14.127 Two datasets in ZRBPDB but not in WORK were not found ZRBBATCH because they did not have the &LIBNAME.. reference in the ZRBRPT1-3 ZRBBATCH program. ZRBRPT1-3 had JCL removed and &LIBNAME Jun 9, 1996 added so as to be consistent with other ZRB members. Thanks to Jay Beeler, Key Services, USA.
ANALDB2R for each Remote Destination, removing references to the Jun 9, 1996 QLSTLOCN variable in DB2STATS, now using DB2STATR.
VMACDMON with eight bytes in the VOL record segment, and created Jun 9, 1996 new variables: Dataset Variable Label DMONVOL RVLVG DMONVOL,DSN,JOB RCDTME CACHE*TIME*SAVINGS DMONVOL,DSN,JOB RMLDMOBJ DSN's*DEMOTION*TIME*OBJTV DMONVOL,DSN,JOB RSCLSFLG SMS*CLASS*FLAG DMONVOL,DSN,JOB LOGICAL*VOLUME*GROUP*NAME Thanks to Chuck Hopf, MBNA, USA. Change 14.124 Change 12.099 was not correct in leap years (like 1996!), VMACDCOL but the impact was minimal. Three EXPDT variables (HSM's VMXGHSM MCDEXPDT and DCOLLECT's DCDEXPDT and UMEXPDT) were set Jun 9, 1996 to MXG "infinite" year of 2099 for a valid leap year date Jun 18, 1996 of 96366 instead of the correct date. MXG uses this "infinite" date for EXPDTs that are not valid Julian dates (like 99999, 99366, and also for the special date of 99365) that are used by tape management systems, but Change 12.099 incorrectly set any xx366 date as infinite. Change the occurrences in VMACDCOL and in VMXGHSM from OR DAYEXPDT GE 366 to OR DAYEXPDT GT 366. Additionally, the default date in VMACDCOL was changed to '31DEC2099'D (from '01JAN2099'D) just to be consistent. This text was revised when I discovered that 2000 is indeed a leap year, but the code change supports all leap years, including 2000. Thanks to Marc Vanden Bergh, Gemeentekrediet, Belgium.
IMACICOC time for SUPRA and DATACOM) were off by a factor of 16. Jun 9, 1996 Insert OMSUPRTM=16*OMSUPRTM; OMDCOMTM=16*OMDCOMTM; after the existing statement OMADABTM=16*OMADABTM; Thanks to Michel Antoons, 3M, BELGIUM.
VMAC7072 should have been input as &RB.8. (causing RESPSTD to be Jun 7, 1996 wrong). Variable AVGELPTM in TYPE7204 dataset was also INPUT as &RB.8.6, but is now INPUT as &RB.8. and then converted with *1024/(1E6) like the other elapsed times. That these errors have been undetected for so long shows how infrequently they are needed. Thanks to Bruce Widlund, Merrill Consultants, USA. Change 14.121 Variable PCTALLBY was not calculated for TYPE78CU dataset ANALRMFR but now is, and new variable LCUIORT in TYPE78CU contains VMAC78 the aggregate I/O rate for all CHPIDs in that LCU. Jun 5, 1996 In validating this change, I discovered that TYPE78CF Jun 7, 1996 variables OFFLINE and ONLINE are interpreted by IBM as: OFFLINE ONLINE IBM Report Explanation Y Y PATH OFFLINE Y OFFLINE OFFLINE Y ONLINE
ANALRMFR REPORT=CHAN report now prints LCUIORT, which is not printed by the equivalent IBM report but is useful! Thanks to Alan Sherkow, IS Management Strategies LTD, USA.
VMACUCB devices, but commenting out IF DEVNR='1...... 'B ..., Jun 5, 1996 but the subsequent line should be changed from ELSE IF to IF (DEVNR=0FFFx AND NOT .... Thanks to Peter Durant, National Australia Bank, AUSTRALIA.
VMAC110S had two typos: variable JCTUTRID should be JCRUTRID and Jun 5, 1996 SAPTEST='SA' /*$$$*SAP*/ needed a semicolon. Thanks to Santamaria Antonio, Agip Petroli, ITALY. Thanks to Mark Cohen, SAS Institute, ITALY.
VMAC37 text string BRFDATTX, but some operators type up to the Jun 1, 1996 maximum of 275 bytes, so the logic of the decoding of the SELD sections's text into BRFTEXT and BRFTEXTA was used in the DETT section to create BRFDATTX and new BRFDATTA. Replace the 7 lines in the DETT section starting with SKIP200=BRFDATLN-200; with the 14 lines from the SELD section starting with IF LENSELD GE 275 THEN INPUT BRFTEXT $EBCDIC200. and then change SELD to DETT (4 occurrences) and change BRFTEXTA to BRFDATTA (6) and then BRFTEXT to BRFDATTX (7) in those 14 lines in the DETT section. Finally, add new variable BRFDATTA to the KEEP= and LABEL statements. Thanks to Tony Sandora, CIGNA, USA. Change 14.117 MSOUNITS was increased from 4 to 5 bytes by Change 14.076 BUILDPDB only in VMAC30, but datasets JOBS SPUNJOBS STEPS TRND72 & BUILD005 TYPE434 still were stored in only 4 bytes. The impact is BUIL3005 mathematically minimal, with at most a loss of 255 units TRND72 with 10-digit values of MSOUNITS VMAC434 and values that large strongly suggest you should fix Yüklə 28,67 Mb. Dostları ilə paylaş:
|