* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
4.TRND72 line 001400 Semi-colon must be a comma 5.PDBTREND line 009500 %GRAFTRN must be %GRAFTRND insert new lines after 011200: 011210 PROC SORT; 011220 BY SYSTEM PERFGRP; 6.VMXGSUM: line 025900 Add DATETIME &DATETIME 8 before semicolon new line 025910 IF DATETIME=. THEN DATETIME=.; line 035400 Add DATETIME &DATETIME 8 at end of line new line 035510 IF DATETIME=. THEN DATETIME=.; Thanks to Alan W. Maloney, Telenet Communications, USA. Thanks to J. D. Hill, CyCare Systems, USA. Thanks to Pete Shepard, Ashland Oil, USA. Thanks to Rich Lopez, Ethicon, USA. LASTCHANGE: Version 7 This page is (almost) blank (intentionally). End of Changes Log, but how's this for page filler, printed verbatim from an entry in IBM's INFO/SYS (SMF6CPS is COPIES in TYPE6): E343725 (HIT LIST 000003/000013) LINES: 1 THRU 15 OF 15 H E343725 S=TOOLS C=GY4 D=JUL89 E=JUL91 L=00015 TITLE: PSF NOT UPDATING SMF6CPS FIELD IN TYPE 6 SMF RECORDS. F -SUGG -OY21704--5665-27-501--IN-INCORROUT REPORTED RELEASE R220 ERROR DESCRIPTION: SMF6CPS IS NOT UPDATED CORRECTLY. COMMENTS: THIS APAR IS BEING CLOSED SUG (SUGGESTION). THE SUGGESTED Change WILL NOT BE IMPLEMENTED. 89/07/19,CHICAGO FS
=========================member=CHANGE06================================ /* COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS */
documenation location, for MXG Version 6 are in Newsletter THIRTEEN, which is now contained in member NEWSLTRS of the MXG Source Library. YOU MUST READ THAT NEWSLETTER BEFORE INSTALLING MXG VERSION 6.6. Newsletter THIRTEEN additionally contains Administrative Announcements Technical notes and enhancements planned for the next version of MXG. After you have read NEWLETTER THIRTEEN, you will need to return to this member to read the changes themselves, as much of the technical information is contained in the detail change descriptions herein.
from that printed in MXG Newsletter THIRTEEN. The time between the printer and tape building allowed enhancements and more consistent naming conventions for the members which control the new Trend Data Base enhancement. Note these related features implemented in that change:
organized summarization of complex SAS data sets with a simple series of parameters. Its use will go far beyond its first implementation here in the Trend Data Base.
objectives (percent transactions responses in less than 1,2,3,5,8, 15, etc. seconds) for each User, Transaction and Terminal, in the new PDB.CICS data set. The ASUMJOBS member uses %VMXGSUM to similarly calculate IWT (Initiation Wait Time) distributions hourly by job class (percent jobs initiated in 2, 5, 15, 30 min, etc.) in the new PDB.JOBSKED data set. These members implement the measurement of service objectives as described in Chapter Eight. %VMXGSUM is used in a different fashion in the four Trend Data Base building members TRNDCICS, TRNDJOBS, TRNDRMFI, and TRND72, which take the weekly PDB data sets and the Trend-to-Date accumulation and produce the new updated trend-to-date ("five years in five CYL") data base. These members, which can be executed after the weekly PDB has been built with JCLTREND, provide the long range tracking, trending and capacity modeling demonstrated in the graphs in Chapter Forty-Two. Member GRAFTRND provides ready-made 18-month graphics. The MXG Trend Data Base is a brand new implementation using new style %MACROs to create a series of a DATA and PROC steps. It has not had the intense testing the remainder of MXG Version 6 received (444 MXG users have been using a pre-release of Version 6, many installing it in a production mode). Thus, while I think it is real good, I reckon it might still have a few cobwebs I missed. If you have problems in using these new %MACROS, look real careful that you did not fail to terminate every parameter with a comma. The %MACRO facility is equally powerful and equally unforgiving. I almost included the ASUMCICS and ASUMJOBS members in BUILDPDB to build PDB.CICS and PDB.JOBSKED by default, but at the last minute decided it had not been tested widely enough to justify that design. Do not hesitate to let me know what was missed and what should be added.
the MVS data sources. The %VMXGSUM macro, however, is there for the using yourself, until next version, when there really will be support for the VM Trend Data Base and the VM/XA Trend Data Base as well! ==========================Changes Log==================================
changes were provided by telephone prior to this production shipment. You MUST read each Change description below to determine if a Change will impact your installation. For each impacting change, you should also read the comments in the beginning of the source members that are listed under the change number. Notes, comments, and last minute documentation are usually found in comments in changed members.
XMACEPIL the data center to build the production tapes, the mail Jan 21, 1989 delivered the Candle documentation of changes in their EPILOG 1000 for CICS Version 440 record formats! Because the records are changed in so many places, and because I did not have test data for validation, this new member contains syntax tested code only, and only applies to Version 440 records, which are incompatible with their Version 430 records. See comments at beginning of this new member. There are 46 new variables (at the end of the KEEP= list, starting with BI4GLPGM), and there were 21 variables removed (see blanks where they used to be in the KEEP= list, compared with VMACEPIL member!) Thanks to Ashok Argarwala, Candle Corporation, USA. Change 06.212 The SAS supplied EXEC for SAS under CMS does not test to EXECDALY see if you issued a GLOBAL MACLIB statement to CMS before REXXDALY you invoked SAS. The SAS EXEC itself issues a GLOBAL Jan 19, 1989 MACLIB statement for the AUTOEXEC MACLIBs. Since the MXG execution instructions under CMS (p. 24, MXG Supplement) tell you to GLOBAL MACLIB USERID SOURCLIB and then type SAS, the concatenation of USERID and SOURCLIB MACLIBS is disconnected by SAS's EXEC, and your MXG program may fail with "Member Not Found". The simplest solution to execute MXG under CMS SAS is probably to create your own copy of the SAS EXEC, and add the USERID and SOURCLIB names to the list of MACLIBs globalled therein. The SAS Institute plans to change their EXEC in a future version to check for GLOBAL MACLIBs first, and if found, to add SAS's desires to your already stated command. Thanks to Steve Morton, SAS Institute, England. for bringing this to my attention.
ANALAUDT the INTENT and ALLOW values, and for RACFAUTH='10'X the Jan 19, 1989 AUTHRITY=AUDIT was corrected to AUTHRITY=SPECIAL. Thanks to Wing Louie, Metropolitan Life, USA. Change 06.210 Newsletter THIRTEEN went to the press on Monday, and it TYPEIMS said IMS FASTPATH log records were not supported in 6.6. Jan 19, 1989 I had really planned to add it during this week while the newsletter was at the printer and while my QA tests were executing. SAS Europe had provided me with test data and a copy of DBFULTA0 output for validation. I had the printed assemblies of ILOGREC RECID=ALL for IMS 1.3,2.1, and 2.2 at hand, as they contain the DSECTs of all IMS log records. When what to my dismay, do I find that IBM does not print the format of the X'59' FASTPATH IMS log records, even when TYPE=ALL is specified. I have been on the phone to IBM support with still no answer as to how or where these records are documented, and I have run out of time. Well, there's always the next version. Sorry! Of interest, however, was IBM Level One's sincere comment that no one knew much about fastpath, because they only rarely get a call about fastpath! Footnote: Two Level 1 calls and one Level 2 call later, but only hours before the production building of MXG 6.6 begins, I did get at least the DBFK.... member names in DCSOURCE that are supposed to contain the needed DSECTS!
TYPEIMS incorrect in some cases when multiple transactions were Jan 17, 1989 processed per program schedule (eg., WFI). The reason was that in step 8 the merge of input and output records did not match in all cases; if an output record is missed the original code merged the input record with the NEXT output record. The result was an increasing RESPNSTM for MULTRANS as much as the time of day continues!!! The logic now balances the timestamps when output records are missing by recognizing the condition and then setting the values missing. An output record will be missed for any transaction which had not completed when the IMS log was dumped, but the effect of a single missed output record was propagated into several IMSTRAN observations. Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
VMACVMON be slightly in error; the correct divisor should have Jan 17, 1989 been 16666.666 (which is 1000000/60). Thanks to Rob Owens, SAS Institute Europe, GERMANY. Change 06.207 DB2 Trace records, when written to GTF only, are limited Jan 17, 1989 to 280 bytes (a 24-byte GTF header, and 256 bytes of DB2 trace data per record). The most important trace records fit in the 256 byte limitation, but Trace events needing more than 256 bytes are internally "spanned" by DB2 into several GTF records. Unfortunately, these are not valid VBS records, and are not straightforward to decode. The MXG 6.6 support for GTF format DB2 trace data processes only the un-spanned records at present. If a real need exists (only startup records are spanned thus far), we will investigate enhancing the MXG algoritms with you. I still think GTF is the wrong place for DB2 Trace. In the first place, the detail accounting reports in member ANALDB2R meet the needs of almost all DB2 administrators, and trace should be limited to special occasions. If you must trace, you should use good sense and SMF files, and "To ensure adequate buffers exist, specify CISZ(4096) and BUFSP(81920) for each SMF VSAM data set" as IBM recommends in SC26-4095-2.
ASUMCICS This series of members are the beginning of the long ASUMJOBS overdue (almost "fabled") enhancement to provide for GRAFTRND the long term trending of response, resources, etc., IMACSHFT in a very small data library referred to as the Trend JCLTREND Data Base. More will be written later on its use, but PDBTREND for starters, PDBTREND will build an initial trend data TRNDCICS base from the past and thereafter JCLTREND will update TRNDJOBS the past weeks data into the Trend Data Base, and give TRNDRMFI management-pretty reports for the past eighteen months TRND72 trends! The member naming conventions to be used are VMXGDUR ASUM.... for the first summarization from detail data VMXGSUM into an interval (eg., hourly) from PDB input back into Jan 15, 1989 a new data set in the same PDB and TRND.... for second summarization from one interval (eg., hourly) into a diffeent (eg. week-shift), from WEEK input combined with existing TREND to create updated TREND data set. ASUMCICS - Creates CICS interval summary and response buckets from detail transaction data (CMF or Landmark!). GRAFTRND - Graphs of CPU capacity with simple linear regression prediction CPU usage from TREND.RMFINTRV. See member. IMACSHFT - Existing IMACSHFT was modified to return both a SHIFT variable and the start-time of the shift for TREND. To be compatible with TREND, you must replace your present IMACSHFT with this new member. The internal logic was restructured to pass back a modified value for the inputted variable DATETIME, but there was no change in the value of SHIFT passed back by IMACSHFT. JCLTREND - Example JCL to execute weekly after your weekly PDB has been built, to update the existing Trend Database with the new week's data. This usually is best run after you have examined your weekly runs, as there is no supplied code for backout if you mess up! PDBTREND - Create your Trend Data Base for the past directly from weekly SMF files or already build weekly PDBs. Start here, and work backward in history as far as you want to go. Each execution adds another week to your Trend Data Base. TRNDCICS - Builds TREND.CICS dataset. TRNDJOBS - Builds TREND.JOBS dataset. TRNDRMFI - Builds TREND.RMFINTRV dataset. TRND72 - Builds TREND.TYPE72 dataset. VMXGDUR - Calculates durations of HOUR, DATE, WEEK, MONTH. Will optionally calculate SHIFT using IMACSHFT. Input variable DATETIME contains the timestamp to be examined. Will calculate SHIFT using IMACSHFT and will reset DATETIME to the timestamp of the beginning of the shift interval. VMXGSUM - The heart and soul of MXG summarization. Contains multiple macros which make it act like a PROC that lets you summarize detail data into interval data and interval data (eg. hourly) into other intervals (eg., weekly), taking into account the things like rates and percentages which must be expanded, summed, and then contracted in the summarization process. "Self-Documented" - ha? Thanks to Chuck Hopf, Hopf Consulting, USA. for lots of help with %macro implementation. This is the essence of the system which generated the graphs in Chapter 42 of the MXG Guide. Five years data in five cylinders! Change 06.205 Several graphics enhancements were made to make MXG GRAFRMFI co-exist better with SAS/GRAPH. Device selection in VMXGGOPT GRAFRMFI is now enabled with the new %VMXGGOPT macro XADMDEFS which added support for IBM3179, IBM3279, IBM3287, Jan 15, 1989 ZETA887, TCX4107, IBM3800, and especially for SAS/PC. Member VMXGGOPT allows for the dynamic selection of graphic devices; see documentation in that member. XADMDEFS is also referenced in VMXGGOPT; it provides the GDDM ADMDEFS for IBM 3800 and 3820 graphics. Thanks to Chuck Hopf, Dean Witter Reynolds, USA. Change 06.204 MXG had provided FMXGUCBL and VMXGVTOC to capture DASD ASMVVDS space management data, but VTOCs do not provide data on EXTYVVDS VSAM files. This contracted enhancement now provides IMACVVDS DASD Space management for VSAM files. Instead of the JCLVVDS VTOC, space information on VSAM data spaces is in the TYPEVVDS VVDS, located on each volume which contains VSAM data VMACVVDS spaces. MXG provides the Assembly source code and the Jan 15, 1989 JCL to create the ASMVVDS program in member ASMVVDS. Once assembled, program ASMVVDS can be executed by the JCL in JCLVVDS, and the VVDS data is extracted and then written to a flat file, or (my recommendation), can be written as an SMF record. Once the VVDS data is in the flatfile or SMF record, member TYPEVVDS will create the MXG dataset TYPEVVDS which can be then used to measure, manage, and charge back VSAM DASD space. See comments in member ASMVVDS; this program must be authorized to read the VVDS.
IMACVMON Release 6, comparison of IBM's documentation and the MXG Jan 15, 1989 code in VMACVMON strongly suggests that MXG will support the Release 6 records, provided only that both the _HPO and _MP macros defined in IMACVMON are enabled. In fact, both were required enabled for Release 5 with or without HPO. The defaults have now been changed to enable both _HPO and _MP since few new MXG sites will come up on 4.2! This should not affect current MXG sites, since you have already tailored IMACVMON into your USERID.SOURCLIB and that member will override the new defaults in MXG!
FORMATS x60-x62 (new with Network Gateway Accounting), and the VMAC28 additional variables added to the MSA, BAS, BAN, and NTK Jan 15, 1989 segments. No NGA data has been available for testing, but having the code in place means that you won't need a new version of MXG when you install NGA later this year. IBM really came through in time with this documentation!
IMAC102 read most new fields added by DB2 Version 2.1. This is IMAC102A also a major restructure of the code. Not all of the new IMAC102B subtypes have been tested against 2.1 data, so there is VMAC102 a slight risk in using the type 102 code in this version Jan 14, 1989 of MXG. A new macro, _DB2IID is defined in IMAC102 that can be used to delete specific IFCID (subtype) values if there are any problems. All TRACEnn labels were removed, and comments in IMAC102 identify which IFCIDs are in each trace class. Change 06.200 PROC DATASETS LIB=_IMSTRAN NOLIST;DELETE IMSTRAN; was TYPEIMS removed, because SAS not only does not support deletion Jan 14, 1989 if _IMSTRAN is a tape, but it creates a condition code twelve! The purpose of the delete was to re-use the same space on disk; thus if you create IMSTRAN data on disk, you will need to do your own delete, eg.: //SYSIN DD * PROC DATASETS LIB=IMSTRAN ... %INCLUDE SOURCLIB(TYPEIMS); Thanks to Tim Follen, Blue Cross of Ohio, USA. Change 06.199 DB2 data written to GTF is now supported by the use of a ANALDB2R new _GTFDB2 macro added to VMACSMF. Members TYPEDB2G and TYPEDB2G TYPE102G are their "no-G" members with _SMF replaced by TYPE102G _GTFDB2. If you write DB2 trace data to GTF, you must VMACSMF apparently specify the complete 0FB9 Event ID to GTF at Jan 11, 1989 startup; Ron responded with only FB9 and the GTF records unexpectedly contained EFB9 as their EID! The member ANALDB2R was also enhanced with the new GTF= option to use that data source for DB2 reports, and a new option PDBOUT was added to create an output copy of the DB2 data sets if desired. Thanks to Ron Roberts, The Equitable Life Assurance Society, USA. Change 06.198 Support for COM-PLETE SMF Accounting Records creates four EXCOMASR data sets, one from each of the four records. COMPULON, EXCOMLON COMPULOF, COMPUCKP, and COMPUTRM correspond to ULOG On, EXCOMLOF ULOG Off, Checkpoint, and program termination. Only the EXCOMCKP COMPUTRM data records have actually been fully tested. EXCOMTRM
IMACCOMP TYPECOMP
VMACCOMP Jan 11, 1989 Thanks to Karl Smit, Decision Support Services, SOUTH AFRICA.
EXSMOASR an SMF-format record for a SDXKSTA0 Statistics Data Set. EXSMOAUR MXG creates six new datasets, SAMONASR,SAMONAUR,SAMONSSR, EXSMOSSR SAMONTLR,SAMONTSR,SAMONUSR which are described in IBM's EXSMOTLR SNA Application Monitor Operations and Diagnosis Guide EXSMOTSR pp.86-98. Caution: no data records have been received EXSMOUSR as yet, so this code has only been syntax checked. IMACSAMO
TYPESAMO VMACSAMO
Jan 11, 1989 Thanks to Jim Gilbert, Texas Utilities, USA. Change 06.196 This VM/370 report caused an error when no channel data ANALVMDY was collected, because PROC TRANSPOSE does not create the Jan 10, 1989 COLn variables when there is not input data. This causes the RENAME COL1=BUSYPCT statement to fail. To fake out the SAS compiler to avoid the error, the statement IF COL1=. then COL1=.; was inserted after the RENAME. This trick creates the numeric variable COL1 to satisfy the SAS compiler, but does not change its value if it already exists. Thanks to Jay Cicardo, Southwestern Bell, USA. Change 06.195 This paper on the VM/XA Monitor Facility will be DOCVMXAF published later this year in a major journal, but Jan 10, 1989 its author has been kind enough to share his work with MXG users. Thanks to Richard Steele, Louisville Gas and Electric, USA.
ANALCACH Reporting Cashed I/O Subsystem Performance", by Nancy Jan 10, 1989 Nearing, Washington Consulting Group discussed methods to depict cache performance characteristics, using both RMF type 74 records and the RMF Cache DASD Reporter FDP SMF records (MXG member TYPECACH). The report examples in that paper are implemented in this contribution. Thanks to Bruce L. Green, Medical Information Bureau, Inc, USA. Change 06.193 RMDS enhancements suggested by this user led to a VMACRMDS general cleanup of RMDS Version 3 SMF record code, Jan 9, 1989 and capture of additional useful RMDS data fields. Thanks to Jenell Ratterree, The Cooper Group, ENGLAND. Change 06.192 HSM Processing. This is a significant contribution from JCLHSM this user, a complete self-contained system. I have not VMXGHSM really tested the code with real data. I simply put all Jan 9, 1989 the macro definitions into a the single VMXGHSM member, syntax tested the code with no input records. It will be examined and documented in the future, and possibly data set names will be prefixed with HSM Yüklə 28,67 Mb. Dostları ilə paylaş:
|