* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
speed in Bytes per second, and new PCHANBY variable is created. When ICEBERGs are shared across systems, you must choose data from only one system, since each system creates a replicated SMF record for each interval. Thanks to Chuck Hopf, MBNA, USA. Change 23.084 The UTILEXCL utility now has "standard" MXG macro tokens EXCICDIC _VCICDIC/_WCICDIC/_PCICDIC/etc instead of hard-coded name IMACICD8 for the CICSDICT dataset. UTILEXCL -Optional CANVRSN field is now supported in IMACICD8. VMXGINIT Apr 19, 2005 Thanks to Michael Oujesky, MBNA, USA.
VMAC7072 SMF 70 record is now kept in datasets TYPE70 and TYPE70PR Apr 18, 2005 as it describes the maximum engines this system could use perhaps as an upper bound on engines under IRD control. -The IFAWAITM and IFAWAIT0-IFAWAITX IFA*WAIT*DURATION variables have been reinstated in TYPE70 dataset, as it turns out they are useful in IFA analysis. Thanks to Art Cuneo, Health Care Service Corporation, USA. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
VMACDB2H with DB2 V8 record, so that I could see what IBM stored Apr 18, 2005 in QWHSLOCN when QWHSFLAG='80'X. Now, with this first instance of QWHSFLAG on, I can see that the text value in QWHSLOCN is simple ASCII data, so MXG's INPUT of the QWHSLOCN is now revised to INPUT either EBCDIC or ASCII based on QWHSFLAG. The IBM documentation for QWHSFLAG in the DSECT is "%U fields contain Unicode UTF-8)", which I assumed meant that QWHSLOCN would contain UNICODE data (i.e., 2-byte, DBCS text), but I've now googled UTF-8 and find that UTF-8 is an ASCII-preserving encoding method, so the INPUT with $ASCII16. is all that is needed! With the ERROR message, the only error is that the value in QWHSLOCN, Local Location Name, was trashed. Thanks to Ian Arnette, Toronto Dominion Bank, CANADA. Thanks to ??? , Toronto Dominion Bank, CANADA. Change 23.081 Changes in WLM Service Policy can be tracked by TYPE9024, VMAC90A now that the new policy name is input as SVPOLNSP from Apr 17, 2005 the IWMVSPOL DSECT. Thanks to Chuck Hopf, MBNA, USA. Change 23.080 Support for RMF III IFA data added by z/OS 1.6. New data VMACRMFV was added to ZRBASI and ZRBENC datasets. No change was Apr 17, 2005 required to the ASMRMFV program, which automatically sees and writes out the longer records. Thanks to Jerry Urbaniak, Acxiom CDC, USA. Thanks to Robert Vance, Zurich Insurance Company, USA. Change 23.079 INVALID DATA FOR MM in NDM NDMRTYPE='SS' SMF record. MXG VMACNDM input two bytes that should have been substringed from Apr 14, 2005 NDMSID0, which also should have been INPUT as $CHAR8 and formatted $HEX16 because it can have hex and character data. Thanks to Bernie Mazur, Bank of Montreal, CANADA. Change 23.078 The path activity report is enhanced to report the CMR ANALPATH (which can be significant for FICON channels) and the OTH Apr 14, 2005 pend time in separate columns on the report. Thanks to Tony P. Steward, CSC, ENGLAND. Change 23.077 ***ERROR.TYPE110.SUBTYPE 2. CICS STAT RECORD STID=106. VMAC110 MXG missed an 8-byte reserved field before PIWPGMNM, and Apr 13, 2005 incorrectly only "skipped" 1160 bytes of the 1168 STILEN. Apr 15, 2005 The last three variables, PIWPGMNM, PIWCONNM, PIWUSECT in dataset CICPIW were wrong. Thanks to Roland Schiradin, Alte-Leipziger, GERMANY. Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.
TYPSTHST created by BMC's DB2 THRDHIST file contain a standard Apr 12, 2005 triplet for the first 10 packages, like an IBM IFCID 0003 record, but then, additional segments are written to the end of the 32752 byte record. Unfortunately, there is only room for 69/70 segments. Instead of writing a valid IFCID 289 record with additional segments, THRDHIST puts part of the next segment, as many bytes as fit, to fill the records (splitting in the middle of a field!), and then creates a new record, without header, with the rest of that segment, followed by the remaining packages. This is an invalid architecture, to split fields across physical records. Until BMC redesigns its file, the best MXG can do is to process those 69 or 70 segments that are complete, and report with a message to the SAS log that additional package segments existed but could not be processed. (Prior to this change, MXG tested the triplet to ensure MXG did not read beyond the end of the record, but when the product of number of segments times their length exceeded the record size, all packages were just skipped, without an error message). Thanks to Bernd Rueckrich, R & V Versicherung AG, GERMANY Change 23.075 -UTILEXCL. Optional CMODNAME='RMI',CMODHEAD='DB2CLOCK' UTILEXCL did not generate an UNKNOWN FIELD SKIPPED message, and IMACICUS did not skip that field in the created IMACEXCL code. Apr 11, 2005 The MXG code for a CMODNAME='RMI', with multiple fields, decoded in IMACICRM was revised to recognize this new RMI variant (which is not to be confused with yet another RMI-containing segment with CMODNAME='DFHRMI' that is supported in IMACICRD! -IMACICUS. Cosmetic; comments were clarified. Thanks to Christen Ole Christiansen, IBM, DENMARK. Change 23.074 This Analysis of FICON Open Exchanges is based on work by ANALFIOE Dr. Pat Artis that was documented in Change 21.087. He Apr 11, 2005 has revised his calculation, slightly, by inclusion of the new DLYCMRTM, the Command Response Time, which is a subset of PEND time that occurs after the channel has selected the I/O for processing, in his note "Managing Complex FICON Configurations." DLRCMRTM is added to the calculation by this change. Thanks to Scott Barry, SBBWorks, USA. Thanks to Mike Crowder, Humana, USA. Change 23.073 Variable MODEL, taken from DEVMODEL, is a numeric value ASUMCACH that is added to the BY list in TRNDCACH to provide more TRNDCACH granularity in the summarization. All values of MODEL Apr 10, 2005 are numeric (3390 33903 33909), but this revision will need revision if a non-numeric DEVMODEL is ever created. Thanks to Diane Eppestine, SBC, USA. Change 23.072 Support for APAR OA09921 for IBM TotalStorage DS6000 adds VMAC78 the Preferred Pathing Function, with these new variables VMAC79 in type 78 subtype 3 records: Apr 10, 2005 -TYPE78CF - R783CPAT - PATH*ATTRIBUTES -TYPE78CU - LCUDST - DATA STATUS BITS -TYPE78IO - R783CSS - CHANNEL SUBSYSTEM ID. and in type 79 subtype 14 records -TYPE79E - R79ECPAT - PATH ATTRIBUTESS -TYPE79E - LCUDST - DATA STATUS BITS
VMXGRMFI PDB.ASUM70LP, and PDB.ASUMCEC. However, you have to be VMXG70PR careful in understanding how IFAs are reported; they are VMXGDUR much like CPs when they are shared across LPARs: Apr 16, 2005 - "System-level" datasets (RMFINTRV/ASUM70PR/ASUM70LP) can NOT provide accurate utilization of shared IFAs. If you have 4 shared IFAs and two MVS systems, these system obs do have the IFAACTTM (IFA CPU time) used by that SYSTEM/LPAR, but each obs will also show there were 4 IFAs, so any percent-used calculation will be only this system's part of the utilization of all four installed shared IFAs. - "CEC/CPC-level" dataset PDB.ASUMCEC does correctly sum the IFAACTTM across all systems running on that CECSER, and the PCTIFABY in PDB.ASUMCEC is the correct percent utilization of all four IFAs by both LPARs. -VMXGDUR was enhanced with operands for interval values of 10-minute and 5-minute. Thanks to Scott Weiner, WPS Insurance Corporation, USA.
VSETZERO exact-on-the-minute value that you thought you'd get when VMAC7072 SYNC(SMF) is specified in ERBRMFxx member of parmlib: VMAC71 "When RMF Monitor I runs with SYNC(SMF) option, RMF VMAC73 will be triggered by SMF via ENF37 at the end of the VMAC74 SMF interval. SMF sends this ENF37 signal shortly VMAC75 before the interval end, and RMF starts its interval VMAC76 processing after receiving that signal. During this VMAC77 interval processing, RMF sets the interval start time VMAC78 for the next interval in the SMFxxIST field, and you VMAC79 must expect some deviation in SMFxxIST time values; VMACCMF since SMF ENF37 is sent shortly before the interval VMACEPMV end, SMFxxIST times can also be earlier than the end. Apr 10, 2005 If you use SMFxxIST field data, which only have one second granularity, you must plan to tolerate small deviations in SMFxxIST times." per Peter Muench, IBM RMF Development, Germany. IBM's SMFxxIST is the STARTIME variable in MXG RMF data. Data with STARTIME at :59 seconds instead of :00 caused the HOUR of the STARTIME to be one hour early, so with IBM's note that STARTIME cannot be guaranteed to be the expected exact minute, it is now up to MXG to detect and correct STARTIME in your RMF datasets. -New VSETZERO member is %INCLUDEd in all RMF-processing code members to detect that seconds of STARTIME were 58, 59, or 01, and it resets the STARTIME to the exact correct hour:minute:00 value. -Note that it is still possible to have STARTIME values that are not exact minutes; for example, the value in Change 23.069 of 19:59:40 would not be changed. Thanks to Wolfbang Vierling, Allianz, GERMANY. Thanks to Bernd Tekath, Allianz, GERMANY. Change 23.069 -RMF Interval less than one minute caused incorrect data VMXG70PR in PDB.ASUMCEC, because MXG logic recalculated STARTIME Apr 9, 2005 (only for PDB.ASUMCEC) to the nearest exact minute value. The STARTIME was 19:59:40 and DURATM was 19 seconds, due to a WLM Policy Reset just before 20:00:00, with a normal 15 minute interval with STARTIME of 20:00:00, but the obs in PDB.ASUMCEC had STARTIME of 20:00 with DURATM=19 secs, and all the calculated PCTxxxxx values were all wrong. This change removed the code in VMXG70PR that modified STARTIME for PDB.ASUMCEC, which corrected the error due to the short interval data, but ONLY because all of the SYSTEMS on this CEC had identical short intervals, and because MXG default _DURSET in IMACRMFI was in effect, causing each original STARTIME value was to be output (i.e., no summarization to a new INTERVAL was requested). The result was that there were two observations created in PDB.ASUMCEC, one with its STARTIME of 19:59:40 and DURATM of 19 seconds, and one at STARTIME of 20:00:00 with DURATM of 15 minutes, and each was valid, because all of the SYSTEMs had the same short interval data. -But if you want PDB.ASUMCEC summarized so that only one observation is created at the "expected" 15-minute DURATM then you must tailor the IMACRMFI member to set STARTIME to the 15 minute time, and then that short interval will be summed into a 19:45 STARTIME with DURATM of 15 min. -BUT PDB.ASUMCEC WILL ALWAYS BE WRONG IF YOU HAVE SYSTEMS ON THE SAME CEC WITH DIFFERENT DURATM VALUES, IF ANY OF THOSE DURATMs ARE GREATER THAN THE IMACRMFI INTERVAL YOU REQUESTED. For example, if systems have 15 minute and hourly RMF data on the SAME CEC, PDB.ASUMCEC dataset has an observation on the hour with DURATM of 60 minutes, but there will also be hour:15, hour:30, and hour:45 STARTIME observations with DURATM of 15 minutes, and all of that data in PDB.ASUMCEC is likely wrong. Only if you set the IMACRMFI summarization to hourly can MXG create a valid PDB.ASUMCEC dataset from that kind of mixed DURATM data. -Note that it is ONLY the PDB.ASUMCEC dataset that had any problems; whether you have short DURATM or mixed DURATMs, the PDB.ASUM70PR and PDB.ASUM70LP datasets were always correct, since they are summarized by SYSPLEX SYSTEM. Nov 10: Not True. See Change 23.289 which is needed. -The IMACRMFI default tailoring sets the interval for the PDB.RMFINTRV, PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC datasets, but that can be overridden if you have tailored either the ASUM70PR member or the RMFINTRV member to use their INTERVAL= arugment, instead of changing IMACRMFI. Setting the INTERVAL= or IMACRMFI work equally well. -Change 21.315 reset the STARTIME in VMXG70PR for ASUMCEC, but the Change 23.070 enhancements eliminates both that need and this exposure, so that code was safely removed Thanks to Diane Eppestine, SBC, USA.
VMAC26J3 MXG Change 22.365 fixed the problem for JES2 BUILDPDB and Apr 9, 2005 this revision fixes the problem for JES3. Two changes were needed; JOBCLASS is now input as J3CLSONE as $1 and then stored into JOBCLASS, and the initial reference to ACCOUNT1 was relocated after the include of IMACACCT so the length would be set by your IMACACCT tailoring. An extremely-rare-in-MXG GOTO was used to preserve the flow of execution. Nov 3: This did not work as expected and caused zero observations in TYPE26J3; corrected in Change 23.282, added in MXG 23.09. Thanks to Diane Eppestine, SBC, USA.
VGETDDS cause this MXGERROR: message to be printed on the log: VGETDDS VGETxxxx IS BACK-LEVEL AT 23.01, WHICH IS EARLIER VGETDSN THAN THE EXECUTING MXG VERSION OF 23.02.... VGETENG Disregard for those members; they were not updated when VGETSORT MXG 23.02 was created. Apr 9, 2005 -Also, the message text now prints MXGWARN: vice ERROR.
EXTY8028 dddddd Dataset Description EXTY8029 TY8028 TYPE8028 RACF EVT 28 DIRECTORY SEARCH EXTY8030 TY8029 TYPE8029 RACF EVT 29 CHECK ACCESS TO DIR VMAC80A TY8030 TYPE8030 RACF EVT 30 CHECK ACCESS TO FILE VMXGINIT
Apr 9, 2005 Thanks to Peter Schubert, CITEC, AUSTRALIA Change 23.065 -Variable EXPCTSRD in dataset VXSTOASP was not VMACVMXA deaccumulated, but now it is. Apr 8, 2005 -Variable TCMMIDSZ was changed to bytes by 20.04, but Apr 10, 2005 its label still had PAGES instead of BYTES. -Variables PFXSPINC and PFXSPINT were incorrect because their deaccumulation assumed descending order, but these two variables are accumulated in ascending order. Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY. Thanks to Brian Crow, BT, ENGLAND.
VMAC78 jobs, only contained subpool information below the 16MB Apr 8, 2005 line (because I thought a subpool was either above or below when I wrote that code years ago!). Now, variables SUBPOOL5-SUBPOOL9 are created, and they will be populated if the subpool for this job allocated above-16MB-space. -The storage variables were not in a LENGTH .. &MXGBYLN statement, so their stored length was the MXG default of 4 bytes, which could have caused small truncation if the value was large (e.g., 999M instead of 1G). They all now have the correct length set in a LENGTH statement. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 23.063 Cosmetic. Label is now ACTRELAP='ELAPSED*TIME'. Label VMACENTX for prior variable had been copied incorrectly. Apr 5, 2005 Thanks to Chris Taylor, GMAC Insurance, USA. Change 23.062 Variables SRMWSSDL, SRMWSSD1, SRMWSSD2, SRMWSSD3 in VMACVMXA VXSYTSCG are working set sizes, but were still in pages, Apr 5, 2005 which is inconsistent with other z/VM working set size variables, so they are now converted to bytes and formatted MGBYTES. Thanks to Kris Ferrier, State of Washington DIS, USA. ====== Changes thru 23.061 were in MXG 23.02 dated Apr 4, 2005========= Change 23.061 The SEQENGINE=V9SEQ is now set in CONFIGV9 for z/OS. You CONFIGV9 must be at SAS V9.1.3, or you must have HotFix SN-012437 Apr 3, 2005 if you are using SAS V9.1 or V9.1.2, but almost everyone is now installing V9.1.3, so I deem it safer to use V9SEQ now. The problem is that using V6SEQ does not work when character variables are greater than 200 bytes, and there are many new variables that need to be 255 or greater; clinging to V6SEQ because you've not installed a Hot Fix is not fair to all the smarties that are using V9.1.3. If you've not installed that Hot Fix and are still using V9.1/V9.1.2, then you MUST change the V9SEQ in CONFIGV9 back to V6SEQ (you cannot use V8SEQ with SAS Version 9). If you want all the historic details of which sequential engine did what, you can search CHANGESS and NEWSLTRS members for V9SEQ for the litany of iterations on what works and what doesn't work. (While we can tell that you are at 9.1.3, for sites still back on 9.1/9.1.2 we cannot tell if you have the hot fix installed.)
ADOCVMXA -Nine new "standard" MONWRITE datasets are created: EOAPLCMS Domain Record dddddd Dataset Description EOAPLTC0 1 18 MTRCCC VXMTRCCC CPU Capability Change EOAPLTC1 2 11 SCLIOP VXSCLIOP I/O Priority Changes EOAPLTC2 5 8 PRCIOP VXPRCIOP IOP Utilization EOAPLTC3 6 21 IODVSW VXIODVSW Virtual Switch Activity EOAPLTC4 6 22 IODVSF VXIODVSF Virtual Switch Failover EOAPLTC5 6 23 IODVSR VXIODVSR Virtual Switch Recovery EOAPLTC6 6 24 IODSZI VXIODSZI SCSI Device Activity EOAPLTC7 6 25 IODQDA VXIODQDA Activate QDIO Device EOAPLTC8 6 27 IODQDD VXIODQDD Deactivate QDIO Device EOAPLTC9 -Eight existing MONWRITE datasets have new variables: EOAPLTCA Domain Record dddddd Dataset EOAPLTCB 0 8 SYTUSR VXSYTUSS EOAPLTCC 2 4 SCLADL VXSCLADL EOAPLTCC 2 5 SCLDDL VXSCLDDL EOAPLTCD 2 6 SCLAEL VXSCLAEL 3 12 STOASC VXSTOASC EOAPLVMR 4 1 USELON VXUSELON EXAPLSL0 4 9 USEATE VXUSEATE EXAPLSLM 4 10 USEITE VXUSEITE EXAPLSLN 6 26 IODQDS VXIODQDS EXAPLSLP -Domain 10 (Application Server) logic was revised; the EXIODQDD separate decoding of Sample and Event data under two EXMTRCCC separate internal macro pairs (_VAPLSDT,_CAPLSDT) and EXPRCIOP (_VAPLEDT,_CAPLEDT) was replaced with a single internal EXSCLIOP pair (_VAPLAPL,_CAPLAPL) because "Configuration Class" FORMATS data for TCP/IP can be either Sample or Event, or both. IMACVMXA -These new datasets are created from domain 10 records: VMACVMXA Source: CMS APPLDATA MDGPROD=5684030MT1020100 VMXGINIT MXG Dataset VXAPLCMS 'CMS Multitasking' Apr 3, 2005 Source: TCP/IP MDGPROD=5735FALSTx0ttt00 Multiple MXG datasets are created, based on the hex value "x" in MGDPROD: x Dataset Description 00 VXAPLTC0 TCP/IP MIB Record 01 VXAPLTC1 TCP/IP TCB OPEN Record 02 VXAPLTC2 TCP/IP TCB CLOSE Record 03 VXAPLTC3 TCP/IP Pool Limit Configuration 03 VXAPLTCX TCP/IP Pool Data 04 VXAPLTC4 TCP/IP Pool Size 05 VXAPLTC5 TCP/IP LCB Link 06 VXAPLTC6 TCP/IP UCB OPEN 07 VXAPLTC7 TCP/IP UCB CLOSE 08 VXAPLTC8 TCP/IP Link Definition 09 VXAPLTC9 TCP/IP ACB 0A VXAPLTCA TCP/IP CPU 0B VXAPLTCB TCP/IP CCB 0C VXAPLTCC TCP/IP Tree Size 0D VXAPLTCD TCP/IP Home 0E VXAPLTCE TCP/IP IPv6 Home Source: VMRM MDGPROD=5739A03RM0000000 MXG Dataset VXAPLVMR 'VMRM Workloads' Most of these new datasets have been tested with data, but some of the de-accumulation may be incomplete, as I only have a few observations in some of the TCP/IP data. If you want to use the new data, especially TCP/IP stuff, please contact support@mxg.com to send your MONWRITE data so we can investigate these new metrics together. -ADOCVMXA notes were revised; Richard Steele's paper from 1988 was changed into plain text, without control chars, and moved to the top of the member, and IBM Manuals that show you how to set up the MONWRITE Virtual Machine and its Saved Segment are now references to make it easier to enable and gather the MONWRITE data from z/VM. Change 23.059 -z/VM format MGVXCMG had wrong values for CSCCMCMG, the VM FORMATS Channel Measurement Group, which should have been values Mar 31, 2005 1-ESCON, 2-FICON, 3-HiperSockets for z/VM, like z/OS. Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY. Change 23.058 Cosmetic. Comments referencing Change 22.050 should have VMACHMF been 20.018, and Change 22.162 should have been 22.168. Mar 31, 2005 Thanks to Larry Stahl, IBM Global Services, USA. Change 23.057 UTILBLDP enhancements. The USERADD= xxxx text required UTILBLDP you to list the "product suffix" xxxx value (e.g., 7072) Mar 30, 2005 but if you only listed part of the suffix (USERADD=70), incorrect code was generated and you got errors. Now, the USERADD= argument can either be the product suffix, or an SMF record number processed by that product. And, if you should list duplicate entries (USERADD=7072 72,) UTILBLDP is now smart enough to remove the duplicates. Thanks to Jake M. Drew, MBNA, USA.
VMAC102 only the first segment, and the DBID/OBID were formatted Mar 30, 2005 only as $HEX2 when they should have been $HEX4. Thanks to Karthik Vinayagam, Morgan Stanley, USA. Change 23.055 Variable DSEXCP: the label should have been EXCP*COUNT* VMACCTLT SINCE*CREATED, rather than USE*COUNT*SINCE*CREATED. Mar 30, 2005 Thanks to Stephen Hahne, Capital One Financial Services, USA. Change 23.054 All z/VM variables that had "SLOTS" in their label are VMACVMXA now corrected to contain "BYTES" in their labels, as all Mar 30, 2005 of the variables had already been converted from a count of 'slots' to the count of 'bytes'. These variables also had been correctly formatted with MGBYTES format; it was only their label that was incorrect. Thanks to Kris Ferrier, State of Washington DIS, USA.
VMAC119 Local time zone, and their labels all have "GMT" removed. Mar 25, 2005 TTETIME and TITIME were converted to local but had wrong Yüklə 28,67 Mb. Dostları ilə paylaş:
|