* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Thanks to Chuck Hopf, MBNA, USA. Change 17.120 For Goal Mode (a/k/a Workload Manager Mode), the PERFGRP VMAC30 variable had value of zero in type 30s but missing in 72 Jun 2, 1999 so it is now set missing in type 30s, so it won't be confused with Compat Mode PERFGRP=0, and so that BY lists can contain PERFGRP SRVCLASS to merge step interval data with either TYPE72 or TYPE72GO data. To know from the job's TYPE30s/PDB.JOBS datasets if a job ran under Goal Mode or under Compat Mode, you can now test IF PERFGRP=. (or alternatively, IF SRVCLASS GT ' ') and both are true for Goal Mode) and both are false if Compat mode. Change 17.119 SyncSort supports up to 32 sort work areas, but MXG had VMACSYNC only decoded the first twelve. Now all thirty-two sets Jun 2, 1999 of the eight variables are created for all possible. Thanks to Chairat Tiajanpan, KTB, THAILAND. Change 17.118 Minor cleanup. The default DDNAME for the CIMSTEMP TYPSCIMS temporary dataset is now //WORK instead of //PDB, and VMXGINIT member TYPSCIMS now invokes _S macros to sort the Jun 1, 1999 CIMSDBDS, CIMSDB2, and CIMSPROG datasets into the default ddname of PDB. Thanks to Carl Meredith, SAS Institute, USA. Change 17.117 Sample RACF Violation reports, originally posted on MXG-L ANAL80A use the TYPE80A and TYPE8002 datasets for reports. May 31, 1999 Thanks to Brian Cavanaugh, Key Services Corporation, USA. Thanks to Sean Sullivan, Key Services Corporation, USA.
VMAC89 support for Concurrent CP Upgrades ("the capability to May 31, 1999 increase the number of usable CPs without requiring a hardware IML or operating system IPL"). New fields are added to the ID section, so they are kept in both usage and state datasets: Type/Model/Manufacturer/Plant/etc, counts of the configured and standby CPUs, and the value of SMF89CPC, the "CPU Capability" value, an integer that specifies the CPU capability of one engine. While there is no formal description of the algorithm used to create the value, CPU Capability Value is used as an indication of the capability of this CPU relative to the capability of other CPU models. Then to adjust that single engine
of CPs in use, you use the Multiprocessing CPU Capability Adjustment Factor for that number of CPs. There are up to fifteen factors, each containing the percentage of the single engine CPU capability for that number of CPs: MXG variable SMF89MA1 contains the percentage for 2CPs, and SMF80MAF contains the percentage if there are 16CPs. The new information comes from the Store System Information Instruction (STSI).
FORMATS did not know that value 'Q', documented as "Pseudo WFI", VMACCIMS but also called Quick Restart, exists also. Now the MXG May 31, 1999 format MGIMFCS decodes both Q and W in FLGSPCHR. Thanks to Ulrich Dillenberger, BMC Software, GERMANY.
VMACTAND Two IF OPSYSVER GE ... should end with "@;", not "END;". May 28, 1999 The ERROR message is INVALID DATA FOR END .... If you pull the data files from the Tandem System using UserAccess - Stream Mode, you get the "unstructured" file format discussed in Change 15.119, and you will have to EDIT and use the UTANDSTR utility to double process the records to create the "structured" records to be read. Change 17.113 Variables SMF6PRMD (Print Mode) and SMF6USID (User) are BUILD005 now carried into the PDB.PRINT dataset in BUILDPDB/PD3 BUIL3005 logic, by adding them to the _PDB6 list of variables to May 28, 1999 be kept from TYPE6 into PDB.PRINT. Thanks to Bob Falla, The Mutual Group, CANADA.
VMAC80A KW24MO00-KW24MO50 WERE FOUND is eliminated by changing May 27, 1999 KW24MO50 to KW24MO18 in the KEEP= list, but there was no impact of this warning, as there were only 18 to keep. Thanks to Jos Schwab, Newell Company, USA.
BUIL3005 observations in TYPE30_V, TYPE30_4 and TYPE30_5 datasets BUILD005 count only the number of tape devices allocated in each EXTY30TD physical step record, and that is still true after this FORMATS change. But this redesign in BUILD005/BUIL3005 will now IMAC30 count the number of unique tape drive addresses that were SPUNJOBS allocated by the step (across all multiple records) in VMAC30 those TAPExxxx variables in the PDB.STEPS dataset. VMXGINIT Note, however, that even the corrected TAPExxxx count for May 27, 1999 the step is not necessarily the number of concurrent tape Jun 7, 1999 drives that were used by the step, but is just the total number of drives allocated by the step: you cannot tell from the step data whether those allocations were sequential or concurrent. In addition to changes in the BUILD005/BUIL3005 members, a new "temporary" dataset WORK.TYPE30TD is created by VMAC30, with one observation for each tape DD segment, that is used to correctly count tape drives. This also required a new SPIN.SPIN30TD dataset to hold these new data for incomplete jobs, and revisions to member SPUNJOBS, as well as logic to convert spun Step records tape drive counts to the new design. And macros _S30 and _N30 were corrected in member VMAC30 so they include TY30UD and TY30UV datasets that had been overlooked. Note 10/19/2000: The TAPEDRVS/TAPExxx variables were removed from the SPINxxxx datasets (because they were the old, probably wrong values), and were relocated into the SPIN30TD dataset (tape allocation count by DEVNR) that will be used tomorrow to put TAPEDRVS/TAPExxxx variables back in the output PDB.STEPS and PDB.JOBS. Change 17.110 Variables EXCPNODD/IOTMNODD are now corrected, and the BUILD005 observations with MULTIDD='Y' in PDB.STEPS dataset will BUIL3005 no longer exist (although they still will exist in the SPUNJOBS TYPE30_4 and TYPE30_5 datasets). Instead of there being May 25, 1999 multiple observations for those steps, there now is only one observation for each step in PDB.STEPS, so the number of observations in PDB.STEPS will be reduced by this fix. This redesign sums the STEP I/O counts from the multiple step records to create only one observation per step, and it re-calculates the NODD "Not Recorded in a DD" values. Previously, the NODD numbers were TOTL - TODD, but when the step had MULTIDD='Y' records, the TODD counts in the "real" step record (the one with MULTIDD=' ') did not include the TODD counts from the MULTIDD='Y' records, so the NODD values in the MULTIDD=' ' observation were too high, and the NODD values in the MULTIDD='Y' observation were missing (because the TOTL values exist only in the MULTIDD=' ' record). The values of the NODD variables in the PDB.JOBS dataset were also incorrect, because they were sums of the incorrect NODD values from PDB.STEPS. This internal redesign splits the STEPS dataset into STEPS and STEPSIO, with all EXCP/IOTM counts in STEPSIO, which is VMXGSUM'd and merged to re-created STEPS with NODD calculations now based on the TODD sum from all records, and so there is no longer any need to create the MULTIDD='Y' observations in the PDB.STEPS dataset. This change was precipitated by the analysis of a step record from TSO-in-batch that executed DB2 that had very large values for EXCPNODD and IOTMNODD. The large NODD counts were completely valid, had nothing to do with any MULTIDD='Y' steps, and in fact were caused a design flaw in the site's DB2 QMF exit that caused repeated loads of the same module from a linklist library, and all linklist accesses are captured by the NODD counts. But before I knew that, I had asked Chuck Hopf to scan his PDB for executions under TSO that called DB2 to see if DB2 might be involved in high NODD counts. While his data proved high NODD counts were not DB2 related, he did serendipitously find MULTIDD='Y' steps with the incorrect NODD counts that led to this redesign. Thanks to Kirk Hampton, Texas Utilities, USA.
VMXGHSM time were detected and corrected. The corrections: May 25, 1999 IF MCPDGNCT=. THEN MCPDGNCT=0 instead of MCTDGNCT, and P2=P2+14; instead of P2=P2+(14C); Thanks to Neville Wright, TELSTRA, AUSTRALIA.
VMAC39 observations output, depending on APARs you have applied, May 21, 1999 because Change 16.258 was incorrect. The ELSE DO; group must be relocated to be before the first "IF OFFPROD-3-COL+1 GE 8 THEN INPUT" statement. And APPN fields may be incorrect, because the INPUT after the second "IF OFFPROD-3..." statement should have offset values of @61, @65, and @67 vice @53/@57/@59. Thanks to Jim Tintle, Mack Trucks, USA.
VMACQAPM as a comparison of the 4.3 and 4.2 record formats found May 21, 1999 no changes.
ASUMTAPE to the fuzzyness of sampled mount times in MXGTMNT are May 20, 1999 now STATUS='MATCHED', by changing the TYPETMNT timestamp used in sorting the Allocate, Mount, and Dismount events. The problem is that the timestamp of the TYPE21 record is exact, whereas the TMNTTIME/TENDTIME (mount start and mount end times) are up to 2 seconds later (with MXGTMNT sampling default value) than their real event time. Using TENDTIME gave good results, but when TENDTIME was later than TY21TIME, the sequence was A/D/M and the mount was missed. By using SMFTIME=MAX(TMNTTIME,TENDTIME-2), in the step that creates MOUNT dataset, those now match. -Status of known causes of STATUS='MISSEDMNT': -tape ape "knocking-down" the outstanding mount for a specific volser by mounting the wrong VOLSER, perhaps by accident, perhaps intentionally so that the message "Mount Pending For 10 Minutes" won't be created, which stops the MVS console operator from harrasing tape ape. Tape apes know they can put in any VOLSER and that MVS Volume Verification will reject and dismount the wrong tape (so the job doesn't fail) and that the new mount event for the original VOLSER resets mount pending! In this case, MXGTMNT still was in mount pending state, so the second mount does not reset the TMNTTIME start of mount pending, but the TENDTIME end of mount does not occur until after the bad mount was dismounted and the correct VOLSER was verified, so the TY21TIME is in the middle of the mount start and end times: Wrong Vol Right Vol TMNTTIME TY21TIME TENDTIME TY21TIME 10:50:51.26 10:52:15.96 10:52:39.00 10:58:29.11
wrong volume with STATUS=MISSEDMNT, but I can't yet see how to status that mount as a "wrong volume mount", or even if that is needed! ASUMTAPE also creates the real observation for the mount of the right volume, and its TAPMNTTM=TENDTIME-TMNTTIME does include all of the delay caused by mounting-the-wrong-volume, because the real mount (and this job) is still pending until the correct VOLSER is mounted). -one mount of a tape by one job that was not used but the tape was then picked up (without a new mount event, as the tape was in the drive) by a second job. The first mount is output to EXTRAMNT dataset rather than ASUMTAPE and the second job has ASUMTAPE obs with MISSEDMNT. -tape swap (an I/O error caused your VOLSER to be moved to a different physical tape drive) creates an extra mount event for each swap, and MXG properly creates an obs in ASUMTAPE, so these mounts are true, counted mount events, but they were not caused by the job. -I may investigate if a further post-processing step is needed to merge TYPETSWP to identify mounts caused by tape swaps, to detect passing of an unused tape from one job to another, or to identify "kicked-down" mounts.
STATUS are still completely valid tape mount events, with true dismount time, bytes, etc,; it just that the start and end of tape mount time are not known because there was no MXGTMNT mount event found.
VMAC39 of &PIB.2., which caused LSESFQNM to be missing its first May 20, 1999 byte. Thanks to Anthony Pagliano, Summit Bank, USA. ======Changes thru 17.104 were in MXG 17.02 dated May 19, 1999====== Change 17.104 DF/SMS 1.4 additional variables UMUSRSIZ, UMCMPSIZ, and VMACDCOL UMFRVOL may be missing because the tests for existence May 19, 1999 should have been GE 8 for the first two, and GE 20 for the DO group for UMFRVOL. Thanks to Dave Cogar, U.S. Department of Transportion, USA.
VMACTCP in the IBM record. While contacting IBM, the INPUT was May 19, 1999 changed to APISTART ?? SMFSTAMP8., inserting the double question marks to suppress the error message and dump. Nov 3, 1999 update: APAR PW29974 and PQ32322 document negative values for APICALLS bytes in and bytes out. Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch Companies, USA.
VMACTMS5 a new test IF TRTCH=0E1X THEN DEVTYPE='36TRK-E'; was May 18, 1999 added to decode them. Thanks to Sal Fazzino, Excelis, Inc, USA. Change 17.101 Support for NTSMF Version 2.3 (COMPATIBLE), and support EXNTSQAM for new Seagate, Site Server, and SQLSERVER 7 objects: EXNTSQBD EXNTSQBM Dataset Object Name Vars EXNTSQCM EXNTSQDA QUOTAS QUOTAS 5 EXNTSQGS SEAGATE SEAGATE INFO 13 EXNTSQLA SITESVAU SITE SERVER AUTHENTICATION SERVICE 32 EXNTSQLO SITESVCO SITE SERVER CONTENT DEPLOYMENT 34 EXNTSQMM SITESVLD SITE SERVER LDAP SERVICE 86 EXNTSQRA SITESVMB SITE SERVER MESSAGE BUILDER SERVICE 7 EXNTSQRD SQLACCES NT SQLSERVER7 ACCESS METHODS 20 EXNTSQRL SQLBKPDV NT SQLSERVER7 BACKUP DEVICE 1 EXNTSQRM SQLBUFMG NT SQLSERVER7 BUFFER MANAGER 18 EXNTSQRS SQLCACMG NT SQLSERVER7 CACHE MANAGER 5 EXNTSQSE SQLDATAB NT SQLSERVER7 DATABASES 22 EXNTSQSS SQLGENST NT SQLSERVER7 GENERAL STATISTICS 3 FORMATS SQLLATCH NT SQLSERVER7 LATCHES 4 IMACNTSM SQLLOCK NT SQLSERVER7 LOCKS 6 VMACNTSM SQLMEMMG NT SQLSERVER7 MEMORY MANAGER 14 VMXGINIT SQLREPAG NT SQLSERVER7 REPLICATION AGENTS 1 May 17, 1999 SQLREPDI NT SQLSERVER7 REPLICATION DIST. 3 SQLREPLR NT SQLSERVER7 REPLICATION LOGREADER 3 SQLREPME NT SQLSERVER7 REPLICATION MERGE 3 SQLREPSN NT SQLSERVER7 REPLICATION SNAPSHOT 2 SQLSTATS NT SQLSERVER7 SQL STATISTICS 7 SQLUSRSE NT SQLSERVER7 USER SETTABLE 1 Only dataset QUOTAS has been data-tested, but there is a lot of new NT measurements in this change!
as suggested by Jim Quigley's posting to MXG-L LISTSERV. These IIS counters are accumulated in NT 4.0, but are supposedly corrected in NT 2000, so the deaccumulation (done in the _SNTWEBS sort macro, where all DIF() code is now located) may need to be suppressed in NT 2000. Change 17.100 Support of i-data afp-software SMF record. The dataset EXTYIDAP TYPEIDAP has counters of pages and bytes printed by FORMATS i-data, for distributing AFP print thru the enterprise IMACIDAP network, using commodity laser printers. TYPEIDAP See their homepage at www.i-data.com. TYPSIDAP
VMACIDAP VMXGINIT
May 15, 1999 Thanks to Engelbert Smets, Provinzial Versicherungen Duessl,GERMANY. Change 17.099 Support of Lexmark MarkVision "job statistics file" for EXTYMRKV printing on Windows, OS/2 and Windows-NT platforms. The FORMATS dataset MARKVISN created counts sheets and impressions, IMACMRKV by treys and feeders and by auto and manual and by color TYPEMRKV of toner. Each observation is either a successful print TYPSMRKV or an error condition (in which case varible ERROR will VMACMRKV be blank and most fields will be missing. This code has VMXGINIT only been tested executing under ASCII reading ASCII data May 14, 1999 but the program should work under EBCDIC reading the raw datafile that were sent to MVS (and converted to EBCDIC). Thanks to Martin Laursen, Danske Data, DENMARK.
VMXGRMFI workloads to be defined. May 14, 1999
VMACAICS were misspelled in their _Wdddddd macro definition (but VMACAPAF if you used the _Sdddddd or TYPSxxxx member to sort from May 14, 1999 //WORK to the //PDB, there was no error). Thanks to Freddie Arie, TXU, USA.
VMAC110 1.2 has two different formats of Journal data in SMF 110, VMXGINIT and only GLRHTYPE=1 was previously validated, but now the May 14, 1999 GLRHTYPE=2 segment (which happens to be used by SAP) are May 17, 1999 recognized and decoded, eliminating "SOR TYPE NOT ONE" MXG error message and hex dump of the record. This change also corrected a 17.01-only error: the macro &WCICACC was repeated inside other _WCICxxx definitions, and &WCICJRN is now defined in VMXGINIT. Thanks to Roy Pennington, Vertex, ENGLAND. Change 17.095 In an undocumented, verbal change to SYNCSORT records, VMACSYNC new variable MAXSORT='Y' or blank if the MAXSORT option May 13, 1999 was specified for a sort. Thanks to John Parla, Cigna, USA. Change 17.094 Extensive additional decoding of RACF bit flags create FORMATS new one-byte character variables to identify the keywords VMAC80A specified, keywords ignored, keywords in error, and many May 13, 1999 other options of RACF events. Since each RACF command has a unique set of keywords, and there can be many in each single record, the naming convention and variable labels convey the keyword specified/ignored etc. The
KWnnIGmm for Ignored Keywords, and similar names for other options, class names, and other flags. For example the TYPE8019 (PERMIT) command has fourteen keyword specification variables, named KW19SP00-KW19SP13, and the corresponding keyword ignored variables are named KW19IG00-KW19IG13: KW19SP00='KEYWORD*SPECIFIED*CLASS?' KW19SP01='KEYWORD*SPECIFIED*ID?' KW19SP02='KEYWORD*SPECIFIED*ACCESS?' KW19SP03='KEYWORD*SPECIFIED*FROM?' KW19SP04='KEYWORD*SPECIFIED*DELETE?' KW19SP05='KEYWORD*SPECIFIED*FCLASS?' KW19SP06='KEYWORD*SPECIFIED*VOLUME?' KW19SP07='KEYWORD*SPECIFIED*FVOLUME?' KW19SP08='KEYWORD*SPECIFIED*GENERIC?' KW19SP09='KEYWORD*SPECIFIED*FGENERIC?' KW19SP10='KEYWORD*SPECIFIED*RESET?' KW19SP11='KEYWORD*SPECIFIED*WHEN?' KW19SP12='KEYWORD*SPECIFIED*RESET(WHEN)?' KW19SP13='KEYWORD*SPECIFIED*RESET(STANDARD)?' KW19IG00='KEYWORD*IGNORED*CLASS?' KW19IG01='KEYWORD*IGNORED*ID?' ...
KW19IG13='KEYWORD*IGNORED*RESET(STANDARD)?' About 800 new variables are created, with a max of 205 in one dataset (TYPE8024), but at one byte per variable, the impact is minimal. If you use PROC PRINT SPLIT='*', the variable label prints as column heading and you can see which keywords were specified/ignored/errored/etc. You can look at member DOCVER to see what variable name is created for each keyword, or you can use PROC CONTENTS to see the label, but the variable label names the contents. This code has NOT been validated, and there was lot's of opportunity for typos, so please verify with known RACF events that all of the bits are mapped correctly. -One new format was added and old one enhanced. Thanks to Michael Brench, National Bank of Australia, AUSTRALIA. Change 17.093 The LRECL=xxx value for each Tandem file was specified on VMACTAND each INFILE statement, but that was removed so that you May 11, 1999 don't have to modify the VMAC for new Tandem versions; instead you can use the LRECL of the dataset on MVS or a FILENAME statement with LRECL=xxx to specify the LRECL. Thanks to Kim S. Johnson, NationsBank, USA. Change 17.092 Support for SOFTAUDIT 6.1.2 (COMPATIBLE) added three new VMACSFTA fields at the end of the Installed Products File. May 11, 1999 Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY Change 17.091 Support for TELEVIEW 4.3 (INCOMPATIBLE). Field TELUSER VMACTELE was expanded to 9 bytes and 3 bytes were inserted in the May 10, 1999 subtype 1 and subtype 2 record. In addition, while the May 18, 1999 variable SMFTIME has been accurate, none of the internal datetimestamps were validated and all were wrong, but now are corrected and Y2K compliant! Thanks to Yvonne McDonough, USDA NITC, USA.
VMACDB2 wrong, starting with QXRLFDPA. The stat code was revised May 10, 1999 and the line with +4 after QXDEGENC was replaced with the input of QXRLFDPA and its associated +3, and the tests for length were corrected: the 256 to 252, 284 to 280, and 316 to 312. Only DB2STATS was affected; the QXxxxxxx variables in DB2ACCT were not misaligned. Thanks to Ken Michalik, Kraft Foods, Inc, USA. Change 17.089 Unused. Change 17.088 Variable BANDTIME in NPM dataset NPMINNSA is missing. VMAC28 The equation should be BANDTIME=DHMS( ... BANDTTME); May 10, 1999 instead of the typo BANDTIME=DHMS( ... BANDTIME);. Thanks to Mr. Holscher, BWS Munster, GERMANY Change 17.087 Documentation. If your DB2 datasets are on tape, you ANALDB2R must specify DATASET=DDNAME, arguments and PDB=PDB to May 6, 1999 prevent TWO OPEN SEQUENTIAL DATASETS ON ONE TAPE error. If your DB2ACCT, DB2ACCTP, and DB2ACCTB datasets are on tapes with DDNAMES of DB2ACCT, DB2ACCTP, and DB2ACCTB, then you would specify Yüklə 28,67 Mb. Dostları ilə paylaş:
|