* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
VMACSAMS Version 3 (1987!), it needed more virtual storage than I Jan 19, 2008 could get back then, and it was set aside. It now brings in all of the VMACs for all IBM and USER SMF records, and it detected numeric-character variable conflicts in one temp variable that was renamed in VMACIPAC, and two kept variables were renamed to avoid the exposure to error, if you were to add these and certain other SMF records to your BUILDPDB job: -VMACSAMS. Variable CLUSTR replaces numeric CLUSTER. -VMACOMCI. Variable DIFTYPEF replaces char DIFTYPE. The current COMPALL requires an 1150 MB Region on z/OS.
VMAC7072 the previous confusing "CPUS IN THE PARTITION" text that VMXG70PR goes back to the days when we "physically partitioned" a Jan 17, 2008 "hardware platform". The variables PARTNCPU PLATCPUS, NUCPSCPU and temp variable NRCPSCPU have always counted the CP/CPU engines in this CEC/CPC/platform/box/etc. If there are no LPARNAME='PHYSICAL' records in TYPE70PR (because your outsourcer turned them off?), the variables PARTNCPU, PLATCPUS, NUCPSCPU and CPCNRCPU will be zero. And the specialty engine counters NRIFACPU, NRZIPCPU, etc will also always be zero. And, in the ASUM70PR/ASUMCEC datasets, only your own LPARn variables are populated. Finally (?), CPCMSU in PDB.RMFINTRV is also zero. Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA. Change 25.293 SMF70GIE is now set from STARTIME+DURATM after SYNC59 to VMXG70PR provide a more stable and consistent value for the Jan 17, 2008 expected end of the interval. See Change 25.270.
ANALRMFR variables LRDY00-LRDY11 are added to the MEAN= parm for Jan 17, 2008 Cpu Reports. Dollarsigns were needed in the below array definitions. -ARRAY INICT05 $ STFBIT05(' ') ; -ARRAY INICT05 $ STFBIT06(' ') ; -Also, updated for 54 engines z/OS 1.9. Thanks to Clay Duncan, Toyota, USA. Thanks to Jerry Cobb, American Century, USA.
VMACDB2 is now included in MXG variable DB2TCBTM, as documented Jan 17, 2008 in DB2 Technical Note 4 (PAR.TASKS) in Newsletter FIFTY.
BUIL3005 had INPUTs with both lengths, and that caused SAS WARNING VMAC26J2 messages that the variable's length was CHANGED; these VMAC26J3 warnings will set Return Code 4 in SAS Version 9.2, so VMAC30 this change revised how MXG handles JOBCLASS for JES3 Jan 17, 2008 to keep the full 8-byte length. The contents of the Jan 20, 2008 SPIN library are also changed; JOBCLASS is no longer kept in SPIN26, and JOBCLAS8 is kept instead of JOBCLASS in SPIN30_1, SPIN30_4, and SPIN30_5. Note: This change was revised in MXG 25.25. Do NOT use MXG 25.12 with JES3 BUILDPD3. Thanks to MP Welch, SPRINT, USA. Thanks to Scott Barry, SBBWorks, Inc, USA.
VMACNMON dataset was one-tenth correct; the INFORMAT 6.1 should be Jan 17, 2008 6.0. The AAACPU2 count was correct in NMONAAA dataset. -Support for ERROR: records, sort of: they are printed on the log in full when read. Thanks to Michael W. Wolke, Boeing, USA. Thanks to Steve Olmstead, Northwestern Mutual Trust, USA.
VMAC7072 of the GMT offset in MXG created incorrect datetimes. Jan 16, 2008 Jan 26: a second instance was removed. Jan 26, 2008 Thanks to Al Sherkow, I/S Management Strategies, USA.
EXT122IT six new datasets: EXT122AL DDDDDD DATASET DESCRIPTION SUBTYPE EXT122WA
EXT122FA T122IT T122INIT ATAM ASID INIT/TERM 0,4 EXT122DY T122AL T122ALOC ATAM SUCCESSFUL ALLOCATE 1 EXT122ON T122WA T122WAIT ATAM WAIT/NOHOLD/ALOCFAIL 2,3,5 IMAC122 T122FA T122FAIL ATAM VARY ONLINE FAILURE 6 TYPE122 T122DY T122DYNA ATAM UNSUPPORTED DYNALLOC 7 TYPS122 T122ON T122VONL ATAM VARY ONLINE TO WAIT 8 VMAC122 VMXGINIT
Jan 16, 2008 Change 25.286 Support for new ITRF variables in subtype '10'x and '18'x EXITRCRG records and new subtype '20'x created by ITRF DCR77/DCR78 EXITRCRG (PTFs UA36089,UA37073). New variables added: IMACITRF Dataset New Variables VMACITRF ITRFMSG VMXGINIT RECTOK ='FULL*RECOVERY*TOKEN' Jan 16, 2008 IMSID ='IMS*ID' COMN ='COMMITS*DURING*THIS*SCHEDULE' OASN ='ORIGIN*APPLICATION*SEQUENCE*NUMBER' SUSEC ='SERVICE*UNITS*PER*SECOND' ITRFDB2 CPUDB2TM='IN DB2*CPU*TIME' New dataset ITRFCRGN, 'CONTROL REGION CPU TIME', which is created once each 24 hours with the daily total CPU Time in the IMS Control Region: Dataset New Variables ITRFCRGN CPUCRGTM='CONTROL*REGION*DAILY*CPU TIME' IMSNAME ='IMSID*FOR THE*IMS SYSTEM' INTBTIME='INTERVAL*START*DATETIME' INTENDTM='INTERVAL*END*TIME' The IMSNAME is retained from the prior ITRF record, as the '20'x record contains only the time fields.
CONFIGW2 CONFIGW2 file caused ERROR: OPTION VALIDVARNAME NOT KNOWN Jan 15, 2008 so it has been removed from CONFIGW2 member. That option is the internal WPS default, but the option name is not supported by WPS.
ANALDB2R -Using %ANALDB2R with new PDBOUT=YES printed COPIED TO YES READDB2 and did not perform as documented; an additional test for VFMT102 AND &PDBOUT NE YES was required to support the new YES. Jan 16, 2008 But then using PDBOUT=YES caused messages: ERROR: Libname PDB is not assigned. ERROR: Libname _VDB2A is not assigned. when no //PDB DD or LIBNAME PDB was allocated. That is an error. When PDBOUT=YES is specified, it writes all DB2 output datasets to their default (or the tailored) DDname, and PDB is the default for sorted DB2 datasets. -But then using no PDBOUT operand, which should write all DB2 output to //WORK, still caused ERROR: Libname PDB is not assigned. because READDB2 had an old segment of code that should have been removed by Change 25.189, now corrected, so that PDBOUT= null does NOW write only to //WORK. -Warnings about T102S017 DOES NOT EXIST are removed with enhancements made in VFMT102. Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA. Thanks to Robert Carballo, Office Depot, USA. Change 25.283 An extraneous ); was inserted in %UTILBLDP output (on a UTILBLDP separate line several lines after %LET EPDBOUT= text) if Jan 15, 2008 both EXPDBOUT= and INCLAFTR= were specified. Thanks to Robert Carballo, Office Depot, USA. Change 25.282 Support for seven new NTSMF Objects: EXNTCICP DDDDDD DATASET DESCRIPTION EXNTCILI NTCICP CITRIXCP CITRIX CPU UTILIZATION MGMT USER EXNTHSMG NTCILI CITRIXLI CITRIX LICENSING EXNTHSRV NTHSMG HEALMGMT HEALTH SERVICE MANAGEMENT GROUPS EXNTOPSM NTHSRV HEALSERV HEALTH SERVICE EXNTSECT NTOPSM OPSMGRCN OPSMGR CONNECTOR EXNTSQDM NTSECT SECTIKAU SECURE TICKET AUTHORITY IMACNTSM NTSQDM SQLDATMI SQLSERVER:DATABASE MIRRORING VMACNTSM or MSSQL:DATABASE MIRRORING VMXGINIT The SQLSERVER and MSSQL Database Mirroring records are Jan 15, 2008 both output in SQLDATMI dataset. The MSSQL records will populate variable SQLDBNAM='SQL*SERVER*DATABASE*NAME' while SQLDBNAM will be blank in the SQLSERVER records. Thanks to Roger Zimmerman, Hewitt Associates, USA.
VMXGRMFI work in "OTHER", a new MXG NOTE alerts you to the SYSTEM Jan 15, 2008 and SRVCLASS that fell thru your workload definitions. Jan 28, 2008 This is not an error, but it is recommended that all of your work be mapped to a unique workload variable in the RMFINTRV dataset. The first ten workload names that fell thru are printed on the SAS log. -Cosmetic. Some ERROR:NEGATIVE CPU OVERHEAD for RMF 70-72s were in intervals in which a Policy Activation occurred, and data for those intervals are always wise to ignore. There is no flag bit that activation occurred during this interval, but the time of policy activation, R723MTPA, is now printed along with STARTIME and DURATM of the raw RMF record, so you can see if there was a policy activation to blame. Variable CPUOVHTM in PDB.RMFINTRV will be negative, non-missing value. to identify the intervals that printed that log message. This message may also be seen in intervals in which the number of hardware CPUs was altered. Thanks to Chuck Hopf, Bank of America, USA. Thanks to Harald Seifert, HUK-COBURG, GERMANY.
EXMQLGMD MQMD Structure in MQ Accounting Log non-SMF file creates IMACMQLG the new MQLGMQMD Dataset with the Descriptor fields for TYPEMQLG each event. This structure is documented on page 51 in TYPSMQLG Chapter 7. VMACMQLG
VMXGINIT Jan 11, 2008 Change 25.279 SMF 85 subtypes 38, 39, and 40 now create three datasets EXTY85RE TYPE85RE, TYPE85IB, and TYPE85TR. Archaic test records EXTY85IB from year 2000 with shorter records were protected. EXTY85TR
VMAC85 VMXGINIT
Jan 10, 2008 Thanks to Harald Seifert, HUK-COBURG, GERMANY. Change 25.278 PDB.TYPE70 variables PCTZIBYx were created in MXG 24.02 VMAC7072 but were accidentally not kept after MXG 24.06; they are Jan 10, 2008 now reinstated. PCTZIBYx/PCTIFBYx are the "MVS" values, variables PCTCIBYx/IFATYPE are "LPAR" values for zIIP and zAAP usage as noted in Change 24.184. Thanks to Harald Seifert, HUK-COBURG, GERMANY. Change 25.277 Support for PSYNCH/390 SMF Record from M-Tech product EXPSYC39 creates PSYNC390 dataset. FORMATS Only one of the four flag variables will have a value in IMACPSYC one record, but it's now too late to change the MXG code. TYPEPSYC May 5: Formats were updated. TYPSPSYC
VMACPSYC VMXGINIT
Jan 10, 2008 May 5, 2008 Thanks to Joseph J. Faska, Depository Trust, USA.
VMAC22 adds these two variables: Jan 9, 2008 SMF22CYL='DEVICE*HIGH*CYLINDER' SMF22PCP='DEVICE*HIGH*CYLINDER*PREVIOUS' to the TYPE22_A dataset.
VMACTPMX your IMACTPMX member with your SYSPLEX and SYSTEM names Jan 4, 2008 and mapping tables; messages like these: Jan 9, 2008 >>ERROR>> MXG/SAS VARIABLE TPMXPLEX NOT ASSIGNED CORRECTLY USING LOCAL PROC FORMAT $MXTPMPX IN >>ERROR>> EXIT MEMBER MXG.PROD.USERID.SOURCLIB(IMACTPMX). >>ERROR>> RUN ABORTED. CORRECT THE FORMAT AND RESTART. resulted when data from SYSTEMs not in IMACTPMX was read. Adding an entry for each SYSPLEX and for its SYSTEMs in IMACTPMX solved those errors. -Variable JXJBSJ4 was incorrectly input as $EBCDIC, but it is a hex flag field, now input and formatted $HEX8. Jan 9: A debugging PUT was removed, VGETJESN %INCLUDEd to create variable JESNR from JCTJOBID for subtype=5. The current level: TM V6R1.2 at PTF TMT6116; the fix for the truncated records is APAR TR61390, but you are at PTF TMT6118, the APAR is TR61391. Thanks to James D. Lieser, UHC, USA. Thanks to Scott Barry, SBBWorks, Inc, USA.
VMAC6156 INVALID DATA warning message when MXG INPUT the oh's as a Jan 2, 2008 numeric. Adding the double question mark modifier to the INPUT function eliminates the warning and causes GENNO to be a missing value: IF ENTTYPID='H' THEN DO; /*GDG, GET GOOVO GEN/VER NUM*/ GDGLEN=LENGTH(ENTRNAME); VCK =SUBSTR(ENTRNAME,GDGLEN-2,1); DOTGCK=SUBSTR(ENTRNAME,GDGLEN-8,2); IF DOTGCK='.G' AND VCK='V' THEN DO; GENNO=INPUT(SUBSTR(ENTRNAME,GDGLEN-6,4),?? 4.); VERNO=INPUT(SUBSTR(ENTRNAME,GDGLEN-1,2),?? 2.); END; END;
Scott had provided this elegant alternative that uses the TRANSLATE and SCAN functions, worthy of sharing: IF ENTTYPID='H' THEN DO; /*GDG, GET GOOVO GEN/VER NUM*/ LASTNODE = SCAN(ENTRNAME,-1,'.'); IF TRANSLATE(LASTNODE,'%%%%%%%%%%','0123456789') = 'G%%%%V%%' THEN DO; GENNO=INPUT(SUBSTR(LASTNODE,2,4),4.); VERNO=INPUT(SUBSTR(LASTNODE,7,2),2.); END; END;
Thanks to Scott Barry, SBBWorks, Inc, USA. Change 25.273 APAR PK38803 incompatibly alters SMF 102 IFCID 22 Record. VMAC102 -These variables were INPUT as fixed length text, but they Jan 2, 2008 can be longer, and can be relocated in the SMF record. MXG now detects the new OFFSETs and INPUTs $VARYING32: Variable Fixed Length Label QW0022CN $EBCDIC18. /*TABLE*CORRELATION*NAME*/ QW0022CR $EBCDIC8. /*TABLE*CREATOR*/ QW0022TN $EBCDIC18. /*TABLE*NAME*/ QW0022AC $EBCDIC8. /*QW0022XC:ACC INDEX CREATOR*/ QW0022AN $EBCDIC18. /*qw0022XN:INDEX NAME*/ (Note: 22AC and 22AN were original DSECT names)
varying length fields on the MXG log, so I can validate. -Records with QW0022PL=. have many missing values, and the $CHAR vars formatted with $HEX have '20'x vice '00'x. The obs was created from a second record, after a legitimate instance with 6 observations, and has only R1O segment. -_S102022 SORT MACRO revised and tested for dupe removal. Jan 23, 2008: Change 25.306 is now required for PK38803. Thanks to Scott Barry, SBBWorks, Inc, USA.
VMAC7072 bit 1 of SMF70PFL is ONE, as that bit indicates this LPAR Dec 21, 2007 is part of a capacity group of that name. If bit 1 is zero, SMF70GNM is blanked, because some z/OS 1.8 data had non-blank SMF70GNM when bit 1 was zero. While I could have created a separate variable for bit 1 to identify this LPAR is in a capacity group, with this change there is no need for a second variable; now, IF SMF70GNM GT ' ' then this LPAR is in that Capacity Group, otherwise not. Thanks to Al Sherkow, I/S Management Strategies, USA. Change 25.271 Corrections for TMON/IMS support. VMACTIMS -CM5612TM is a datetime variable, now format DATETIME21.2. Dec 21, 2007 -CMCOMP, CPCOMP are formatted HEX8. -XXTOKN Token variables are LENGTH 5 and HEX8 format. -CMGMTA value's second division by 4096 was removed. -ENDTIME is already on Local time, its GMT correction was removed. -These variables were incorrectly input as &PIB.8.6 vice &PD.8.6, causing too-large values when non-zero: TIMSCH: CMTMEIO CMTMEPL CMMINT CMMPOL CMMSCH TIMSCM: CMTMEIO CMTMEPL CMMINT CMMPOL CMMSCH TIMSCN: CNTMEIO CNTMEPL CNMINT CNMPOL CNMSCH TIMSCP: CPTMEIO CPTMEPL CPMINT CPMPOL CPMSCH TIMSCT: CTTMEIO CTTMEPL CTMINT CTMPOL CTMSCH These fields were correctly documented as Packed in the DSECT, but overlooked originally as they all were zero. -Variables input &PIB.8.6 that are NOT GMT offsets are NOT then divided by 4096: e.g., CTRSPTME when CTSDATE and CTSPDATE are both non-missing matches their delta. However, when CTSDATE is missing, CTRSPTME contains the value of CTSPDATE shifted right by three nybbles, i.e. a very large and very invalid data. This problem will be passed to Landmark for correction, but is circumvented by MXG setting CTRSPTME to missing. -Five CPU variables are documented on the DSECT as (MILS) for milliseconds and have always been input as &PIB.4.3: CHCUMCPU CMCUMCPU CNCUMCPU CPCUMCPU CTCUMCPU -But eleven REGION*CPU*TIME variables have no clue as to their decimal place location: CHCTCPUT CHDBCPUT CHDLCPUT CHIRCPUT CHCQCPUT CJTXNCPU CNCTCPUT CNDBCPUT CNDLCPUT CNIRCPUT CNCQCPUT I have arbitrarily input them as &PIB.4.3 (MIL) but this must be validated. -These variables are assumed input of &PIB.4.6 to be like their xxDUR counterparts, but this must be validated: CMSQ6GM CMACCQ6 CNSQ6TM CNACCQ6 CPSQ6GM CPACCQ6 CUSQ6GM CUACCQ6 Thanks to Warren Waid, JC Penny, USA.
ASUM70PR can NOT be used, and output datasets created with that VMXG70PR tailoring will be invalid if STARTIME is changed in your Dec 19, 2007 IMACRMFI member and you used the default ASUM70PR, which specified INTERVAL=DURSET as its default prior to this change. You must use INTERVAL=HOUR, QTRHOUR, etc. in in your %VMXG70PR invocation in your ASUM70PR member to specify the desired interval. For RMFINTRV, you can still use IMACRMFI/DURSET, because it is a per-SYSTEM dataset, but I still recommend you use INTERVAL=xxxx and not use IMACRMFI, for clarity.
Because ASUM70PR summarization combines SYSTEMs that can have different STARTIME, it uses and resets the value in SMF70GIE. When I detect INTERVAL=DURSET, I have to detect if STARTIME was changed in IMACRMFI, and if so, then MXGDURTM (that you added in your IMACRMFI per Change 25.150) must be added to STARTIME to create SMF70GIE. I though I could use this code: OLDSTART=STARTIME; _DURSET;
IF STARTIME NE OLDSTART THEN DO; and that worked with the first test case. However, I now discover that the test will always fail if STARTIME is already exactly on the interval, i.e. STARTIME=DHMS(DATE,HOUR,0,0); for HOURly intervals will equal OLDSTART when OLDSTART is exactly on the hour. Since I can only detect some, but not all, changed obs, I cannot support IMACRMFI and DURSET in ASUM70PR. This is a rare problem; using INTERVAL=value in the ASUM70PR invocations of %VMXG70PR and RMFINTRV invokes of %VMXGRMFI is self-documenting and works safely, so this change is mostly this change text and updates to the INTERVAL= documentation comments in the cited members.
EXTY50 observations with ATTCHTYP=4 to TYPE50 dataset, but only FORMATS if this DEV had activity during this interval; the logic VMAC50 that deletes zero-activity intervals is in the EXTY50 Dec 22, 2007 if you should want to output all of those observations. Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
AAAAAAAA members, but the member CHANGES was correct with 2007. COPYRITE The dates were corrected and the ftp site was refreshed Dec 7, 2007 on Tuesday with the Dec 7, 2007 date. Thanks to Mike Ryan, Acxiom, USA.
AUTOEXEC options, a temporary variable in VMAC78 caused AUTOEXEU ERROR: The variable named N78HCNTCN contains more than AUTOEXEW 8 characters CONFIGV8 because the V6 value restricts the length of variable's CONFIGV9 names to be 8 bytes or less. VMAC78 MXG tests with the default VALIDVARNAME=V7, which allows Dec 7, 2007 variable names to be up to 32 characters. But almost all MXG variables will always be 8-bytes or less, because I think shorter, encoded, albeit cryptic, variable names are easier for PROGRAMMERs to work with. But because some new open systems code was written with their long names, and because change the default in the MXG members can do no harm but can avoid future errors, VALIDVARNAME=V7 has been added to MXG CONFIGVx and the AUTOEXEx members. Thanks to Andreas von Imhof, Rabobank Nederland, THE NETHERLANDS.
VMAC110 the CICS/TS 3.2 expected values. Dec 6, 2007 Thanks to MP Welch, SPRINT, USA. Change 25.265 Required for DB2 Version 9.1, DB2TCBTM correction. VMACDB2 DB2TCBTM could be significantly less than it should be in Dec 7, 2007 non-rollup observations in DB2ACCT. The CPU time delta QWACEJST-QWACBJST was NOT included in DB2TCBTM when QWACBJST was zero (and DB2PARTY NE 'R') in DB2ACCT. And the loss has only been reported at sites with zIIP engines for their DB2 systems.
QWACBJST=0 meant that CPU timing was in error, and so MXG had always NOT included that QWACEJST-QWACBJST delta in MXG's DB2TCBTM variable. Accidentally, DB2TCBTM for the Rollup Records (i.e., DB2PARTY='R") has always included the QWACEJST when QWACBJST=0. Note that DB2TCBTM=SUM(DB2TCBTM,QWACSPCP,QWACTRTE); is the final value output in DB2ACCT dataset.
an MXG site that QWACBJST=0 is valid and the QWACEJST in those records should be included in DB2TCBTM, adding that "If we have an agent running 100% on a zIIP, QWACBJST will be zero." It was only after that reply from IBM DB2 Support that I looked to see the CPU timing not is not in DSNWMSGS in the DB2 V 1.9 Macro Library.
can measure how much DB2TCBTM was lost with PROC MEANS SUM DATA=PDB.DB2ACCT (WHERE= (DB2PARTY NE 'R' AND QWACBJST=0)); VARIABLES QWACEJST; TITLE TOTAL QWACEJST NOT INCLUDED IN DB2TCBTM; If no observations are selected, no CPU time was lost. Several folks at DB2 Support were ultimately involved in the problem, providing this information about PK46171: - Class 1 CP, zIIP, and elapsed times could be incorrect. Because we don't get a 'start accounting' call: 1. QWACBSC would be from the last transaction to see a start
transaction to see a start -- this can result in this number being unrelated to QWACEJST 3. QWACCLSL_ZIIP would be effected similarly to (QWACEJST - QWACBJST) since it is internally calculated from a start ziip time that can be unrelated to the end time 4. QWACAJST and QWACCLS2_ZIIP are probably not noticeably effected although there could be an Yüklə 28,67 Mb. Dostları ilə paylaş:
|