* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Oct 31, 2007 when it was found (and confirmed by RMF support) that it contained both CP and zIIP Engine CPU time, but MXG will always preserve the CP-Engine CPU times separately from the zIIP and/or zAAP engine CPU times. Thanks to Rodger Foreman, Acxiom, USA. Change 25.224 The tests for CPUTYPE IN ('2064'X ...) are revised to now VMAC7072 alternatively test for ZARCHMDE='Y', so that a new value VMXGRMFI for CPUTYPE does NOT have to be added to MXG's table. Oct 16, 2007 Previously, an unknown CPUTYPE was INCOMPATIBLE until Oct 27, 2007 it was added to the tables in these two members. The tests for CPUTYPE were needed to identify which data exists in some of the early CPU types, but now that IBM has added the bit for ZARCHMDE, it eliminates the need for a new MXG version when IBM has a new CPUTYPE. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 25.223 The variable HOST is increased to 32 bytes; the original VMACNMON length of 8 is insufficient for unix/AIX/linux host name. Oct 15, 2007 Thanks to Michael W. Wolke, Boeing, USA. Change 25.222 EXIT112 is the enhanced CICS INFILE EXIT for z/OS MXG EXIT112 that reads compressed SMF 110 and SMF 112 records, but it Oct 13, 2007 is temporary, as it will replace EXITCICS when a site reports successful production sites with both records. EXITCICS is running in production at several sites. EXIT112 is an extension to EXITCICS, and EXIT112 has been tested, but only with a small SMF file. I recommend that EXIT112 be installed instead of EXITICS, and ask that you confirm successful processing compressed 110 and 112 data so that I can remove EXIT112 and rewrite this change.
EXTVW001- ten new datasets. Many VMW metrics are the same as their EXTVW010 Solaris and RedHat Linux counterparts, but with different FORMATS variable names because not all exist and they are created IMACTNG in different orders. While "TNG" still must be the suffix VMACTNG for the MXG code members, the dataset labels of all "TNG" VMXGINIT datasets are now changed to "NSM". New VM Ware datasets: Oct 13, 2007 DATASET DDDDDD DESCRIPTION VW001 VW001 NSM CA CPU GROUP VW002 VW002 NSM CA FILE SYSTEM VW003 VW003 NSM CA INTERFACE GROUP VW004 VW004 NSM CA KERNEL CONFIG GROUP VW005 VW005 NSM CA MEMORY GROUP VW005 VW005 NSM CA NETWORK GROUP VW007 VW007 NSM CA PER CPU GROUP VW008 VW008 NSM CA SWAP GROUP VW009 VW009 NSM CA PROCESS GROUP VW010 VW010 NSM VIRTUALIZED ENVIRONMENT Thanks to Xiaobo Zhang, CheckFree, USA.
ANAL91 it was changed in ANAL91, incorrectly, in an unneeded and Oct 11, 2007 redundant and now removed LABEL statement. Thanks to Dave Krouse, IBM, USA. Change 25.219 TYPE74CA variable FWDC was replaced some time ago, but VMAC74 the label was not corrected; the variable is labeled now: Oct 11, 2007 FWDC ='DASD F/W*BYPASS*COUNT*R745DFWB' Thanks to Ed Woodward, UPS, USA. Change 25.218 Support for local CICS USER field CMODHEAD,CMODNAME=TRADE IMACICU5 creates variable TRADEU5 in CICSTRAN, when enabled. VMAC110 Jul 3, 2008: Field was increased to 80 bytes; the test UTILEXCL and INPUT were also increased to 80. Oct 11, 2007 Jul 3, 2008 Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
VMACPRPR lost. Originally support for the '1620' record was added Oct 10, 2007 June 12, and test records had different delimiters in date/time fields, so INPUTs were changed in MXG, but now I see that no other record's date/times were changed. This change, which was included in MXG 25.10, reverted date/times for all other records to the original format, but created a separate path to decode 1620 subtypes. Thanks to Siegfried Trantes, IDG, GERMANY.
IMACICEZ been enhanced and documentation revised for clarity: IMACICE1 IMACICE2 -IMACICEZ always has these 5 fields, identified by their VMAC110 CMODNAME='EZA01' and CMODTYPE='S': Oct 11, 2007 Jun 13, 2008 EZA01 S 001 12 ooo INIT EZA01 S 002 12 ooo READ EZA01 S 003 12 ooo WRITE EZA01 S 004 12 ooo SELECT EZA01 S 005 12 ooo OTHER
CMODLENG=8, but IMACICEZ supports both lengths, so you just remove the comment block to tailor IMACICEZ and it will process data with either or both lengths. -IMACICE1 can have up to 13 fields, identified by their CMODNAME='EZA01' and CMODTYPE='A' (yes, CMODNAME is the same 'EZA01' as IMACICEZ, but the CMODTYPE is different):
EZA01 A 002 4 ooo TREAD EZA01 A 003 4 ooo TWRITE EZA01 A 004 4 ooo TSELECT EZA01 A 005 4 ooo TOTHER EZA01 A 006 4 ooo REUSABLE EZA01 A 007 4 ooo ATTACHED EZA01 A 008 4 ooo OPENAPI EZA01 A 009 4 ooo TCBLIM EZA01 A 010 4 ooo TREUSABL EZA01 A 011 4 ooo TATTACHE EZA01 A 012 4 ooo TOPENAPI EZA01 A 013 4 ooo TTCBLIM
last CMODHEAD field 'EZA01' instead of the names shown) to know how many fields are in your data. If you have the expected 13 fields, then you just remove the one comment block. If you have fewer fields, then: - Change the IF xxxx GE 52 THEN DO; statement so its test value is 4 times the number of fields, e.g. with seven fields change the "52" to "28". - Change the INPUT statement's suffix from EZA01A13 to the number of fields you have; if there are seven: INPUT (EZA01A01-EZA01A07) (&PIB.4.) @; - Delete the LABELs for variables that don't exist. -IMACICE2 has 22 fields with z/OS 1.7 TCP/IP data, but had only 11 fields with z/OS 1.4, which are identified by the CMODNAME='EZA02' and CMODTYPE='A: EZA02 A 001 4 330 CONN EZA02 A 002 4 331 STARTED EZA02 A 003 4 332 INVALID EZA02 A 004 4 333 DISTRAN EZA02 A 005 4 334 DISPROG EZA02 A 006 4 335 GIVESOKT EZA02 A 007 4 336 SECEXIT EZA02 A 008 4 337 NOTAUTH EZA02 A 009 4 338 IOERR EZA02 A 010 4 339 NOSPACE EZA02 A 011 4 340 LENERR EZA02 A 012 4 341 TCONN EZA02 A 013 4 342 TSTARTED EZA02 A 014 4 343 TINVALID EZA02 A 015 4 344 TDISTRAN EZA02 A 016 4 345 TDISPROG EZA02 A 017 4 346 TGIVESOK EZA02 A 018 4 347 TSECEXIT EZA02 A 019 4 348 TNOTAUTH EZA02 A 020 4 349 TIOERR EZA02 A 021 4 350 TNOSPACE EZA02 A 022 4 351 TLENERR You will HAVE to look at UTILEXCL REPORT THREE to confirm if you have 22 or 11 fields, and remove only one of the two comment blocks in IMACICE2 to tailor it. -You create REPORT THREE with the _RPTEXCL macro run with or after your UTILEXCL execution: //SYSIN DD * %INCLUDE SOURCLIB(UTILEXCL); _BLDDICT; _BLDEXCL; _RPTEXCL; -The only actual change made was to update VMAC110 to keep the EXA01A13 13th variable.
VMXGUOW caused CHARACTER OPERAND IN %EVAL FUNCTION errors. Oct 7, 2007 Also, parameter HOWDEEP added to set kept array sizes.
TSOIDMS on,using IBM SMF 30 and IDMS PERFMON USER SMF records. Oct 6, 2007 Thanks to Pat Curren, Supervalu, USA. Change 25.213 Documentation only. DB2 variable THREADTY shouldn't have VMACDB2 been added to DB2ACCTP dataset (Change 25.097), because Oct 7, 2007 DB2 V8.1 writes all Package data in IFCID=239 (ID=101.1) records, which do not contain a QLAC segment, and IBM's THREADTY definition (in comments for QWHDRQNM field in their DSNWMSGS member of the DB2 Macro Library) compares QWHDRQNM with QLACLOCN. Since I can never safely remove a variable, it will still exist in DB2ACCTP, but it will always be blank in that dataset. No code was changed.
VMACSYNC sum of VSCORET plus the GDSM Adjustment, so its label Oct 6, 2007 is revised to be: Nov 17, 2007 SYNCUSET='CORE USED*TOTAL*VSCORET*PLUS GDSM ADJ' -SYNCSORT added a new field, which MXG decodes as: SYNHWMPF='HIGHWATERMARK*PAGEFIXED*STORAGE*USED' where the old HPALLOC/HPUSED ESTORE BLOCKS was located. -All reserved and unknown fields in SYNCSORT SMF record are decoded, but none of these variables are kept: /* SYNRSV41-SYNRSV45 SYNUNK01-SYNUNK15 */ /* SYNCHFUT SYNCBFUT SYNXXXX1 SYNSPARE */
VMAC7072 corrected for Dedicated zIIP Engines. For Shared zIIPs, Oct 5, 2007 the LPAR Dispatch time is valid, but Dedicated engines report 100% dispatch. For TYPE70, the ZIPWAITM is used to correct ZIPACTTM, which corrects the other variables. Thanks to Jerry Cobb, American Century, USA. Change 25.210 -WARNING: LENGTH OF CHARACTER VARIABLE ACCOUNT1 HAS BEEN VMACSFTA SET under SAS V9 is issued ONLY when a LENGTH statement VMACDB2 changes the length of a character variable, and, like all VMACOPC WARNING: messages in SAS V9, z/OS sets Condition Code 4. VMACBE97 (Under V8, this specific WARNING did NOT set CC=4, VMAC7072 but V9 has tightened specs so WARNINGS always CC=4.) TRNDDB2S But it should never occur in MXG code: although there are ANALCISH multiple LENGTH statements, they should always set the Oct 4, 2007 same value. But it did occur when VMACSFTA was executed standalone, because the statement ACCOUNT1=XPUPNOAC; was located prior to the %INCLUDE of IMACACCT, which is where the LENGTH of ACCOUNT1 should always be defined. Relocating that ACCOUNT1=XPUPNOAC; statement eliminated the WARNING. -When WARNING for numeric vars (eg. QB1TALX) were printed, I discovered there were six members that had hard-coded values for LENGTH DEFAULT=4 that should have been changed to LENGTH DEFAULT= &MXGLEN; the were overlooked or added after Change 19.272, but now all are consistent so that numeric variables are stored 5 on z/OS and 6 on ASCII, except for the specific cases where length 8 is required. Thanks to Ron van der Zande, KLM Info Services, THE NETHERLANDS. Thanks to MP Welch, SPRINT, USA.
TIMEBILD application by SYSTEM of "SYNC59" timeshifting logic: TIMETABL - TIMEBILD now reads columns 71-72 of TIMETABL to INPUT VMXGTIME the (+ or -) number of minutes to be added for SYNC59. VMXGINIT That value is a part of the format built by TIMEBILD. VMXG70PR - %TIMEBILD must be executed first to create the table. Oct 5, 2007 - To enable the addition of SYNC59 offset, you must set %LET MXGTIM59=YES; and then you would run the program whose datetimes are to be shifted by both TIMEBILD zones and SYNC59. - The "SYNC59" option is intended to be used ONLY with RMF/CMF data, and in particular, for data from a CEC that has some systems SYNC59 and some SYNC00. It may not work with other programs, including BUILDPDB, as you may not want all records SYNC59'ed. And, if you now use the SYNC59 option in TIMEBILD, you must also change your ASUMxxx, TRNDxxxx, VMXGxxxx tailored code to now specify SYNC59=NO to prevent a double shift. - To process only the RMF data with a TIMETABL that has been updated to include the SYNC59 flag, you could use %LET MXGTIM59=YES; %TIMEBILD; %UTILBLDP ( BUILDPDB=NO, USERADD=70 71 72 73 74 75 76 77 78, ZEROOBS=74.1 74.5, INCLAFTR=RMFINTRV ASUM70PR, OUTFILE=INSTREAM); %INCLUDE INSTREAM; to build you RMF-only PDB Library (which will be small, as that example does NOT create observations in the two big TYPE74 and TYPE74CA datasets due to that ZEROOBS=). - TIMEBILD will PROC PRINT the input TIMETABL and the output TIMEBILD datasets by enabling MXGDEBUG: //SYSIN DD * %LET MXGDEBUG=1; %LET MXGTIM59=YES; %TIMEBILD; RUN;
%LET MXGDEBUG=0; - You can conditionally reset MXGTIME59 for some SMF data and not for others; for example, to enable for59 add, and you do NOT have to rerun TIMEBILD. %TIMEBILD(TIMEBILD=YES); %LET MACFILE=%QUOTE( IF ID=30 THEN CALL SYMPUT('MXGTIM59','NO'); ELSE CALL SYMPUT('MXGTIM59','YES'); ); %UTILBLDP(USERADD=7072 30,BUILDPDB=NO); %INCLUDE INSTREAM; -Once TIMEBILD worked to selectively SYNC59, the original problem, duplicate observations in PDB.ASUMCELP, could be diagnosed: while BY variable GMTOFFTM is correctly used to creating the "per-SYSTEM" datasets, it can never be used in the "per-CEC" datasets, because they are built from multiple SYSTEM's data, which can have multiple values in GMTOFFTM. Removing GMTOFFTM from the creation of PDB.ASUMCELP has eliminated the duplicates; I should remove GMTOFFTM where it makes no sense, but instead, I have set GMTOFFTM=. in ASUMCEC and ASUMCELP, so it will not create a VARIABLE NOT FOUND ERROR. Thanks to Ingegerd Jannson, Volvo, SWEDEN Change 25.208 CICS local user field CMONDNAME DAT008 CMODHEAD ENTRADA IMACICU4 creates new variable ENTRADA. VMAC110 UTILEXCL
Oct 1, 2007 Thanks to Jane Dickenson, Santander Produban UK, ENGLAND. Change 25.207 The NTSMF dataset LOGLDISK had the variables FREESPAC VMACNTSM (FREE MEGABYTES and PCTFRESP (PCT Free space) but the Sep 27, 2007 size of the volume did not exist until now, with the new DISKSIZE variable. Thanks to Michael Ryan, Acxiom, USA.
FORMATS was not in your //CONFIG DD statement in your MXGSASV9 CONFIGV8 JCL procedure, the PROC FORMAT failed to build MXGTNGON, CONFIGV9 because lines 12092 thru 12099 in FORMATS were low-case Oct 3, 2007 duplicates of preceding lines, that should not have been have been there, but they caused no error when the CONFIG member was present. Since they also caused the error if they were UPPERCASED, I assume the absence of the SAS CONFIG member caused them to be treated as UPCASE. Also, there were Macro Variable error messages because MERROR is a required option that is normally set in SAS CONFIG. To protect, MERROR is now added to CONFIGV9 and CONFIGV9. Thanks to Jim Wertenberger, Antares Solutions, USA.
VMAC7072 Z/OS 1.9 allows up to 54 CP engines in a single image, Sep 27, 2007 but SMF 70 records with CPUID=33 or higer caused ARRAY Oct 4, 2007 SIZE EXCEEDED with MXG 25.09 or prior. Now, CPUs with CPUID=33 thru CPUID=53 are supported in the PDB.TYPE70 dataset (the only MXG dataset altered due to 54-CPUs). Each CPUID has a set of variables in PDB.TYPE70; existing 0-32 CPUIDs variable names were created with suffix 0-9 and A thru X. Now, Y and Z are used for 33-34, and ZA thru ZS suffix are used for CPUIDs 35-53 variables. Where the variable name is 8 characters, that "Za" had to overlay the penultimate character in the name. To operate on these CPU-specific variable names, they are all defined in VMAC7072 with an ARRAY statement that you can cut and paste into your program to avoid spelling all those names. -Unrelated, discovered in testing: APAR OA18244 documented that the CPUC segment was increased to 116 bytes, but the APAR actually increased its length to 160 bytes, causing SMF70GJT and following variables to be missing value, as the MXG test was for EQ 116 (without APAR is EQ 102). Now, the test is for GE 160, as IBM RMF Development has confirmed the correct length, to be documented, is 160, adding 44 unused bytes of zeroes. This APAR applies to both z/OS 1.8 and z/OS 1.9. Thanks to Tony Curry, BMC, USA. Change 25.204 CFI Segmentation feature added for RMF III VSAM support, ASMRMFV which now eliminates the possibility of skipped CF data, VMACRMFV new ASM symbolics for tailoring, and additional items. Sep 25, 2007 Issues Resolved: Oct 3, 2007 -PROCCFI is now a subroutine to conserve the mainline Dec 4, 2007 base register. -CFI Table output is now segmented in response to reported problems by MXG users. This removes a long standing restriction that the size of the CFI table could not exceeding the 32K LRECL output maximum without data loss. -The RMFV005E error message could have overlaid text when multiple ASMRMFV parameter errors were detected. -Several problems with index data fields in the CFI table output record either not being set or set incorrectly that caused PDB build errors in VMACRMFV have been fixed during alpha code testing. Enhancements: -There are a pair of new option keywords BYTES/NOBYTES. These specify whether ASMRMFV should or should not provide byte counts for 5 categories of data read, decompressed, written, filtered, and skipped. The counts are provided in each RMF data set detail report and also as totals in the summary report. This feature is intended to aid users to understand the volume of data being processed by ASMRMFV, as a coarse comparison tool when using different versions of (or sets of keyword options with) ASMRMFV, and finally as a possible diagnostic aid. The alias for BYTES is BY and the aliases for NOBYTES is NOBY or -BY. The byte counts now appear in message RMFV104I and the former RMFV104I message is now RMFV105I. The distributed default is BYTES Packed decimal arithmetic is used for these counters to allow up to 15 decimal digits in magnitude or up to a value of 999,999,999,999,999 bytes. The assembler symbolic variable &BYTES is provided to allow the user to change the default for BYTES/NOBYTES to NOBYTES in the ASMRMFV source code. The distributed default is 'Y' meaning that BYTES is the default. These counters take little overhead to maintain and display. So there is little benefit in suppressing them except to reduce output report volume by 2 lines per data set. But that choice is certainly available. -A pair of new option keywords CFALL/CFMASTER is added in support of the CFI segmentation support. CFALL specifies that CFI tables from all input RMF III LPARs are to be output as in prior versions of ASMRMFV. CFMASTER specifies that by testing a particular flag that only data from the LPAR designated as RMF III Master Gatherer is to be output. The distributed default is CFALL. Effective use of CFMASTER requires that the RMF III parameter CFDETAIL be in effect in all LPARs in the Sysplex. Due to the IBM usage of this flag, using the CFMASTER option when RMF III NOCFDETAIL is in effect (IBM default) will cause all CFI records to be filtered out by ASMRMFV. CFALL has no alias. Aliases for CFMASTER are CFMAST and CFM. With CFDETAIL in effect only the single LPAR determined by RMF III to be the Master Gatherer collects all Coupling Facility detail data. So including incomplete CF data from the remaining LPARs may be an unnecessary and redundant overhead. The intent of CFMASTER is to automatically exclude this extra data. The &CFALL assembler symbolic is also provided to change the CFALL default in ASMRMFV source code if needed. The &CFALL symbolic can be changed in the ASMRMFV source to 'N' prior to assembly to permanently enable CFMASTER processing. The distributed default is 'Y'. Do not make this change unless using CFDETAIL on all LPARs being input to ASMRMFV.
-When CFMASTER is in effect the CFI table id in the RMFV105I message displays as CFIM instead of the usual CFI to indicate this option is in effect. -When the BUFFERS option is in effect the RMFV102I message will now display a count of both buffers available and used for each buffer pool type. This feature was intended mainly to enable MXG users to intelligently size the large VSAM LSR buffer pool used to optimize random RMF III data set read access by ASMRMFV. The distributed default is 5000. Unfortunately, at this time the VSAM SHOWCB macro seems to always return a 1 for actual buffers used in the LSR pool. Given the number of random I/Os typically issued this value seems suspect and requires further investigation. -Program logic for both buffer pool accounting and normal/filtered/skipped record output has been improved. -Documentation on the contents of fields for several messages has been improved to provide more details on their content and meaning. -ASMRMFV program prologue documentation is upgraded to document all related program changes. -Oct 3: corrected INPUT STATEMENT EXCEEDED; 1.8 CFI data ends with CFISCCOC in member VMACRMFV. -Dec 4: VMACRMFV restructured to output only the first CPUG3 segment to ZRBCPU; the ASMRMFV CPU segmentation creates a CPUG3 segment for each LPARNAME, which caused duplicate observations in WORK.ZRBCPU; using TYPSRMFV to sort ZRBCPU did remove those duplicate obs, but this change compares CPUHNAME with LPARNAME an outputs only the first instance for each interval. Thanks to Jerry Urbaniak, Acxiom, USA. Thanks to Ben Romano, Hewitt Associates, USA. Thanks to Lawrence Jermyn of Fidelity Investments, USA. Change 25.203 OPTIONS COMPRESS=NO was inserted in ASUMTALO back in 1995 ASUMTALO by Change 12.273, because the first (temporary) DATA step Sep 25, 2007 was extremely expensive, but then Change 12.273 was not recalled when MXG set COMPRESS=YES as the default value, so INCLUDEing ASUMTALO turned off compression for any subsequent programs. Now, VMXGOPTR is invoked to store your current value of the COMPRESS option, which is then reset prior to the creation of PDB.ASUMTALO, so it will be compress based on your choice of the COMPRSS option. Thanks to Patrick Holloman, Zions Bank Corp, USA. Change 25.202 ANALDB2R Statistics Reports VARIABLE QBnTDPIO NOT FOUND ANALDB2R and VARIABLE QLSTCRSR NOT FOUND errors because those Yüklə 28,67 Mb. Dostları ilə paylaş:
|