* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
TYPE70SP dataset (thanks to the "Split 70s" redesign, so nothing was lost). Under z/VM, the CPUID segment of the RMF 70 record does not exist. The revised message reads: MXGNOTE: RMF70 CPUID SECTION DOES NOT EXIST THIS IS NORMAL IF z/OS IS EXECUTING UNDER Z/VM. OTHERWISE THIS IS AN INVALID RMF 70 RECORD. -Prior to z/OS 1.12, the PRCS/PRDS segments of the RMF 70 record did not exist when z/OS was run under z/VM. But in z/OS 1.12, APAR OA35675 captures the CPU dispatch time of both the z/OS partition and the z/VM "overhead". See Change 29.127 which added support for that APAR. -On the topic of z/OS under z/VM, past Newsletters noted: - To construct the configuration and recording of TYPE78 data, RMF must read the IOCDS data set, but under z/VM, the IOCDS is not available to z/OS, so some type RMF 78 records will not exist. - Under z/VM, the RMF I/O Queueing Activity Report shows only the static configuration data. -And IBM's Running Guest Operating Systems documents that: -When you analyze the z/OS environment, remember that you have two operating systems running in a single processor. Both z/VM and z/OS are vying for the basic system resources, such as processor, I/O, storage, and paging. Each is generating its own accounting information, and each is supplying its own performance information. -Remember that z/OS is unaware that it is running as a guest under z/VM. What the z/OS guest thinks is real-time is actually the time-of-day clock and processor timer facility. Elapsed time as measured by the time-of-day clock is accurate. The guest's virtual processor timer (VPT) runs whenever the guest is dispatched or is in a voluntary wait state. It does not run if the guest is in a CP wait state. Thus, when z/VM dispatches another virtual machine and later dispatches the z/OS guest, z/OS does not realize it had stopped running.
-Information about guest system performance is frequently published in Washington System Center flashes. Contact your marketing team for obtaining flashes that pertain to your particular installation. -And IBM's RMF Programmer's Guide documents for z/VM: -Partition Defined Capacity Used Percent is zero. -And IBM's RMF Reports Manual documents for z/VM: -When Channel Path Measurement Facility (CPMF) is not available, for example, on z/OS systems running as z/VM guests, RMF uses sampled data from SRM so that the reported channel utilization is only an approximate value. With increasing channel speed, the channel utilization value becomes more and more inaccurate. Therefore, in such cases, RMF does not provide accurate values of FICON channel utilization. Beginning with z990 processors, the channel data from SRM is no longer available. As a result, the channel utilization data on a z/OS system running as z/VM guest, is not reported. -In the DEV and DEVV reports, LCU will be blank if this is a non-dedicated device in a z/VM guest system environment. -Running in a z/VM guest environment, these RMF reports: Partition Data Report LPAR Cluster Report Group Capacity Report do not exist (because TYPE70PR has zero observations). Dataset TYPE70 variable VMSYSTEM='Y' for z/OS under VM. -For the CPU Activity Report: If RMF is running as a guest under z/VM, it only reports the z/OS busy time percentage. If you want to measure partition utilization (as well as the individual CPU utilization of the single guests, namely LPAR busy time percentage), you need to use a z/VM monitor. Thanks to MP Welch, Aprize, USA. Thanks to Bruce Widlund, Merrill Consultants, USA.
VMAC110 "knee-capped, i.e. slow" CP engines with zIIP/zAAPS. Apr 1, 2011 The specific case had CPUTM=25 and ELAPSTM=5 on a CP with a zAAP that was 10 times faster (or that CP was 10 times slower!). CICS Support responded to the PMR documenting that CICS uses the TIMEUSED macro to capture CPU time: "Note: TIMEUSED returns normalized CPU time. Some servers are configured with System z(TM) Application Assist Processors (zAAPs) or IBM System z9® Integrated Information Processor and IBM System z10(TM) Integrated Information Processors (zIIPs), which run at a faster speed than the normal CP processors. In this case, zAAP time and zIIP time is normalized to the equivalent time it would take to run on a normal CP when accumulated into total CPU time. " The specific case had CPUTM=25 and ELAPSTM=5 on a machine with a zAAP that was 10 times faster (or a CP that was 10 times slower!), which printed a recently added MXG ERROR message "CPUTM MUCH LARGER THAN ELAPSED". This message was added to enhance MXG's detection of mis-aligned SMF records when CICS fields were excluded or optional fields were added. Previously, the only way for MXG to catch mis-alignment was to test that TASKNR was a valid packed decimal or that STRTTIME was a missing value, but both of those fields are at the beginning of the segment, and some combinations of EXCLUDEd fields with optional data segments passed those tests as the record was read, but the CICSTRAN dataset contained invalid values for fields later in the record, but that was only after the MXG job had completed and the user analyzed the data. This test was added for more robust detection, but the original was only for CPUTM GT 2*ELAPSTM, which in this specific case was a spurious ERROR message. I have changed the test to CPUTM GT 10*ELAPSTM and added a note in the message that this could be normal if you have knee-capped CP engines. -These CPU time variables in CICSTRAN recorded those 25 Normalized CPU seconds: TASDSPTM (USRCPUT), KY8CPUTM, L8CPUTTM, and the total CPUTM, for this transaction that obviously spent some serious time on the zAAP engine. Thanks to Hugo L. Michel, Prince Georges County, MD, USA. Thanks to Dan Zachary, IBM CICS Support, USA.
EXNTD001 And, a MAJOR redesign in MXG architecture, isolated now EXNTD062 to the NTSMF product support, but a possible harbinger IMACNTSM of future MXG support: DATASET NAMES UP TO 32 CHARACTERS, VMACNTSM with that dataset name being the OBJECT name (with blanks VMXGINIT and periods changed to underscores). The "dddddd" dataset Mar 31, 2011 tokens for the new datasets are "NTD001-NTD062", and the VMXGINV variable/metric names use the D001 part of the dddddd UTILVREF token as their prefix, and are sequentially numbered, e.g. D0010001-D00010008 are the 8 variable names for the dataset with NTD001:_NET_CLR_NETWORKING, and the labels for the metrics are the metric name, shortened to forty characters with asterisks inserted for the SPLIT='*' SAS operand (to split labels when printing). Previously, I created unique dataset names and variable names that were arbitrarily limited to 8 characters, but this design was implemented by the MAKENTSM code member that programmatically generates all of the structural code that is then cut/pasted to add the new datasets and their exit members. The _UNTDISC utility provides the cut and paste text for the metric names, that become the labels for each variable; that is (and will always be) a manual process, as that's how I discover what new metrics are created, and get an understanding of each new object. It is also where the conversion of values to be consistent (like converting KB fields to bytes) and assignment of MXG formats (like MGBYTES to those converted fields, both for the "print pretty" aspect, but more importantly, to document (in PROC CONTENTS) the variables that contains storage units) that requires human knowledge is done. The new objects are listed in IMACNTSM rather than here! -The increase of DATASET name required revisions to the internal programs VMXGINV and UTILVREF that create the DOCVER members; for datasets with names longer than 9, DOCVER now has two lines, one for the DATASET name and a second line for the DATASET label. Additional updates were needed in a number of the internal QA programs to support the longer dataset names.
VMAC82 SMF82DCN, MORE THAN 20 UNAUTH DUPE for TYPE8225 are notes Mar 30, 2011 that you had more than the 20 I thought was enough. With a max of 36 now observed, I've increased to 40 the number of these variables that are kept in the two datasets. But, with MXG's default of COMPRESS=YES, why have any limit at all: there really isn't any real cost of DASD space, if the extra variables are all blanks. If this is really a normal need, to know each of the instances of the duplicate KEY, when there might be more than 40, then MXG would create a new dataset with one observation per instance, and free itself from any array-size constraints! Thanks to Bruce Hewson, Citibank N.A., SINGAPORE. Thanks to Alan Yang, Citibank N.A., SINGPORE
READDB2 to create ONLY the PDB.DB2STATS dataset, with no other Mar 28, 2011 datasets written to the PDB library. It should also be noted that, to create observations in PDB.DB2STATS, both DB2STAT0 and DB2STAT1 must have observations; DB2STAT4 can have zero observations. Thanks to Jane S. Stock, USPS, USA.
UTILBLDP the MACFILEX argument can be used to skip unwanted SMF Mar 28, 2011 records and subtypes. Apr 7, 2011 -Some MXGWARN were changed to MXGNOTE and text revised. Thanks to Nicholas Ward, CentreLink, AUSTRALIA.
EXTPM10 creates new datasets: EXTPM16S dddddd Dataset Description EXTPM16J TPM10 TPM10 Description IMACTPMX TPM16S TPM16S Step Termination VMACTPMX TPM16J TMP16J Job Termination VMXGINIT Mar 28, 2011 Change 29.070 Replaced by Change 29.220. Mar 24, 2011 Change 29.069 The DB2 Report of TOP users of resources was revised to ANALDB2T report separately for each DB2 SubSystem. Mar 24, 2011 Thanks to Ron Wells, American General, USA. Thanks to Rick Brooks, American General, USA.
BUILD005 and all variables from TYPE26J2 were blank or missing in Mar 24, 2011 the PDB.JOBS dataset. Change 28.304 unintentionally output all TYPE26J2 obs with SYSEXEC LE ' ' to the PDB.NJEPURGE dataset, so they were not used to build the PDB.JOBS obs. Instead, only the Purge records that have INREASON IN ('JR','JT','SR') AND SYSEXEC LE ' ' are (now, correctly) output in PDB.NJEPURGE. Fortunately since purge records with SYSEXEC LE ' ' did NOT execute, there was no actual loss of resources, except for the counting JCL errors. Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN. Change 29.067 RACF UNLOAD utility dataset RACF0270 (OMVS) decodes these VMACRACF ten variables for UID limits: Mar 28, 2011 ASSIZEMAX ='MAXIMUM*ASID SIZE FOR UID' CPUTIMEMAX ='MAXIMUM*CPU TIME*FOR UID' FILEPROCMAX='MAXIMUM*CTIVE/OPEN FILES*FOR UID' MEMLIMIT ='MAXIMUM*SIZE OF*NON-SHARED*MEMORY' MMAPAREAMAX='MAXIMUM*MAPPABLE STORAGE*FOR UID' PROCUSERMAX='MAXIMUM*PROCESSES*FOR UID' SHMEMAX ='MAXIMUM*SIZE OF*SHARED*MEMORY' THREADSMAX ='MAXIMUM*THREADS*FOR UID' Thanks to Ed Webb, SAS Institute, USA.
FORMATS last read was used correctly. The first is now $MG119ST VMAC119 and is used to decode SSH_FSCMD, SSH FTP Subcommand. Mar 16, 2011 Thanks to MP Welch, Aprize, USA.
VMAC111 dataset TY111CXI, but always INPUT for TY111GD dataset; Mar 16, 2011 when it existed in GD but not in CXI, but only when the GD segment preceded the CXI segment in a physical record, the value from the GD segment was carried forward into the CXI dataset. Now, the value is blanked after output in the GD segment to prevent being carried forward. Thanks to Gordon E. Griffith, Edward D. Jones, USA. Thanks to Jim Poletti, Edward D. Jones, USA. Thanks to Jeana M. Bechtel, Edward D. Jones, USA. Change 29.064 The INFILE Exit for Compressed CICS and DB2 records did EXITCICS not always work, sometimes causing an I/O Error message. Mar 16, 2011 Code that had been moved in testing was restored. Thanks to Harald Seifert, Huk-Coburg, GERMANY. Change 29.063 Support for CICS/TS 4.2 was available in MXG 29.03, but UTILEXCL was announced in Change 29.135. This change was Reserved VMAC110 until the product became GA on June 24. Mar 15, 2011 These new variables are added to the CICSTRAN dataset: Apr 2, 2011 ECSEVCCT='SYNCHRONOUS*EMISSION*EVENTS' Jun 24, 2011 OADID ='ORIGINATING*ADAPTER*ID' OADATA1 ='ORIGINATING*ADAPTER*ID*DATA 1' OADATA2 ='ORIGINATING*ADAPTER*ID*DATA 2' OADATA3 ='ORIGINATING*ADAPTER*ID*DATA 3' PHNTWKID='PREVIOUS*HOP*DATA*NETWORKID' PHAPPLID='PREVIOUS*HOP*DATA*APPLID' PHSTARTM='PREVIOUS*HOP*TASK*STARTIME' PHSTARCN='PREVIOUS*HOP*TASK*STARTS' PHTRANNO='PREVIOUS*HOP*DATA TRANS*SEQ NR' PHTRAN ='PREVIOUS*HOP*DATA*TRANSACTION*ID' PHCOUNT ='PREVIOUS*HOP*DATA*COUNT' -UTILEXCL needed revisions because new fields inserted in the middle of the record that were unknown to UTILEXCL were not correctly handled in the prior UTILEXCL, which created an IMACEXCL that had syntax errors that could be visibly seen (the IBM field after the (last) new field was NOT preceded by an INPUT statement.) This was NOT an incompatibility with CICS/TS 4.2, but using the prior UTILEXCL with CICS/TS 4.2 dictionary records did cause the syntax error when that new IMACEXCL was used. -New Statistics STID=19, Dataset CICSMD, exactly the same fields as STID=6 in this iteration. -New Statistics STID=20, Dataset CICSMT, exactly the same fields as STID=5. -New Statistics STID=29, existing Dataset CICSMDSA SMSVABYT='ALLOCATED TO*PRIVATE*MEMORY*OBJECTS' SMSVHBYT='HIDDEN IN*PRIVATE MEMORY*OBJECTS' SMSVGBYT='HWM USABLE*IN*PRIVTE MEMORY*OBJECTS' SMSPMOBJ='PRIVATE*MEMORY*OBJECTS' SMSFGFAI='FROMGUARD*FAILURES' SMSFGBYT='FROMGUARD*FAILURE*SIZE' SMSSHBYT='SHARED*FROM*LARGE MEMORY*OBJECTS' SMSHSBYT='HWM SHARED*IN*LARGE MEMORY*OBJECTS' SMSSHOBJ='SHARED*MEMORY*OBJECTS' SMSASPMO='AUX*SLOTS*BACK*64-BIT*PRIVATE*MEMORY' SMSHSPMO='HWM AUX*SLOTS*BACK*PRIVATE*MEMORY' SMSRFPMO='REAL FRAMES*BACK*64-BIT*PRIVATE*MEMORY' SMSHRPMO='HWM REAL FRAMES*BACK*PRIVATE*MEMORY' SMSLMOBJ='LARGE*MEMORY*OBJECTS' SMSLPINR='LARGE PAGES*BACKED IN*REAL STORAGE' -New fields in STID=48, Dataset CICTSQ: A12TSQDL='QUEUES*AUTO*DELETED' A12TSCTR='CLEANUP*TASK*RUNS' -New fields in STID=142, Dataset CICEPG: EPGEVLNO='EVENT*LOST*NO*ADAPTER' Change 29.062 -UNKNOWN OPTION VNVERR should have been spelled VNFERR in ASUMUOWT VMXGUOW. The error only occurs when ASUMUOWT is used for VMXGUOW TMON CICS input. ASUMUOWT was not called in MXG QA job Mar 15, 2011 or I would have caught this typo; that will be corrected. Mar 18, 2011 -Debugging option TRACEUOW(YES) was left on in ASUMUOWT, causing many thousands of lines FIRST.UOWICCHR= ... to be printed on the log. Thanks to Frank Lund, EDB ErgoGroup, NORWAY. Change 29.061 Variables PCTZAPBY, PCTZALBY, PCTZIPBY, PCTZILBY are VMACRMFV added to dataset ZRBCPU. These represent the Physical Mar 13, 2011 and Logical Busy Percentage for ZAAP and ZIIP engines respectively. Thanks to Rodger Foreman, Acxiom, USA.
ASUM113 were revised by John Burg in his March SHARE session: VMAC113 IF BASIC01 GT 0 THEN DO; Mar 13, 2011 ESTFINCP=((BASIC03+BASIC05)/BASIC01)*(.57+(0.1*RNI)); END; IF SUM(BASIC02,BASIC04,0) GT 0 THEN DO; ESTSCP1M=((BASIC03+BASIC05)/(BASIC02+BASIC04))* (0.57*(0.1*RNI)); END;
EXTYBETF creates two new datasets: EXTYBETG dddddd Dataset Description IMACBETA TYBETF BETA25 93 SPOOL ACCESS VMACBETA TYBETG BETA50 93 WEB BROWSER LOGON/LOGOFF VMXGINIT
Mar 13, 2011 Thanks to Andreas Menne, Finanz Informatik, GERMANY. Change 29.058 Variable CPUCEPTM is now set to a missing value in all of VMAC30 the datasets that contain it (TYPE30_4,TYPE30_V,TYPE30_5, Mar 11, 2011 PDB.STEPS,PDB.JOBS, where it was flat out WRONG, and in PDB.SMFINTRV, where it was validly deaccumulated, but is not needed). The error, starting in Change 22.326, was that CPUCEPTM was an ACCUMULATED CPU time and was NOT the CPU time of the interval, step, or job. In Change 22.326 MXG did deaccumulate it, but only in PDB.SMFINTRV, and in that process, lost the value of the first interval. IBM corrected their error, creating a new deaccumulated field MXG variable CPUCIPTM, added in Change 23.329, which was kept in all of the above datasets since that 2006 change. But then in 2007, forgetting that it was completely wrong I carelessly kept it in PDB.STEPS and PDB.JOBS. While it might be better to just remove the variable, it is safer to now set CPUCEPTM to a missing value, and hope/presume that if/when you notice it is missing, that you will have first searched CHANGESS and will have found this text to tell you to use CPUCIPTM instead. Note that CPUCIPTM is already contained in CPUTCBTM so you would only even want to use it when examining the components of CPUTCBTM. An obscure comment in VMAC30 notes that the variables CPUASRTM CPUENCTM CPUDETTM CPUIFETM CPUEFETM CPUDFETM and CPUCIPTM are all included in CPUTCBTM. Thanks to Alfred Holtz, Medco, USA. Thanks to Charles D'Angelo, Medco, USA. Thanks to Alex Pasterick, Medco, USA.
EXTY116C -SMF 115 record, dataset MQMMSGDM, new variables: IMAC116 QMSTPUBS QMSTSTUS QMSTSUB QMSTSUBR QMSTTCB QMSTTCTL VMAC115 QTSTETHW QTSTETTO QTSTPHIG QTSTPLOW QTSTPNOS QTSTPTO1 VMAC116 QTSTPTO2 QTSTPTO3 QTSTSDUR QTSTSEXP QTSTSHI1 QTSTSHI2 VMXGINIT QTSTSHI3 QTSTSLO1 QTSTSLO2 QTSTSLO3 QTSTSPHW QTSTSTOT Mar 12, 2011 QTSTTMSG Apr 19, 2011 -SMF 116 record, datasets MQMACCT1 and MQMQUEUE: New variables added from both WQ and WTAS segments: WTASCTCT WTASCTET WTASCTN WTASCTSR WTASSQCT WTASSQET WTASSQN WTASSTCT WTASSTET WTASSTN WTASSUCT WTASSUET WTASSUN WTASSUSC WTASSUSL WQCBCT WQCBET WQCBN WQCLCFD WQCLSUET WQCLSUN WQCLTOSR WQOPCFD WQOPSUET WQOPSUN WQOPTOSR WQP1TOSR WQPUBCN WQPUTOSR WQSELCOU WQSELMXL New MQCFSTAT dataset has one obs with these 5 variables WQCFCOUN &PIB.4. /**TIMES*IN THE*ROUTINE*/ WQCFSYCN &PIB.4. /**SYNC*REQUESTS*/ WQCFSYET &PIB.4.6 /**SYNC*ELAPSED*TIME*/ WQCFASCN &PIB.4. /**ASYNC*REQUESTS*/ WQCFASET &PIB.4.6 /**ASYNC*ELAPSED*TIME*/ with those statistics for the Coupling Facility, if used, for each of the five MQ Verbs (variable WQVERB); OPEN CLOSE GET PUT PUT1 and for each of the thirteen MQ requests (WQREQSTY): LOCK UNLOCK WRITELC SIGXCF SIGCF READ WRITE STARTMON STOPMON NEW MOVE MOVEENT DELETE
but observations are ONLY created in MQCFSTAT if there are non-zero counts in one of the statistics variables. Apr 19: VMAC110 QJSTDRE1/3 corrected to QJSTDRQ1/3 Thanks to Victoria Lepak, Aetna, USA. Thanks to Chris Weston, SAS ITRM Development, USA.
VMACBBMQ MXG code had not been updated since 2007 and many new Mar 13, 2011 fields were inserted in 'E6'x (dataset BBMQQUES) record, the 'E5'x (dataset BBMQCHAN) record was completely revised with several new fields, and the 'E1'x (dataset BBMQQMGR) had new fields added at the end. The VERSREL value in the 4.4 records contains 4.2, so the logic to detect MVMQ Version was change to use the Length ENTL field. This iteration suppresses checking for compress bit while EXITMNVW is examined for possible error. Thanks to James Swwinarski, Credit-Suisse, SWITZERLAND.
JCLUOWV PDB.ASUMUOW using SAS Views was altered by Change 28.220 Mar 9, 2011 but undocumented; the default ASUMDB2x members that were %INCLUDed were changed, creating different PDB.ASUMDB2x datasets. While any or all of the ASUMs are optional, it was not my intent to create different datasets, so the default original ASUMs are restored, with this note: /*ANY OR ALL OF THE BELOW SUMMARIZING ASUMDB2X ARE OPTIONAL. */ /*THE PAIR INCLUDED BY DEFAULT ARE THE ORIGINAL PAIR, KEPT FOR */ /*CONSISTENCY, BUT AS ASUMDB2P CAN BE VERY EXPENSIVE, YOU MIGHT*/ /*NOT WANT TO EXPEND THOSE RESOURCES TO SUMMARIZE PACKAGES, AND*/ /*YOU MIGHT FIND SUMMARIZING DB2STATS WITH ASUMDBSS TO BE BOTH */ /*USEFUL AND CHEAP (SINCE THOSE ARE INTERVAL DATASETS). */ %INCLUDE SOURCLIB(ASUMDB2A); /*BUILD PDB.ASUMDB2A FROM DB2ACCT*/ %INCLUDE SOURCLIB(ASUMDB2P); /*BUILD PDB.ASUMDB2P FROM DB2ACCTP*/ /*%INCLUDE SOURCLIB(ASUMDB2B); BUILD PDB.ASUMDB2B FROM DB2ACCTB*/ /*%INCLUDE SOURCLIB(ASUMDB2G); BUILD PDB.ASUMDB2G FROM DB2ACCTG*/ /*%INCLUDE SOURCLIB(ASUMDBSS); BUILD PDB.ASUMDBSS FROM DB2STATS*/ Thanks to Carolyn Saul, West Virginia Office of Technology, USA.
ASUMDB2A potentially longer arguments. ASUMDB2B -Macro variable DSETEXST=NO, defined/set in VMXGINIT, was ASUMDB2G incorrectly re-defined in VMXGSUM, ASUMDB2A, ASUMDB2B, ASUMDB2P ASUMDB2G and ASUMDB2P, preventing it from being changed VMXGSUM to YES by ANALDB2R, the only place it is currently used. Mar 13, 2011 Re-definitions are now removed from those five members. With DSETEXST=NO, VMXGSUM calls VGETOBS to determine if the input dataset exists, gracefully failing was an MXG Yüklə 28,67 Mb. Dostları ilə paylaş:
|