* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
means there were new objects and/or new metrics that are not yet supported, and when there are obs in UNKNOWN, it is possible that MXG will not output any observations (when the last object in a group is unknown, the output of the entire cube never occurs). Adding support for all new objects and metrics causes the observations to be output. -An ARRAY EXCEEDED error messaged, because AI007V should have been 7 instead of 2. -Some of the new "CA.." objects have identical metrics in both Solaris and AIX cubes, but other datasets, notably, the SO016, 020, 021, 022, and SO023 have a different set of variables than their AIX counterparts; always use the variable's LABEL, and not the NAME, to match AIX data to Solaris data in those dataset. -Major enhancements in error detection and reporting of array size issues were added; the number of instances and the number of variables in your data are compared to the array limits, and messages print which object's value in which array is too small, and by how much.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND. Change 21.268 The PDB.ASUMCACH variable IORATE was wrong, because both ASUMCACH TYPE74 and TYPE74CA datasets have a variable IORATE, and VMAC74 both values were being summed. But in investigating the Jan 6, 2004 error, I found that the TYPE74 IORATE variable is often a very different value than IORATE in TYPE74CA: In TYPE74, the SIO74CNT variable is directly used: IORATE=SIO74CNT/DURATM; in TYPE74 dataset. But in TYPE74CA, as there is no SIO count variable, the I/O request counts RDREQS+WRREQS+ICLR+BPCR are added to get the total I/O request count, SIO74CA: IORATE=SIO74CA/DURATM; in TYPE74CA dataset. Both SIO74CNT and SIO74CA variables are in PDB.ASUMCACH, so you can see the differences in your own data. One test had TYPE74 with 4,635,246, while TYPE74CA had 18,425,069. -In VMAC74, variable SIO74CA is created in TYPE74CA data set, for direct comparison with TYPE74 data. -In ASUMCACH, the IORATE variable is now calculated in the OUTCODE= argument, using IORATE=SIO74CNT/DURATM, since the TYPE74 IORATE existed long before cache controllers, but also, new variable IORATECA=SIO74CA/DURATM is created so that you can compare the two I/O rates directly. -The local variables IORATEA-IORATEZ were also removed. Thanks to Kasandra Natzke, Infores, USA.
ASUMUOWT names _LDB2ACC _LMONTSK, _LCICTRN and _INMQ had hardcoded VMXGUOW DDnames of DB2ACCT, MONITASK, CICSTRAN, and PDB, but now VMXGUOWT have &PDB2ACC, &PMONTSK, &PCICTRN, and &PTY116 (&Pdddddd) Jan 7, 2004 macro variable names for the LIBNAME/DDNAME, so they can be easily overridden, and to be consistent. -ERROR: OLD-STYLE MACRO NAME MUST CONTAIN ... in ASUMUOWT was corrected by redefining each old-style macro name to itself immediately before the %LET MACKEEP= statement. (see Change 21.244). -PSUUOW macro variable is no longer re-set in ASUMUOWT. Thanks to Chris Weston, ITRM Development, USA. Change 21.266 Calculation of CPCMSU in PDB.RMFINTRV and PDB.ASUM70PR VMXGRMFI and PDB.ASUMCEC is now rounded to an integer, to more VMXG70PR closely match the IBM values. Jan 5, 2004 CPCMSU - Announced MSU alue, calculated from SMF70CPA. CPCFNAME - MXG-created "standard" long name for the box. SU_SEC - SRM "constant" value in SMF 72 record, changes when the LPAR configuration is changed, cannot be used to exactly calculate CPCMSU. Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
VMAC7072 output in every observation in PDB.TYPE70PR, which made Jan 5, 2004 the LPnLAC values identical for all LPARs. This change recognizes SMF70LAC is a "this-partition-only" value and it is now non-missing only in PDB.TYPE70PR dataset from the 'this-partition' records, which will correct values of LPnLAC in PDB.ASUM70PR and PDB.ASUMCEC. However, MXG must read the raw SMF type 70 records from each LPAR for the LPnLAC values to be completely non-missing. Thanks to Richard S. Ralston, Humana, USA. Change 21.264 New utility %VGETSORT macro reads the contents of a SAS VGETSORT data library, and, for each dataset in that library, will Jan 5, 2004 build a macro variable that contains the member name and the SORTEDBY variables,or UNSORTED if there is no SORTBY. This will be used to dynamically build a WEEKBLD/MONTHBLD process that will preserve the default sort order. Change 21.263 Support for UniCenter NetMaster Automation Services SMF EXNETM22 record with Event View, Resource View, and Server View EXNETM30 Statistics creates two new datasets: IMACNETM DDDDDD Dataset Description TYPENETM NETM22 NETM2200 Subtype 2000, 2200 Event View TYPSNETM NETM30 NETM3000 Subtype 3000, Resource/Service View VMACNETM Some problems exist with datetimestamps that are under VMXGINIT investigation, and no 2200/2000 data has been tested. Jan 4, 2004 Thanks to Andy Creet, Defence Computing Bureau, AUSTRALIA. Change 21.262 WebSphere MQ Version 5.3 new variables SM115REL/SM116REL VMAC115 with Version and Release ("531") is now kept in all MQ VMAC116 datasets. However, as there are no other changes in 5.3 Jan 3, 2004 DSECTS, except for these two new Release variables, MXG Jan 23, 2004 21.05 or later supports MQ Version 5.3 SMF 115/116s. -Label for QPSTDMC is now SYNC, it was incorrectly ASYNC, a very important difference in this case, since Sync page writes can significantly delay transactions. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
VMAC74 more than one SMF 74 subtype 4 record was written (due to Jan 2, 2004 a large number of structures). The MXG logic test to output TYPE74CF included variable SMF744SN, which has been removed, and only if the XN, GN, and PN segments are present in this SMF 74 record will TYPE74CF be output. Thanks to Art Cuneo, Health Care Service Corporation, USA.
UTILBLDP corrected; this error was introduced in Change 21.231. Jan 2, 2004 Thanks to Scott Barry, SBBWOrks, Inc, USA. Change 21.259 Using VMXGTIME to shift timezones caused MXG's calculated VMACSMF GMTOFFDB GMT offset to be wrong, and so QWACBSC/QWACESC VMACDB2H were also wrong. DB2 has no GMT offset value in the SMF VMAC110 records, but all timestamps are on the TODCLOCK, so MXG VMACOMCI compared SMFTIME with TODSTAMP values to create the GMT Jan 2, 2004 offset, and then shift the DB2 timestamps to local zone. But when VMXGTIME is enabled, the SMFTIME was shifted in VMACSMF, before the GMT offset calculation in VMACDB2H, causing this error. Variable UNMODSMF is now created and it contains the un-modified SMFTIME value, and UNMODSMF is used in VMXGDB2H to calculate the GMT Offset for DB2. -SMFTIME was also used in the calculation of UOWTIME, to find the FRSTBASE (epoch) of the 205-day-wrapping-clock. While that exposure is extremely small, UNMODSMF is also now used in that calculation. Thanks to Chuck Hopf, MBNA, USA. Change 21.258 Label for variable ESFRLSAV in TYPE71 dataset revised to VMAC71 ESTORE vice CSTORE, and ESFRLSAV=. is now set instead of Dec 17, 2003 CSFRLSAV when ESFRLSAV is LT 0 (line 1412). Thanks to Jennifer C. Chu, State Street Corporation, USA. Change 21.257 Output statement for ZRBSVPP dataset was relocated to VMACRMFV after the segment has been input, causing variables to be Dec 17, 2003 populated.
VMXG70PR
Dec 17, 2003 Thanks to Hugh Lapham, RCMP, CANADA. Change 21.255 New BLDSMPDB builds an executable "BUILDPDB jobstream" BLDSMPDB that executes under either ASCII or EBCDIC SAS, reads an Dec 16, 2003 SMF file to create the MXG recommended, enhanced, Daily "SMF" PDB library, optionally copies that daily PDB to the appropriate one-of-seven day-of-week PDBs, optionally updates the current Week-To-Date PDB library, optionally creates the Weekly PDB library from the seven dailies on the first day of your week, optionally creates the Monthly PDB on the 1st day of the month, and optionally updates your TREND PDBs. First draft, to be revised. This program effectively implements the suggestions in the (still out of date documentation) ACHAP35 member. Thanks to Joe Key, BOC, ENGLAND.
TRNDDB2A
Dec 16, 2003 Change 21.253 New GLOBAL macro variables TRENDOLD, TRENDNEW, TRENDINP VMXGINIT default to TREND, TREND, and WEEK respectively, and will Dec 16, 2003 be used in place of those hard-coded DDNAME/LIBNAMEs in the MXG Trend Members. Change 21.252 Two ways to see RMF control blocks, happy values, SU_SEC: RMFMON one uses the LIST subcommand of the TSO TEST command, Dec 16, 2003 a better one uses the SAS PEEK() function specifically to display the SU_SEC value in your z/OS system. Change 21.251 SAS has a new SMFEXIT that adds SAS Version/Release, User VMACSASU and JOBID to the SAS User SMF record; those fields are Dec 16, 2003 now input as variables SASVEREL, SASUSER, and SASJOBID. The revised SMFEXITs are available from SAS Institute at: http://ftp.sas.com/techsup/download/mvs/SMFEXIT.ASMSRC Thanks to David Heiniluoma, Commonwealth of Massachussets, USA. Thanks to Rich Anderson, SAS Institute, USA.
ANALALL how many records of which type and subtype were written ANALJOBN by each JOB, so you can track down which runaway JOB VMXGPRAL filled your SMF file. Dec 12, 2003 -Existing ANALALL member (prints all variables and all Dec 15, 2003 observations for all job-related datasets created by selected jobnames) was revised so only datasets with JOB name are created. -The VMXGPRAL utility (invokes PROCs PRINT or PROC MEANS against all datasets in a SAS data library: %VMXGPRAL(DDNAME=WORK,NOBS=50); was enhanced with the NOFREQ= option used by ANALJOBN. -The confusing SAS NOTE on the log when VMXGPRAL was run: "The variable NOBS exists on an input dataset, but was also specified on an I/OI statement option. The variable will not be included on any output data set." was eliminated, thanks to Charley. Thanks to Adam Floro, Southern Illinois University, USA. Thanks to Charley Mullin, SAS Technical Support, SAS Institute.
VMACNSPY wrong time per frame variables were used in the equation. Dec 10, 2003 Jan 17: Typo NSPYTMFS corrected to NSPVVTMFS. Jan 17, 2004 Thanks to Steve Donahue, BCBS of Texas, USA.
VMACMWUX "Process Queue Histogram" and before "Process Waiting" Dec 5, 2003 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error. Circumvention coded while the vendor is being contacted. Thanks to Miguel Fernandez, Information Services International, USA.
VMACTPMX all of the fields created as of their latest version, Dec 2, 2003 TMT5210, adding 259 new variables to TYPETPMX dataset. Thanks to Lawrence Jermyn, Fidelity Systems, USA. Thanks to Nancy DiFilippo, MVS Solutions Inc, CANADA.
VMXGRMFI to clarify their known causes: Dec 1, 2003 -If your workload definitions are incorrect: ***ERROR.RMFINTRV. WORKLOAD CPU TIMES DO NOT MATCH REAL CPU. YOU HAVE CPUTM=00:30:00 REAL CPU TIME IN SMF 72, BUT HAVE CPU72TM=00:45:00 CPU TIME IN YOUR WORKLOAD DEFINITIONS. AT STARTIME=30NOV2003:00:02:30.00 FOR SYSTEM=SYS1. THIS IS A SERIOUS ERROR IN YOUR TAILORING IN IMACWORK, OR IN RMFINTRV MEMBERS. ALL OF YOUR WORKLOAD VARIABLES (BATXXXX, TSOXXXX, CICSXXXX AND THEIR SUMS (CPUTCBTM,CPUSRBTM,CPUHPTTM,CPU72TM) ARE WRONG. SEE TEXT OF CHANGE 15.138.
*** ERROR. NEGATIVE UNCAPTURED-CPU-TIME (TYPE70-TYPE72). *** ERROR. NEGATIVE UNCAPTURED-CPU-TIME (TYPE70-TYPE72). FIRST: LOOK AT THE VALUES OF CPUTM AND CPU72TM, BELOW. IF THEY ARE NOT EQUAL, THERE WAS AN EARLIER ERROR MESSAGE: ERROR.RMFINTRV. WORKLOAD CPU TIME... TELLING YOU THIS ERROR IS DUE TO TAILORING OF YOUR WORKLOAD DEFINITIONS IN IMACWORK OR RMFINTRV. THIS MESSAGE IS PRINTED HERE FOR REINFORCEMENT. SECOND: LOOK AT THE VALUES OF CPUACTTM AND CPUEFFTM, BELOW, IN THIS MESSAGE. IF CPUEFFTM IS MORE THAN CPUACCTM, THEN READ APAR II10549 ABOUT SLOW COUPLING FACILITY AND HARDWARE PROBLEMS. YOUR CE NEEDS TO OPEN A HARDWARE PMH TO FIX. SEARCH MXG NEWSLTRS FOR II10549 FOR MORE INFO. THIRD: IF NEITHER, THEN YOU HAVE BAD DATA IN YOUR 70/72 RECORDS. BMC CMF PRODUCT NEEDS CMF PTF BPM6782. IBM RMF APARS OW28256 (1997) OR OY51878 (1992). ONLY 2 INSTANCES OF THIS MESSAGE ARE PRINTED. READ TEXT OF CHANGE 15.238 IN MEMBER CHANGES. *** ERROR. THIS IS A SERIOUS ERROR********************** CPUOVHTM=-00:00:01.40 SYSTEM=PRD2 STARTIME=30NOV2003:00:30:00 CPUACTTM=0:05.22.35 CPUEFFTM=0:05:59.77 CPUTM=0:05:23.75 CPU72TM=0:05:23.75 and you can see this error was for the Second case. Thanks to Hugh Lapham, RCMP, CANADA. ====== Changes thru 21.245 were in MXG 21.07 dated Nov 30, 2003========= Change 21.245 Revisions to resolve errors and inconsistencies. ASUMUOW
ASUMUOWT ASUMUOTT
VMXGUOW VMXGUOWT
VMXGUOTT Nov 30, 2003 Change 21.244 Cosmetic cleanup after first MXG 21.07 QA runs: ANALCNCR -ANALCNCR. UNINITIALIZED VARIABLE NEXTINTV/LASTINTV VMXGTPFI messages had no impact on the results, but have been VMACOMDB eliminated. ANAL16 -VMXGTPFI revised to remove unneeded sorts and messages Nov 28, 2003 about MXGSUM2. -VMACOMDB minor revisions to remove duplicate variables in FORMAT statement, and $CHAR instead of $EBCDIC for $HEX. -ANAL16 following INCLUDE of TYPE16 failed with message ERROR: OLD-STYLE MACRO NAME MUST CONTAIN ONLY LETTERS. because ANAL16 used %LET MACKEEP to redefine old-style macros. Redefinition (MACRO _KTY16 _KTY16 %) inserted ANAL16 before the %LET MACKEEP re-definition, as noted in the DOCMXG comments related to use of %LET MACKEEP. Change 21.243 Support for Candle Omegamon II for DB2 Historical D2540 EXDB0010 file creates 312 new datasets, based on the SAS code that ...310 more Candle provided with the product. This iteration EXDB3370 supports DB2 V7.1; only forty-two of the datasets have IMACOMDB been populated with observations, and only cursory TYPEOMDB validation of formats, labels, etc., has been completed. TYPSOMDB VMACOMDB
Nov 24, 2003 Change 21.242 JCLTEST8 fails with VARIABLE OPERATOR NOT FOUND if your ASUMCICS CICS guru has Excluded OPERATOR or TERMINAL from CICSTRAN JCLTEST8 dataset, because those two variables are historically in Nov 24, 2003 in the default SUMBY list in MACRO _BSUCICS. - See Change 21.105: We no longer recommend ASUMCICS be used, since it summarizes transaction segments instead of unit-of-work transactions. Instead, you should create PDB.ASUMUOW and then use the ASUMCICX program to create PDB.CICS summary dataset: %INCLUDE SOURCLIB(ASUMUOW,ASUMCICX); (and you need to tailor IMACUOW - read its comments).
DB2 data, to combine CICS MRO segments together to get correct TRANNAME, etc. If you do not create the PDB.DB2ACCT dataset, you can create a zero-observation DB2ACCT dataset to satisfy ASUMUOW, using: OPTIONS OBS=0; %INCLUDE SOURCLIB(TYPEDB2); RUN;
OPTIONS OBS=MAX;RUN; &INCLUDE SOURCLIB(ASUMUOW,ASUMCICX); - If you still must create PDB.CICS from CICSTRAN, you can re-define the old SUMBY list "instream": //SYSIN DD * %LET MACKEEP= MACRO _BSUCICS APPLID USER STRTTIME TRANNAME SYSTEM SHIFT % ; %INCLUDE SOURCLIB(ASUMCICS); to remove the OPERATOR and TERMINAL variables. - But so you don't get blindsided during testing with my defaults, One site with excluded fields had never used ASUMCICS but their "clean running" JCLTEST8 job failed. this change added "compiler fakers' in ASUMCICS to create one-byte OPERATOR/TERMINAL variables when they do not exist in your CICSTRAN. Jan 25, 2004 Update: You can now use the VMXGSUME member created in Change 21.277, and not have to modify ASUMCICS or ASUMUOW to deal with dropped variables.
VMACMWUX now a/k/a OVPA. Nov 22, 2003 -DISKKBYT,KBYTRATE,PREADKBS,PWRITKBS are mult by 1024. -GLOBAL Transaction variables no input by default -The REPORT ALL command in ADOCMWUX is the command to use that creates the MXG-expected data fields. -Many TRAN fields were removed as they are not in the HP default REPTALL, and I had no test data to validate with. Thanks to Tony P. Steward, Royal Mail, ENGLAND. Thanks to Miguel Fernandez, Information Services International, USA. Change 21.240 Support for new S4RSP7CT in STID=124 CICS Statistics data VMAC110 record. Caused "FOUND WITH SKIPPED FIELDS" warning with Nov 21, 2003 STID=124,SKIP=4,STILEN=120, but no error. Thanks to Tim Vanderhoek, Fidelity Systems, USA. Change 21.239 The ability to read multiple PDB libraries was lost in a ANALDB2R prior change, but has been restored, so you can again use Nov 20, 2003 the documented syntax PDB=MON TUE WED THU FRI SAT SUN, to read multiple PDBs as input to ANALDB2R. Thanks to Bill Bonfitto, MassMutual Financial Group, USA.
VMAC74 because the offset SMF744RO is unlike other RMF offsets. Nov 20, 2003 It is from the first data byte and not from the RDW, so SMF744RO=SMF744RO-3 used to calculate the byte location had to be deleted. And with data to look at, the two sum of squares R744RSSS and R744RSSD are actually &PIB.8 and not the &RB.8 that I had assumed. Thanks to Tom Draeger, Aurora Health Care, USA. Change 21.237 New ASUMUOTT member creates new PDB.ASUMUOTT from the ASUMUOTT ASG-Landmark DB2 TMDBDB2 dataset and ASG-Landmark CICS EXTMDDB2 MONITASK dataset. The output is named PDB.ASUMUOTT, IMACUOTT even though it is logically the same as PDB.ASUMUOW, JCLUOTT because the TMDBDB2 variable names are used instead of VMACTMDB the DB2ACCT names. VMXGUOTT -Member VMACTMDB was modified to create the DB2PARTY Nov 19, 2003 variable, to identify DB2 Parallel event records (see Nov 30, 2003 Change 14.287). Formats MGDB2RC and MGDB2LM applied to RINV/PREC vars. All ACE vars are now all numeric, $HEX8. &MXGBYLN. All /4096 are now formatted TIME12.2. -Member EXTMDDB2 was revised to use DB2PARTY to delete events that should not be output (see Change 19.027). -Member JCLUOTT is a standalong example to read the raw TMON CICS and TMON DB2 files to create PDB.ASUMUOW. -Member VMACDB2, variable QWACLRAB now formatted MGBYTES. Nov 30:
New member ASUMUOWT and VMXGUOWT created to support the combination of MONITASK.MONITASK and DB2ACCT.DB2ACCT. Thanks to Hamid Tavakolian, CSC, USA.
ASMRMFV that did not include the enhancements in Change 21.186. Nov 18, 2003 I copied the wrong member into the source library. The ASMRMFV at Change 21.236 dated Nov 18, 2003 (or later) contains that major revision to the ASM program for the RMF III VSAM data; Change 21.228 added VMACRMFV support. Change 21.235 Variable CPCFNAME, the CPC FULL NAME (2064216) created in VMXG70PR PDB.RMFINTRV, is now also created in PDB.ASUM70PR and in Nov 18, 2003 PDB.ASUM70LP datasets. Thanks to Kenneth D. Jones, xwave, CANADA. Change 21.234 Test for '2084'X added, but only needed if OS/390 R2.10 VMXGRMFI with SMF70WLA=. (i.e., do not have the APAR that added Nov 18, 2003 SMF70WLA installed) is running on a z990.
FORMATS user SMF record creates new OPENFT dataset for each SMF EXOPENFT event record. IMACOPFT
TYPEOPFT TYPSOPFT
VMACOPFT VMXGINIT
Nov 17, 2003 Thanks to Wolfgang Prescher, Itellium, GERMANY Change 21.232 Replaced change. Change 21.231 Now, USERADD=80 USERADD=90 cause the TYPE80A or TYPE90A UTILBLDP code to be generated, and not TYPE80 nor TYPE90, which Nov 17, 2003 were replaced by their "A" counterparts. MXG's original logic for RACF TYPE80 and OPERATOR COMMAND TYPE90 created one TYPE80/TYPE90 dataset with hundreds of variables; the "A" replacements create many TYPE80nn/TYPE90nn datasets, one for each event with only that event's variables kept. You can see what events occurred, just by looking at the non-zero observation counts for each dataset on the log. Previously: "USERADD=90," created obs in TYPE90, but "USERADD=90 90A," generated both _CDE90 and _CDE90A segments, and that first ELSE IF ID=90 ... in _CDE90 prevented _CDE90A from being executed, so there were never any obs in any of the TYPE90nn datasets. Thanks to Gadi Ben-Avi, Malam Systems Ltd, ISRAEL.
VMXGCICI the ORDER= argument "clean up" by Change 21.152 increased Nov 11, 2003 the number of lines which exceeded the maximum size of a SAS V6 macro argument. Compacting the lines reduced the total bytes and the code now executes under V6 or V8+. Thanks to Kelvin Wells, ScaleOn GmbH, GERMANY. Yüklə 28,67 Mb. Dostları ilə paylaş:
|