* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
WQGETDVA'=SUCCESSFUL DESTRUCTIVE GETS' WQGETJCE'=ELAPSED WAIT*FOR FORCE*JOURNAL GETS' WQGETJCN'=NUMBER OF FORCE JOURNAL GETS' WQMAXQDP'=MAXIMUM ENCOUNTERED QUEUE DEPTH' WQPUT1JE'=ELAPSED WAIT*FOR FORCE MQPUT1*JOURNAL WRITES' WQPUT1JN'=FORCE MQPUT1 JOURNAL WRITES WQPUT1PW'=MQPUT1 CALLS WHERE MSG PASSED' WQPUTJCE'=ELAPSED WAIT*FOR FORCE*JOURNAL WRITES' WQPUTJCN'=FORCE JOURNAL WRITES' WQPUTPWG'=NUMBER OF MQPUT CALLS WHERE MSG*PASSED' WQSETJCE'=ELAPSED WAIT*FOR SET' WQSETJCN'=NUMBER OF SET' Thanks to Victoria Lepak, Aetna, USA. Change 23.346 Documentation example; to add DB2 102 records to BUILDPDB IMACKEEP and to create the T102S022 T102S044 T102S063 datasets and Feb 13, 2006 copy them into the //PDB library you would use: %LET MACKEEP=%QUOTE( MACRO _CDEUSER _HDR102 _C102022 _C102044 _C102063 _C102105 _END102 % MACRO _VARUSER _V102022 _V102044 _V102063 _V102105 % ); %LET EPDBOUT=%QUOTE( RUN;
PROC COPY INDD=WORK OUTDD=PDB;SELECT T102: ; RUN;
); %INCLUDE SOURCLIB(VMAC102); %INCLUDE SOURCLIB(BUILDPDB); We're not sure why both RUN; statements are required, but the PROC COPY doesn't execute without them. Thanks to Ricci Hsial, China Trust, TAIWAN. Change 23.345 Enhancement for the %READDB2 utility to read DB2 records. READDB2 New WANTONLY option lets you create observations only in Feb 13, 2006 selected datasets, with sub-options to DROP or KEEP the variables you want in that dataset, and logic to choose which observations are output. See documentation in the comments, but for example. %READDB2(IFCIDS=ACCOUNT,WANTONLY=DB2ACTB, DB2ACTB=YES/IF QBACGET GT 0); would create observations only in the DB2ACCTB dataset, and only if the observation had non-zero GETS count. Change 23.344 The KEEP= list for dataset FICON73 needed SYSNAME added, ANALFIOE as a result of the RMF changes in MXG 23.11. Feb 10, 2006 Thanks to Brian Crow, British Telecom, ENGLAND. Change 23.343 MXG 23.11. PDB.TYPE72GO NOT SORTED. Several BY statements VMXGRMFI had only BY SYSPLEX SYSNAME STARTIME; but the correct BY Feb 10, 2006 list is BY SYSPLEX SYSTEM SYSNAME STARTIME;. This error only occurred when SYSTEM and SYSNAME were not the same. Thanks to Paul Naddeo, FISERV, USA.
IMACICD9 Field/Variable Label IMAC IMACICC1 CANFLAGS CANDLE*UMBRELLA*FLAGS IMACICD9 IMACICC2 CANGMTOF CANDLE*GMT*OFFSET IMACICC1 IMACICC3 CANUMBTR CANDLE*UMBRELLA*TRANID IMACICC2 IMACICC4 CANUMBUS CANDLE*UMBRELLA*PROGRAM IMACICC3 UTILEXCL CANUSRWK CANDLE*UMBRELLA*USER*WORKAREA IMACICC4 VMAC110 The UTILEXCL program must be used to create a tailored Feb 8, 2006 IMACEXCL member, and the UTILEXCL output tells you which Feb 15, 2006 of the IMACICxx members also must be EDITed to create the optional variable(s) in the CICSTRAN dataset. Thanks to John Shuck, SunTrust, USA. Change 23.341 CICS Statistics dataset CICSJR variable SJRPRXMX, the XMX VMAC110 value, was read as an 8-byte binary value, but the field Feb 5, 2006 contains either blanks or '32M ' in EBCDIC text, and reading text fields as binary gets large values: input field read as binary decimal exponential 8-bytes of blanks 4.6*10**18 'F3F2'x -32- in first bytes 17.5x10**18 4-bytes of hex FFx 4,294,967,294 4x10**9 4-bytes of FFx 1,077,952,576 1x10**9 Now, new character variable SJRPRXCH is the text field, which is parsed and decoded into the original numeric variable SJRPRXMX, now formatted MGBYTES. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. ====== Changes thru 23.340 were in MXG 23.11 dated Feb 2, 2006========= Change 23.340 MXG support for Omegamon for DB2 Archive file records. VMACOMDB -A short IFCID 44 record caused INPUT STATEMENT EXCEEDED; Feb 2, 2006 the record was only 350 bytes, and contained none of the actual IFCID 44 data fields; MXG now INPUTs the first 350 and tests to see if there is any more before INPUTing. -IFCID 63 had a fixed INPUT of $5000 for the SQL text, which caused INPUT STATEMENT EXCEEDED error when there was a shorter text. This statement was taken as-is from Candle's SAS code in 2003, but apparently no IFCID 63 data had been tested before by an MXG user or Candle! The MXG logic now INPUTs using VARYING informat Thanks to Rosaline E. Howe, IBM Global Services, USA. Change 23.339 -Harmless DIVIDE BY ZERO because TOTSHARC was not tested VMAC7072 to be non-zero, but results are still fine; the variables Feb 2, 2006 LPARSHAR and LPARSHAC will be missing when TOTHARC=0. -SHIFTHRS references in DROPs removed as it doesn't exist. -Missing labels, and other RMFINTRV cosmetics cleaned -TEST70SP did not include VMXGRMFI for NEWRMFI compare, which caused many false positive comparison differences. Thanks to Bruce Widlund, Merrill Consultants, USA. Thanks to Chris Weston, SAS ITRM Cary, USA.
ASMTAPEE event trace to the STK user exit in ASMHSCEX; we now have ASMHSCEX excellent cooperation with STK developers who are working Feb 1, 2006 with "asmguy" to install ML-38 at STK so we can diagnose why we miss so many mounts in that user exit. -ASMTAPEE corrects MXGC009E Unrecoverable error messages; the error was introduced back in ML-30 with the Volume mount enhancement, but only one site has reported only two instances, and it was with ML-37. -ML-38 also corrected 0C4 ABEND during processing of an IEC6000I reply message in offline device allocation. This note added Feb 21. Thanks to Keith McWhorter, Georgia Technology Authority, USA.
VMAC7072 PLATBUSY,PLATCPUS,TOTSHARE,TOTSHARC,LPARSHAR,LPARSHAC VMXG70PR can occur, even with Jan 31 MXG 23.11, but only if there VMXGRMFI were short intervals, as when an LPAR is started/stopped, Feb 2, 2006 or as when a Policy Change is issued, which wrote two short intervals (an 8:45 STARTIME with a 2 minute DURATM, an 8:47 STARTIME with 13 minute DURATM). -Previously, those variables were extracted by ASUM70PR from PDB.ASUM70PR dataset and merged into PDB.RMFINTRV; however the rewrite in Change 23.322 to ASUM70PR uses the SMF70GIE time interval (9:00 in the above example), but the PDB.RMFINTRV is created for each of the STARTIME values, so all of the old logic was moved from VMXG70PR into the VMAC7072 and VMXGRMFI members. -So: ASUM70PR no longer updates PDB.RMFINTRV. -This, too, was not a trivial revision. The biggest difficulty with this change was validation; these short intervals created invalid data in the old ASUM70PR/ASUMCEC datasets, which now have fewer obs than the old MXG version, so this change was filled with false positive differences in the PROC COMPARE output! Thanks to Diane Eppestine, AT&T Services, Inc, USA. ====== Changes thru 23.336 were in MXG 23.11 dated Jan 31, 2006========= Change 23.336 Support for RMF with repeated SYSTEM names in a SYSPLEX. VMAC7072 Variable SYSNAME (SMF70SNM) was inserted in the BY list VMXG70PR for all RMF-based datasets. These RMF records all have VMXGRMFI the same value in variable SYSTEM, but SYSNAME is unique ANALRMFR to each system and must be used to separate them. Test VMAC7072 data's SYSTEM was different from each of the two SYSNAME ADOC7xxx values. The new RMF sort order is changed to: ANALRMFR BY SYSPLEX SYSTEM SYSNAME STARTIME .... ; Jan 29, 2006 ANALRMFR This change in sort order should have NO impact if you VMAC70PR have no repeated SYSTEM names in a SYSPLEX. By putting VMXG70PR SYSNAME to the right of SYSTEM, merges with old MXG data Jan 31, 2006 (that were sorted BY SYSPLEX SYSTEM STARTIME...) won't be impacted, and your report code with logic testing for FIRST.SYSTEM or LAST.SYSTEM won't be impacted.
ONLY if you have multiple SYSTEM names in a SYSPLEX do you need to deal with this changes. You MUST revise BY statements in your report programs, inserting SYSNAME after SYSTEM, and using SYSNAME instead of SYSTEM in reports. Tests for FIRST.SYSTEM or LAST.SYSTEM must be changed to FIRST.SYSNAME or LAST.SYSNAME in your code. But without this change, these multiple SYSTEM names created incorrect output, without any error messages.
it is useful for Disaster Recovery LPARs, and can avoid changing SYSTEM in JCL, etc., when moving a SYSTEM to a SYSPLEX that already has a SYSTEM with that same name. Some initial revisions were made to ANALRMFR, but they are still being validated, and those reports will be enhanced to support selection by SYSNAME or SYSTEM.
ACHAP35 ADOC7072 ADOC70PR ADOC71 ADOC73 ADOC74 ADOC75 ADOC76 ADOC77 ADOC78 ADOC89 ADOCPDB ANALDALY ANALFIOE ANALMPL ANALPGNS ANALRMFI ANALRMFR ANALSRVC ANALSTOR ASUMMIPS DOCMXG GRAFWORK GRAFWORX GRAFWRKX JCLQAOLD MONTHASC MONTHBL3 MONTHBLD MONTHBLS MONTHDSK QASAS TEST70SP TRNDRMFN VMAC7072 VMAC71 VMAC75 VMAC76 VMAC77 VMXG70PR VMXGRMFI WEEKBL3 WEEKBL3D WEEKBL3T WEEKBLD WEEKBLDD WEEKBLDT These changes are in the MXG 23.11 dated Jan 31, 2006: Jan 31 updates (hooray - no critical changes!!): -ANALRMFR: revised, not DROP SYSNAME after SHAR74). -VMAC7072: cosmetic removal of duplicate SYSNAME in KEEP= in several places, eliminated NOTE on log. -VMXG70PR: variable SMF70GIE now kept in RMFINTRV. -If _STY70 is executed twice, you will get an ABEND and ERROR: DATASET WORK.TYPE70SP NOT FOUND That error is intended, as it alerts you that your program has caused that macro to be executed a second time. Please rerun with OPTIONS SOURCE SOURCE2 MACROGEN MPRINT; and send the full log to support@mxg.com so we can understand what you were doing that is incompatible with the new MXG redesign. -VMAC73: variable SYSNAME was added to KEEP= list for the always-zero-obs TYPE73L,TYPE73P datasets; WEEKBLD etc need those variables because they are in the BY list, even though those datasets have not had observations for decades. (And I can't safely stop creating them, as that can only cause somebody's report program to fail.) Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA. Thanks to Alain Delaroche, CA-Atlantica, FRANCE. Thanks to Chris Weston, SAS ITRM Cary, USA.
VMAC7072 TYPE70; they have always been INPUT but were not kept. Jan 27, 2006 SMF70OIL='ORIGINAL*INTERVAL*LENGTH' SMF70SYN='SYNC*VALUE' Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
IMACINTV 30 subtype 2/3 records is finally changed so that now, INSTALL observations will always be output into TYPE30_V dataset, Jan 26, 2006 if the SMF file contained SMF 30 subtype 2/3 records. -Always use PDB.SMFINTRV, created by BUILDPDB and NOT the "raw" TYPE30_V dataset, nor the PDB.SMFINTRV created by TYPS30 program; those other "PDB.SMFINTRV/TYPE30_V" data sets still have incomplete data because they still have those multiple observations if MULTIDD='Y'. Only MXG's BUILDPB logic combines the multiple TYPE30_V obs into a single complete observation in PDB.SMFINTRV. -The default was unwise because many new users have wasted their time and were frustrated when they got no output, and wasted more time looking for what they had done wrong OK, they had done something wrong: they had failed to read (and understand the impact of) every word in the INSTALL member, which is where I documented that zero obs would be created by default! -I originally chose to not write the interval record when they first appeared in 1980, because I was concerned for the additional disk space that might blind-side your fine running daily job, and because back then they weren't sychronized with time of day, and were not of much use. -Now, however, PDB.SMFINTRV is synchronized, so you can create legitimate interval sums of all tasks to compare with RMF, and potentially use in place of PDB.RMFINTRV for workload measurement, and it so important that it is normally created by everyone, and so I could have saved many support calls if I'd changed the default a long time ago. And, the cost of a little of DASD space is still a lot cheaper than the cost of the beginner's time and frustration, so it now is populated by default. Change 23.333 Cosmetic. Missing Value calculations when OFFWQ was a VMAC116 missing value; now, OFFQW is tested first so those log Jan 26, 2006 messages are eliminated.
VMACVMXA z/VM MONWRITE data, but were not de-accumulated in MXG. Jan 25, 2006 Logic to use DIF() was added to properly decode and Feb 1, 2006 convert them to percentages. Feb 1: typo HFLPGACT corrected to HFPGACT Thanks to Kris Ferrier, State of Washington DIS, USA. Thanks to Bruce Widlund, Merrill Consultants, USA.
EXNDMTX (TCQ Full, TCQ Below Threshold, or TCQ At Threshold) IMACNDM create observations in the new NDMTX dataset. VMACNDM
VMXGINIT Jan 25, 2006 Thanks to David Kaplan, Depository Trust, USA.
TEST70SP The "best tested ever" revisions in MXG 23.10 for RMF 70s VMAC7072 were still not perfect. The TYPE70/TYPE70PR/ASUM70PR and VMXG70PR ASUMCEC datasets have had no reported data-value errors, VMXGRMFI but the RMFINTRV dataset had missing values for the PR/SM Jan 24, 2006 variables, due to an incorrect sort order, and errors in Jan 26, 2006 building the WEEK/MONTH PDBs with new/old data uncovered Jan 27, 2006 the need for additional PROC SORTs to put the new data back in the old and expected sort order. Chronological list of revisions to the revision: 23Jan2006: -VMXG70PR. Cosmetic. Variables SYSPLEX SYSTEM were in KEEP list for the new ASUMCELP but should not have been; only impact was a possible WARNING message. 24Jan2006,27Jan2006: -TEST70SP fails in its comparison of OLDRMFI and NEWRMFI, with VARIABLES SYNCTIME LPARNAME LCPUADDR not found. The two BY statements for the two SORTs and one BY statement for the DATA step in lines 88-96 of TEST70SP should be: BY SYSPLEX SYSTEM STARTIME; BY SYSPLEX SYSTEM STARTIME; BY SYSPLEX SYSTEM STARTIME; 26Jan2006: -VMXGRMFI fails if SPIN.SPINRMFI dataset had observations: ERROR: BY VARIABLES NOT SORTED ON DATASET WORK.SPINRMFI because the new logic needed a sort of the old SPINRMFI into the new sort order. -VMXG70PR rebuilt PDB.RMFINTRV caused OUT OF SORT ORDER error when (for example, WEEKBLD) old and new RMFINTRV datasets were combined. Adding a final sort to force the output to be BY SYSPLEX SYSTEM STARTIME corrected. 27Jan2006: -VMXG70PR creation of PDB.TYPE70PR needed an additional PROC SORT to put it in the original SORT order for the WEEKLY merge. -VMXG70PR rebuild PDB.RMFINTRV had missing values for the "PLATCPUS" variable; re-sequencing the BY statements was necessary. All four members have now been redated 27Jan2006, so you will know you have all current changes. Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY. Thanks to Alain Delaroche, CA-Atlantica, FRANCE. Thanks to Diane Eppestine, AT&T Services, Inc, USA.
VMAC30 accumulated in SMF 30 interval records, but Change 22.326 BUILDPDB added logic to deaccumulate CPUCEPTM in PDB.SMFINTRV. BUILDPD3 Now, IBM has added field SMF30CEPI, the interval CPU time Jan 23, 2006 and MXG creates new variable CPUCIPTM from that field in all of the TYPE30 datasets, as well as in PDB.STEPS and PDB.JOBS. Thanks to Scott Barry, SBBWorks, Inc, USA. ====== Changes thru 23.328 were in MXG 23.10 dated Jan 23, 2006========= Change 23.328 New macro variable &MXGEOF with null value is now called VMACSMF when EODOFSMF or ENDOFLOG condition is true; you could VMXGINIT use &MXGEOF to execute code, like storing the MNSMFTME Jan 22, 2006 value into a macro variable for subsequent use. While Jan 26, 2006 this may look slightly kludgy, using an old-style macro to hold the text (quotes, parens, semicolons etc.) that is to be stored into a %LETed macro variable is often much safer, cleaner, and easier to type-in, although the use of %LET macvar= %QUOTE ( ... text ... ) ; may often be all that is required, and, occasionally, you can even use %LET macvar= ... text ... ;, but this always works to pass executable SAS code into a macro variable: MACRO _MXGEOF CALL SYMPUT("MNSMFTME",PUT(MNSMFTME,DATETIME21.2)); % %LET MXGEOF= _MXGEOF ; %INCLUDE SOURCLIB( .. any SMF processing ) ; %PUT &MNSMFTME; Jan 26: Two instances of ENDOFSMF in seldom-used JOURNAL INFILEs were corrected to ENDOFLOG; only impact was an UNINITIALIZED VARIABLE ENDOFLOG message on the log. Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY. Change 23.327 Enhancements to IBM-RMF-Report-like report examples. ANALRMFR Revisions for Change 23.321 to insert _STY70 when PDB=SMF Jan 22, 2006 and REPORT=CPU is requested. Thanks to Bruce Widlund, Merrill Consultants, USA. Change 23.326 Macro variable PSUDB2 (used only by the new ASUMDB2) was VMXGINIT not GLOBALed, even though it was %LET in VMXGINIT, caused Jan 18, 2006 APPARENT SYMBOLIC REFERENCE PSUDB2 NOT RESOLVED on MVS. Thanks to John Riera, InfoCrossing, USA. Change 23.325 Syntax error 180 underscoring _C1020, only when TRACECLS READDB2 argument is used, was introduced by Change 23.287 and is Jan 18, 2006 corrected by relocating the test for TRACECLS argument to Feb 17, 2005 after the include of VMAC102 code. Feb 17: MAC102S initialized, eliminated error if no 102s were requested. Thanks to Thomas Zuber5, Independence Blue Cross, USA.
VMACTPFC are now converted to rates per second by division by the Jan 20, 2006 TPFCTDIF interval duration, which is already in seconds and fractions. Their labels were also revised as shown: Variable Label TPFCHMSG HIGH*SPEED*MESSAGES*PER SEC TPFCLMSG LOW*SPEED*MESSAGES*PER SEC TPFCROEN ROUTED*ENTRIES*PER SEC TPFCCREN CRTD*ENTS*PER SEC TPFCSIMS SSCP*INPUT*MESSAGES*PER SEC TPFCCIMS INSDB*IN*MESSAGES*PER SEC TPFCCMTS COMMITS*PER SEC TPFCCFRQ CF*REQUESTS*PER SEC Thanks to Chris Weston, SAS Institute Cary, USA. Thanks to Martha Hays, SAS Institute Cary, USA. Thanks to Luis R. Vega-Zayas, IBM, USA. Change 23.323 IBM APAR OA14365 corrects negative CPUUNITS in SMF 30s, VMAC30 which occurs only when IFAs are used, and only when the Jan 16, 2006 address space had little activity. The negative value is created when CPUUNITS=CPUUNITS-IFAUNITS finds IFAUNITS are greater than CPUUNITS. CPUUNITS is SMF30CSU, and IFAUNITS=CPUIFATM*CPUCOEFF*LOSU_SEC or in IBM names: (SMF30_TIME_ON_IFA) * SMF30CPC * (16000000/SMF30SUS) MXG now detects that the CPUUNITS are negative, and prints warning messages on the SAS log that you need to install this APAR. Text revised March 6, 2006. Thanks to Micchia Marco Antonio, UniCredit, ITALY.
VMAC7072 z/OS 1.7 now supports up to 60 LPARs; your MXG code will VMXG70PR fail with messages (ARRAY OUT OF RANGE) if you have an Jan 19, 2006 LPARNUM greater than 32. This change was extensive: -VMAC7072: Size of temporary ARRAY S70LPCP was increased from 32 to 60. No other changes were required for the TYPE70 and TYPE70PR datasets. -VMXG70PR summarization. 1. New PDB.ASUMCELP dataset is created from PDB.ASUMCEC, with only one set of variable names, and it should be used for reporting instead of PDB.ASUMCEC. 2. Major mechanical rewrite to support 60 LPARS. Created 28 sets of 25 new variables for each of the new LPARs in the PDB.ASUM70PR and PDB.ASUMCEC datasets (so they are even more unwieldy for report writing). While those datasets are valid, I strongly recommend that you instead use PDB.ASUM70LP and PDB.ASUMCELP datasets, instead of PDB.ASUM70PR and PDB.ASUMCEC; those "LP" datasets have only one set of variable names, for easy reporting, and you can select by LPARNAME. The LPARNUM is no longer valid because an LPARNAME's LPARNUM will change if a new LPARNAME is created (LPARNUMs are set by alphabetical LPARNAME order). But in case you have reports based on those clumsy sets of variable names in ASUM70PR/ASUMCEC datasets, the variable names for LPARs 33-34 have Y and Z as markers (1-9 and A-X were used for LPARs 0-32), and these new names are created for LPARs 35-60 in the (archaic, but valid) ASUM70PR and ASUMCEC datasets: LPARS 0-34 LPARS 35-60 LPnAAAAA LQnAAAAA LPCTnAAA LQCTnAAA PCTLnAAA PCTQnAAA 3. MXG variable CPUOVHTM has been wrong for some time; it contained both LPPUPDTM and LP0MGTTM, which are identical measurements of the "PHYSICAL" CPU time, and only one of them should have been included; this error caused both the CPUOVHTM and PCTOVHD values to be slightly too large. 4. LPARs with the same STARTIME but different DURATM's caused incorrect calculations in PCTCPUBY and/or in individual LPAR percentages, which could be over 100%, in the ASUM70PR/ASUM70LP/ASUMCEC summary datasets. To properly summarize data across a CEC, neither the STARTIME nor SYNCTIME can be used to identify the minimum set of interval data from all systems on that CEC. STARTIME has been documented as varying by one to several seconds for the same logical interval on Yüklə 28,67 Mb. Dostları ilə paylaş:
|