* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Change 25.108 Unused Change. ====== Changes thru 25.107 were in MXG 25.05 dated Jun 7, 2007========= Change 25.107 Support for CA Brightstor Tape Encryption user SMF record EXBTENCR creates two new datasets: EXBTEN32 DDDDDD MXG MXG IMACBTE DATASET DATASET DATASET REC TYPEBTE SUFFIX NAME LABEL St TYPSBTE BTENCR BTENCRYP BTENCR: BRIGHTSTOR TAPE ENCRYPTION all VMACBTE BTEN32 BETNCR32 BTEN32: BRIGHTSTOR SUBTYPE 32 VMXGINIT but this change was not included in MXG 25.05; 25.06+ is Jun 7, 2007 needed for these data. See also Change 25.143. Jun 14, 2007 Thanks to Ray Dunn, CIGNA, USA.
TYPETMS5 IF DSN='DB2SPEC.DBBKUP.ONSITE.CSTDB21R.CSTTSP10' THEN Jun 5, 2007 statement that should have been deleted. Thanks to Jan Bigalke, AGIS Allianz Dresdner Infosys, GERMANY. Change 25.105 -Variable PARTNCPU contains the number of CP Engines, but VMAC7072 the "in what" is different in different MXG datasets: VMXG70PR In ASUMCEC and ASUMCELP the label now reads: Jun 5, 2007 PARTNCPU='NUMBER OF*CP ENGINES*IN CEC' in TYPE70PR, ASUM70PR, and ASUM70LP, the label now reads: PARTNCPU='NUMBER OF*CP ENGINES*IN PARTITION' For example, you could see PDB.ASUMCEC with NRPRCS=5 NRPHYCPS=4 NRICFCPU=2 PARTNCPU=2 and PARTNCPU is thus the correct number of CP engines for any "CPU Busy" calculations. -Variable MXGCIN was not always set correctly for 'ICF's; fortunately, there was no impact on other variables. -If you should accidentally/incorrectly run ASUM70PR with incorrect CECINTRV=QTRHOUR reading DURATM=30 Minute data, then, as should be expected, the ASUMCEC output dataset is invalid, and had many PCTCPU's much greater than 100%. Change 25.104 Full support for NMON, Nigel's Monitor for AIX/unix. All EXNMONAA OBJECTs are now supported; an NMONxxxx dataset is created EXNMONCD from each OBJECT that has multiple instances per interval EXNMONDS (e.g. NMONDISK has an observation for each DISKNAME), and EXNMONIN EXNMONIO NMONINTV dataset has all metrics from all OBJECTs that EXNMONJF have only one instance per interval. EXNMONNT
EXNMONFS These datasets are now created from NMON records: EXNMONTO DDDDDD MXG MXG EXNMONUA DATASET DATASET DATASET EXNMONVG SUFFIX NAME LABEL Instance EXNMONWL IMACNMON NMONAA NMONAAA NIGELS MONITOR AAA CONFIG none VMACNMON NMONCD NMONCPUD NMON CPU DETAIL CPUNR VMXGINIT NMONDS NMONDISK NMON DISK DISKNAME Jun 5, 2007 NMONIN NMONINTV NIGELS MONITOR INTERVAL none NMONIO NMONIOAD NMON IOADAPTER IOADAPTR NMONJF NMONJFSF NMON JFSFILE JFSFIL NMONNT NMONNETW NMON NETWORK NETNAME NMONFS NMONNFS NMON NFS CLIENT AND SERVER NFSTYPE NMONTO NMONTOP NMON TOP PROCESS PID NMONUA NMONUARG NMON UARG PROCESS PID PPID NMONVG NMONVG NMON VOLUME GROUP VOLGROUP NMONWL NMONWLM NMON WLM WLMCLASS
DATASET DATASET DATASET are listed. SUFFIX NAME LABEL
OBJECTS: AAA NMONCD NMONCPUD NMON CPU DETAIL OBJECTS: CPUnn NMONDS NMONDISK NMON DISK OBJECTS: DISKBUSY DISKREAD DISKWRITE OBJECTS: DISKXFER DISKBSIZE NMONIO NMONIOAD NMON IOADAPTER OBJECTS: IOADAPT NMONJF NMONJFSF NMON JFSFILE OBJECTS: JFSFILE JFSINODE NMONNT NMONNETW NMON NETWORK OBJECTS: NET NETPACKET NETERROR NMONFS NMONNFSS NMON NFS CLIENT AND SERVER OBJECTS: NFSCLIV2 NFSCLIV3 OBJECTS: NFSSVRV2 NFSSVRV3 NMONTO NMONTOP NMON TOP PROCESS OBJECTS: TOP NMONUA NMONUARG NMON UARG PROCESS OBJECTS: UARG NMONVG NMONVG NMON VOLUME GROUP OBJECTS: VGBUSY VGREAD VGWRITE OBJECTS: VGXFER VGSIZE NMONWL NMONWLM NMON WLM OBJECTS: WLMCPU WLMBIO WLMMEM
OBJECTS: CPU_ALL VARS: PCPUUSER PCPUSYS PCPUWAIT VARS: PCPUIDLE PCPUBUSY NRCPUS OBJECTS: MEM VARS: REALFREE VIRTFREE REMBFREE VARS: VIMBFREE REMBTOTL VIMBTOTL OBJECTS: MEMNEW VARS: MNPROCPC MNFSCAPC MNSYSTPC VARS: MNFREEPC MNPINNPC MNUSERPC OBJECTS: MEMUSE VARS: MUNUMPPC MUMINPPC MUMAXPPC VARS: MUMINFPC MUMAXFPC OBJECTS: PAGE VARS: PGFAULTS PGIN PGOUT PGSIN VARS: PGSOUT RECLAIMS SCANS CYCLES OBJECTS: PAGING VARS: PGMBFREE OBJECTS: LARGEPAGE VARS: FREEPAGE USEDPAGE PAGES VARS: HIGHPAGE SIZEMB OBJECTS: PROC VARS: RUNNABLE SWAPIN PSWITCH VARS: READ WRITE FORK EXEC SEM MSG VARS: SYSCALL OBJECTS: PROCAIO VARS: AIOPROCS AIORUNNG AIOCPU OBJECTS: FILE VARS: IGET NAMEI DIRBLK READCH VARS: WRITECH VARS: TTYRAWCH TTYCANCH TTYOUTCH OBJECTS: LPAR VARS: PHYSICPU VIRTCPUS LOGLCPUS VARS: POOLCPUS ENTITLED WEIGHT VARS: POOLIDLE USEDALL USEDPOOL VARS: SHARECPU The JFSFILE and JFSINODE objects have errors in one file out of many; after many intervals, the number of data fields in those object records is smaller than the number of file names in the "dictionary" record. Logic in MXG detects and reports these bad records on the log, and deletes the defective records. If a fix from Nigel is forthcoming, this note will be updated. Thanks to Steve Olmstead, Northwestern Mutual Trust, USA. Thanks to Henry Steinhauer, Northwestern Mutual Trust, USA.
EXITRMST -Many new variables added to datasets ITRFMSG & ITRFMSGO. IMACITRF -Variables LOCLTIME and PSTNR added to all ITRF datasets. VMACITRF -New ITRFMSGT dataset is created from subtype 12 with the VMXGINIT text of the DFS554A message. Jun 4, 2007 -There is a known error now fixed in APAR CCnnnnn; a few '10'x records (39 out of 10000) are misaligned, causing very high CPU time (1E13) and missing value in LOCLTIME. Use PROC MEANS N MIN MAX SUM DATA=ITRFMSG; to examine the maximum value of ACCPU and SRBTIME and LOCLTIME to see if it has any missing values. Thanks to Guenter Rucks, FinanzIT GmbH, GERMANY. Thanks to John Maher, IBM Tivoli, USA. Thanks to Bert Winberg, IBM Nordic Processor, DENMARK. Change 25.102 The erase of the old month directory syntax was wrong; VMXGALOC statement %let killmo="&basedir.w%trim(&killmnth)\*.*"; Jun 2, 2007 is now %let killmo="&basedir.m%trim(&killmnth)\*.*"; Thanks to Patrick Holloman, Zions Management Service Company, USA. Change 25.101 MXG 25.04 only. Back in Change 25.085, I added options MEMLEAVE=25M NOSORTBLKMODE in CONFIGV9 because they did CONFIGV9 correct an error, but those values were suggested for the Jun 1, 2007 diagnostics; this change restores SORTBLOCKMODE because it is used by DFSORT for significant improvement in sort performance, and it is the SAS default, so it no longer set in MXG's CONFIGV9. MEMLEAVE protects a virtual storage area used only by SAS (especially needed when SAS calls an external product, like a host sort program), but MEMLEAVE is taken from the REGION size of the JOB; if you had an old job with the prior-recommended-by-MXG of REGION=64M, with MEMLEAVE=25M you only had 39M for the MXG job. Additionally, the SAS recommended value is 10% of the REGION size, and almost all of MXG will execute in a REGION=100M, changing the value to MEMLEAVE=10M is more correct. But what about REGION=0M, didn't that solve the need to periodically increase any static REGION=nnnM values in your JCL? Yes, it did, prior to the new Threaded Kernel Memory architecture in SAS V9, which operates independent of the prior "SAS Proper" WM Memory architecture, but the existence of two independent memory managers in one ASID has uncovered memory exposures if and only if REGION=0M is specified. While a future version of SAS may resolve, the safest recommendation now is to set REGION=100M on your job card, with this revised CONFIGV9 member in use. (MXG also sets NOTHREADS because there are exposures to the use of THREADS on z/OS at this time that need to be understood, so I leave it to you to decide to THREADS, but even with NOTHREADS, the REGION=0M exposure exists, because SAS V9 itself is threaded.) Thanks to Jim Hayes, Huntington, USA. Change 25.100 Documentation. References to JCLINSTL were changed to INSTALL JCLINST9 for SAS V9.1.3 or JCLINST8 for SAS V8.2; the JCLINSTx JCLINSTL member no longer exists because it didn't work Jun 1, 2007 for both SAS versions, but I failed to update the doc. Thanks to Allan Hardman, Co-Operative Bank, ENGLAND.
VMAC112 ERROR and/or incorrect values in T112DLI and T112DLIT VMACOMCI datasets; an 8-byte field was overlooked. May 31, 2007 -Jun 28: Detection of unknown TTYPE added for safety. Jun 28, 2007 -The SMF 112 record replaced the OMEGAMON for CICS user Jun 30, 2007 SMF record, but only the SUBTYPE=203 "ONDV" record is processed by TYPE112, because that is the useful data, because only the subtype 203 can be compressed, and because the existing TYPEOMCI/TYPSOMCI code will read the other two subtypes: 200 - SYST 201 - INTR in a standalone job from SMF with this example
//SMF
//PDB //SYSIN DD * %LET MACKEEP= MACRO _IDOMCI 112 % %INCLUDE SOURCLIB(TYPSOMCI); so you can investigate if the other two subtypes contain data of interest. You could easily add processing of the SMF 112 and OMCI records to your BUILDPDB, using:
%QUOTE( IF ID=112 THEN DO; INPUT @OFFSMF+19 SUBTYPE &PIB.2. @; IF SUBTYPE IN (200,201) THEN ID=299; END; );
%UTILBLDP(BUILDPDB=YES,USERADD=112 OMCI); %INCLUDE INSTREAM; Because the TYPE112 code now processes the subtype 203, VMACOMCI now only reads subtype 200 and 201 records, it was updated to accept V560 version, and the four bytes inserted for compression statistics are skipped. But see Change 26.257, which revised OMCI and 112 code. Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA. Thanks to Ray Dunn, CIGNA, USA.
UTILBLDP generate an %INCLUDE for BUILDPD3 instead of BUILDPDB to May 31, 2007 create a PDB library with JES3 instead of JES2 records. Thanks to Julian Smailes, Experian, ENGLAND. Change 25.097 MXG-created DB2-variable THREADTY was blank if there was VMACDB2 no QLAC segment (i.e., non-DDF), because the MXG code to May 28, 2007 create THREADTY was located inside the QLAC processing, Jun 6, 2007 because the logic needs to test QLACLOCN. The code block was relocated to after the QLAC processing, and THREADTY should, now, always be populated. -THREADTY added to DB2ACCTP dataset default KEEP list. Thanks to Eileen F. Van Etten, Bank of America, USA. Change 25.096 Using an IMAC7072 tailoring that had an old _STY70 caused IMAC7072 ERROR: VARIABLE LPARNAME NOT FOUND. from within a VMXGSUM May 28, 2007 that was "INVOKED BY VMXGRMFI TYPE70 - R70HOUR", although the real error was back when PDB.TYPE70 was created, as it had zero observations because the new "SPLIT70" _STY70 must be executed, now, to create observations in TYPE70. Removing the IMAC7072 corrected the error; it has been the MXG recommendation to remove all of the old IMACnnnn "product tailoring" members, and use only IMACKEEP to redefine macros you know you want to change. Long ago, the IMACxxxx members actually defined the _L, _K, _S, _B etc macros, but those definitions moved into the VMACxxxx member precisely because of these exposures when I have to make an incompatible change in MXG architecture. Thanks to Jim Hayes, Huntington, USA. Change 25.095 Reading VSAM SMF with TYPE42 caused false MXG messages VMAC42 **ERROR SHORT SMF 42 SUBTYPE 6 ACCESS METHOD SECTION May 28, 2007 (OFFDSAM=1 confirms it's a false message) and **ERROR INVALID TYPE42 SUBTYPE 5 RECORD (COL=229,S42VTVDO=228 confirms false message). and these records were incorrectly deleted, but only when the (undumped) VSAM SMF file is read; when the (normal, dumped) BSAM SMF file is read, there are no errors. Logic to handle OFFSMF for subtype 5 and OFFDSAM revised. Thanks to Jim Poletti, Edward Jones, USA. Change 25.094 Harmless divide by zero when EXCPDASD was zero; the obs ANALBLSR is now deleted since it can't be a BLSR candidate. May 28, 2007 Thanks to Rodger Foreman, TransUnion, USA. Change 25.093 With BUILDPDB=YES,SUPPRESS=DB2, an %INCLUDE for ASUMCICX UTILBLDP was generated, but the prerequisite %INCLUDE for ASUMUOW May 22, 2007 was not generated, causing ASUMCICX to fail in a SORT. Thanks to Robert Sample, Atlanta Journal Constitution, USA. Change 25.092 Doc only. The example in the comments to run ASUM70PR ASUM70PR against SMF data was incorrect; the corrected example is: VMXG70PR %INCLUDE SOURCLIB(TYPS7072,ASUM70PR); May 21, 2007 Error Dataset PDB.TYPE70PR NOT FOUND resulted if you used the example in the comments. Thanks to Art Cuneo, Health Care Services, USA. Change 25.091 After MXG 25.04 QA completed, but before it was packaged, TESSOTHR a untested TESSOTHR member was copied into SOURCLIB; the May 15, 2007 PROC COPY that causes the ERROR in JCLTEST9 is removed. Thanks to Randy Parker, Trustmark National Bank, USA. Change 25.090 -Support for PK37354 SMF 100 Subtype 4 in DB2 V1.9, which EXDB2ST4 will contain the old IFCID=225 (ID=102 Subtype 225) data. IMACDB2 This makes my head hurt, because I can't safely use the VMACDB2 old T102S225 dataset name: combining 100 and 102 records VMAC102 in the same DATA step would cause SAS to fail due to the VMXGINIT duplicate output dataset names. So the old IFCID=225 May 15, 2007 data will be output in new DB2STAT4 dataset. -NEW QW0225BB='STORAGE POOL*MANAGER*BLOCKS BELOW*THE LINE' was also added by this APAR, for both DB2 V1.8 and 1.9, and it is INPUT and kept in T102S225 and DB2STAT4. Apr 8, 2008: QW0225BB was only added to T102S225 by this change. Change 26.057 added it to DB2STAT4. Change 25.089 GMTOFF30 must be calculated because IBM does not put it VMAC30 in SMF 30 records; it can only be calculated from the May 14, 2007 subtype 2 or 3 interval records, which contain interval May 31, 2007 start on both local and GMT clocks (SMF30IST is local and Jun 1, 2007 SMF3ISS is GMT), and then GMTOFF30 was used to create the Jun 18, 2007 local zone INTBTIME & INTETIME interval start/end times. It was also RETAINed to convert INTETIME in the subtype 6 record, which has no local counterpart, and from which INTBTIME will be created when TYPE30_6 is deaccumulated. These problems existed prior to this change: - Subtype 6 logic caused GMTOFF30 to be zero, causing INTBTIME/INTETIME in TYPE30_6 to be wrong. Worse, if the next subtype 2/3 did not have a CPU segment, (MULTIDD='Y' observations have no CPU segment and thus SMF30IST is a missing value), that RETAINed zero GMTOFF30 value was used, causing INTBTIME/INTETIME in TYPE30_V and PDB.SMFINTRV datasets to be wrong. - Subtype 2 and 3 records for OMVS tasks do NOT have the interval start time in SMF30IST (they appear to have the original substep initiate time, not the current interval's start time; this undocumented feature caused very large GMTOFF30 values (like -29 hours). This change revised the subtype=6 logic so GMTOFF30=0 is not created, and the OMVS records (SUBSTEP GT 0) are not used to calculate GMTOFF30; instead, they use the RETAIN value of GMTOFF30 to recalculate INTBTIME and INTETIME. There can still be errors in the value of GMTOFF30, or INTBTIME or INTETIME because of the need to RETAIN the GMT offset from prior records, but many records do not have the needed data. These design errors exist in 30s: - SMF30IST is wrong in OMVS (SUBSTEP GT 0) records. - SMF30IST is not populated in subtype 6 records. - SMF30IST is not populated in records with no CPU segment, notably MULTIDD='Y' records with only EXCPs, or records with more MULC segments than fit in one physical SMF 30 record. The only solution for auditable SMF 30 data is for IBM to add the GMT Offset value in EVERY type 30 record. -May 31, 2007: Variable INTRVLTM was missing after May 14 change, only for SUBSTEP GT 0 (USS - OMVS) tasks, because it wasn't calculated in that revised code block.
fixed datetime value of '17SEP2042:23:53:47.37' in all subtype 6 records was found at one site; the hex value of the field showed it was actually a negative binary value of -22 (the number of leap seconds of offset!) when it was INPUT as &IB.8.6 and then divided by 4096, which is the TODSTAMP algorithm for negative values. IBM's SMF manual only documents SMF30IST/SMF30IET for the subtype 2 and 3 records; in subtype 6, SMF30IST is always missing, but previously SMF30IET was the valid end time. Now, additional logic detects the duration rather than datetime in SMF30IET, and sets SMF30IET from SMFTIME in those cases in TYPE30_6 observations. -Jun 18, 2007: IF TST30IET GT 0 THEN test was corrected of IF TST30IET LT -30 THEN because valid TODSTAMP values have first bit on, which causes TST30IET to be always be negative, but the -30 test detects the invalid values of IET that contained leap seconds and not a valid time. Thanks to Douglas C. Walter, Citicorp, USA. Thanks to Rudolf Sauer, T-Systems Enterprise Services, GERMANY. Change 25.088 The &VMXGVERS as the last line should have been %VMXGSERS VGETDDS
May 10, 2007 Thanks to Jim Horne, Lowes', USA. Change 25.087 BROKEN CONTROL RECORD error caused by DMN=10 RC=2 record VMACVMXA for MDGPROD=:'5739A03RM0000000' logic, now corrected. May 10, 2007 Thanks to Tom Draeger, Aurora, USA. ====== Changes thru 25.086 were in MXG 25.04 dated May 7, 2007========= Change 25.086 New Analysis of CEC-level z/OS Capture Ratio combines PDB ASUMCAPT ASUMCEC and RMFINTRV datasets, summing workload CPU & TCB VMXGCAPT time for all Service Classes in all z/OS LPARS in the CEC May 6, 2007 to create new dataset PDB.ASUMCAPT with total CPUACTTM from PDB.ASUMCEC and total CPU72TM from PDB.RMFINTRV for new variable CECAPTRT='CEC*CAPTURE*RATIO' to be created CECAPTRT=100*CPU72TM/CPUACTTM; You can simply add %INCLUDE SOURCLIB(ASUMCAPT); after the your %INCLUDE SOURCLIB(ASUM70PR); in your BUILDPDB job. The default summarization is by HOUR. This hour's data shows how 17532 CPU Seconds of CEC Busy time ends up as only 16389 CPU seconds captured in RMF 72 Service Class records, for a CECAPTRT=93.48 for the CEC:
| ASUMCEC | RMFINTRV | RMFINTRV | RMFINTRV | RMFINTRV | | CPUACTTM | CPUMVSTM | RMFACTTM | CPUEFFTM | CPU72TM | | 17532 | 17500 | 17448 | 17389 | 16389 | | | | | | | | | | | | __16389__ | | | | | / | | | | |__17389__/| | | | | /| | | | | |__17448__/ | | | | | /| | | | | |__17500__/ | | | UNCAPTURED| | /| ??Phys?? | PHYSICAL | CPUOVHTM | | |__17532__/ |__ 32__ | __ 84__ | __ 143__|__ 1143__ | Of those 16389 CPUTM seconds, only 14086 was CPUTCBTM, showing why you MUST use total CPUTM and not just TCB. Change 25.085 Strange V9.1.3 z/OS memory failures in the SAS Internal CONFIGV9 SORT (no error message on SAS log nor in JOBLOG, even no May 4, 2007 end of step IEF374I message, but SYSLOG shows the job was placed in HOLD by JES after a S0F9 ABEND; system couldn't acquire storage for an SVRB. The error was in _BLDEXCL of UTILEXCL's sort to create dataset UNIQUE, which must use internal SAS sort because its BY list is way over the 4092 character limit of host sort packages. By using a REGION=256M (not REGION=0M, NO LONGER SAS-RECOMMENDED) and by using these replacement values in CONFIGV9 that were recommended by SAS Technical Support: MEMLEAVE=25M NOSORTBLKMODE the error was eliminated. So I have added those option values to the CONFIGV9 member in this change. -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I. Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
TYPETMS5 created from the VOL record, for multi-volume, multi-file VMACTMS5 tapes. FILSEQ does not exist in the VOL record, but MXG May 4, 2007 creates a pseudo-DSNBRECD obs with the DSNAME in the VOL May 29, 2007 record; MXG logic did not handle these cases correctly. VMACTMS5 changed only cosmetic DEBUG statements. May 29: TYPETMS5 member in MXG 25.04 did NOT contain this correction; the member copied into MXG 25.04 was not the tested member that is now updated and redated May 29. Thanks to Tim Hare, Florida Department of Transportation, USA. Thanks to Paul Naddeo, FiServ, USA.
VMAC21 SMF21DBR and SMF21DBW were still wrong after two tries. May 3, 2007 I missed the 4096 multiplier, and I reversed the label text COMPRESSED/UNCOMPRESSED in all four variables. Worse, the customer actually had to go to IBM Support, who quickly and politely diagnosed my coding errors. These old variables always had correct value: BYTEREAD='UNCOMPRESSED*CHANNEL*BYTES*READ' BYTEWRIT='UNCOMPRESSED*CHANNEL*BYTES*WRITTEN' These new variables were wrong prior to this change: SMF21DBR='COMPRESSED*DEVICE*BYTES*READ' SMF21DBW='COMPRESSED*DEVICE*BYTES*WRITTEN' These two new compression ratio variables are created: SMF21CRR='READ*COMPRESSION*RATIO' SMF21CRW='WRITE*COMPRESSION*RATIO' Thanks to Karl Lasecki, Chemical Abstracts Service, USA. Thanks to Ken C. Jobbitt, IBM Support, USA.
EXXMHAPP VSISFT,VSISYS,VSIUSR and STOSCS creates new VMXHSTAPP, EXXMHAPP XMVSIAPP,XMVSINAP,XMVSISFT,XMVSISYS,XMVSIUSR, and EXXMOSCS XMSTOSCS datasets. Variables fron new segments SYTSXP Yüklə 28,67 Mb. Dostları ilə paylaş:
|