* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
you normally allocate in your BUILDPDB.
daily, you will also need to add code to EXPDBWEK (or modifying WEEKBLD) to create the WEEK.ASUMDB2A dataset in your weekly PDB from dailies. ASUMDB2 would have been automatically included in MXG's BUILDPDB except for the possible problem with work space cited above. The dataset should prove to significantly reduce the cost of ANALDB2R reporting. Change 10.089 %VMXGSUM is enhanced to provide two new macro parameters VMXGSUM MINTIME= and MAXTIME= that name the datetime variable Jun 12, 1992 that will be used in building the minimum and maximum datetimestamp values in each summary record. (Because timestamps require LENGTH 8, and all SUM= MIN= MAX= or MEAN= have a length of 4), new parameter names were necessary. Variables MINTIME and MAXTIME are created in the output dataset created by %VMXGSUM. Change 10.088 BUILDPDB/3 redundant SORTs of DB2STAT0 and DB2STAT1 were BUILDPDB removed because SORTs were relocated into DIFFDB2. Some BUILDPD3 superfluous OPTIONS were removed from DIFFDB2. READDB2 DIFFDB2 standalone execution that unintentionally always sent the READDB2 output to the PDB DDname was also corrected. Jun 12, 1992 Change 10.087 Product Documentation "ADOC...." members have been added. ADOCAAAA Twenty-five "Products" are now documented in the style of Jun 12, 1992 future MXG online documentation, although none of the ADOC members are completely finished, and the text is still in draft (no spell check, no grammar check, author's "zzzzz" mark where there's more to be written). Nevertheless, the detail description of the MXG variables and datasets built from each "Product" are now consolidated into an ADOC per VMAC and the technical descriptions are now current. As additional ADOCs are completed, they are added to the next MXG PreRelease. Comments, criticism, and suggestions for this ongoing project are welcome. Change 10.086 Trending of Printer Throughput could cause divide by zero TRNDPRTR message (but no impact on the Trend Database). Zerodivide Jun 12, 1992 protect lines 002200 and 002300 (by adding the IF test): IF denominator GT 0 THEN XXX = YYY / denominator ; Thanks to Dan Barbatti, Southwestern Bell Telephone, St. Louis, USA.
ANALDSET of IMAC30DD in &SOURCLIB, and if the MXG.SOURCLIB member Jun 12, 1992 IMAC30DD had been modified, a 311 error occurred. A new line XY ADD NAME=IMAC30DD was added to the IEBUPDTE. Thanks to Mike Crane, Annheiser Busch, USA.
ASMIMSLG a significant contribution to MXG processing of IMS log JCLIMSLG records. MXG's algorithms have tried to recognize an IMS TYPEIMSA transaction after the fact from log records that do not TYPEIMSB have a consistent token. Pete and Jeffrey's work solved VMACIMSA that major weakness of the IBM IMS log records by creating Jun 11, 1992 a pre-processor Assembly program that reads the IMS log records, acts like the IMS queue manager, adds transaction identifier to some of the log records, and even stores the status of the IMS queues to initialize the next run. The modified records are then SORTed and manipulated with a new SAS program, TYPEIMSB (that does not create SAS data sets, but instead manipulates IMS log records). The fourth and final step of the algorithm uses a modified version of MXG's TYPEIMS, (named TYPEIMSA for "Appended" IMS record processing) to combine the two sets of IMS log records into the _IMSTRAN.IMSTRAN MXG dataset.
10x and the 33x, that must be selected in your IMS archive log job. These are the IMS log records now required:
ASMIMSLG, the ASM source code and the JCL to assemble and link edit MXGIMSLG. Member ASMIMSLG also contains the documentation of the algorithms, and a schematic of the four steps of this "Appended IMS log" processing.
four-step job to build the _IMSTRAN.IMSTRAN dataset: STEP01 - Execute MXGIMSLG to read IMS log, split into two OS files, IMSSUM and IMSMPRS. In addition, reads INQUEUE (last run queue status) and then writes OUTQUE (for input to next run). STEP02 - SORT the IMSSUM file into IMSSUMSO. STEP03 - Execute TYPEIMSB SAS step to read IMSSUMSO and write out IMSMERGE OS file. STEP04 - Execute TYPEIMSA SAS step to read IMSMERGE and the IMSMPRS IMS log records to create IMSTRAN.
but the IMS log records can never be used for accurate IMS resource measurement by transaction, because IBM does not create a resource record per transaction. The IMS 07x record contains total CPU Time and DL/I calls per program schedule event, which can include many transactions. Thus IMSTRAN contains only the average CPU time and DL/I calls for each group of transactions reported in each 07x. Only a major change in IBM's functional design of the IMS log can provide accurate IMS measurement of both resources and responses of IMS transactions.
response measurement from IMS log records for sites that do not have an IMS transaction monitor product.
is not my intention to test or revise the algorithm for any earlier IMS versions. If any user lets me know that the algorithm has been validated with earlier IMS log records (by assembling MXGIMSLG using that version's macro libraries), we will so report here in this Change text. Thanks to Pete Shepard, Ashland Oil, USA, USA. Thanks to Jeffrey S. Crum, Ashland Oil, USA, USA. Change 10.083 Change 9.017 discussed how vars can be DROPped with a DOC DROP statement in an EXTY member, but did not stress that Jun 10, 1992 the DROP statement is global to ALL datasets being built; if a variable name is DROPped in an EXTY member, it is dropped from all other datasets with that variable name in that SAS DATA step, even if the variable name is in the KEEP= option of the DATA statement! The only way to drop a variable name from a specific MXG dataset is to copy the _VAR.... macro into member IMACKEEP and erase the variable name from the KEEP= list for the specific dataset. (Perhaps someday, I'll find a simpler way.)
Thanks to John Astle, National Australia Bank, AUSTRALIA. Change 10.082 For TMS tapes with multiple datasets per volume, or for TYPETMS5 datasets that span multiple volumes, the MERGE of their Jun 10, 1992 TMSREC (volume record, with 1st dataset information) with DSNBREC (dataset record for 2nd+ datasets on a volume) MXG overlaid some dataset-related TMSREC variables with their DSNBREC values requiring revision of the MERGE logic. More important: the calculation of TAPEFEET was changed. TAPEFEET of a dataset was calculated only if the RECFM was F/FB/VBS/VS, which have absolutely known record length. For V/VB/U files, MXG did not calculate a TAPEFEET, because record length was not guaranteed. I now think it better to always calculate the estimated TAPEFEET for all datasets, even though it may overestimate the feet used occasionally. Since the primary use of TAPEFEET is to identify tapes using "lots" or "few" feet (i.e., "good" vs "bad" tape usage), always calculating TAPEFEET will ensure that tapes with lots of data (i.e., large BLKCNTS) aren't misidentified as "few" because they have variable lengths. Jun 30, 1992 Note: After Newsletter TWENTY-TWO was sent to printer: Variable TAPEFEET now exists in both TMS.TMS and DSNBREC, and is calculated for all datasets. Not only was the code in TYPETMS5 redesigned, VMACTMS5 had to be changed. Now, VOLSER in DSNBREC is equated to FVOLSER for multi-volume files, because FVOLSER is the actual volume with this DSN, and VOLSER was the first volume of the multi-volume tape! (the original VOLSER in DSNBREC is now in OVOLSER). Thanks to Tom White, US.Sprint, USA.
VMACWSF accounting fields ACCX.... to the WSFACCT (for AREP, ERD, Jun 10, 1992 PROFILE, and WSF2 events) and to the WSFERD (for ERD Batch and WSF2 Batch). It appears the job accounting fields and jobname are those of the WSF2 Bundling job, and not the (desired!) users accounting information. Thanks to Diane Eppestine, Southwestern Bell, USA.
VMACHSM can be negative (for Small Data Set Packaging, SDSP, or Jun 9, 1992 for VSAM, but MXG input them as PIB2. instead of IB2. We are still asking IBM what it means to read negative tracks (or write them!)? IBM APAR OY58311/OY61585 fixed. Thanks to John Mattson, National Medical Enterprises, USA. Change 10.079 EPILOG/MVS support was wrong. MXG failed to subtract 3 VMACEPMV bytes from two offsets, and did not protect for zero value Jun 9, 1992 in triplets used in the two iterative DO groups. Before each of the statements "DO SM180Oxx=SM180Oxx TO ..." (where xx=IO or xx=EQ), insert the following two lines: SM180Oxx=SM180Oxx-3+OFFSMF; IF SM180Oxx GT 0 AND SM180Nxx GT 0 AND SM180Lxx GT 0 THEN to correctly calculate the offset, and to conditionally execute the (now following) iterative DO group only if all triplet fields (offset, length, and number) are non-zero. In addition, the RSRC subtype (SM180SUB='RSRC') record is now deleted; it caused INVALID DATA FOR SM180RID message, and "represents activity recorded by EPILOG that is not obtained from RMF's SMF records. The RSCS subtype is not documented further" according to Candle. Thanks to Wayne Parrino, Avery Dennison, USA. Change 10.078 Amdahl APAF product (Amdahl Processor Analysis Facility) VMACAPAF creates a user SMF record describing MDF resource usage by Jun 8, 1992 domain and LP within each domain that is now documented in Appendix B, APAF Record Layouts of Amdahl's manual). The preliminary variable names in MXG 9.9 were changed and now the MXG variable names are based on the Amdahl documented field names. Some previous fields are now reserved, and storage variables are now in bytes, formatted by MGBYTES. The number of LPs data kept is set in member IMACAPAF with MXG %macro variable __NRLPS (yes, that's two underscores) to only keep variables describing your environment, and MXG defaults to keep four partitions (LP0-LP3) by setting %LET __NRLPS=3;
ANALNPMR AVGOBYTE and AVGIBYTE were not protected for zero divide. Jun 8, 1992 Now they are. Thanks to Mike Jacques, Best Products, USA. Change 10.076 Preliminary support for UNIX iostat and vmstat command's XUNIX output data has been tested against ULTRIX data. The code Jun 8, 1992 is temporarily located in the "X-rated" member XUNIX until formal naming conventions for UNIX support have been decided. Thanks to Chuck Hopf, Primerica, USA. Change 10.075 Support for North Ridge Software's "The Network Director" EXNRS... SMF record creates thirteen NRS..... datasets that are IMACNRS described in the vendor's Network Administrators Guide, TYPENRS under the topic of "Event Recording", thanks for this VMACNRS significant user contribution, which included test data Jun 8, 1992 for validation! Thanks to Tom Jones, Banks of Iowa Computer Services, USA.
VMACTMS5 with create date of 91000 (found in volume that was shared Jun 5, 1992 between MVS and TPF). Now, MXG validates the julian date is valid before creating CREATIME. Thanks to Chuck Hopf, Primerica, USA.
ASMVTOC primarily by VM DASD volumes shared with MVS, which do not Jun 5, 1992 have a legitimate MVS VTOC. Now, these "bad" volumes are bypassed and no longer cause ASMVTOC to ABEND. Thanks to Wayne Beardsley, Citibank National Technology Div, USA.
VMAC102 not know that, and thus SQLCODE was input as PIB4, causing May 21, 1992 a return code of -204 to show up as 4,194,967,091! Change both occurrences of SQLCODE PIB4. to SQLCODE IB4. Thanks to Andrew Jeppeal, Marshalls, USA.
VMACVMXA if member TYPEVMXA is used to process MONWRITE output data May 19, 1992 because of a misspelling. Change _DSYTCUP in line 010060 (inside the _PRNTALL macro definition) to _PSYTCUP. The unintended invocation of _DSYTCPU (which deaccumulates the VXSYTCUP dataset) inside _PRNTALL after OBS=50 was set in TYPEVMXA caused the correctly built VXSYTCUP data set to be re-built incorrectly with only 49 observations. Thanks to Mark Kraut, Walgreens, USA.
VMACDCOL with an INVALID VALUE FOR FUNCTION DATEJUL message. May 19, 1992 Change DATEJUL(CALEXPDT) to DATEJUL(ORGEXPDT) in 2 places. In tests and calculation for DCDDATE1, DCDDATE3, UMCREDT, UMLRFDT and UCCOLDT, remove -1900000 from both the IF test and from inside the DATEJUL function. MXG converted dates to yyddd format, which only supported years thru the next millennium, but the SAS DATEJUL function supports date yyyyddd formats beyond the year 2155 (the maximum year in the present IBM calendar). In several labels, asterisks were omitted and MACINE should have been MACHINE, and two REBLK? variables are now spelled correctly. Thanks to Chuck Hopf, Primerica, USA.
VMACSPMS causing errors. Pending documentation of the new field, May 17, 1992 insert the following line after the @; after SPMSRVR3: IF SPMSLEN3 GE 32 THEN INPUT +4 @; (Note: In NL 22, SPMSRVR3 was misspelled as SMFPSRVR3). Thanks to Pino Todesco, Western Australia Police, AUSTRALIA. Change 10.068 Variable TAPE3490 (number of 3490 tape drives allocated) IMACPDB is now added to PDB.STEPS (drives per step) and PDB.JOBS May 17, 1992 (max drives in any step). Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA. Change 10.067 TMON/CICS dataset MONITASK variable CREATIME was used in ASUMCICS reports and summarization where STRTTIME should have been. TYPEMONI Both variables were correctly described in the MXG TYPEMON8 Supplement, but reports (See Change 10.066) and ASUMCICS May 17, 1992 now use STRTTIME variable instead of CREATIME. Both are still kept with equal values in MONITASK. Change 10.066 TMON/CICS reporting with ANALMONI can loop, filling WORK ANALMONI file, because STRTTIME from the interval dataset was used May 17, 1992 where instead of STRTTIME from the MONITASK dataset. The correction of CHANGE 10.067 corrects the problem. This change provided a circumvention to ANALMONI that is now no longer required after Change 10.067. Thanks to Peter Paproota, BMI N.Y. Operations, USA.
IMAC40DD in type 40 SMF record. The old TYPE40 dataset creates 1 VMAC40 observation per SMF record, but there can be many devices May 17, 1992 represented in a single dynamic deallocation event. MXG's analysis of tape drive utilization (work in progress) will need this new TYPE40_D dataset. New member IMAC40DD will control whether observations are created in TYPE40_D; by default, no observations are created, although comments in IMAC40DD shows how to create only tape drive events.
EXTY72 MXG 9.9 subtracted CPURCTTM from CPUTM in member EXTY72 to May 15, 1992 prevent negative overhead values until IBM fixed their error. Now, PTF UY77275 exists and does correct the CPU value, so MXG has now eliminated the subtraction in this Exit Member. If you install that PTF before MXG 10.1+, you need to tailor member EXTY72 from MXG 9.9 into your USERID and remove the subtraction, remembering to remove EXTY72 from your USERID.SOURCLIB when you install MXG 10.1+.
VMACCIMS were not correct if multiple bits were on in these flags, May 15, 1992 because MXG tested for the Hex value instead of the Bit value. Variables RGNIOPT,BHTOON,DEPRECN,CPUNONE,CPUDEP, BILLOVHD,TRNSYNC,BMPNO,DBIOWAIT, and DBIONONE could have been affected. Change the hex test to bit test to fix. Thanks to Mr. Steinkopf, Volksvagen Ag, GERMANY.
CICINTRV records is added. IBM changes were incompatible and MXG MECICALL 10.1 or later is required for CICS 3.3 statistics records. PRCICALL MXG now no longer creates eleven statistic datasets whose VMAC110 STIDs were eliminated by IBM in CICS 3.2.1 (they were all May 14, 1992 summary records that were redundant with detail STIDs). These datasets no longer exist and their Exit Members have been deleted from the MXG Source Library: STID Exit Member Dataset STID Exit Member Dataset 05 EXCICTST CICTST 53 EXCICCO2 CICCONST 26 EXCICLDT CICLDT 59 EXCICTC2 CICTCLT 35 EXCICTCT CICTCT 68 EXCICFCT CICFCT 38 EXCICLS2 CICLSRT 77 EXCICCO4 CICCONMT 41 EXCICLS4 CICLSRFT 82 EXCICBTA CICBTAM 44 EXCICDQT CICDQT Because four of the above datasets had previously been used in building the CICEODRV (shutdown statistics) and CICINTRV (interval) datasets, member CICINTRV was changed to summarize the detail data previously in CICDQT, CICFCT, CICTCT, and CICTST. Additionally, exit members now exist for the four datasets created by CICINTRV. The CICUSSRV dataset can be large, since it represents every dynamic resource, and you may wish to disable it in its exit. Dataset Description Exit Member CICEODRV - End-of-day "Shutdown" EXCICEOD CICINTRV - Interval Statistics EXCICINT CICREQRV - Requested Statistics EXCICREQ CICUSSRV - Unsolicited (Dynamic) EXCICUSS The order of the CICS statistics datasets was alphabetized as were the labels for their variables, and member VMAC110 was renumbered. Fields added by IBM to several statistics records are now supported. Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
VMAC110 record is added. Twelve new fields added to CICSTRAN are VMAC110M very useful, describing program and user storage, but the IMACEXCL fields were added incompatibly (they were inserted in the May 14, 1992 middle, rather than added at the end of the record) and thus MXG 10.1 or later IS REQUIRED for CICS 3.3 CICSTRAN. Member VMAC110M processes ONLY the monitor (and not the statistic) subtype, but it should be needed only by sites still using SAS Version 5 under MVS/370 where virtual storage constraints exist. The following table lists the MXG variables in CICSTRAN which capture transaction-level virtual storage usage: Virtual Program User User User Storage Storage Storage Storage Storage Area HiWaterMk HiWaterMk Getmain Occupancy Amount Amount Count Page-seconds Above 16MB:
EUDSA PC31UHWM STORHWMH SCGETCNH PAGESECH ERDSA PC31RHWM Total Above PC31AHWM Below 16MB: CDSA PC24CHWM SC24CHWM SCCGETCT SC24COCC UDSA PC24UHWM STORHWMK SCGETCN PAGESECS Total Below PC24BHWM
Total PROGSTOR Change 10.060 TMS inactive DSNBs are now deleted before merge with TMS VMACTMS5 records, because their existence created invalid results. May 13, 1992 A DSNB exists in TMS when multiple datasets are created on a VOLSER, but when that VOLSER becomes scratch and it is reused, its old DSNB is not removed from the TMC, and this old DSNB was incorrectly matched with the VOLSER, creating an observation in TMS.TMS with incorrect dataset name. Statement IF DSNBACTV='Y'; was inserted after 012100. Thanks to Gary Matney, Twentieth Century Investors, USA.
VMAC110 one site; MCTSSDRN was 16 but there were only 15 segments May 12, 1992 and MXG did not protect for this IBM error. Now, the test IF SEGSTRT+MCTSSDRL GT LENGTH+1 THEN DO; NBAD110+1; IF NBAD110 LT 10 THEN PUT " INVALID RECORD DELETED " // _N_= APPLID= MCTSSDCA= MCTSSDCL= MCTSSDRL= COL= ICICS= ;
DELETE; END;
was inserted after each statement SEGSTRT=COL; to detect and delete these bad records, while IBM investigates. Thanks to Tom Elbert, John Alden Life Insurance, USA.
VMACTMVS because when IBM eliminated these EBCDIC fields, TMON/MVS May 12, 1992 wrote hex nulls instead of EBCDIC values, causing the SAS error condition. The MXG data set is not affected and variables (WKLCPURF,WKLIOCRF,WKLMSORF) are set to missing values. Inserting a ?? format modifier for each variable eliminates the invalid data message and hex dump. Thanks to Marcia Ketchersid, Price Waterhouse, USA. Change 10.057 Support for NETSPY Release 4.2 added new dataset NSPYNPSI EXNSPYNP describing X.25 multi-channel lines, X.25 MCH PUs and X.25 VMACNSPY virtual circuits with 50 variables; variable DLYVALUE was May 5, 1992 added to NSPYNCP, variables NTRISUBT,NTRISBTE to NSPYTR, and dataset NSPYLINE now captures resources for six new elements (X.25 line, PU, LU, and SNA switched line, PU, and LU). The NTRI entry was internally reformatted.
EXPDBCDE your PDB is documented in the MXG supplement (pp 137-140). May 4, 1992 However, in many instances, you may only want certain of the SMF record's subtype's datasets to be created. If the Yüklə 28,67 Mb. Dostları ilə paylaş:
|