* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Apr 18, 2003 -In Trending logic, EXRMFINT is now invoked; without that logic, variables dropped from RMFINTRV in EXRMFINT were not being dropped in the TRNDRMFI dataset. -Invoking VMXGRMFI twice, using PDB=PDB logic to create two levels of summary (like RMFINTRV and RMFINTHR, as suggested in comments in the original RMFINTRV member) corrupted the SPINRMFI dataset so it did not keep enough data for correct calculations of MSU4HRAV. The example is revised, and the TREND logic should be used for the second summary, to eliminate SPINRMFI corruption: %VMXGRMFI(PDB=PDB, OUTDATA=PDB.RMFINTRV, INTERVAL=DURSET); %VMXGRMFI(PDB=,TRENDIN=PDB.RMFINTRV, TRENDOLD=, TRENDOUT=PDB.RMFINTHR, TRENDINT=HOUR); %VMXGRMFI(PDB=,TRENDIN=PDB.RMFINTRV, TRENDOLD=, TRENDOUT=PDB.RMFINTDY, TRENDINT=DATE); These examples assume the IMACWORK=YES default, i.e., the workload definitions are in your IMACWORK member. If you instead invoke %VMXGRMFI with IMACWORK=NO and use its WORKnn= arguments to define your PDB.RMFINTRV workloads, then you must specify those same WORKnn= arguments when you use the VMXGRMFI to create TREND.TRNDRMFI dataset; otherwise, none of the extended varaibles will be in TREND.TRNDRMFI. Thanks to Scott Barry, SBBWorks, Inc, USA. Change 21.066 TYPSZARA was revised to copy the ZARA datasets into the TYPSZARA PDB library; the ZARA support is unique in that it does Apr 18, 2003 depend on the macro overrides in IMACZARA, so this was the safest change to copy ZARAxxxx datasets into the PDB ddname, and still preserve prior user's tailoring. Thanks to Bob Miller, Conseco, USA. Change 21.065 Support for servers with more than 16 CPUs or LPARs. VMAC7072 -TYPE70 Dataset: Support for 32 engines. VMXGRMFI The existing sets of 11 CPU-specific variables per CPUID VMXG70PR CAIx CPUSERx CPUWAITx CPUEDTMx CPUPDTMx IORATEx May 29, 2003 PCTCPUBYx PCTTIPx VFAFFTMx VMONx MVSWAITx where suffix 0-9 and A-F are for CPUs 0-15, have 17 more suffixes, G-L and N-X, for CPUs 16 thru 32 (187 vars). Note that the suffix letter "M" had to be skipped, because variable CPUWAITM was already defined. Labels document which suffix is for which CPU number. -TYPE70PR Dataset: No change was needed for more than 16 LPARs; MXG stores the LPARNUM in four bytes. Note, however, we recommend you use the MXG-build PDB.ASUM70PR or PDB.ASUMCEC dataset for your LPAR and CEC analysis, as those datasets know how to recognize and not count LCPUs that are ICFs or Linux partitions; if you use TYPE70PR, you'll have to make sure you understand how to recognize what's what. -RMFINTRV Dataset: CPU Serial variables CPUSERG-CPUSERL and CPUSERN-CPUSERX were added to the ID= operand for PDB.RMFINTRV dataset. -ASUM70PR,ASUMCEC datasets (built by member ASUM70PR): The existing sets of 22 LPAR-specific variables per LPAR LPxNAME LPxDUR LPxUPDTM LPxUEDTM LPxMGTTM LPCTxBY LPCTxOV PCTLxBY PCTLxOV LPxNRPRC LPxBDA LPxCAP LPxCHG LPxDED LPxWAIT LPxSHARE LPxLAC LPxMSU LPxMSUHR LPxMSU70 LPxONT LPxWST where suffix 0-9 and A-G are for LPARs 0-16, have 16 more suffixes, H-O and Q-X, for LPARs 17 thru 32 (+352 vars). Note that the suffix letter "P" had to be skipped, because variable CPUWAITM was already defined. Labels document which suffix is for which LPAR number. This was "Feature 0" or "z/OS 1.4 z990 Compatibility".
ASMIMSL6 -BMC's IMF, Candle's ITRF, Landmark's TIMS. VMACIMS -MXG's "Supported" TYPEIMS7 to create IMS0708 dataset Apr 17, 2003 -MXG's ASMIMSL6/JCLIMSL6 to create IMSTRAN dataset. May 21, 2003 -BMC's IMF, Candle's ITRF, and Landmark's TIMS products write their own records that MXG reads, and none have changed in their output records, so MXG 20.20+ supports their products under all versions of IMS, including 8.1.
dataset from 07 and 08 log records (has IMS resources by transaction name, but no response times) does work with IMS 8.1, but there are "INVALID DEQDATE" messages and hex dumps printed on the job log, because IBM incompatibly changed their 036x log record. VMACIMS has been updated to support the non-fast-path IMS log records, and when fast path 8.1 records are available along with DSECTS, the VMACIMS code for them will be examined for changes. The _IMSVERS macro default value in IMACIMS7 and IMACIMS are left at 7.1, since some sites may be exploiting that existing default; change to 8.1 to process IMS Version 8.1 records.
examples work just fine with IMS Version 8.1 records, as they do with IMS Version 7.1 records, but you must first re-assemble the ASMIMSL6 assembly program using the IMS Version 8.1 macro library to create the V 8.1 program, and you must run separate JCLIMSLx jobs to process the V7.1 and V8.1 data separately; you cannot concatenate the IMS logs from two versions and read with JCLIMSLx. MXG 20.03 contained the last change to this support.
VMACIMS logic, and a FLAG2 test added for log record 36x. Thanks to Jiann-Shiun Huang, CIGNA, USA.
VMACNTSM to NRTRIPLT=1 but no triplets in that record. Error is Apr 16, 2003 circumvented by inserting a statement IF OID=0 AND OBJECT NOT IN ('0','1') THEN DELETE; before the test for the NRTRIPLT input statement. Thanks to Roger Zimmerman, Hewitt Associates, USA. Change 21.062 MXG 20.07 thru 21.01 may have filled SPIN.SPINUOW with FIXASUOW many observations that should not have been spun. Change JCLUOWP 20.221 did not expect cases when the DB2ACCT ending time JCLUOWV stamp was after the CICS end time, which caused TRANNAME VMXGUOW to be blank, causing that observation to be "spun". And Apr 15, 2003 because TRANNAME is now blank (and we will most likely never see another record for that unit of work) that record will spin up for 7 days (default in SPINUOW), and that increased the size of SPIN.SPINUOW. This change now uses a forward sequence of the Start Time to put all the CICS and DB2 pieces together, and is not dependent on the end times. -If you wish to preserve the "spining" records currently in your SPIN.SPINUOW dataset, member FIXASUOW can be used to create a revised SPIN.SPINUOW dataset that can then be used with the revised VMXGUOW to create the corrected PDB.ASUMUOW. That first execution will "clean out" many of the spinning transactions that should not have been spun in the first place. Or, you can just delete your existing SPIN.SPINUOW and start fresh with the new code. -VMXGUOW has a new parmeter, TRACEUOW=YES (Default NO) to trace the UOW chain for diagnostic purposes (printing lots and lots of messages on the log). Thanks to Alfred Nardi, CMX Group, USA. Change 21.061 Dataset T102S196 was never fully decoded, but now is, for FORMATS V6 and V7. An observation is created for each holder of VMAC102 this lock that caused a timeout for the "victim". This Apr 9, 2003 "victim" is identified in QWHCxxxx & QWHSxxxx variables. Apr 14, 2003 The lock is identified in QW0196RH/RL/FR/KD/KP/K1-K7/WU /WS/WD/WF/TI and QW0196TC variables; those QWHC, QWHS, & QW0196xx variables repeat in subsequent observations if there was more than one holder (QW0196NU counts holders) segment in an SMF record. The identity of the holder(s) are in the three sets of variables QW0196Hx, QW1196Hx, & QW21196Hx for up to 3 holders of the lock. More than 3 holder prints a note. -MGD044K format was expanded for new values. Thanks to Ron Alterman, Charles Schwab, USA. Change 21.060 The row between 16M-2G was added to the Paging Report; ANALRMFR this row shows values only if your system is running in Apr 6, 2003 ESAME mode; in ESA mode, the row will show 'N/A'. The Channel report READ(MB/SEC) and WRITE(MB/SEC) values in the IBM report are incorrect: IBM code divides the raw byte values by 1000*1000 to print as MegaBytes, but they should have used 1024*1024 to convert; the IBM values are about 5% too high. Thanks to David Kellerman, ADP, USA.
FORMATS fields thate were negative, because IBM documented them VMAC74 as floating point, but they contained binary data. The Apr 9, 2003 variables R744SPST,SPSS,SRST,SRSS,SCST,R744SCSS are now Apr 22, 2003 correctly input as binary, and R744SLSV as TODSTAMP8. Apr 24, 2003 -Some (but not all) observations in TYPE74ST had missing values for R744QSIZ, when there were a large number of structures. The QSIZ (SMF744QN) segments are written at the beginning of one physical physical record, followed by as many SSIZ segments that can fit in that record, but additional SSIZ segments are in a separate physical record. Those additional SSIZ elements had missing QSIZ. By retaining the QSIZ array and storing the number of elements, the subsequent SSIZ segments are now populated with their QSIZ values. -But R744QSIZ will only be non-missing in records from the one system in a sysplex that "owns" the Coupling Facility i.e., the "Sysplex Master" system. This is now discussed in IBM Information APAR II13172, which applies to both the RMF III data and the RMF 74 subtype 4 QSIZ segments. -Variable R744QFLG is now decoded by new $MG074QF format, which includes '00X: NOT SYSPLEX MASTER, NO QSIZ' value for TYPE74ST observations from non-master systems, and obs with R744QFLG='00'X will also have R744QSIZ missing. Thanks to Coen Wessels, Unicible, SWITZERLAND.
VMAC74 to RMF records and RMF Device Activity Reports, and sets VMAC79 the existing Director Port Busy (DBP) and Control Unit Apr 6, 2003 Busy (CUB) Delay fields to zero in SMF 74 and 79 records. Apr 29, 2003 The CMR time for a start or resume function of the sub- channel is the time needed until the device indicates it has accepted the command; this allows distinction between real hardware errors versus workload spikes (contention in the fabric and at the destination port). -In dataset TYPE74, new variables DLYCMRTM and AVGCMRMS are created. Variables DLYDIRTM, DLYCHATM, PCTPNDIR, DLYCUBTM, AVGPNCUB PCTPNCUB will all be zero when this APAR is installed. And I've assumed that DLYCMRTM should also be subtracted from DEVPNDTM to calculate DLYOTHTM (since DLYCUBTM and DLYDIRTM were). -In dataset TYPE799, new variable R799CMR is created, and variables R799DPB and R799CUB will be zero with the APAR. -OW54347 documented that R799CMR was added at offset +92, but the original text of APAR OW31701 had R799TMS added at offset +92. IBM now confirms that OW31701's text was wrong, R799CMR is at +92, and that R799TMS does not exist in the RMF 79 record. Thanks to Ermanno Bewrtolotti, Banca Intesa, ITALY.
FORMATS RACFTYPE are updated for new values in z/OS 1.2 and 1.4. Apr 7, 2003 Thanks to Chuck Hopf, MBNA, USA. Change 21.056 -Enhancements to BUILDPDB/BUILDPD3. Exit member EXPDBSPJ BUILD005 and old-style macro _EPDBSPJ are created so that local BUIL3005 variables can be added to the PDB.SPUNJOBS dataset. EXPDBSPJ -Variable DATETIME (Start of Shift, equal to INTBTIME) is SPUNJOBS added to PDB.SMFINTRV for consistency. Apr 4, 2003 -Variables SMF6LPGE and DOCLENFT are added to PDB.PRINT, and those variables plus PAGECNT are summed into the PDB.JOBS and the PDB.SPUNJOBS datasets. Thanks to Scott Barry, SBBWorks, USA.
VMACAIM6 when ID=116 MQ Series records were in your test SMF data. Mar 28, 2003 To avoid conflict, FACOM support was changed to use an _IDAIMn macro to set SMF TYPE of FACOM records, and the default value is set to the impossible value of 512. All FACOM users will have to redefine the appropriate macro in their IMACKEEP member to create observations in the FACOM datasets from the FACOM records: FACOM Record MXG MACRO NAME 110 _IDAIM0 111 _IDAIM1 112 _IDAIM2 113 _IDAIM3 116 _IDAIM6 117 _IDAIM7 98 _IDAIMR For example, to process the FACOM 116 record, you would put this statement MACRO _IDAIM6 116 % in your IMACKEEP member. Thanks to Mike Hoiey, Ameren Services, USA.
UTILEXCL the KY8DISTM=16*KY8DISTM; after the IF CMODIDNT='263'... Mar 28, 2003 should have been KY8CPUTM=16*KY8CPUTM; Jun 12, 2003 -Jun 12,2003: Original change only changed the first instance, but there was a second instance in lines after CMODIDNT='263' that also needed to be changed. Thanks to Steve Yucha, Aetna, USA. Thanks to Tony P. Steward, Royal Mail, ENGLAND. Change 21.053 Support for BlackBerry Server object. EXNTBLKB
VMACNTSM VMXGINIT
Mar 28, 2003 Thanks to Jim Quigley, ConEd, USA. Change 21.052 -Archaic V6 JCL example was revised to match MXGSASV8 with MXGSAS DISP=(NEW,DELETE) per Change 20.076. MXGSASV8 -DISP was changed to NEW,DELETE in MXGSASV9 as it should MXGSASV9 have been in MXG 20.20 Mar 27, 2003 -The WORK DD symbolic &WORK was not in parenthesis in V8 example.
Thanks to Yao Chun Rickert, Bank One, USA. Thanks to Jim Horne, Lowe's, USA. ====== Changes thru 21.051 were in MXG 21.01 dated Mar 24, 2003========= Change 21.051 -Negative values for LOGNATMP & TOTANONS in WEBSERVR occur VMACNTSM because MXG de-accumulation did not recognize a stop and Mar 23, 2003 start of the webserver. Adding SEQCHECK=DIF(SEQNR) and testing SEQCHECK EQ 1 now correctly deaccumulates. -Support for SYSTEM object with 32 fields; that object has only 26 unique fields; the last six are repeats. -The Discovery Print macro _UNTDISC was updated to support multiple sets of discovery records. Thanks to Xiaobo Zhang, ISO, USA.
VMACCMF record adds variable CMF27MDL to dataset CMF27C93, which Mar 21, 2003 will now contain both 2105 and 3390 observations; the 2105 observations contain CMF27MDL='20', while 3990s have CMF27MDL='96'. Thanks to Kevin Batty, EMC Engineering, USA. Change 21.049 MXG Execution under unix at SAS with early ports of V9.1 AUTOEXEC suggested revisions for MXG's IEBUPDTE program, and found IEBUPDTE a workaround for a unix SASAUTOS error that is now fixed: Mar 21, 2003 -MXG's IEBUPDTE program (IEBUDPTE for ASCII) needed these Apr 10, 2003 revisions to work under unix: - LENGTH MEMBER $200; was added, as that becomes the full member plus path name and 50 was too short as default. - Only the PDS_MEMBER is lower cased; previously, the full path and member were lowcased, but unix path names can be mixed case. - The suffix "sas" in the member is now lower case, so that the files do not have to be re-cased. -The OPTIONS SASAUTOS=(SOURCLIB SASAUTOS) statement in the MXG autoexec.sas file did not correctly work under unix: SAS Note SN-000444 - SASAUTOS fileref is not automatically generated on unix platforms. The SASAUTOS is required, because MXG uses the associated MAUTOSOURCE options so that %MACROs references (%ANALDB2R %VMXGSUM, etc) are automatically resolved. A workaround OPTIONS SASAUTOS=(SOURCLIB, %scan(%sysfunc(getoption(sasautos)),1,%str(()))); was added in MXG's AUTOEXEC member in MXG 21.01, which works on both unix and Wintel SAS platforms, but in April SAS unix developers fixed the problem, so that syntax is not required, and was removed in MXG 21.02. Thanks to Jan Squillace, SAS Institute, USA. Change 21.048 INFO: CHARACTER VARIABLES DEFAULTED TO LENGTH OF 200 are TYPEVLFC printed if OPTIONS MSGLEVEL='I' is in effect; this has VMAC6 been documented since V6, and occurs when a character VMAC6156 variable is defined by a function, and the variable is VMACCTLG not in a LENGTH/ATTRIB statement (unless the function is VMACEAGL SUBSTR - then, the length of the first argument is used). VMACTNG The longer length has no MXG impact, but the seven cases Mar 21, 2003 where the message was produced are now protected with the variables now in a LENGTH statement, just to eliminate that possibly confusing message: Member Variable VMAC6 - PR VMAC6156 - SYSPAR61 (was SYSPARM, but renamed). VMACCTLG - SYSPARCL (was SYSPARM, but renamed). TYPEVLFC - HITPCT VMACEAGL - IDS, MSGIDC VMACTNG - TEXT Thanks to Stephen Bell, Sparkassen Informatik, GERMANY. Change 21.047 Format $MGCICCL (applied to variable A17DTTYP in dataset VMAC119 CICFCR) adds values for K:CFDT CONTENTION MODEL and Mar 20, 2003 L:CFDT LOCKING MODEL'. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 21.046 Support for SMF 119 APAR PQ71376, which changes TICONNID VMAC119 and TTCONNID from $EBCDIC8 to $CHAR4 with $HEX8 format. Mar 19, 2003 Originally the CONNID fields had jobname, which was not unique; now they contain the unique hex Connection ID. Variable TISUBTSK was removed; it never really existed.
WEEKBLDT works fine under Version 8, but the LABEL= was not fully Mar 18, 2003 implemented, so it can be removed if you're under V6. I intended to have (LABEL= _LABEL SORTEDBY=_BYLIST) and set MACRO _LABEL 'this is the dataset label' for each of the weekly and monthly datasets, but didn't do that yet. Thanks to Jesse Gonzalez, CSC - NASA, USA.
VMXGRMFI not work, because the &R70MAX statement was left out of Mar 18, 2003 the Trending part of VMXGRMFI, and because the doc was not clear: to use the &R7xMAX= macro to "add" variables, you must list all existing variables in the default list, and then add you new variables in your invocation. Thanks to Rick Mansfeldt, IBM Global Services, USA.
VMACESPH and JHRFLAG2 are decoded into individual variables. Mar 18, 2003 Thanks to Jesse Gonzalez, The Gap, USA. Change 21.042 Variables QPPCTNOW and QPPCTLOW, the percent buffers are VMAC115 full now, and full lowest, are created in MQMBUFFER. Mar 18, 2003
ASUMCICS datasets while still creating a 0 obs output dataset with ASUMCICX all variables labelled and formatted. Additionally, some Mar 14, 2003 variables that were only output in ASUMCICX are now also created by ASUMCICS. Thanks to Diane Eppestine, SBC, USA. Change 21.040 New graph plots the Peak to Average Utilization ratio at GRAFTRND the SYSTEM SHIFT level; the peak value of the shift is Mar 14, 2003 compared to the average for that shift and plotted on a range of 1 to 2 by .1. If the ratio exceeds 2, it is set to 2. Thanks to Cheryl Watson Walker, Watson & Walker, USA. Change 21.039 Cosmetic. LABEL was missing for NDMCPUTM. VMACNDM
Mar 12, 2003 Thanks to Khoan Dang, MBNA, USA. Change 21.038 Protection for WORD7 to be the last word eliminated NOTE: VMACWWW INVALID THIRD ARGUMENT TO FUNCTION SUBSTR when processing Mar 11, 2003 a WebSphere HTTP log file. Thanks to Craig Collins, State of Wisconsin, USA. Change 21.037 Documentation. Thou shalt not use a RENAME= statement in VMXGSUM your OUTCODE= argument to %VMXGSUM that renames variables Mar 11, 2003 that are in the SORTEDBY= list; thy %VMXGSUM will fail with ERROR: VARIABLE xxxxx NOT SORTED and and ERROR: INVALID VALUE FOR THE SORTEDBY OPTION. Thanks to Khoan Dang, MBNA, USA. Change 21.036 -RSDA AUDIT error message was printed even though AUDHEXZR VMACRSDA was zero; the test should have been 0000X (numeric) but Mar 11, 2003 was incorrectly coded as '0000'X (character, so the test failed when AUDHEXZR was zero). -But then View Records (AUDACT=04) caused INPUT STATEMENT EXCEEDED message, because those records do not have the Folder Name segment that MXG expected; a test was added to see that the Folder Name segment is present. Thanks to Christa Neven, KBC BankVerzekeringsHolding, BELGIUM
VMXGUOW BY VARIABLES ARE NOT SORTED ON WORK.TEMPCICS because the Mar 10, 2003 BY list in MACRO _SUOWTMO was not updated in VMXGUOW. Thanks to Tom Heaton, Texas Legislative Council, USA. Change 21.034 Protection for missing STARTDTE was added; records with VMACXCOM only ENDDTE populated caused INVALID DATA FOR STARTDTE Mar 10, 2003 message, but no actual impact on the output XCOMDATA. Thanks to Mark Williams, Marks & Spencer, ENGLAND. Change 21.033 Additional AS/400 5.2 files LRECL have been validated and VMACQACS are listed in the comments in VMACQACS. Minor cosmetic Mar 7, 2003 changes were made to suppress INVALID DATA messages for Mar 17, 2003 reserved packed fields. The data files had been sent to MVS with incorrect LRECLs, and when those MVS files were ftp'd to me, I discovered Padded Bytes added to the last record of each file; the bytes are all hex zeros and they caused invalid data messages when PD fields were input. So MXG tests the INTNUM packed decimal field and prints a message "PAD RECORD FOUND AND DELETED _N_= nnnn" on the log. As long as the _N_= value is the same as the xx in the SAS NOTE: xx RECORDS READ, then the delete record was comprised of these pad bytes and there was no error. Thanks to Brian Keller, ConAgra Foods, USA. Change 21.031 -Tests for FTPSTART xx FTPEND and FTPEND xx SMFTM were ANALTCP incorrect as GE, and are changed to the correct GT, and Mar 7, 2003 two output columns were shifted one position. Mar 14, 2003 -A sort step was added, required only when PDB=SMF. Yüklə 28,67 Mb. Dostları ilə paylaş:
|