* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Sep 22, 2007 variable names should never have been in the VMXGSUM Oct 4, 2007 invocation for the statistics reports. Thanks to Clayton Buck, UniGroup, USA. Thanks to Yaohua Hu, ISO, USA. Change 25.201 -Unexpected FILESYSTEM data with characers caused errors EXTRH019 INVALID ARGUMENT FOR FUNCTION, temporarily circumvented, FORMATS but the circumvention causes RH017001 to be a mising IMACTNG value until further investigation of the strange data. VMACTNG -Unrelated, Red Hat object USERS is supported in the new VMXGINIT RH019 dataset created by this change. Sep 24,2007 Thanks to Xiaobo Zhang, CheckFree, USA. Change 25.200 Use of %LET mackeep= whatever ; was not supported. READDB2
Sep 18, 2007 Thanks to Gary Diehl, Sun MicroSystems/STK, USA. ====== Changes thru 25.199 were in MXG 25.09 dated Sep 17, 2007=========
VMXGRMFI to create PDB.RMFINTRV, the STARTIME was reset to 00/15 Sep 15, 2007 but SMF70GIE was not. Now it is, so PDB.RMFINTRV will be consistent with PDB.ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP. Thanks to Douglas C. Walter, Citicorp, USA. Thanks to Brent Turner, Citicorp, USA. Thanks to Tom Koelle, Citicorp, USA.
VMAC89 SMF89DTO were wrong because the comment for SMF89PFL was Sep 15, 2007 not present. Thanks to Al Sherkow, I/S Management Strategies, USA. Change 25.197 %UTILCSV creates a CSV (Comma Separated Values/Variables) UTILCSV or TAB or ANY-character-DELIMITED "text file" from any Sep 14, 2007 SAS dataset, with the ability to order left-to-right and to use FORMAT statements to control the output text. Change 25.196 If you set %LET MACKEEP= %STR( lots of lines of text ); UTILBLDP before invoking %UTILBLDP, some of your MACKEEP code may Sep 14, 2007 not get executed, leading to strange errors or unexpected results. We now parse the text inside the macro language into line-sized chunks to eliminate the exposure. And while we were at it, we've created new arguments that you can use for tailoring, as an alternative to using %LET's for these macro variables: Macro Variable Name Macro Argument Name macfile macfilex mackeep mackeepx ihdrdb2h macdb2hx ihdr110 mac110hx One reason to use the Macro Argument in your UTILBLDP rather than a %LET statement is that macro argument are significantly more robust in that they do not need to be wrapped in %STR() and we have NOT been able to find any text string the argument couldn't handle, vs the many combinations that have broken %QUOTE, etc. in %LETs! However, you can use both a %LET macxxxx= and macxxxxx= argument; the text in your %LET will preceed any text you passed in the corresponding argument. And, just to be sure, we now "chunk" any EXPDBOUT text. Thanks to Michael Creech, Fidelity National Information Svcs, USA. Change 25.195 Support for EMC's SRDF/A user SMF record. VMACSRDF
VMXGINIT EXSRDFAA
TYPESRDF TYPSSRDF
IMACSRDF Sep 13, 2007 Change 25.194 Variable SJGRQRST='JVM*REQUESTS*WITH RESET' in CICTCPSJ VMAC110 CICS Statistics dataset is now created; while it does not Sep 13, 2007 exist in CICS/TS 3.2 (resettable JVMs were withdrawn in 3.2 because continuous use JVMs save lots of CPU), it is useful for detecting these bad guys in 2.3 and 3.1. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 25.193 MXG 25.08 Change 25.182 was incomplete, which caused the IMACEXCL ERROR: LABEL IMACICU3 NOT FOUND when UTILEXCL was run. UTILEXCL Sep 13, 2007 Thanks to Christelle Abily, Groupe Informatique Credit Mutuel, FRANCE
VMAC92 because the SMF92DNR/SMF92DRN Rename Length/Name fields Sep 11, 2007 only exist when the file is RENAMEd, and because the SMF manual did not document that feature. Now, MXG confirms that data exists prior to its INPUT. Thanks to John Schoenbeck, AT&T Services, Inc, USA Change 25.191 Support for RMF Monitor III CFI table segmentation in the ASMRMFV ASMRMFV, and their input in VMACRMFV. New datasets EXZRBCFC ZRBCFC is created from the CFICONNUS Connection Table, IMACRMFV and the new variables in the CFISTRES Table are created VMACRMFV when they exist (i.e., when CFIDETAIL was specified in VMXGINIT RMF III parameters). Sep 10, 2007 Sep 14, 2007 Thanks to Jerry Urbaniak, Acxiom, USA.
VMACDB2 DB2STAT2 dataset; it was added in DB2 V8.1, in the same Sep 8, 2007 location as QDBPVTPT, which is now always blank. Thanks to Lori Masulis, Fidelity Systems, USA. Change 25.189 Revision to PDBOUT= options, when PDB=SMF is specified, READDB2 and possible INCOMPATIBILITY when PDBOUT was null. Now, ANALDB2R these options for PDBOUT= control output destination: Sep 11, 2007 PDBOUT=, All datasets written to //WORK, always. Sep 17, 2007 PDBOUT=PDB All datasets written to //PDB. Sep 24, 2007 PDBOUT=YES All datasets written to their default destination, with user tailoring honored. PDBOUT=XXX ALL datasets written to //XXX. This change could cause perfectly running jobs to fail, if PDBOUT=, was specified and you had tailoring that redirected the output dataset destinations. Sorry for that, but using PDBOUT=YES instead of PDBOUT=PDB is now the DOCUMENTED and SUPPORTED option to create output.
invoked with PDBOUT=, and it failed with DDNAME PDB NOT FOUND and _VDB2A UNDEFINED errors when no //PDB DD existed.
Note: Only READDB2's code was changed; ANALDB2R calls READDB2 with the same possible PDBOUT= argument, so it is listed here for documentation (that you'll only find after the error?). Text revised Sep 17 for PDBOUT=PDB description. -MXG 25.08 only, bit test for SADUCL=6 was one bit short; only the list of Audit Trace Classes might be incorrect. This was accidentally corrected in this change. 24Sep07. Thanks to R. Berry, Internal Revenue Service, USA. Thanks to Clayton Buck, UniGroup, Inc, USA. Change 25.188 If RMFINTRV=NO and BUILDPDB=YES and ASUM70PR included, UTILBLDP the invocation failed because the TYPE70xx datasets were Sep 7, 2007 not sorted into the PDB due to the RMFINTRV=NO. Now, as expected, BUILDPDB=YES sorts them into the PDB library. Thanks to Trevor Holland, ANZ, AUSTRALIA
VMAC92 but that was corrected in z/OS 1.9 manual to correct 2, Sep 5, 2007 so two MXG tests for SMF92RVN GE 3 were change to GE 2. This corrected the bit variables SMF92MFG and SMF92MF2. Variable SMF9PPN is a path name so it was increased to $VARYING1024. with input length set by SMF92PPL. Thanks to Hyrum E. Smith, Charles Schwab & Co., USA
ANALDB2R PDB.ASUMDB2A existed was corrected with a compiler faker. Sep 5, 2007
IMACSHFT not have a DURATM variable for the ASUM70GC and ASUM70GL VMXGDUR datasets; the interval is forced to HOURLY, but interval VMXG70PR datasets should always have a DURATM variable. Sep 5, 2007 I tested this change with %VMXG70PR(INTERVAL=SHIFT,...) and found it caused VARIABLE MXGDURTM UNINITIALIZED notes because MXGDURTM was not defined in IMACSHFT example, and MXGDURTM was not always protected in VMXGDUR. Thanks to Chris Weston, SAS Institute Cary, USA.
ANALRMFR new data was added by MXG Change 25.163. Sep 5, 2007
TYPETMS5 DELETEs commented out for testing are now uncommented. Sep 5, 2007 CHANGED DSNBREC DSNBRECS DSNBRECT DSNBRECU DSNBRECV DSNBRECW MGTMSVL TMSREC TMSRECS Thanks to John Shuck, Sun Trust, USA. Thanks to Stan Helms, Sun Trust, USA. Thanks to Mike Duwve, Sun Trust, USA.
IMACICU3 CMODHEAD='APPLINFO' is added. UTILEXCL Sep 2, 2007 Thanks to Peter Gschirr, ARZ, AUSTRIA. Change 25.181 Support for CA Unicenter NSM has been in MXG under "TNG" EXTAI026 for years, because TNG was NSM's original name, and the EXTNT132 "performance cube" format was not changed at name change. EXTRH001 Support for CA NSM PLATFORM='RHEL401', RedHat 4.01 Linux EXTRH002 performance cube is added by this change, which initially EXTRH003 populates the Solaris "SOnnn" datasets, as they exist and EXTRH004 have the most objects/metrics in common with Linux, but EXTRH005 there are Solaris-only variables that have missing values EXTRH006 and there are RHEL objects/metrics not yet supported. EXTRH007 EXTRH008 This change also externalizes the list of PLATFORM names EXTRH009 that map to AIX or SOLARIS with new _AIPLAT and _SOPLAT EXTRH010 macros (like the existing _NTPLAT macro). And, that test EXTRH011 is now IF PLATFORM IN : ( _NTPLAT ) THEN DO; with the EXTRH012 "colon modifier" inserted so the test matches only the EXTRH013 starting characters of the platform names. I did this EXTRH014 when I thought RHEL was a user-assigned name, which it EXTRH015 isn't, but these macros are no-cost tokens that will make EXTRH016 my testing easier for new PLATFORM names. EXTRH017 EXTRH018 New variables were added to these existing datasets: IMACTNG Dataset Description VMACTNG AI019 AIX - CA MEMORY GROUP VMXGINIT NT035 NT - PROCESS Sep 2, 2007 New datasets are created from these new objects: Dataset Object Name AI026 AIX - PROCESS NT132 NT - CA CUBE STORE GROUP -New datasets are created from Red Hat Platform Objects: Dataset Object Name RH001 RH - CA CPU GROUP RH002 RH - CA INTERRUPT RH003 RH - CA CUBE STORE GROUP RH004 RH - CA PER CPU GROUP RH005 RH - CONTEXT SWITCHING RH006 RH - INTERRUPTS RH007 RH - PAGING RH008 RH - PROCESS CREATION RH009 RH - SWAPPING RH010 RH - CA DISK GROUP RH011 RH - CA FILE SYSTEM GROUP RH012 RH - CA INTERFACE GROUP RH013 RH - CA MEMORY GROUP RH014 RH - CA PROCESS GROUP RH015 RH - CA SWAP GROUP RH016 RH - CPU RH017 RH - FILESYSTEM RH018 RH - NETWORK Thanks to Xiaobo Zhang, CheckFree, USA. Change 25.180 The Omegamon OMCI subtype 203 is now written in SMF 112s, VMACOMCI but can still be created in the old User SMF record; MXG Aug 29, 2007 Change 25.099 moved the 203 code into VMAC112, but also disabled subtype 203 in VMACOMCI. This corrects. But now see Change 26.257, which revised support. Thanks to Tom Kelman, Commerce Bank of Kansas, USA. Change 25.179 Protection for %UPCASE() and %LOWCASE() for literals. ANALDBTR Almost all of the SAS code in MXG is in UPPER CASE, but BLDSMPDB some members are mixed case, with "case sensitive" noted GRAFHSM in their comments, but that did not prevent accidental GRAFLPAR low-case-ing some lines in BLDSMPDB that contained tests GRAFTALO if %upcase(something) eq yes %then %do; GRAFTMNT which failed because the yes value was now lower case. GRAFTRND Macro variable tests are in many MXG members, especially GRAFWORK those that define %MACROS where user-typed input text is GRAFWORX shifted with %UPCASE() for consistent testing, but I had GRAFWRKX never thought to protect the text being compared! PRINTNL
READDB2 Now, all members were examined that used %UPCASE/%LOWCASE UTILBLDP and those that tested for literal text values now use UTILCONT UTILDUMP if %upcase(something) eq %upcase(yes) %then %do; VMACMWNT VMXGALOC The DATA step UPCASE() function is also used in even more VMXGDEL members, but as those values are not 'human-typed', I did VMXGGETM not see the need for also wrapping those text values. VMXGSUM VMXGSUME New MXG Recommendation: Use %LET MACxxxx= %STR( text ) ; VMXGUOW with blanks as shown, when storing any text string that Aug 28, 2007 can contain semi-colons, into those MXG tailoring macro variables, since those macro variables will be resolved at "compile time", which is where %STR() is to be used. Previously I suggested using %QUOTE() or %BQUOTE() to pass text with semi-colons, but they are not resolved until "execute time", and, while QUOTE/BQUOTE frequently did work, the use of %STR, especially for MACKEEP/MACFILE macros is the more appropriate among the many functions. Thanks to Tom kelman, Commerce Bank of Kansas, USA. Change 25.178 Support for V5R4MO QAPMDISK with LRECL=456 adds these 20 VMACQACS variables: Aug 28, 2007 DSBKCT1='BUCKET*1*OPERATIONS' DSBKCT2='BUCKET*2*OPERATIONS' DSBKCT3='BUCKET*3*OPERATIONS' DSBKCT4='BUCKET*4*OPERATIONS' DSBKCT5='BUCKET*5*OPERATIONS' DSBKCT6='BUCKET*6*OPERATIONS' DSBKRT1='BUCKET*1*RESPONSE*TIME' DSBKRT2='BUCKET*2*RESPONSE*TIME' DSBKRT3='BUCKET*1*RESPONSE*TIME' DSBKRT4='BUCKET*4*RESPONSE*TIME' DSBKRT5='BUCKET*5*RESPONSE*TIME' DSBKRT6='BUCKET*6*RESPONSE*TIME' DSBKST1='BUCKET*1*SERVICE*TIME' DSBKST2='BUCKET*2*SERVICE*TIME' DSBKST3='BUCKET*3*SERVICE*TIME' DSBKST4='BUCKET*4*SERVICE*TIME' DSBKST5='BUCKET*5*SERVICE*TIME' DSBKST6='BUCKET*6*SERVICE*TIME' DSSRVT ='DISK*SERVICE*TIME' DSWT ='DISK*WAIT*TIME' Thanks to Clayton Buck, UniGroup, Inc, USA.
VMXGINIT with a month's SMF data from scores of systems. The VMXGRMFI culprit is the MXG algorithm to calculate MSU4HRAV, the Aug 24, 2007 rolling hourly average MSU over the past four hours, created in RMFINTRV before IBM added the SMF70LAC value (and SMF70LAC is the variable to use, not my MSU4HRAV, as SMF70LAC is IBM's calculation that is used in WLM capping decisions, and it is slightly different than the MSU4HRAV, where I used total CPU and IBM didn't, and where I calculate true average even across an IPL and they don't!). When MSU4HRAV was created, the size was set for a daily or weekly RMFINTRV creation, so an array size of 9999 elements would hold hourly data for: over 100 system's daily data at 15 minute intervals over 14 system's weekly data at 15 minute intervals but only 3 system's monthly data at 15 minute intervals! (and this site had 5 minute intervals!). This is one of the MANY reasons why I avoid ARRAYs; while increasing the ARRAY size will hold more system's data, that requires more virtual storage, and that will grow as the number of systems increase, exchanging OUT-OF-MEMORY errors for OUT OF RANGE. The immediate user circumvention was to process the SMF data one week at a time, which worked just fine. Though hopefully unneeded, I have externalized the size of the three temporary arrays with new macro variable with default value of %LET ARRAYRMF=9999; unchanged. I have also inserted a trap to detect the array size was exceeded and inform you via an ERROR message on the log. Change 25.176 Support for APAR OA18244, Blocked Workload metrics, adds VMAC7072 -These variables to the TYPE70 dataset: Aug 24, 2007 SMF70PMI='AVG*BLKED*DISPATCH*UNITS*MAY GET' SMF70PML='OPT*PARAMETER*BLWLINTHD' SMF70PMP='MAX*DISPATCH*UNITS*BEING*BLOCKED' SMF70PMT='OPT*PARAMETER*BLWLTRPCT' (Note: The default you type is "5", but that will be a value of .005 in SMF70PMT, i.e. one-half of a percent. RMF reports that a .5% but the variable is NOT labelled Percent so you need to know that .005 is one-half percent default. SMF70PMU='BLKED*DISPATCH*UNITS*PROMOTED*PERSEC' SMF70PMW='AVG*DISPATCH*UNITS*BEING*BLOCKED' STFBIT05='OPT PARM*BLWLTRPCT*CHANGED? STFBIT06='OPT PARM*BLWLINTHD*CHANGED? -This variable, previously added to the TYPE72GO dataset by Change 25.140 is populated by this APAR: R723TPDP='CPU TIME*AT PROMOTED*DISPATCH*PRTY' and this new flag variable is created by this APAR: ZIPHONPR='ZIP*HONOR*PRIORITY?' Change 25.175 Internal logic was revised so when INTERVAL= is used, the ANALRMFR variables LPARCPUX and SMF70BDA are added to the ID= parm Aug 24, 2007 for Cluster Reports. -Also, MVSCHRLV and NCYCLE are added to report headings. Thanks to Bruce Widlund, Merrill Consultants, USA.
ASUMTAPE build of their dictionary. VMAC7072 -Variable JBACPU dataset QAPMJOBL now FORMATed TIME13.3. VMACQACS -Variable MAXVLSEQ is no longer created/kept in TYPETMS5. VMACTMS5 -Variables for CP/ICF/IFL/IFA/ZIP counts/time are labeled VMXG70PR in VMXG70PR & VMAC7072, PROC DELETEs uncommented to clean VMAC110 up WORK file. Variables IFAWSTTM,ZIPWSTTM formatted. VMACDB2 -ASUMTAPE variables BEGTMNT, ENDTMNT, TOTMNTTM labeled. VMACSTC -CICSDS variables DSGEJST DSGSRBT labeled and formatted; Sep 5, 2007 they are the total TCB for all CICS TCBs and total SRB for all SRBs in the interval. -DB2ACCT variable QWHUCPU formatted. -TYPESTC variable STC15CTP label corrected. Sep 6 changes, not in 25.08: -TYPE7072 - variables NRPHYCPX, NRPRCX no longer kept. - variable GMTOFF70 GMTOFF72 formatted. -TYPE85 - variables R85ST74F, R85ST78F labeled. Thanks to Chris Weston, SAS Institute Cary, USA. Change 25.173 -Support for NMON "CPU_VP_USE" and "CPU_EC_USE" objects VMACNMON (Virtual Processor and Entitled Capacity) adds these new Sep 1, 2007 variables to NMONINTV dataset: NRECUS='CPU_EC_USE*COUNT' NRVPUS='CPU_VP_USE*COUNT' PCPUUSER='CPU_ALL*USER*PERCENT' PECTOTAL='CPU_EC_USE*TOTAL*PERCENT' PECUBUSY='CPU_EC_USE*BUSY*PERCENT' PECUIDLE='CPU_EC_USE*IDLE*PERCENT' PECUSYS='CPU_EC_USE*SYSTEM*PERCENT' PECUUSER='CPU_EC_USE*USER*PERCENT' PECUWAIT='CPU_EC_USE*WAIT*PERCENT' PVPUBUSY='CPU_VP_USE*BUSY*PERCENT' PVPUIDLE='CPU_VP_USE*IDLE*PERCENT' PVPUSYS='CPU_VP_USE*SYSTEM*PERCENT' PVPUUSER='CPU_VP_USE*USER*PERCENT' PVPUWAIT='CPU_VP_USE*WAIT*PERCENT' -Support for NMON NETSIZE object adds thes new variables to NMONNETW dataset: NETSRDRT='NETSIZE*READS/S' NETSWRRT='NETSIZE*WRITE/S' -The count of JFSFILE fields drops to less than the count in the header record, occasionally, causing MXG to have to delete of that record with an MXG ERROR MESSAGE on the log. Under investigation with NMON support. -The "UNKNOWN RECTYPE=" message for Nigel's Monitor NMON is clarified to indicate it's not an error, but a new monitor record that is not yet supported by MXG, but will be if you send the input data file to MXG support. Thanks to Michael W. Woelke, Boeing, USA. Thanks to John Keenan, Boeing, USA.
ADOCDB2 libname db2acctp 'c:\mxg\db2acctp\'; Aug 20, 2007 libname db2acctb 'c:\mxg\db2acctg\'; libname db2acctg 'c:\mxg\db2acctb\'; libname db2acct 'c:\mxg\db2acct\'; libname db2gbpat 'c:\mxg\db2gbpat\'; libname db2gbpst 'c:\mxg\db2gbpst\'; /* unsorted, written directly to individual DDNAME for parallelism */ %LET WDB2ACP=DB2ACCTP; %LET WDB2ACB=DB2ACCTB; %LET WDB2ACG=DB2ACCTG; %LET WDB2PAT=DB2GBPAT; %LET WDB2PST=DB2GBPST; %LET PDB2ACC=DB2ACCT; /* deflected to work, as they are combined into db2stats */ %LET PDB2STO=WORK; %LET PDB2ST1=WORK; /* sent to pdb, stats, should be small in size */ %LET PDB2ST2=PDB; %LET PDB2ST4=PDB; %LET PDB2STS=PDB; %LET PDB2STB=PDB; %LET PDB2STR=PDB; %LET MACKEEP= %BQUOTE( MACRO _SDB2ACp % MACRO _SDB2ACb % MACRO _SDB2ACg % MACRO _SDB2pat % MACRO _SDB2pst % MACRO _SDB2ACc % ); %INCLUDE SOURCLIB(TYPEDB2); or could be %INCLUDE SOURCLIB(BUILDPDB); or could be %ANALDB2R(PDB=SMF); Change 25.171 Documentation. The DOCVER and DOCVERnn text printed only UTILVREF 3 positions for LENGTHs, causing a 32000-byte variable to Aug 20, 2007 be printed as 3E4 in exponential format. While I can't expand LENGTH to print 5 digits without truncating LABEL, I now detect the TYPE='NUM' and print four positions for those variables to be more accurate where I can. You can always use PROC CONTENTS DATA=whatever; to see the actual stored LENGTH of each variable. See MXG Technical Note 2 in Newsletter FIFTY for a list of "Very Long Stored Length" variables created by MXG. Change 25.170 If there no Mount-Related SYSLOG messages were captured ASUMTAPE by ASMTAPEE/MXGTMNT, i.e. TYPESYMT has zero observations Aug 20, 2007 then there were no observations created in PDB.ASUMTAPE, even though the TYPETMNT and TYPE21 records matched. The missing SYSLOG records was due to backlevel ASMTAPEE at ML-38 that missed messages now captured in ML-39, but this revision tests for zero obs in TYPESYMT dataset, and forces the OUTPUT of PDB.ASUMTAPE in that case. Note that this only works when all systems do not capture the SYSLOG data; if some systems do and others don't, this revision will NOT work, and only systems with obs in the TYPESYMT dataset will have output in PDB.ASUMTAPE. Thanks to John Doherty, Capita, SCOTLAND.
VMACDB2 for each "ACE group" that had any parallel activity, Aug 18, 2007 (i.e., had one or more DB2ACCT obs with DB2PARTY=O/P/R), keeps a large but manageable set of important variables, and then PRINTs the detail DB2ACCT observations for each "ACE Group", in time sequence, where each unique set of values of these BY variables defines an "ACE Group":
Yüklə 28,67 Mb. Dostları ilə paylaş:
|