* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
-SMFSRCH reports the counts/sizes of SMF records input and selected, and maps USER SMF records to their product if the_IDxxxx macro was found. -New parameters added to VMXGGETM, used in new SMFSRCH: BEGTIME= earliest datetime to be selected ENDTIME= latest datetime to be selected INCODE= A stub of code executed after the header is read LOOKFOR= text string to be searched in each SMF record -TYPESMF executes all TYPExxxx member that read any SMF records, reading SMF once for each TYPExxxx member, so it is only used in SMFSRCH to read the selected records. -VMXGPRAL's TITLE "PRINT OF FIRST MAX OBS.." corrected. Thanks to Jeffrey Dyke, USDA, USA.
VMAC102 error with DB2 V10, but did not work for DB2 V9. And, in Oct 19, 2011 testing this update the T102I022 dataset was found to be in serious need of realignment. Thanks to Tom Buie, Southern California Edison, USA.
VMAC110 print the value of the triplets (dictionary records) that Oct 19, 2011 are defined in your IMACEXCL tailoring, to make it easier to see that your UTILEXCL missed a dictionary record. Change 29.233 Support for BETA93 Version 4.1.0: Subtype 25 was changed, VMACBETA with fields removed, causing wrong or missing values in Oct 18, 2011 dataset BETA25, plus INVALID DATA FOR BETASTRT messages. These variables are now missing/blank with 4.1.0: BETACPU BETAELAP BETAEND BETAETKN BETALTKN BETAOWNR BETARTKN BETASTRT BETAVIOR BETAVIOW Additionally, missing value messages for some datetimes are circumvented by testing DATE GT 0 before calcs. Thanks to Michael Brenning, Finanz Informatik, GERMANY.
VMAC16 documented as to their units, but data shows they are in Oct 15, 2011 KB and not Bytes, so they are now multiplied by 1024 to Oct 25, 2011 convert to bytes, and then so MGBYTES format will print 16M rather than 16K previously printed. IBM has privately verified that the units are 16M and plan to update their DFSORT documentation to show the units attribute. Thanks to Neil Ervin, Wells Fargo Bank, USA. Change 29.231 Support for Axway CFT/ESA (Cross File Transfer) two SMF EXAXWAY record formats ("2.3" and "2.4" but "2.3" format records FORMATS (8-byte vs 32-byte fields) are created/creatable with the IMACAXWY current CFTMON 2.6.4. As there is no version number and TYPEAXWY the two records have same length, three one-byte fields TYPSAXWY that must be blank in 2.4 are used to identify version of VMACAXWY the record. The 2.4 code with 32-byte fields is INPUT VMXGINIT first so the kept variables will be the longer length. Oct 15, 2011 Nov 17, 2011 Thanks to Richard Wendland, US Bank, USA. Thanks to Claude Breault, Centre de Services Partages Quebec, CANADA. Change 29.230 Comparison of BMC IMF FA and IBM 56FA IMS Log records. ASUM56FA -Variable IMSRECCH added to CIMSTRAN to capture that IMS EXIMS56C log sequence number at the end of each IMS log record; it FORMATS was already in IMF56FA. In TYPECIMS variable IMSRECNR is IMACIMS the _N_ sequence number and is NOT input from the record. TYPEIMST -IMS56FA records are written as pairs for a single IMF FAx VMACCIMS log record. The pair have the same ARRV and STRT times, VMACIMS and are written 5 milliseconds apart at transaction end. VMXGINIT -See the new IMS Technical Note in NEWSLETTER FIFTY-NINE Oct 11, 2011 for a detail explanation of what is captured in IMS56FA Oct 21, 2011 transaction event records, and a comparison with IMF. Oct 27, 2011 -ASUM56FA program (still in testing) is added to MXG. Change 29.229 -Variable TPMCA7JN is now input &PIB.2. + 2 versus &PIB.4. VMACTPMX -Variable TPMPI was decimal 243 for 'F3'x which is EBCDIC Oct 11, 2011 numeric/character three. INPUTing TPMPI as $EBCDIC1 would Oct 15, 2011 create a character variable with value '3', but TPMPI is a numeric variable, so the field into TPMPICH $EBCDIC1., but then TPMPI=INPUT(TPMPICH,1.); will preserve TPMPI to remain a numeric variable, but with value 3 versus 243. -Datetime variable TPMDUEOT is now correctly populated but that variable can have a missing value. Thanks to Tren Csuy, Humana, USA. Thanks to Scott Barry, SBBWorks Inc, USA.
BUILD005 factors that were used to normalize those Engine's CPU BUIL3005 time are now kept in PDB.JOBS. This updates Change Oct 11, 2011 28.139. Nov 17, 2011 Nov 17: (DROP=_26NJE) was added to DATA TYPE26J2 to ensure dropping of those NJE variables from PDB.JOBS, if those variables were still somehow in SPIN26. Thanks to Jim Horne, Lowe's Companies, USA Change 29.227 -Revised code to read HP MeasureWare NT records with new VMACMWNT fields added in GLOG record: Oct 8, 2011 PKDSKPCT='PEAK*DISK*PERCENT' PKDSKTIM='PEAK*DISK*TIME' and with the MXG code restructured to match the changed fields in the REPORT command used to extract the data. -DDMMYY8 format revised to DDMMYY10 for those dates. Thanks to Frank Tonneau, KBC Global Services NV, BELGIUM. Thanks to Geert Debatselier, KBC Global Services NV, BELGIUM.
VMAC1415 could print for a record without an Extended Segment. MXG Oct 7, 2011 code now tests SMF14XSG first to validate existence. Thanks to Herbert Sweeney, Verizon Data Services, USA. Change 29.225 INVALID THIRD ARGUMENT OF SUBSTR message and hex dump of VMACDB2 the record was caused by DB2 V10 record with INVALID QMDA Oct 7, 2011 segment for QMDAPTYP='JCC' - invalid because it does not match the DSNDQMDA DSECT in the DB2 Macro Library. Now, the first three records are detected and MXGWARN messages are printed on the log, while a PMR will be opened. Thanks to Kim Morrell, RCMP, CANADA.
VMXGGETM written, and is enhanced with new arguments SYSTEM=, Oct 3, 2011 BEGTIME=, and ENDTIME=, to select SMF records by SYSTEM Oct 24, 2011 and/or ranges of SMFTIME values. This could alternately be done with the powerful but obscure %LET MACFILE= logic (the "instream" equivalent of IMACFILE EDIT tailoring). -LOOKFOR=text, added: selects SMF records with that text. Thanks to Chuck Hopf, Independent Consultant, USA. Change 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420 TRF) VMACITRF TRFOUT record adds five new variables (COMPATIBLY) that Oct 2, 2011 are output in MXG dataset ITRFMSG. MI ='SPA*INDICATOR*PSTMI' MSRC ='MESSAGE*SOURCE*FLAG*PSTFLAG1' SCHF1 ='QUICK*SCHEDULED*PSTSCHF1' SPAL ='CURRENT*SPA*SIZE' VSFLG ='PRIMED*MSG*INDICATOR*PSTVSFLG' Change 29.222 New tokenid values are now decoded in TYPE80A: VMAC80A TOKMEMLI='MEMLIMIT' Oct 2, 2011 TOKSHMEM='SHMEMMAX' These "NO" value tokens have no data values so they are output in TYPE80TK with their TOKDANAM to record that the option was in effect, suppressing a NOT DECODED message: NOCPUTIMEMAX NOFILEPROCMAX NOPROCUSERMAX NOTHREADSMAX NOMMAPAREAMAX NOASSIZEMAX Thanks to Angelito Lontoc, Northern Territory Government, AUSTRALIA.
FORMATS identified as new were overlooked, but are now added: VMAC110 D2GPSIGN='PARTIAL*SIGNONS' Oct 3, 2011 D2GCTHCR='COMD*THREAD*CREATES' Oct 16, 2011 D2GPTHCR='POOL*THREAD*CREATES' D2GREHIT='REUSELIMIT*HIT*COUNT' -Statistics Dataset CICSMDSA variable SMSDSAIN indexes the type of DSA, but values of '00'x have been found for RDSA EUDSA, and ERDSA, so the SMSDSANM (DSA Name) is used to set their value in SMSDSAIN to '04'x, '86'x, and '08'x when '00'x is found, and the FORMAT $MGCICDS (which maps SMFDSAIN to the name of the DSA) is updated with values '09'x (ECDSA), '8D'x (GCDSA) and '7F'x (ESDSA) that were undocumented in the CICS Data Areas. Variable SMSDSAIN existed before variable SMSDSANM, the actual DSA Name, so with these undocumented and '00'x values in SMSDSAIN, the variable SMSDSANM should be used instead of SMSDSAIN to identify which DSA name is being reported in CICSMDSA. -The CICSMDSA variables for "ABOVE THE BAR" storage were wrong; they are in (undocumented, but now obvious) units of 1 GB, so they are now converted to bytes and formatted with MGBYTES to print the correct storage values: NOTE: ABOVE WRONG, THEY ARE IN MB NOT GB. CHANGE 30.094. These variables are DSA-specific and corrected: SMSDSASZ SMSHWMDS SMSCSIZE SMSFSTG SMSHWMFS SMSLWMFS SMSLFA
These variables are in the header of the CICSMDSA record and thus repeated in each observation for the interval, but are also corrected: SMSGDCUL SMSGDHWL SMSGDCUR SMSGDHWM Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
VMAC7072 -VMAC7072. IBM now stores 'FF' character ('C6C6'x !) for VMAC71 the CPUID (SMF70CID) for engines that don't exist in the Mar 24, 2011 CPU Data Section, which MXG saw as 50886 decimal, which VMAC23 caused ARRAY SUBSCRIPT OUT OF RANGE error. MXG logic Apr 2, 2011 relocated the initialization of the two arrays that used VMAC113 CPUID as the subscript, and created a DO group to only VMAC6 process the CPU Data Sections with valid CPUID number. VMAC42 -VMAC71. TEST for OFFSWAP GE 0 AND NRSWAP GE 0 caused VMAC64 INPUT STATEMENT EXCEEDED. That test should have been GT Sep 30, 2011 for a long time (since SWAP datasets went away!!). Accidentally didn't fail with prior z/OS but was wrong. Cosmetic: SWAPAUX calculation was moved back inside the DO group for (now non-existent) SWAP counts so that it doesn't cause a Missing Values message. -VMAC23. Two new triplets are decoded, for the new Spin Lock and Bind Breakdown Instrumentation sections, but both are currently "For Internal Use Only". -VMAC6. The Reserved 16-bytes in SMF6INDC=7 Extended Mode segment contains SMF6IPV6, currently just input and not kept nor decoded. SMF6URIL, added by OS25152 is not in the Pre-GA SMF Manual. -VMAC42. New variables added to several datasets: SMF42GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS' SMF42GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS' SMFA2GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS' SMFA2GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS' SMF42JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK' SMF42JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS' SMFA2JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK' SMFA2JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS' These fields were added by APAR OA30300. -VMAC64. New variable added to TYPE64: SMF64RLM='CA-S*RECLAIMED*IN ESDS*SINCE CLOSE/EOV' -VMAC7072. New ID=72 Subtype 5 adds 13 new datasets: dddddd Dataset Description TY725A TYPE725A RMF III SERIALIZATION DELAY TY725B TYPE725B RMF III CMS LOCK DELAY TY725C TYPE725C RMF III CMS ENQUEUE DEQUE LOCK DELAY TY725D TYPE725D RMF III CMS LATCH LOCK DELAY TY725E TYPE725E RMF III CMS SMF LOCK DELAY TY725F TYPE725F RMF III LOCAL LOCK DELAY TY725G TYPE725G RMF III CML LOCK OWNER DELAY TY725H TYPE725H RMF III CML LOCK REQUESTOR DELAY TY725I TYPE725I RMF III GRS LATCH SET CREATOR DELAY TY725J TYPE725J RMF III GRS LATCH REQUESTOR DELAY TY725K TYPE725K RMF III GRS ENQUEUE STEP DELAY TY725L TYPE725L RMF III GRS ENQUEUE SYSTEM DELAY TY725M TYPE725M RMF III GRS ENQUEUE SYSTEMS DELAY -VMAC7072. New variables added to TYPE70XT dataset: R7023CRT='EXEC TIME*ALL OPS*4096-BIT*CRT-FMT' R7023CRC='NUMBER OF*ALL OPS*4096-BIT*CRT-FMT' -VMAC71. New variable added to TYPE71: SMF71LFA='LARGE*FRAME*AREA*SIZE' All Logical Swap and ESTORE variables are now reserved. -VMAC113. New variables added to TYPE113 SM1132MM='MACHINE*MODEL' SM1132MT='MACHINE*TYPE' Change 29.219 Support for Tivoli Workload Scheduler For z/OS Ver 8.3 is FORMATS completely incompatible with numerous changes to many of IMACOPC the tracklog file's records. VMACOPC -The _OPCVER macro is no longer used, since this update Sep 24, 2011 supports the current version. However, it may have to Sep 27, 2011 be reinstated in the future since IBM still does not Nov 14, 2011 provide the version number in each record. -There are numerous instances in different MT0TYPE records that end with a 4-byte field of hex zeros where the next MTDTYPE/MTDOPER pair were expected. Probably APAR-able, but it was more expeditious to detect and delete them in MXG than to take the time to document them for a PMR. -Invalid TRL 29 record caused INVALID ARGUMENT messages; the internal %DT macro now tests the incoming arguments and if the date or time is missing, RETURNs, preventing those cosmetic messages. With or without those messages the date values returned were and are missing values. -Nov 14:
This is not a used record type so the error will not be pursued until a customer who actually needs this record type raises the issue. -There are one new MTD segment, MTDTYPE=16 that is not not documented in SC32-1261-03. -MTD17 segment is decoded. Thanks to Louis Deledalle, BNP Paribas, FRANCE
BUILD005 the number of physical SMF 30 records created for this BUIL3005 step (which were all consolidated into this observation). Sep 22, 2011 Change 29.217 Corrected and improved support for the RCDSD section in ASMRMFV RMF III RCD data is provided. VMACRMFV -ASMRMFV now correctly calculates the length of the RCDSD Sep 20, 2011 array that before could cause a SAS INPUT LENGTH ERROR in Sep 27, 2011 VMACRMFV processing. Nov 2, 2011 -ASMRMFV now correctly handles an RCDSD when a Class with Nov 20, 2011 zero periods is detected. An RCDSD cannot exist in this EXZRBRCP case because the RCDSD pointer is part of the period data NOV 13, 2013 -VMACRMFV formats for the variables RCDRGCAP and RCDRCGD were reversed. -New variables RCDBPMI and RCDSDPH are added to the ZRBRCDD file by VMACRMFV. -VMACRMFV now reads both the Begin-To-End and Execution Phase data for each RCDSD entry. Current documentation for RMF III did not clarify that each RCDSD entry is actually a pair of arrays for these two Phases. -ASMRMFV when processing a CFI Table with the RMF III CFDETAIL option in effect, did not correctly handle the condition where no connections exist for a CF Structure. This resulted in a corrupted CFI Table record and an SAS INVALID DATA message during VMACRMFV processing. -When the number of records output for a RMF III table exceeded 16,277,215 the output record counter in ASMRMFV would wrap to zero resulting in a very low incorrect count for that table type. The total record count output by ASMRMFV would then not match the input record count from VMACRMFV. -VMACRMFV did not count the 4 byte RDW (Record Descriptor Word) in its report of bytes read but ASMRMFV did. Now, the RDW length is added so that the VMACRMFV byte count matches the ASMRMFV byte count. However, as neither ASMRMFV nor VMACRMFV knows how many blocks were written, both byte counts will not include the 4-byte BDWs (Block Descriptor Word) for each block. -The RMF Monitor III version id variable names are now more consistent with the naming pattern of xxxVERG3. RCDVERS is now RCDVERG3 (RCD version id). OPDVER is now OPDVERG3 (OPD version id). SPGVER is now SPGVERG3 (SPG version id). -A new variable SVPRTC (Response Time Unit Code) is added to files with Service Policy data. It is the decoded value of SVPRTU. This indicates the response time units for a goal. Values are I=Milliseconds, S=seconds M for Minutes, H for Hours, and ? for Unknown. -Added SPACE/NOSPACE parameter option: -SPACE displays two new messages RMFV030I and RMFV031I for each RMF Monitor III VSAM data set processed. -Message RMFV030I shows HARBA (High Allocated Relative Byte Address), HURBA (High Used Relative Byte Address), and AVAIL (Available Free Space in Bytes). -Message RMFV031I shows percent of Allocated Space Used and percent of Allocated Space Available (Free). -Both standard & extended format (EF) VSAM data sets are supported, but RMFV030I message format varies slightly to accommodate the much larger data sets possible in EF mode.
-Assembler symbolic variable &SPACE can be changed by users prior to assembly from the distributed default of 'Y' (SPACE in effect) to 'N' (NOSPACE in effect). -In conjunction with the existing INDEXES parameter SPACE is intended to assist MXG users in properly sizing their RMF Monitor III data sets. -Program prologue comments documentation was updated. -Nov 20, 2011: Change 29.204 (29.05) changed these version variables PGPVERG3 CPDVERG3 CPUVERG3 CSRVERG3 CFIVERG3 ENCG3VER OPDVERG3 SPGVERG3 CPUVERNU SVPDVN SVPRTU from NUM to CHAR, which would create errors combining PDBs built with different MXG Versions, so they are now changed back to their original numeric nature. This code change was NOT in MXG 29.07 dated Nov 14. -Nov 13, 2013: Exit member EXZRBRCP is no longer called as ZRBRCP dataset is no longer output, because ZRBRCS and ZRBRCR now include ZRBRCP variables. Thanks to Neil Ervin, Wells Fargo Bank, USA. Thanks to Dan Case, Mayo Clinic, USA. Change 29.216 Cosmetic. The comment in JCLIMSL6 that two %LETs are JCLIMSL6 needed to set MACKEEP with _IMSVERS was wrong, as it is TYPEIMSB only in the STEP04 step that the _IMSVERS must be set. Sep 19, 2011 In TYPEIMSB, the %INCLUDE of VMACIMS and IMACKEEP and the comment "to get _IMSVERS" was removed because that program has no dependency on any of the IMS macros. Thanks to Trevor Ede, HP, NEW ZEALAND.
VMAC119 from GMT to LOCAL, but now are. Sep 19, 2011 Thanks to Robert Stoffregen, Great Lakes Higher Education Corp., USA. Change 29.214 Almost cosmetic. In subtype 2 (TYPE78PA dataset) eight VMAC78 variables ending with TOTL were mislabeled as samples but Sep 19, 2011 they are the total memory for all samples, so they are now correctly labeled and added to MGBYTES format to show they contain memory values. Variables LGMOMIN/TOFRMIN are RB8 floating point fields, but they can contain hex value 7FFFFFFFFFFFFFFFx (presumably on systems that don't have large memory frames), so they are now set missing (rather than decimal values 7.237E75!). Some datetimestamps are no populated (hex zeros for TODSTAMP8), so they are set to a missing value (automatically, by SAS). Thanks to Tony P. Steward, CSC, ENGLAND. Change 29.213 Support for DB2 V10 IFCID 225 (Subtype=4) INCOMPATIBLE. CLEARDB2 The IFCID 225 record contains important storage metrics, EXDB2225 and is written each statistics interval. In DB2 V8, it READDB2 was a trace record (ID=102,IFCID=225), creating T102S225 VMACDB2 dataset. In V9, it became a statistics interval record VMXGINIT (ID=100,SUBTYPE=4) creating DB2STAT4 dataset, but with Sep 20, 2011 the same suite of 8-byte field/MXG-variable names, and Sep 23, 2011 because it was then recognized as useful, those QW0225xx variables were added transparently into PDB.DB2STATS from either DB2 V8 T102S225 or DB2 V9 DB2STAT4 datasets. But now, DB2 V10 completely and incompatibly restructured (but also significantly enhanced the storage metrics) in the IFCID=225 record, still writing it as SUBTYPE=4, with some fields preserved, but with many new fields with long names, that I now use for MXG variable names, rather than struggling to create unique two-character suffixes and 8-byte names (but two new prefixes are needed for the new separate storage used by DBM1 & DIST address spaces, so those sets of variable's names are QWA225xx/QAB225xx. -For DB2 V10, IFCID=225 records are output in PDB.DB2ST225 dataset, and all variables in DB2ST225 are automagically merged into PDB.DB2STATS dataset with all these programs: TYPEDB2/TYPSDB2/BUILDPDB/READDB2(IFCIDS=STATISTICS). -With DB2 V10, the PDB.DB2STAT4 dataset will have zero observations from DB2 V10 data, since it is populated only from DB2 V9 IFCID=225 records. -Test data from the same DB2 Subsystem (QWHSSSID), when the release changed from V8 to V10, had negative CPUTM in that statistics interval, because there is no field in a DB2 Header that clearly identifies when a DB2 subsystem is started (i.e., unlike CICS records, that have the JOB and READTIME). Normally, a restart resets QWHSISEQ to a smaller value, but in this case, that sequence number was larger in the V10 record than the prior V8 record! So, MXG now tests both QWHSISEQ and SEQCHECK to circumvented the IBM omission. That SEQCHECK test in the "bad" data interval did identify the problem, so the previous test of SEQCHECK GT 0 was enhanced to 0 LT SEQCHECK LE 5 to confirm the inteval is valid with no restart. Thanks to Betty Wong, Bank of America, UDS. Change 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records. VMAC84 After long discussions with JES3 SMF 84 Support Folks, I Sep 16, 2011 understand how JMF creates multiple, segmented records Oct 11, 2011 when there are more entries (FCTs) that will fit in one SMF record. I can probably circumvent the absence of the JMF PROD section (source of start/end times!) that is NOT written in the 2nd and subsequent segments, but ONLY if I add post-processing steps to sort and to populate those missing values, and ONLY if there are no missing segments in the SMF file. -BUT, there is NO WAY that I can directly process each of these segmented records, because sections (FCT ENTRY) are truncated and split (a/k/a "spanned" in JES3 circles) and written in two separate physical SMF records, but there are no length fields to identify how many bytes were in which record. -Processing these JMF segmented records will require a new Yüklə 28,67 Mb. Dostları ilə paylaş:
|