* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
contain no independent information without the prior time interval. VM/XA should have looked at RMF design! 3.Since no startup records can be guaranteed, the MXG logic that attempted to capture VMDTTIME,VMDVTIME and VMDCTIME in the first interval has been eliminated. Until IBM adds a flag in the USER data record itself, it is impossible to unambiguously and safely capture these CPU times from USER logon to the first interval. The remainder of the MXG algorithm to detect subsequent logon events (done by setting variable LOGON) has not been altered. 4.VM/XA SP Release 2.1 did not alter the contents of any data records, but several VM/XA APARs have changed many MXG data sets by creating additional variables. As is always the case, member DOCVER07 in the MXG SOURCLIB library provides the delta-documentation of the datasets and variables added. These support of these IBM changes required these sources of documentation:
Appendix B, Monitor Records, which is now the basic source of documentation of VM/XA records. II. VM/XA System Product Release 2.1 Program Directory for VMSUP Level: 8905 for VM36583 and VM37852. III. INFO/SYS Entry E343842 for VM35968. IV. INFO/SYS Entry E337409 for VM35962. V. INFO/SYS Entry E336950 for VM35321. a. Variable VMDCPUAD has been added to three MXG datasets for schedule domain, VXSCLADL,VXSCLDDL and VXSCLAEL by VM35321 (supported in MXG 7.0 and later).
available in the VXIODATD, VXIODVON, and VXMTRDEV MXG data sets, and RDEVOFFL in VXMTRDEV identifys if the device was OFFLINE/ONLINE at Monitor START by VM35962. c. VM35968 adds information on I/O activity (variables RDEVSKCT,RDEVSKSM,RDEVWRCT,RDEVRDCT containing Seek counts and cylinders ('passed over while the arm is passing over uninteresting data', according to Siebo), and separate counts of Read or Write channel programs to VXIODDEV at the device level. Variables IORDWRIT, IORPOSCT,IORPOSSM, CALECYL,CALUSER,and RDEVDEV were added to the VXSEKSEK seek trace record that IBM had previously reported as in error and unusable. This is thought to mean that seek data is now usable. d. VM36583 and VM37852 add 27 new fields to the interval VXSYTXSG dataset extending ESTORE (or XSTORE if you must, even though MVS' used ESTORE long before VM was able to use "XSTORE") efficiency measurements. Thanks to Phil Strange, BP International, ENGLAND. Thanks to Martyn Stevens, Barclays Bank London, ENGLAND. Thanks to Rob Owens, SAS Institute Europe, GERMANY.
VMACVMON it was not in the RETAIN statement. Now it is. Jan 15, 1990 Thanks to Rob Owens, SAS Institute Europe, GERMANY. Change 07.217 TYPE76 RMF Trace variables INTRVAVG and AVG were slightly VMAC76 wrong if the last sample set did not have complete sample Jan 15, 1990 count. The calculations were corrected to use NSAMPLE for NRSETS*SAMP_SET for INTRVAVG, and SAMP_LST instead of SAMP_SET for AVG if _I_=NRSETS (i.e., for last set). Thanks to Steve Cavill, SAS Institute, AUSTRALIA. Change 07.216 TYPE60 VVR variables are now labeled. VMAC60
Jan 12, 1990 Change 07.215 TYPE6156 ICF Catalog Activity records have been enhanced FORMATS to extract volume serial numbers from the catalog section VMAC6156 at the end of the record, if a volume segment exists. Up Jan 12, 1990 to five volumes (VOLSER1-VOLSER5) will be contained in each observation and multiple observations (sequenced in variable MULT6156) are created if the entry has more than five volumes. Catalog records consist of a sequence of catalog cell records, identified by a hex "cell type". Not all TYPE6156 records contain a 04 Volume record; to examine the structure of the catalog segments, variable CATCELLS contains the first 16 cell types encountered.
C2 01 05 GDG Base subrecord C2 01 05 C8 01 03 04 GDS subrecord C3 01 02 03 06 Cluster component C4 01 02 04 Data component C7 01 03 AIX component C7 01 C4 01 04 C9 01 04 AIX subrecord C9 01 02 04 Index component D8 23 Secondary VVR D9 01 02 03 Path record E3 03 Truename record E4 01 03 04 User catalog connector E7 03 Alias E9 21 60 23 Primary VVR Multiple occurrences of 02 03 can occur. Multiple 04 (volume) occur for multi-volume entries. There are cases with no 04 volume cell in the record. Variable ACTION shows DEFINE action for non-VSAM files files with no 04 cell, and have found SCRATCH action for GDS G0002V00 but there was no C8 entry for that gen! (The catalog record for a GDS consists of the base GDG entry followed by a C8 01 03 04 for each generation; MXG parses the GooVoo in the entry name and finds its C8 entry in the catalog record to extract the VOLSER(s) of that generation). We have also found catalog records containing only the E3 03 (Truename) entry, and a GDS with only the base GDG C2 01 05 entry.
ENTTYPID entry type id field, although we still have found three data values that IBM level 2 could not explain (although they did offer to build a slip trap we were unwilling to install!). Thus far, we have found:
B - GDG Base P - Pagespace C - Cluster R - Path D - Data S - undocumented F - Free T - Truename G - Alternate Index U - User Catalog H - GDG V - Volume I - Index X - Alias Name K - VSAM VVR Y - Upgrade M - Master Catalog 00 - undocumented Perhaps ENTTYPID will assist in explaining why an ICF entry was changed, but does not have a volume record. For VSAM entries, the catalog record typically contains 04 volume records for the cluster, the index component and the data component. In this implementation of MXG, ALL volume records are extracted and stored in VOLSERn variables, in the sequence found in the catalog record. Thanks to Connie Lee, Morgan Stanley, USA. Change 07.214 Sample RMF Monitor III report programs variable DYDELAY ZRBRPT1 should have been spelled DVDELAY. ZRBRPT2 Jan 9, 1990 Thanks to Brian Redmond, Home Savings, USA. Change 07.213 Support for Candle's Network Accounting Facility (NAF) EXNAFENT SMF records (written by Candle Products CL/SUPERSESSION, EXNAFGLI CL/GATEWAY, and VTAMPLUS) have been added by this user EXNAFGOF contribution. Data sets NAFSTART, NAFSHUTD, NAFENTVA, EXNAFGON NAFLOGON, NAFLOGOF, NAFVOGON, NAFVOGOF, NAFGOGON, EXNAFGPA NAFGOGOF, NAFGPASS, NAFGLIMT, NAFGPSTR, NAFGPSTO EXNAFGPO are created from subtypes of these network records. EXNAFGPR This support includes NAF thru Version 145 of Candle's EXNAFLOF CL product line. EXNAFLON
EXNAFSHU EXNAFSTA
EXNAFVOF EXNAFVON
IMACNAF TYPENAF
VMACNAF Jan 9, 1990 Thanks to Gene Quinn, Blue Cross of Rhode Island, USA.
VMACTSOM version adds a number of resource fields (swaps, paging, Jan 8, 1990 service units, I/O connect time) to the TSOMSYST and TSOMCALL datasets. MXG 7.6 or later is required for TSO/MON Version 5.2 if TSO/MON options ACCOUNTING=YES or DSNAMES=nnn were specified (because TSO/MON inserted data before the accounting/dsname sections, and because MXG did not use the offsets to those sections until MXG 7.6+). Thanks to Ken Dove, Legent, USA. Change 07.211 Duplicate records were not deleted by the NODUP option BUILDPDB in the PROC SORT of DATA=TYPE70PR because the BY list BUILDPD3 was insufficient to guarantee that duplicate observations Jan 5, 1990 ended up physically adjacent. The variable LCPUADDR had to be added to the end of the BY list in BUILDPDB/3. Thanks to Earl Ryan, Life Insurance Company of Georgia, USA. Change 07.210 The OUTPUT statements in _ANALMON deaccumulation macro TYPEMONI are now includes of EXMONSYS, and the first definition Jan 5, 1990 (unused) of _ANALMON deaccumulaton macro was removed. Thanks to Glenn Thompson, Comalco, AUSTRALIA. Change 07.209 -Further ANALDB2R report validation fixed Accounting ANALDB2R trace long (max page locks) and total lock suspends, GRAFTMNT corrected ABEND in IOS report if PDB did not contain ASUMVMON IOS trace data, and eliminated uninitialized variable GRAFVMON message if nondefault sort parameters are used. Jan 5, 1990 -GRAFTMNT did not properly handle tape mount reporting if multiple systems were used, now it does. -ASUMVMON spelled PFAULT incorrectly as PFAULTT. -GRAFVMON had trailing ./ IEBUPDTE command. Thanks to Bob Olah, Dun and Bradstreet, USA. Change 07.208 Support for Landmark's TMON/MVS product ("TMV or TMVS"). EXTMVEL Twelve data sets: TMVSEL,TMVSIC,TMVSIOL,TMVSIOD,TMVSIV, EXTMVIC TMVSJI,TMVSJIST,TMVSNQ,TMVSPS,TMVSSYS,TMVSYSSW,TMVSYSUI EXTMVIOL are currently created, though there may be more later. EXTMVIOD Landmark cooperated extensively in the development and EXTMVIV testing/validation of this support. Most variable names EXTMVJI are Landmark field names, except for "standard" MXG names EXTMVJIS like STARTIME,ENDTIME,DURATM,SYSTEM, etc. EXTMVNQ Release 1.12 of TMON/MVS must be installed (as record EXTMVPS formats have been changed from earlier releases). EXTMVSYS Unfortunately TMON/MVS does not create SMF records, which EXTMVSW will necessitate a separate jobstream to read their data EXTMVUI from the MXG-required DDNAME of TMVSIN. FORMATS The TMON/MVS monitor data can be created in compressed TYPETMVS format (as is Landmark's Monitor for CICS data), and VMACTMVS the MXG-provided "SAS Infile Exit" named TMON (created Jan 5, 1990 by member EXITMONI as described therein and in the CICS chapter in the MXG Supplement) can be used to allow MXG to directly decode their compressed format data. After the "TMON" exit has been installed by EXITMONI change "INFILE TMVSIN" to "INFILE TMVSIN TMON" to invoke that exit which will handle either un-compressed or the compressed data automatically. Thanks to George Greenacre, Landmark Systems, USA. Note added Oct 24, 1990. Landmark renamed Release 1.12 to Release 1.1 (went from 1.11 to 1.1!). ===========Changes thru Change 7.207 comprised Prerelease 7.5========== Change 07.207 IBM added nine new fields to the type 64 SMF record for VMAC64 VSAM activity. Added to support IBM's marketing aid for Dec 22, 1989 Hiperbatch analysis, these new fields (ACBSTRNO,BUFDRNO, ACBBUFSP,ACBBUFND,ACBBUFNI,JFCBDSN,PLHCNT,ACBMACR1-3) may prove useful in normal VSAM analysis, as the data now indicates concurrent strings, buffer counts, and read/write sequential/indexed flags as well. PTF UY40839 (APAR OY23661) added the data to the type 64 record, but failed to update the IDAEXTWA macro to document the order of the new fields! APAR OY26396 contains the actual DSECT of the new fields. Thanks to Lawrence Jermyn, Fidelity Systems, USA. Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
VMAC37 off by a few bytes, and some fields were not formatted to Dec 22, 1989 display in hex. The quick fix is to change BRFLSL from $1. to $2. and insert +3 after BRFADDR to align MXG with the apparently undocumented changes in this record! Thanks to Bruce Widlund, Texas Utilities, USA. Change 07.205 DB2 2.1 writes an SMF type 100 record with SUBTYPE='80'x VMACDB2 instead of the expected value of 0 or 1. When or why is Dec 21, 1989 not known at this moment, but it appears the field that was originally documented as subtype is now a reserved field. This change uses the product section IFCID value to set SUBTYPE when the expected subtype value of 0 or 1 was not originally found. I'm still pursuing this one.
@;
IF ID=100 AND SUBTYPE NE 0 AND SUBTYPE NE 1 THEN DO; INPUT @25+OFFSMF OFFPROD PIB4. @; LOC=OFFPROD-3+OFFSMF+4; INPUT @LOC QWHSSIID PIB2. @; IF QWHSSIID=1 THEN SUBTYPE=0; IF QWHSSIID=2 THEN SUBTYPE=1; END; Thanks to Elliot Weitzman, Oryx Energy Company, USA. Change 07.204 This is a "protective" change to protect you from your VMAC6 own system programmers. A JES2 system programmer at one VMAC26 site made incompatible changes to their type 6 and 26 Dec 20, 1989 SMF records when the site added support for 99,999 JES numbers! This change eliminates the "NOTE: INVALID DATA FOR JESNR IN LINE nnn bytes bb-ee. linenr : col " if these incompatible records are processed by MXG. What did the system programmer do? The 4-byte EBCDIC field JESNR (which could contain only 0001-9999 in its original EBCDIC format) was changed to a 4-byte packed decimal (SAS PD4.) format! Programs expecting a 4-byte EBCDIC format raised a data exception when they found illegal EBCDIC numeric values in what was now a valid packed decimal field. What did IBM do? As described in the SMF manual, IBM stores EBCDIC value 0000 (which was never a valid job number), and tells you instead to skip 3 bytes and read the 5-byte EBCDIC job number from the previously-existing JCTJOBID field. What did MXG do? The TYPE6 data set was okay, but the above "NOTE:" was printed; MXG captured the 5-digit field correctly even with their modfication. However, the TYPE26J2 dataset had blank value for JESNR, and this caused BUILDPDB to put all these jobs into SPIN rather than the PDB. The simple fixes to MXG were: a) in both VMAC6 and VMAC26J2 change JESNR 4. to JESNR ?? 4. - this suppresses the NOTE: and the Error condition when invalid data found, and b) in both VMAC6 and VMAC26 change IF JESNR NE 0 to IF JESNR GT 0 and c) insert new line in VMAC6 after the line IF JESNR GT 0 THEN INPUT .. JESNR ?? 4. @; reading: IF JESNR EQ . THEN INPUT @65+OFFSMF JESNR ?? PD4. @; The site had made its own mods to JES mods before IBM! Now MXG is robust enough to support this mod. Thanks to Robert Manalo, EDS, USA.
XMAC74 used to circumvent a SAS limitation in large shops), Dec 20, 1989 causing AVGPNCHA, AVGPNCUB and AVGPNDEV to be seconds instead of milliseconds. Applied the changed. Thanks to Bruce Widlund, Texas Utilities, USA.
VMAC6 the SYSOUT release time (Change 7.137, added in MXG 7.1) Dec 19, 1989 did not handle JES3 print record variables DATAERR, OUTPRTY, SUPGROUP correctly, and could cause STOPOVER. The INPUT statement after SUBSYS='JES3' OR SUBSYS='SAR' should not have the offsets (OFFTONXT, OFFTONXT+nn). Remove the offset from before variables DATAERR, OUTPRTY SUPGROUP, SMF6RVSJ, and SMF6RSVU. Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.
IMACPDB identify the Subsystem (JES2,JES3,EXTW,PSF,SAR,EXD,CADI) VMAC6 which created the print record. While SUBSYS already is Dec 19, 1989 in TYPE6, BUILDPDB already uses SUBSYS from the TYPE30_4 (probably not a wise choice now!) Rather than changing a meaning of an existing variable, adding SUBSYS6 here and in IMACPDB (to the _PDB6 macro list of kept variables) avoids a compatibility exposure. Why do you need SUBSYS? Some sites want to recover CPU time spent by printing subsystems (read PSF) by surcharging that subsystem's PRINT charges. Unfortunately, additional CPU time caused by PSF has been shown to occur primarily when a non-PSF data stream is converted, and it is not possible to know if data-stream-conversion occurred from a type 6 record. record. (Call XEROX at 213-333-2068 for a free copy of publication number 720P60340 "Benchmark Report JES2 vs PSF in Text Oriented Printing" by Tom Bell and Chuck Hopf. IBM should capture the CPU time for print events and store it in the type 6, or at least a flag bit should be set if PSF did convert the data stream. One comparison shows if PSF takes 7 CPU seconds for Line Mode JES2 Dump convert and print, a JES2 controlled 3800 Model 3 in Mod 1 emulation mode would take 1 sec. But conversion cost may be only half the cost. A DCF prepared PSF data stream of same size took 3 seconds. Sustained print rates of 200 pages per minute are seen feasible for 3800 Model 3. The type 6 record does record PAGEDEFS FORMDEFS FONT.... activity for PSF; nonzero counts here does guarantee only that those PSF functions were invoked.
VMACNSPY sets, and is now supported. Dec 15, 1989 Thanks to David W. Anderson, Chase Lincoln First Bank, USA. Change 07.199 TPX Version 2 causes STOPOVER because the length of the VMACTPX subtype 5 is incorrect. Their fix number TGB308A fixes Dec 12, 1989 their problem. MXG failed to recognize the redefinition of TPXM1SP0 over its two preceding fields (TPXPESIZ & TPXPECD8) in a subtype 1 record, also causing STOPOVER. This is corrected by inserting a new statement M4=-4; after the @; after TPXMSMRT $CHAR8. and before the IF, and then putting +M4 just before (TPXM1SP0-TPXM1SP9 Thanks to Larry Doub, RJR, USA.
VMACPDSM (incompatibly, in the middle of the existing data!) which Dec 12, 1989 are now supported by this change. LGJOB, LGMGEN, LGLMM, LGNMM and LGRMGEN were added. Thanks to Lesley Woolston, Manufacturers Hanover, ENGLAND.
EXTY42AU 1.TYPE6 data now identifies the Step which caused the print EXTY42CU activity, and added security related information in these EXTY42SC new PRINT variables: EXTY42TO BIN1USED BIN2USED BIN3USED BIN4USED DIASLIG DIADPLWS EXTY42VL DIAJHWP DIAUPAWS DPAGELBL ERROVRUN ERRSECOV INTEGRTY EXTY83 PRSUCCES SMF6NSOL SMF6NSFO SMF6NPS SMF6FDNM SMF6PDNM IMACPDB SMF6PTDV SMF6STNM SMF6PRNM SMF6DDNM SMF6USID SMF6SECS TYPE42 SPAGELBL STDUPLEX SYSAREA TMBUPLEX TYPE83 The variables SMF6STNM (stepname), SMF6PRNM (procstep) VMAC6 and SMF6DDNM (ddname of print file) have been added VMAC1415 to the default list of TYPE6 variables that will be VMAC42 automatically carried into PDB.PRINT in MXG's BUILDPDB. VMAC80 2.TYPE1415 data variables PDSE, TRUNC, and NULLSEG added, VMAC83 and several fields documented as zero if PDSE-managed VMAC90 (BLKCNT, TTRN, UCBSTAB, DSSEQCNT, DSSEQNR). The EXCPCNT Dec 11, 1989 variable for PDSE-managed datasets counts pages read or written. Before MVS 3.1.1, PDSE was referred to ILIB. 3.TYPE80 additional bit added to $MG080AU for BYPASS, new character variable RACFVRMN (version, release, mod level) replaces numeric RACFVERS, and new RACFTOSK (security label) added by RACF 1.9.0. 4.New type 42 SMF DFP 3.2 record provides SMS statistics configuration, and audits changes in five data sets built from this record. Interval buffer statistics for 3990 cache controlers (total and by storage class) are in TYPE42TO and TYPE42SC. Control Unit configuration and delta statistics are in TYPE42CU (and SMS managed volumes behind that control unit are in TYPE42VL). TYPE42AU audits operator VARY SMS commands, ACTIVATEs in ISMF or SETSMS, or ENF occurred because operator issued a vary command to an SMS-managed volume. This is a new, and significant source of information for management of System Managed Storage, as well as 3990 statistics. 4.New type 83 SMF RACF Audit Record (For RACF Datasets whose security label was changed by ADDSD, ALTDSD, or DELDSD) is now supported in MXG dataset TYPE83. 5.Two new SMF options were introduced in MVS/ESA 3.1.3 that allow the installation to never loose SMF data. LASTDS and NOBUFFS can specify MSG (console message and continue processing with loss of SMF data) or HALT (puts MVS in a restartable wait state) whenever either no buffers or no SMF data set is available to SMF. These options are now contained in MXG TYPE90 dataset. Change 07.196 DB2 2.2.0 changed SMF 102 SMF values in 21,30,31,44,62, FORMATS and 140 IFCIDs, affecting formats $MGD044D, $MGD062S, IMAC102 $MGD062O, $MGD140P, and creating $MGD063O. IFCID'S 63 and VMAC102 106 were changed incompatibly, although only 106 has new Dec 9, 1989 variables. The new Distributed Header is decoded, and now all header variables are output in T102S106. Twelve new IFCIDs (with many new variables) were added by DB2 2.2.0, and these IFCIDS (plus the seven DB2 2.1 IFCIDS that had not been previously decoded) are now supported by MXG. With this change, ALL data produced by DB2 is now thought to be supported by MXG. (There may be additional formats added to MXG for a few of these new variables). The list of IFCIDs within class has been updated in IMAC102. There are also eight new "trace class" macro definitions that are necessary in MXG (but only until SAS Version 6.06 is universally available; the MXG use of the _DB2TCn macros is necessary only because of an internal SAS limit on the number of iterative DO statements, which has effectively been eliminated in SAS Version 6.06). A later change will be made to ANALDB2R to provide reports on these new DB2 DB2 elements. Initially, though, the changes primarily support Distributed Data Facility, and the addition of the Monitor Class data records (which contain the same data already available in the DB2ACCT & DB2STAT datasets from the 100/102 records!). For the record, these new IFCIDs were added by this change: TC1 (153), TC6 (156), TC7 (164,165,166,167), TC8 (125,168), new TC14 (67), new TC15 (154), new TC16 (157,158,159,160,161,162,163), new Monitor Class MC1 (124,147,148,149,150), new MC4 (155), new AC7 (169), Yüklə 28,67 Mb. Dostları ilə paylaş:
|