* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
and other CSM users without having to physically copy the data, saving memory and CPU by sharring buffers. -New subtype 'DE'x creates NPMVSVRT dataset: LABEL='028VRT: VTAM RTP RAPID TRANSIT PROTOCOL' with first-in/middle-in/last-in/non-seg sent/rcvd pius, bytes sent/received over RTP, back pressure count/times RTP is a highly efficient mechanism used by the High Performance Routing (HPR) to enable SNA to run highspeed multi-megabit links with low bit error rates on LANS and WANS and is used by SNA to exploit frame relay, SMDS and ATM and other new switched virtual network technologies. -New subtype 'DF'x creates NPMVSVMN dataset: LABEL='028VMN: VTAM MNPS MULTINODE PERSISTENT SESSION' VTAM uses multinode persistent sessions MNPS to preserve sessions across application outages when connected thru the S/390 coupling facility. While MNPS is primarily for recovery of hardware, VTAM, MVS, or other failures, NPM 2.4 now collects, for each application connected thru MNPS, the percent of CF blocks in use by all MNPS sessions and by this application, with CF Structure name and structure sizes/bytes/writes and recovery counts! The "IBM Marketing" descriptions came from pages xxix-xxx of NetView Performance Monitor Reference Version 2 Rel 4, (SH19-6965-02), which also describes the new TCP/IP Session Collection Capability (response time data for TELNET sessions to a mainframe application, including the IP network segment, available for TN3270E servers that reside on the same host as NPM and are running OS/390 Release 5 or higher). The NetWare resource counters, although not new in NPM 2.4, are described in Appendix B (and support for those NCV, NGV, NLS, NLV, NRV, NVS, and NVV NetWare segments and subtypes has been in MXG for some time). Change 16.283 Comments only, but the LRECL values for AS/400 4.2 were IMACQAPM wrong for QAPMCONF (LRECL=16 in 4.2, was 46 earlier) and VMACQAPM AS/400 support is critical for correct LRECL. Comments Nov 18, 1998 were revised and updated with correct LRECLS where known. Thanks to Bob Eastlake, Hosiery Corporation of America, USA.
ASUM70PR raw SMF were old and had not been updated for changes in Nov 18, 1998 the datasets needed by RMFINTRV. These examples have now been revised and tested. Thanks to Bob Eastlake, Hosiery Corporation of America, USA.
VMACCTCP blank; the eight lines decoding CTCIPAD from CTCPLOAD in Nov 18, 1998 the SUBTYPE=2 DO group must be moved to within the SUBTYPE=1 DO group. Thanks to Patsy Hildredth, CMX, USA.
VMACICE new test/prod/both unique/shared capacity/used statistics Nov 18, 1998 in new variables: BEBYTSHR BEBYTUNQ NOTRMAPU PHCAPUSS PHCAPUSU TPHCPSRB TPHCPSRP TPHCPSRT TPHCPUNB TPHCPUNP TPHCPUNT Thanks to Bonnie Jean Walter, Summit Bank, USA. ======Changes thru 16.279 were in MXG 16.06 dated Nov 17, 1998====== Change 16.279 Errors only in the first 16.06 tape dated Nov 16: FORMATS -Format MGMVCIT was missing equal signs in member FORMATS, VMAC434 causing JCLINSTL to fail. Format was added after QA. VMAC80A -VMAC80A MACRO name is _S80A rather than _STY80A. VMACTSOM -VMAC434 variable TERMTIME rather than TERMIME. VMACHMF -VMACTSOM _BTSOCAL/_BTSODRU STRTTIME vice SMFTIME. Nov 17, 1998 -VMACHMF ending comment missing in _STYHMFB macro.
VMACSYNC The variables are: SYNCAVLA SYNCAVLT SYNCREQT SYNCUSEA Nov 16, 1998 SYNCUSET SYNDSMVL SYNVSCOR SYNVSCRT Thanks to Chuck Hopf, MBNA, USA. Change 16.277 The PDB.CICINTRV dataset can be very wrong; users must CICINTRV install MXG 16.06 or later to correct the errors in the VMAC110 MXG logic. Depending on which CICS Statistics records VMXGCICI had observations, CICINTRV could be valid, but the logic Nov 15, 1998 was completely redesigned. Many datasets did not pass Jul 22, 1999 thru VMXGSUM, so their COLLTIME was never reset to the start-of-interval-value, and if there were multiple obs to be summed, their unique COLLTIME values created many repeated instances in the MERGE which were then falsely summed. The revised logic sends all 45 CICS Statistics datasets thru VMXGSUM, and all have INTERVAL=&INTERVAL and DATETIME=COLLTIME specified so that shorter intervals are correctly summarized. KEEPIN= and ID= were also set so that LABELs and FORMATs are propagated, which produces notes: "Variable xx exists on file WORK.MXGSUM3". Now that PDB.CICINTRV is valid, you can use it to measure the maximum CPU time required for any of CICS's six TCBs, to confirm that that single CICS TCB will fit in single engine, for capacity planning and for backup site sizing. MXG creates the interval duration from DSGTDT+DSGTWT and the individual DSxPERCT is the percent of DURATM when DSx's TCB was busy; new variable PCTCICBY is the percent of DURATM when all TCBs in this region were busy. Note that if you want to see the raw interval data and set MACRO _CICINTV % (i.e., "none"), and you thought you were writing 5 minute interval CICS statistics data, you will find some intervals only seconds apart, because if there are SMFSTREQ='REQ' or 'USS' event records in between the 'INT' and 'EOD' records, the CPU times and counts have to be de-accumulated, and you end up with erratic, but completely accurate, intervals.
that are used in CICINTRV, so you can insert in EXPDBOUT MACRO _SCICEXC % _S110
to sort and save all CICS Stat datasets into the PDB library (and CICINTRV detects and uses sorted data). The redefinition of MACRO _SCICEXC to a null was added in Jul 99; it is needed because in BUILDPDB, that sort was already invoked, and the work copy of CICSEXCE has already been deleted. By nulling the one _Sdddddd macro, the _S110 can be executed without error. However, the raw CICxxxxx Statistics Datasets frequently contain accumulations rather than interval values; this is especially true of the CICDS (Dispatcher) dataset, which contains the CPU TCB times (DSGACT, DS2ACT...). Those numbers in CICDS can be very deceptive, and thus you should use this new PDB.CICINTRV to be safe. If you already have existing CICDS data, you can PROC SORT it PROC SORT DATA=PDB.CICDS OUT=SRTDS; BY SYSTEM APPLID SMFPSSPN CICSSTCK COLLTIME ; PROC PRINT; VAR APPLID COLLTIME DSGACT ... SMFSTRQT; DATA DIFDS; SET SRTDS; DSGACT=DIF(DSGACT); DS2ACT=DIF(DS2ACT); ... DS6ACT=DIF(DS6ACT); PROC PRINT; VAR APPLID COLLTIME DSGACT ... SMFSTRQT; and disregard the negative numbers, to get a quick view. If there is a need, I may expand CICINTRV to optionally create de-accumulated CICxxxxx Stat datasets, but for now PDB.CICINTRV in MXG 16.06 is the dataset to use! Thanks to Mike Marek, First Card - FCC National Bank, USA. Thanks to Tom Elbert, Fortis, USA.
VMXGINIT -VMXGINIT: PTY848, PTY849, PTY8026 added to GLOBAL. VMAC79 -VMAC79: SYSTEM added to KEEP= list 79DF/79E/79EF. VMAC80 -TYPS80: _S80 macro invocation added. VMAC85 -VMAC85: "%" in column 72 caused SAS ERROR 180 error, VMAC88 which technically is a SAS compiler bug, but it VMAC94 is easier just to split the long line into two Nov 14, 1998 and not use column 72 for ending percent signs! -VMAC88: _BTY8811 variable is SMF88ANM, not SMF88LSN. -VMAC94: _STY94 macro, added BY _BTY94 ; after PROC SORT. Thanks to Bruce Widlund, Merrill Consultants, USA.
VMACEDGS MVDSNL $VARYING44. MVDSNLL so that the DSN Nov 14, 1998 length input was the length of last DSN. Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA Change 16.274 -The _S110 macro no longer sorts CICSTRAN (high volume) VMAC110 nor CICSACCT nor CICSYSTM (both pre-CICS/ESA only). The Nov 14, 1998 _S110 macro should be invoked in your EXPDBOUT member if you want all of the CICS Statistics and CICS Journal data sets sorted into your PDB library with BUILDPDB. If you use member TYPS110 to directly read type 110 SMF records, it invokes _S110 to sort from work to PDB library.
ASMIMSL6 DF/SMS is installed. Using the MXG default of zero Nov 13, 1998 caused an 878 out of memory error, because the table that had been moved above 16MB by Change 14.149 was put below the line by the zero value. The correct default, that DF/SMS is installed (not necessarily active), will put the table above the line and eliminate the ABEND. Thanks to Harry Olschewski, DeTeCSM/SLM - Kiel, GERMANY. Change 16.272 The PROC SORT of TYPE25 in the _STY25 macro had SMFTIME VMAC25 after _BTY25, but _BTY25 already contained SMFTIME. For Nov 13, 1998 reasons still not understood, that redundant SMFTIME at the end caused the data set to be not sorted in BUILDPD3 so it was removed. Thanks to Jean Quinkert, Inland Steel, USA. Change 16.271 MXG 16.04-16.05 only. PDB.ASUM70PR summarized by SHIFT ASUM70PR rather by expected HOUR default. Change 16.146 added new VMXGDUR line &DATETIME=DATETIME; in VMXGSUM after %VMXGDUR call, VMXGSUM but the VMXGSUM invocation in member ASUM70PR has both Nov 15, 1998 NEWSHIFT='Y' and MYTIME=_DURSET specified, which caused the DATETIME variable used in VMXGDUR to inadvertently be the start of shift. The correction is in member VMXGDUR, so that it uses the correct DATETIME value in all cases. Member ASUM70PR was the only place in MXG where VMXGSUM used both the NEWSHIFT='Y' and MYTIME=xxxxx options. Only member VMXGDUR was changed by this change. Thanks to Lee Teague, Lockheed Martin, USA. Thanks to Sandra M. Rodriguez, Liberty Mutual, USA.
EXCICJRN The type 110 subtype 0 Journal Format record was entirely VMAC110 restructured in CICS TS 1.2 (a/k/a 5.2). The record now Nov 12, 1998 contains an LGMS header, an LGMS CICS Product Segment, a 56-byte LGGF (GLRH Record Header), and a 20-byte LGGF SOR record at the start of each subtype 0 record. Then one or more LGGF (GLRH Record Header again), an LGGF CL_USER-HEADER (which is where the JCRUTRID Journal ID value is finally found) and then bytes of user data. This new code has been tested with user journal data, but not yet with either SAP nor Shared Medical journals from CICS TS 1.2. IBM provides a COMPAT41 facility for journal records written to the logger, but IBM says there is no compatibility service for user journalling records written to SMF. Thanks to Thomas Weiland, Phoenix Home Life Mutual Insurance, USA. Thanks to Mark Hawks, Phoenix Home Life Mutual Insurance, USA.
VMAC42 DCMEPCT 'DCME*INHIBIT*PERCENTAGE' Nov 12, 1998 RCIPCT 'RECORD*LEVEL*CACHE*INHIBIT*PERCENTAGE' Thanks to Michael Marek, First Card, USA. Change 16.268 Some variables were not input from SMF type 90 subtypes: VMAC90 Subtype 5/9/13/15 new variable SMF90SBU (SMF Flags) is Nov 12, 1998 created, and variable ACTIVEMN is increased to $44 to contain the full (long) name of the SMF dataset. Subtype 6, OLDDSNSM and NEWDSNSM are increased to $44. Thanks to Jan van Kemenade, Candle, THE NETHERLANDS. Change 16.267 MXG 16.04-16.05 only. MACRO _LRAC507 needed two decimal TYPSRACF points: MACRO _LRAC507 &PRAC507..RACF507 % in VMACRACF, VMACRACF and the PROC FREQ was removed from member TYPSRACF. Nov 11, 1998 Thanks to Tom Downey, IBM Global Services, CANADA.
VMXGWORL the location (_W or _L) of the CICS Stat dataset that are Nov 12, 1998 read by CICINTRV, but if found in the _L location it was assumed that the PROC SORT could be bypassed. However, if you used PROC COPY IN=WORK OUT=PDB; SELECT 7IC:; in the EXPDBOUT member, CICINTRV failed as the data was not sorted. Now, the logic in VMXGWORL tests the SORTED flag in the found data and only if it is true is the PROC SORT bypassed by MXG now. Why did I not let the PROC SORT detect that the data was sorted so it would bypass the actual sorting? Because invoking the PROC SORT would still result in an unnecessary copy from input to output that is avoided by MXG not evening calling the PROC SORT. Instead of the PROC COPY syntax in your EXPDBOUT, you should instead add the single line containing _S110 which will sort all of the CICS Statistics datasets into the work file, (and CICINTRV will skip their sorts!). Thanks to Jean Quinkert, Inland Steel, USA. Change 16.265 The type 88 subtype 11 was badly misdocumented, but it is VMAC88 now corrected by APAR OW36033, which also describes three Nov 11, 1998 new fields, SMF88ATW, SMF88ALS, and SMF88AFG that are now input and kept in dataset TYPE8811. Change 16.264 Support for PSF/MVS Release 3.1.0 (APAR 35685) compatibly VMAC6 adds a new count of the accumulated number of logical Nov 11, 1998 pages per side, SMF6LPGE, and the size of paper (length and width in millimeters, BINxBNLE and BINxBNWI). Change 16.263 Change 16.214 formatted new HSM Functions in DF/SMS 1.4, VMACHSM but failed to output the new subtypes 17-20. Nov 11, 1998 FSRTYPE Description 17 Expire primary or migrated data set 18 Partrel function 19 Expire incremental backup version 20 Expire incremental backup version Now, test data shows they are the same structure as the existing subtypes 1-14, so changing the test to read: IF (1 LE FSRTYPE LE 14) OR (17 LE FSRTYPE LE 20) THEN DO; will output them into dataset HSMFSRTP. Thanks to Solomon Baker, The Prudential Service Company, USA. Change 16.262 Candle's Omegamon for VTAM SMF record NTRI segment was VMACOMVT incorrectly documented, causing INPUT STATEMENT EXCEEDED Nov 10, 1998 error. The eight-byte reserved field after ON14OP is in fact only four bytes. Change the +8 to +4. Thanks to Eric Barnes, Prudential, ENGLAND.
VMACNTSM following the _WNTNSHU reference (lines 1815-1816). Nov 10, 1998 Thanks to Carl Kyonka, Consumers Gas Company Ltd., CANADA Change 16.260 Support for Boole & Babbage MainView for CICS CMRDETL EXMVCICF VSAM file creates two new datasets from CMR52: EXMVCICS Dataset dddddd Description FORMATS CMRDETL MVCICF MAINVIEW CICS CMRDETL file detl IMACMVCI CMRFILE MVCICS MAINVIEW CICS CMRDETL TRANSACTS TYPEMVCI There is one observation in CMRDETL for each transaction VMACMVCI and one observation in CMRFILE for each file that was VMXGINIT accessed by each transaction. The CMRDETL is similar to Nov 7, 1998 type 110's CICSTRAN and the CMRFILE is similar to CICFCR. Nov 13, 1998 The raw CMRDETL file is compressed, but the compression Nov 16, 1998 algorithm Boole used for CMRDETL is not the same as the compression algorithm that Boole now uses for its other MainView products (i.e., the new ASMMNVW does NOT work with CMRDETL file), but Boole intends to provide me with a separate ASMxxxxx member to handle CMRDETL compression. You can use Boole's PGM=CMRCMPW to decompress the data until the new Infile Exit for CMRDETL exists. Boole also corrected documentation errors; CICS 5.2 date format is now MMDDYYYY and T6EUSTGX replaces T6EUSTGO. New format $MGMVCIT decodes File type. Thanks to Peter Hartmut, R & V Allgemeine Versicherung AG, GERMANY.
ASMTAPES situation associated with the DSAB flag. The original Nov 1, 1998 logic looked for the end-of-queue marker, but now the code uses the count of entries to find the end-of-queue, as we found one instance in which there was no end-mark and MXGTMNT went into a loop and had to be cancelled. Change 16.258 RMFR Reports, variables SYSPLEX and STARTIME NOT FOUND if ANALRMFR parameter overrides are PDB=SMF and REPORT=ALL. Fields Nov 1, 1998 R744FMOD/FVER/VLVL added to Coupling Facility Usage, and the LPAR MGMT column in the Partition Data report was corrected (it was sometimes negative).
TYPEIMSA from European Summer time, which had GMTOFFTM of zero, VMACIMSA but with non-zero GMT offset, VMACIMSA converted GMT to Nov 1, 1998 local only for the ENDTIME variable in the 07/08 records (because they contain the GMTOFFTM), but the IMSMERGE records created as output from ASMIMSL6 do not contain the GMT offset (because it did not exist prior to 6.1!). The mixed time zones caused invalid (large negative in the western hemisphere, large positive east of GMT) for SERVICTM (service time) and RESPNSTM. This fix removed the conversion of ENDTIME/STRTTIME in VMACIMSA, instead keeping variable GMTOFFTM from the 07/08 record, and then in the final MERGE, the GMT offset is added to all timestamps in that one place. PLEASE VERIFY THIS LOGIC! Thanks to David Martin, USS-Posco Industries, USA.
VMACDB2 were not input, but now they are. Nov 1, 1998 Thanks to Craig Collins, State of Wisconsin, USA. Change 16.255 Support for new DF/SMS OAM type 85 SMF record with 31 EXTY85AC subtypes create eleven datasets tracking Optical Access EXTY85CV Method activity, volumes, space, durations, objects, EXTY85LS bytes, deletes, etc., etc: EXTY85RD Subtypes MXG Dataset Description Test Data? EXTY85RQ 1- 7 TYPE85AC OAM OSREQ ACTIVITY Y EXTY85SO 32-35 TYPE85ST OAM OSMC STORAGE MANAGEMENT Y EXTY85ST 36 TYPE85SO OAM OSREQ SINGLE OBJECT N EXTY85TD 37 TYPE85LS OAM OAMC LIBRARY SPACE Y EXTY85TP 64-67 TYPE85VL OAM VARY LIBRARY/DRIVE N EXTY85TV 68-73 TYPE85CV OAM LCS CARTRIDGE/VOLUME Y FORMATS 74-77 TYPE85RQ OAM LCS READ/WRITE/REQUESTS Y IMAC85 74-77 TYPE85RD OAM LCS READ/WRITE DETAILS Y TYPE85 78,79,88 TYPE85TP OAM LCS TAPE READ/WRITE Y VMAC85 78,79,88 TYPE85TD OAM LCS TAPE READ/WRITE DETAILS Y VMXGINIT 87 TYPE85TV OAM TAPE VOLUME DEMOUNT N Oct 31, 1998 While the record contains "kilobytes", MXG converts all those storage size variables into bytes and formats them with MGBYTES format which prints as KB/MB/GB etc. I assumed 1024 bytes per kilobyte, but need to confirm. The start and end timestamps are on the GMT clock but there is no GMT offset in the records, but I used the delta between SMFTIME and the R85PENDT to create the GMT85OFF (but it probably won't contain leap seconds). There are 24 undocumented bytes in the product section that look suspiciously like job/step/procstep names, but they are not decoded until they are documented by IBM. There is an incredible wealth of information provided by IBM for accounting, performance and capacity planning, and the SMF manual has a brief discussion of OAM data. Thanks to Gary Matney, American Century, USA.
VMAC16 required no change in MXG, since the record format was Oct 31, 1998 not changed, and MXG already supported APARs that had added bits to some flag fields. Change 16.253 CICINTRV now figures out whether your CICS Statistic data CICINTRV is sitting in the Work file ("_Wdddddd") or whether you TYPS110 had used the _Sdddddd macro to PROC SORT it into the PDB VMXGCICI ("_Ldddddd destination). This applies only to the type VMXGWORL 110 subtype 2 SMF records. Normally, BUILDPDB/3 will Nov 1, 1998 build AND sort all datasets for a product from WORK into the PDB, but CICS type 110 subtype 2 records are only created in the WORK file and are not SORTed to PDB, (because the CICS Statistics datasets can be large and are not useful unless your are going to use them!). The old way to add CICS Stat data into your PDB with the BUILDPDB added a PROC COPY IN=WORK OUT=PDB; SELECT CIC:; in tailoring member EXPDBOUT to copy all, or individual PROC SORTs were added in EXPDBOUT. But now with the new MACKEEP design, you only need to add the _SCICddd macro for each dataset you want, and you don't even have to use a %LET PCICDS=PDB; because the default value for PCICDS is already PDB! Well, adding the _SCICDS macro in EXPDBOUT does create dataset PDB.CICDS, but CICINTRV failed with DATASET NOT FOUND, because it hardcoded the input CICS stat data to be in the _Wdddddd, but the PROC SORT is from _W to the _L, and housekeeping deletes the _Wdddddd dataset! This solution is a redesign of CICINTRV to invoke new member VMXGCICI (because CICINTRV is a "%INCLUDEd member" but we needed the power of a "%MACRO), and creation of a new utility %MACRO VMXGWORL to determine for a given dddddd value whether the data is in the _W or in the _L (and if it is in the _L, the new CICINTRV logic will bypass the PROC SORT since it's already sorted.) In the interim, you can override the _Wdddddd definition and send the un-sorted dataset to the PDB library, and then CICINTRV will use that dataset. Philosophically, I don't want you to have to manipulate the _W or _L macro names, just because they are messy to use, but they will always be there, so this fix will work - it's just not as pretty as simply adding the _Sdddddd macro(s) in EXPDBOUT! For example, you would add MACRO _WCICDS PDB.CICDS % in either member IMACKEEP or with %LET MACKEEP= logic. Additionally, member TYPS110 now invokes _S110 to sort all of the CICS Stat datasets, as it should have. See final revision in Change 16.266. Thanks to Jean Quinkert, Inland Steel, USA. Change 16.252 Six lines with pairs of 'DD'x (ASCII) or 'BD'x (EBCDIC) ANALBATW characters should have been pairs of exclamation points Yüklə 28,67 Mb. Dostları ilə paylaş:
|