* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
VMAC7072 been inconsistently kept) and were added to RMFINTRV data VMAC71 set as well, so as to fully analyze sysplex data from VMAC73 multiple sysplexes. VMAC74
VMAC75 VMAC76
VMAC77 VMAC78
VMAC79 Aug 23, 1995 Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
none MXG 13.02, as there appeared to be no new record changes Aug 22, 1995 in 5.2.2. However, that was not true, and once IBM got Jan 11, 1996 the new SMF manual to me, there were noted several new data. Fortunatly, the 5.2.2 changes were compatible so that none of your existing datasets failed with MXG 13.02 and 5.2.2 records (except for Open Edition/MVS type 92 data). Change 13.156 added the support for type 88 data, Change 13.162 fixed an MXG error in type 6 record that occurred at a 5.2 site (though the error was due to PSF and has happened with earlier MVS), Change 13.310 added fields to type 30, and Change 3.311 dealt with the type 92 so to completely capture all of the new 5.2.2 fields from all records, MXG 13.13 is required. Change 13.170 Support for additional subtypes from Landmark TMON/MVS: EXTMVMLG subtypes CS, IX, ML, and XI are now decoded and these new EXTMVMLL datasets are created from ML and XI records: EXTMVMLP Dataset Description EXTMVMLV TMVSMLG PR/SM Global Segment EXTMVXIM TMVSMLL PR/SM Logical Partition EXTMVXIP TMVSMLP PR/SM Product Segment EXTMVXIS TMVSMLV PR/SM Virtual Processor FORMATS TMVSXIM XCF Member IMACTMVS TMVSXIP XCF Path TYPETMVS TMVSXIS XCF System VMACTMVS while existing datasets TMVSCS and TMVSIX are now Aug 21, 1995 populated with variables. -Additional decoding of several existing segments: Subtype CI, variables CIJFM and CIJGM are not listed in either the online documentation (Ver 1.3, Mod 9405): A: ADVANCED FUNCTIONS 4: DICTIONARY RECORD DIRECTORY nor in the 'Report Writer' 8: Data Elements document, but are in member TMVDSECT (with the same OFFSET=54). Both variables are generally marked as comments. -The TRANSLATE function was inserted after each input for some variables in the subtypes 'NQ' and 'PS'. Thanks to Peter Proppe, Bremer Lagerhaus Gesellschaft(BLG), GERMANY. Thanks to Rod Fernandes, Albert Heijn B.V., NETHERLANDS.
VMACEPMV the I/O section, causing INPUT STATEMENT EXCEEDED RECORD. Aug 21, 1995 The new I/O section logic now looks like this: IF SM180VRS GE '03' THEN DO; /* OMEGAMAON 300+ */ INPUT @SM180OIO SM180DVT $EBCDIC1. SM180DNR $CHAR3. SM180DEV $EBCDIC4. SM180ACT &PIB.4. SM180QCT &PIB.4. SM180VOL $EBCDIC6. @; FORMAT SM180DNR $HEX6. ; END; ELSE DO; ... original code ... END; and variables SM180DNR SMF180DVT were added to KEEP= list for dataset EPMVEPIO. Thanks to Frank Altrichter, Bell Atlantic, USA.
VMACVMXA encountered with IPARMLF1=873Fx and IPARMSG1=MSG2=03Fx, Aug 22, 1995 causing me to reopen and revise Change 13.126 after it was printed in Newsletter 28. However, the site's data is invalid (for example, the 1.14 record had domain 3Fx, but there are only 10 domains, and the record length of the 1.14 record is 34, but there are only 28 bytes until the next 1.14 record). The VM data was sent to MVS with FTP using MODE S (Stream) with no TYPE E (EBCDIC) instead of MODE B (Block) TYPE E, and this caused data values to to be changed in transmission ('09'x was changed to 'F3'x and '1C'x was changed to '22'x by TCP/IP!). Now that I know the cause of the bad values, I might not have made the revisions in Change 13.126, but they make the support more robust and are thus worthwhile to keep. Thanks to Connie Mak, Avon, USA. Change 13.167 This work is incomplete. MVS/ESA 5.2 added several new ASMRMFV tables that need to be added to ASMRMFV and then decoded VMACRMFV in VMACRMFV, but I have no test data for validation. As Aug 21, 1995 test data is provided, the support will be coded and tested. Nothing was changed in ASMRMFV in this change; VMACRMFV was updated with new code blocks and new 5.2 variables were added to existing datasets, but more work is required for the new segments. Change 13.166 Support for 3590 Tape device adds variables EXCP3590 and FORMATS IOTM3590 and TAPE3590 to TYPE434, TYPE30_V, TYPE30_4, IMAC30IO TYPE30_5, TYPE30_6, TYPE40, PDB.JOBS, and PDB.STEPS data VMAC434 sets. The DEVCLASS/DEVTYPE value for this new device is VMAC30 '8083'x; in member FORMATS, only the formats MGCMFDD and VMAC40 $MGDEVTY use those IBM values; the formats MGERPDV (EREP) VMACEXC2 and MGZAREN/MGZARTQ (ZARA) have their own device type VMACUCB value and I have guessed that the value '43'x will be the Aug 19, 1995 3590 value, but I will confirm with IBM and Altai.
MXG Newsletter TWENTY-EIGHT (and are contained in member CHANGESS). Change 13.165 Deaccumulation of HMF datasets TYPEHMF4, TYPEHMF5, DIFFHMF TYPEHMF6, TYPEHMF7, TYPEHMF8, and TYPEHMF9 is required. TYPEHMF Member DIFFHMF is automatically invoked now in member VMACHMF TYPEHMF, but if you add HMF record processing to your PDB Aug 11, 1995 you must also add %INCLUDE SOURCLIB(DIFFHMF); in the Aug 20, 1995 member EXPDBOUT to accomplish the deaccumulation. Some $EBCDIC variables were changed to $CHAR with $HEX format. Test data has determined what should/should not be deaccumulated because it is not noted in the vendor's documentation, but some fields were always zero and thus you should verify with your own data. The vendor states that variables HMF8CS06 thru HMF8CS12 in TYPEHMF8 data set are invalid and should not be used; the problem has been open for over a year and is not resolved yet. Thanks to Shaheen Pervaiz, Acxiom CDC Inc, USA.
EXERPCRW EREPCRW - Channel Report Word EXERPDDR EREPDDR - Dynamic Device Reconfiguration EXERPEOD EREPEOD - System Ending /EOD/Normal/Abnormal EXERPETR EREPETR - External Timer Reference Record EXERPHDR EREPHDR - LOGREC Header Record EXERPIOS EREPIOS - Input/Output Supervisor Recovery EXERPIPL EREPIPL - System IPL EXERPLMI EREPLMI - Link Maintenance Information EXERPLRS EREPLRS - Lost Record Summary EXERPMCH EREPMCH - Machine Check Handler EXERPMDR EREPMDR - Miscellaneous Data Record EXERPMIH EREPMIH - Missing Interrupt Handler EXERPOBL EREPOBL - Outboard Long Records EXERPOBR EREPOBR - Outboard Short Records EXERPSDW EREPSDW - Software System Diagnostic Area EXERPSIM EREPSIM - DASD Service Information Message EXERPSLH EREPSLH - Subchannel Logout Handler EXERPSYM EREPSYM - Symptom Programming Failure EXERPTIM EREPTIM - Logrec Time Stamp Record IMACEREP Either SYS1.LOGREC or EREP records can be processed with JCLEREP this support, even though the data records are not quite TYPEEREP identical. All records have been tested except for the VMACEREP ETR, SIM, IOS, and MCH events, which did not occur in my Aug 20, 1995 test data. Thanks to K.U. Geiger, KKH, GERMANY. Change 13.163 MAINTLEV 6 does not yet exist, although it was listed in ASMTAPES this change text in the printed MXG Newsletter 28. It is VMACTMNT still in development testing. The ASMTAPES on this 13.05 Aug 12, 1995 is MAINTLEV 5, which seems to solve the stall problem Aug 19, 1995 (the monitor would simply stop, using no CPU and writing no records) by better handling the SRB. You may see some "TMNT" messages printed on the job log of the MXGTMNT job (TMNT009I SRB Timeout PURGEDQ attempts, TMNT011I SRB was PURGED) that are really diagnostics to indicate how often the SRB we scheduled in the tape job's address space did not respond. Previously we sometimes scheduled a second SRB before the first ended; now if the first is not back we first purge it and then start another SRB. We almost always eventually get the information back from the SRB routine, so that the data in the SMF record is usually good even when SRBs are purged. However, the READTIME and other timestamp variables may be invalid if the job ended before we got the SRB response, so I have added ?? modifiers to the SMFSTAMP fields in VMACTMNT so as to avoid printing of a hex dump if you should by chance get an invalid READTIME in a record. The "TMNT" messages so far occur mostly right on or after the hour, and then for hours there are none, and we are using these diagnostics to continue to enhance what will be MAINTLEV 6. In that iteration, the printing of those "TMNT" messages will be optional, and the default will be not to print them. The problem that is still in development testing occurs very infrequently, but we still occasionally find the PROGRAM=IEFIIC or the incorrect job name will be put in the SMF record. This seems to be isolated to jobs that had some tapes allocated, went into allocation recovery for additional drives, received WAIT,NOHOLD response, had its drives stolen away, and later was reallocated to the same device. This fix may require additional records to be created and additional logic in VMACTMNT to completely resolve these rare instances. Statistically, the records created by MXGTMNT still are quite valid.
office) if you would like to be shipped MAINTLEV 6 when it is ready (probably not before October, 1995).
above have been MIM sites, and their MIM administrator had specified that MIM should reply NOHOLD. In the MIM manual, there is a statement that NOHOLD is required by MVS 4.3, but the MIM Product Manager has confirmed that that statement is false; either HOLD or NOHOLD can be used with any version of MVS. It is true that MIM does strongly recommend that you use NOHOLD instead of HOLD, because MIM favors throughput over job importance.
that job will block any other allocations by any other job on any other system from getting any tape drive in that tape group, until it completes its allocation. Thus HOLD response favors the completion of the job that has already been initiated ahead of any other job. By specifying WAIT,NOHOLD, those drives that have already been allocated are freed, and the job goes to the bottom of allocation queue, so that maybe another job on this or another system could now run. This favors other jobs. I think I would rather finish what I have started first (especially if I have a smart job scheduling system that is based on service objectives - I can presume there that the job that was started was more important than the not started job), but you must understand the difference and make your own decision as to which senario is appropriate for your site's job scheduling system, and not just arbitrarily accept MIM's NOHOLD recommendation. ======Early MXG Version 13.05, dated Aug 14, 1995, thru 13.162====== Change 13.162 PSF 4.0 type 6 SMF record INPUT STATEMENT EXCEEDED RECORD VMAC6 LENGTH error because IBM did not document that SMF6TUL Aug 11, 1995 includes its own two bytes, causing MXG to try to read 2 more bytes than are in the record. After the @; after the INPUT of SMF6TUL, insert this line: SMF6TUL=SMF6TUL-2; Thanks to Diane Eppestine, Southwestern Bell, USA.
VMAC115 been input separately as SM115SSI or SM116SSI, but it was VMAC116 not kept. Labelled MQMSSSID='MQM*SUBSYSTEM*ID', it is Aug 9, 1995 needed to associate MQM records. Thanks to Pat Quinnette, Principal Mutual Life Insurance Co., USA.
ANALRMFR tests GE "4" should have been GE "3". The adjacent MVS Aug 8, 1995 release number (3.1.3) was printed correctly. Thanks to Victor Chacon, NYNEX, USA. Change 13.159 DB2 Statistics Detail report, page 6 had 4 values wrong ANALDB2R and four labels were clarified, and the SHIFT= parameter DIFFDB2 did not work quite right. Aug 8, 1995 Buffers Allocated (VPOOL or HPOOL) were negative because their variables, QBxTVPL and QBxTHPL, were wrongly built in data set DB2STATS; those variables were DIF()ed in member DIFFDB2, but they are endpoint values, instead of accumulated, a fact not documented by IBM; only non-zero data can validate whether to DIF() or not to DIF()! Delete all lines in DIFFDB2 with TVPL or THPL suffix. -The values for GET/PAGE SYNC READ RANDOM was incorrectly calculated. Replace RANDOM with RANDOMP for the random page calcs, replace RANDOM with RANDOMR for the random read calcs, and recalculate RATIO=RANDOMP/RANDOMR. -The value for D PRF PAGES READ was wrong because the variable RANDOM was printed instead of RATIO. -Labels for the four rations now read: RANDOM PAGES PER READ, SEQ PREFETCH PAGES PER READ, LIST PREFETCH PAGES PER READ, DYN PREF PAGES PER READ. -If you used SHIFT=P in report PMSTA01, you would not just get a report for all Prime time in DB2STATS, but got multiple reports, one short and before prime, and one that covered almost all of the requested shift (and that report was accurate for the timeframe it reported). The error was in using ENDTIME instead of STRTTIME in the recalculation of SHIFT. After %MACRO PMSTA01, move the STRTTIME=ENDTIME-DURATM; statement to immediately before the %IF %LENGTH(&SHIFT) GT 0 %THEN %DO; statement, then three lines later, change DATETIME = ENDTIME to read DATETIME=STRTTIME; Thanks to Neil Ervin, Huntington Service Company, USA. Thanks to Cal Cooke, Huntington Service Company, USA. Thanks to Clark Jennings, Reynolds Metal, USA. Change 13.158 Support for the Year2000, phase one: DOC -All variables with DATETIME or DATE formats were changed Aug 7, 1995 to expand the printed width to display the year in four print positions: Was Now Is So it will print as DATE7. DATE9. 08Aug1995 DATETIME16. DATETIME18. 08Aug1995:20:58:20 DATETIME19.2 DATETIME21.2 08Aug1995:20:58:20.99 DATETIME20.3 DATETIME22.3 08Aug1995:20:58:20.999 DATETIME23.6 DATETIME25.6 08Aug1995:20:58:20.999999 Note that only the printed value is changed; all MXG date variables are stored in 4 bytes, and all of the datetime variables are stored in 8, so MXG has always internally supported the year 2000. Those variables that had an undefined length (DATE. or DATETIME. format) were changed to one of the above formats. Over 10,000 instances of these formats were changed in several hundred members. -The preliminary list of products that do not support the year 2000 was expanded in member YEAR2000; the earlier list overlooked some products whose dates were created using the MDY(MO,DA,YY) function. I believe the list of products now is very close to complete. -Those instances of MDY(MO,DA,YY) wherein the actual FIELD that was input was a PD4 containing 'CYYMMDDF'x are now converted, using this logic: CC=FLOOR(FIELD/1000000); YY=FLOOR((FIELD-1000000*CC)/10000); MO=FLOOR((FIELD-1000000*CC-10000*YY)/100); DA=FIELD-1000000*CC-10000*YY-100*MO; YYYY=1900+YY+C*100; DATE=MDY(MO,DA,YYYY); for these types of data values: Hex Date 0991231F 12/31/1999 1000101F 01/01/2000 1001231F 12/31/2000 1010101F 01/01/2001 The use of YYYY instead of YY signifies that MXG has put the code in place to support the century bit; of course, this will be 2000 in 2000 only if the vendor sets that century bit; otherwise it will look to be the year 1900! -Those instances of MDY(MO,DA,YY) wherein the YY variable was input as PIB2. can support either the Century bit or a four digit year: Field Decimal Hex Year YY 99 0063x 1999 CYY 100 0064x 2000 CYY 142 0216x 2042 YYYY 1999 05CFx 1999 YYYY 2042 07FAx 2042 For these fields, this new logic is now used, as it will correctly resolve the year whether the vendor sets the century bit or sets a four digit year: IF 0 LE YY LT 1960 THEN YYYY=1900+YY; ELSE YYYY=YY; DATE=MDY(MO,DA,YYYY); Again, the YYYY confirms the MXG four digit year support. Note that the MDY() function fails if the YY argument is 100, so this new logic was required. About 20 members were protected by this additional code. -All instances of DATEJUL() function, which does not yet support the century bit, must be revised. Values input with PD4 format could contain a century bit (0cyydddF0, or they could contain a four digit year: Hex Date 0099365F 12/31/1999 1999365F 12/31/1999 0100001F 01/01/2000 2000001F 01/01/2000 0100365F 12/31/2000 2000365F 12/31/2000 0101001F 01/01/2001 2001001F 01/01/2001
PD4 DATEJUL fields, as it will protect for either the century bit or a four digit year:
CC=FLOOR(PD4FIELD/100000); YY=FLOOR((PD4FIELD-100000*CC)/1000); DDD=MOD(PD4FIELD,1000); IF 0 LT DDD LE 366 THEN DO; IF 0 LE CC LE 2 THEN YYYYDDD=DDD+1000*(CC*100+YY+1900); ELSE IF CC GE 19 THEN YYYYDDD=DDD+1000*(CC*100+YY); ELSE YYYYDDD=.; END; ELSE YYYYDDD=.; IF YYYYDDD GT 0 THEN DATEYYYY=DATEJUL(YYYYDDD); ELSE DATEYYYY=.; Here, the YYYYDDD confirms the MXG support for year 2000. Eighty-two members contained 340 uses of DATEJUL() that were modified by the addition of the above logic.
was incomplete; the above code is the tested code that is now implemented in MXG 13.05.
EXECDALY and EXECTEST were deleted; they had been replaced by the EXECEMAC REXXxxxx members of the same suffixes in 1989, were kept EXECPDB only for transition, and now are no longer needed (and EXECTEST the EX prefix is now used only for dataset exit names). Aug 7, 1995 Change 13.156 Support for MVS/ESA 5.2 System Logger Data SMF type 88 EXTY88 creates this new dataset: IMAC88 TYPE88 - System Logger Data TYPE88 These interval records record system logger activity and VMAC88 system wide logger exceptions. IBM comments that if the Aug 5, 1995 variable SMF88SIB (bytes deleted before the data was migrated to DASD) is high, and variable SMF88SAB (bytes deleted after data migration to DASD) is low, then the system logger is successfully using the coupling facility structure to avoid DASD input/output. MXG creates the variable SMF88RAT as SMF88SIB divided by SMF88SAB. This code has not been tested with data records. When I have data records, I intend to produce reports similar to IBM's sample program IXGRPT1 (in SAMPLIB). Change 13.155 Support for OpenMVS File System Activity SMF type 92 adds EXTY9201 six datasets: EXTY9202 TYPE9201 - OMVS File System Mount EXTY9204 TYPE9202 - OMVS File System Quiesce/Suspend EXTY9205 TYPE9204 - OMVS File System UnQuiesce/Resume EXTY9210 TYPE9205 - OMVS File System UnMount EXTY9211 TYPE9210 - OMVS File System Open IMAC92 TYPE9211 - OMVS File System Close TYPE92 The only change in VMAC30 was to make labels consistent. VMAC92 I used the pre-existing MXG variable names from the type Aug 5, 1995 30 record where appropriate. This table shows what is and what is not consistent between 30s and 92s: MXG Type 30 Type 92 Description Variable field field OMVSAPG n/a SMF92APG Parent Process Group ID OMVSASG n/a SMF92ASG Parent Session ID OMVSOPG SMF30OPG SMF92PGD Process Group ID OMVSOPI SMF30OPI SMF92PID Process ID OMVSOPP SMF30OPP SMF92API Parent Process ID OMVSOSI SMF30OSI SMF92SSD Process Session ID OMVSOUG SMF30OUG SMF92GID Process User Group ID OMVSOUI SMF30OUI SMF92UID Process User ID JOB SMF30JBN SMF92JBN Job name READTIME SMF30RST SMF92RST Read-In/Logon Datetime STEPNAME SMF30STM SMF92STM Step Name STEPNR SMF30STN n/a Step Number SUBSTEP SMF30SSN n/a Sub Step Number The SMF Manual (GC28-1457-01) has a good introduction to OMVS accounting records in Chapter 8 (but the schematic does not show when the 92s are written). This new type 92 record looks very useful in measuring Unix-under-MVS I/O activity, something not available in other Unix! This code has not been tested with data; I hope to get test data with both OMVS 30s and 92s for testing and intend to write a technical note on OMVS at that time. Thanks to Lee Borgman, Boeing, USA. Change 13.154 If CICINTRV was executed outside of BUILDPDB, it failed CICINTRV because the macros defined in IMACCICS were not included. Aug 4, 1995 (BUILDPDB includes IMACCICS before invoking CICINTRV.) Add %INCLUDE SOURCLIB(IMACCICS); at beginning of code. See Change 14.188. Thanks to Chuck Hopf, MBNA, USA. Change 13.153 NPM 1.5 creates subtype 18x record with invalid data for VMAC28 variables LNADDCTD and/or LNADDCTT, causing INVALID Aug 3, 1995 ARGUMENT TO FUNCTION INPUT message and a hex record dump is printed on the SAS log. Those fields did not exist in release 1.5, but when they are non-zero, they cause the error, because MXG expected if the LENAOF=136, it was because the two new fields were in your record. There is no impact on the MXG datasets, but the message and the printed dump can be avoided by changing the test: IF LENAOF GE 136 THEN DO; to read: IF LENAOF GE 136 AND NPMPVN GE 15X THEN DO; Thanks to ???, ???, Hong Kong. Change 13.152 User-written invocations of VMXGSUM must be examined, due VMXGSUM to a just-discovered incompatibility introduced in Change Aug 3, 1995 12.084 (MXG 12.02 and later). Even though you used the Yüklə 28,67 Mb. Dostları ilə paylaş:
|