* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
However, the architecture of each _Sdddddd macro would make this possible, so if this remains a problem for you, let's discuss this as a future enhancement.
be a real data loss, but that possibility was eliminated when there were no messages that CICS had suspended write to SMF. But to re-document what might happen: When CICS cannot send data to the SMF address space, you get "DFHMN0101 CICS COPYNAME SMF RC '0028'X" or "DFHST0103 CICS COPYNAME SMF RC '0028'X" messages on both SYSLOG and the JOBLOG of that CICS region. The MN message says CICSTRAN (subtype 1) records were lost, the ST message is for Statistics (subtype 2) records. This happens briefly when SMF Buffers are being expanded or when SMF SWITCH occurs (because both are serialized functions under the single SMF TCB). By scheduling the SMF dump/SWITCH away from the interval pop, its impact may be eliminated. By increasing the size of your SMF buffers with APAR OW12836 (increases minimum from 1MB to 8MB, which might eliminate the need for expansion; increases the maximum from 32MB to 128MB; and increases each increment from 1MB to 8MB so there are fewer buffer expansions and fewer exposures to data loss) you may be lucky and avoid the problem, until IBM responds to the SHARE requirement to fix this design! The only code change was an enhancement to the UCICSCNT program that counts CICS records by APPLID and type; a new reports details Statistics counts by STID and record so I could tell if stat data really was lost! Thanks to David Lyle, Total System Services, USA.
VMAC42 adds S42CVLUX to contain the 4-digit UCB address in MXG Oct 22, 1999 dataset TYPE42CV. The existing 3-digit S42CVLUA variable contains 'UCB' for any 4-digit UCB address! Change 17.277 Documentation only, no code was changed. TYPE94 data VMAC94 fields VMV/VPS/VPM/VPR/VMP/VBW/VBR/VTW/VTR will be zero, Oct 22, 1999 and fields VBA/VEC/VLA/VNM/VCA/VCZ will stop accumulate, if the screen on the PC that is attached to the VTS/ATL and that is collecting those physical back end activity counters is minimized! Discussions with IBM in progress. Change 17.276 New Format $MGTCPFM decodes the FTPDATFM data format FORMATS variable (ASCII/EBCDIC/IMAGE/DOUBLE-BYTE/UCS-2) values. VMACTCP Variable FTPDSNA2 is no longer kept in TYPETCPC dataset Oct 22, 1999 (FTP Client), as that field exists only in TYPETCPF (FTP Server), and was filled with hex trash. Thanks to Jason Cooley, CITICORP, USA. Change 17.275 Reading type 39 SMF records directly from VSAM SMF file VMAC39 failed because the calculation of offset for two optional Oct 21, 1999 triplets did not include (+OFFSMF). Thanks to Bruce Hudson, Payless Cashways, USA. Change 17.274 The symbolic &TAILOR and its //TAILOR DD were removed JCLTEST6 from the MXGSAS example JCL procedure, because in a few MXGSAS sites either SAS 180 errors or USER ABEND 2415 occurred Oct 20, 1999 due to (strange?) problems, and so I've decided that the optional tailoring library is more pain than value, as no one really used it anyhow! Thanks to Richard Phelps, Arizona State University, USA.
TYPETMS5 non-zero when BLKSIZE=0 because the two calculations in Oct 20, 1999 TYPETMS5 did not match the logic in VMACTMS5, so tests for BLKCNT GT 0 and BLKSIZE GT 0 AND RECFM conditions in VMACTMS5 were added to calculations in TYPETMS5. Thanks to Pat Moffett, CMX Group, USA. Thanks to Patsy Hildreth, CMX Group, USA.
VMACNSPY 3270 buckets instead of the LU6.2 buckets. It should be: Oct 20, 1999 OVRSPPC6=100-T1RSPPC6-T2RSPPC6-T3RSPPC6-T4RSPP6; Thanks to Julian Smailes, Experian Limited (UK), ENGLAND. Change 17.271 This utility was developed to show you how your IMACWORK UTILRMFI definitions cluster PERFGRP or SRVCLASS into the workload Oct 18, 1999 variables in RMFINTRV dataset. It shows where the type72 CPU times came from, using your IMACWORK, and it also reads type 30s to show SRVCLASS/RPTCLASS/JOB CPU times. The utility is needed when your RMFINTRV execution prints error messages that your workload definition CPU time does not match the true CPU time in SRVCLASS/PERFGRPS. Thanks to Chuck Hopf, MBNA, USA.
VMAC103 was created by Internet Connection Secure Server (R3,R2) Oct 18, 1999 and then by Lotus Domino Go Webserver for OS/390 (R4-R6), May 31, 2000 now named WebSphere Application Server OS/390 (R7-R8), (and now May, 2000 sub-titled HTTP Server Version 5.2), adds many new statistics, including five sets of avg/min max response times for DNS, Plugins, CGI, SSL, & Proxy, to subtype=2 record in dataset TYPE1032. Change 17.269 Long ago, when I observed that the total device pending VMAC74 time (PCTDVPND) was more than the sum of its two parts, Oct 18, 1999 Pend for Device (PCTPNDEV) plus Pend for CU (PCTPNCUB), Dec 16, 1999 I stored the difference as the Pend for Chan (PCTPNCHA). But when IBM added Pend for Director Port (PCTPNDIR), I did not treat that as a component of PCTPNCHA, and now I measure there still is a difference between the Total and its components, so I now: - Store Pend Dir Port into PCTPNCHA/DLYCHATM variables and changed their labels to be Chan Dir Port delay - Calculate the Other Pending PCTPNOTH/DLYOTHTM as PCTPNOTH = PCTDVPND - (PCTPNDEV+PCTPNCUB+ PCTPNDIR) Other Pend = Total - (Device + CU + Dir Port)
Total Pend Time (SMF70PND) of 28 seconds but Pending for Device component (SMF70DVB) was 37 seconds are written occasionally for devices simulated in an EMC box. The error causes PCTPNOTH to be negative (and, before this change, PCTPNCHA was also negative because it used to be the same as PCTPNOTH). We have also seen similar, but much smaller differences, for tape devices. Thanks to Robert Girard, EMC, USA.
VMACDCOL not in the KEEP= list for dataset DCOLBKUP. Now they are. Oct 18, 1999 Thanks to Alastair Gray, Philip Morris EDC, SWITZERLAND. Change 17.267 The VTS report program was corrected; while its example ANAL94 in comments worked fine, invoking %ANAL94(PDB=SMF); to Oct 13, 1999 read SMF to produce reports did not produce! Parameter REPORT=HOURLY is now the default, so that a report will now always be produced, plus other cleanup.
VMACHARB IF HH GE 0 AND MM GE 0 AND SS GE 0 THEN .... Oct 11, 1999 because the "GT" caused some missing timestamps. Nine flags, AXR0nFL1, are now formatted $HEX2. Thanks to Patsy Hildreth, CMX Group, USA.
VMXGSUM relocating the ALLVARS initialization higher up in the Oct 11, 1999 logic; it was bypassed when INCODE= was not used, and was blank when it should have had a list of variables. When &ALLVARS was blank, VMXGSUM generated code was PROC MEANS; VAR ; OUTPUT OUT=X SUM(A B C); (i.e., a VARIABLES statement with no variables). This PROC MEANS failed "NO ANALYSIS VARIABLES" with SAS V6, but under SAS Version 8, it ran just fine! Exactly why is under investigation; but I think it is enhancements SAS made under SAS V8: in this specific PROC MEANS invocation, a VAR statement is not needed because the SUM(A,B,C) syntax provides the names, so SAS V8 ignored the unneeded VAR statement? In any event, VMXGSUM now always populates ALLVAR with the list of variables so it won't be blank. ======Changes thru 17.264 were in MXG 17.07 dated Oct 8, 1999====== Change 17.264 The VMXGSUM of Change 17.255 was never put in MXG 17.07, VMXGSUM because it was not correct. MXG QA under SAS V8 had no XMXGSUM errors, so 17.07 was built, but final QA with SAS V6 Oct 8, 1999 found errors in VMXGSUM that were not caught by V8, so I removed VMXGSUM for the MXG 17.07. Note that 17.255 was reinstated by Change 17.265 in MXG 17.08.
EXTY1081 three new datasets from subtype 1 interval records: EXTY108P Dataset Description EXTY108T TYPE1081 Server Statistics IMAC108 TYPE108P Port Statistics TYPE108 TYPE108T Transaction Statistics TYPS108 Additional development work is ongoing by IBM so you can VMAC108 anticipate additional measurements for Domino soon. Oct 8, 1999 Domino Release R5.0 & R5.01 are supported by this change. The type 108 record originated with Lotus Notes Domino Server, and was primarily a mail server for Lotus Notes, but now the Lotus Domino Server provides services for Notes, and contains its own HTTP server & JAVA function. Note that the Websphere Application Server HTTP Server is the product that creates the SMF 103 record. Thanks to John Milne, Suncorp Metway, AUSTRALIA. Change 17.262 Revisions in DAILYDSN to use TYPSDCOL instead of TYPEDCOL DAILYDSN (so the PROC SORT and NODUP logic would be taken from the Oct 8, 1999 VMACDCOL instead of being coded in DAILYDSN) wrote the output to the //PDB instead of the expected //DATASETS. By inserting %VMXGINIT(DEFAULT=DATASETS); before the include of TYPSDCOL, the default PDB becomes DATASETS and DAILYDSN now works as it did previously. Thanks to Craig Gifford, City of Lincoln, USA. ======Changes thru 17.261 were in MXG 17.07 dated Oct 7, 1999====== Change 17.261 Unexpected Expiration date of 2099366 (also invalid, as VMACDCOL 2099 is not a leap year) was found, and caused missing Oct 7, 1999 value for DCDEXPDT/UMEXPDT. The logic was revised to add test (YREXPDT=199 AND DAYEXPDT GE 365) OR in two places so that the '31DEC2099' infinite MXG date is stored in DCDEXPDT or UMEXPDT. Thanks to Jens Mohring, HUK Coburg, GERMANY. Thanks to Harald Seifert, HUK Coburg, GERMANY. Change 17.260 NTSMF SQLServer Objects Cache Manager, Databases, Locks, VMACNTSM and User Settable were corrected (NRNAMES and/or NRDATA, Oct 5, 1999 and NRNAMES=NRNAMES-1 was added) and validated with data. Thanks to Leigh Ann Payne, Wachovia Operational Services, USA. Change 17.259 Landmark PTF TD01655 for TMON Version 2 added fields VMACTMV2 COMPATIBLY to the CI and JD records: Oct 5, 1999 -Variables CICSALUB,CIECSLUB added to TMVSCI dataset. -Variables (enclave CPU times) JDDECPU JDENCSU JDENCTR1 JDENCTR2 JDIECPU JDJDECPU JDJENCSU JDJIECPU JDSDECPU JDSENCSU JDSIECPU JDSWPRSN were added to TMVSJD dataset. -Variables JDOPRID JDOSTCK were added to TMVSJDOM dataset. Thanks to ???, IDUNA NOVA, ITALY.
TRNDUOW TREND.TRNDUOW.DATA DOES NOT EXIST because the statement Oct 4, 1999 OPTIONS NODSNFERR; should have been at the start of the TRNDUOW member. "No DSN Not Found" option protects the first-time execution of TRND members, but was left out of the TRNDUOW member. Thanks to Tom Marchant, Wayne State University, USA.
VMAC26J2
Oct 4, 1999 Thanks to Bruce Widlund, Merrill Consultants, USA. Change 17.256 This revision, used by UTILGETM, allows you to read an VMXGGETM SMF file and report on the contents by type, subtype, and Oct 4, 1999 system, using PROC TABULATE. If you specify SMFOUT= a null string, and specify FREQ=YES, the report is created. Thanks to Chuck Hopf, MBNA, USA.
VMXGSUM in VMXGSUM output, and detects execution under SAS V7/V8 Oct 6, 1999 so that the new INHERIT parameter in PROC MEANS can be used, which may eliminate the need for the final datastep (previously required to reset variable lengths). Thanks to Chuck Hopf, MBNA, USA. Change 17.254 A number of new timestamp fields from DB2 and CICS were IMACNORM added to the PDB.ASUMOW dataset. In addition, new member ASUMUOW IMACNORM is added to permit you to normalize the CPU time Oct 3, 1999 created in the PDB.ASUMUOW dataset, in case you have CICS Regions and/or DB2 Subsystems executing in machines of different speeds. IMACNORM is preliminary, and may be changed in the future, but it has no impact unless you change it, as IMACNORM now only contains commments. Thanks to Chuck Hopf, MBNA, USA.
VMAC102 DB2 trace records that contain variable length text. See Oct 3, 1999 Change 17.251 text. Both COMPRESS=YES and execution with SAS V7, V8, or later is required. -For trace subtypes 206, 208, and 236, if the message text was greater than 200 bytes, the first 200 bytes were not input, but now are. The first INPUT of QW0207HR was removed, as the second one, inside the test for length, was the correct one. See minor revision in Change 17.390. Thanks to Chuck Hopf, MBNA, USA.
ANALDATE was added by Change 17.168 now works; the debugging lines Oct 3, 1999 302 and 303 are now removed, and line 10 now has an ending */. Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
VMXGINIT of an MXG %INCLUDE SOURCLIB(TYPExxxx); program always Oct 2, 1999 went to //WORK, but with this change, the WORK= or USER= destination will be honored. Apr 5, 2000: The USER= or WORK= options must be specified on // EXEC SAS or on the SAS command; they are resolved when VMXGINIT executes at MXG startup, and cannot be changed later with an OPTIONS statement. -A new macro variable, SASCHRLN, is set to 32000 if SAS V7 or V8 is executed AND if COMPRESS=YES is turned on, but SASCHRLN=200 for V6 (and for V7, V8 with COMPRESS=NO).
variables in some specific cases: With the SAS character variable limit of 200 bytes, MXG datasets with long text strings (SQL text in DB2 trace averages 2000 bytes per statement) are output into many observations for each 200 bytes of text (and the fixed fields are many hundred repeated bytes!). Instead, now that variables can be 32000 bytes long, only one output observation is needed, and by using compression, only the actual data has to be stored, so the unused length won't actually take up any space, and you can get the effect if variable length text storage in SAS! Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
VMXGINIT Version Number that is printed in MXG messages and kept Oct 4, 1999 in dataset TYPE70. The MXGVERS value was kept in member VMXGINIT, but its value is now read from member AAAAAAAA used because it has always had the version and because it is never modified by user tailoring), so that now I can email you a change that includes an altered VMXGINIT member (two new macro variables are defined there for a new MXG dataset), but the MXG Version will be unchanged. Only when you install the full new MXG Version will the new number be seen. This had not caused any error nor had anyone noticed, but this seems more righteous. Change 17.249 New FORMAT MGKILO is created to print five-position FORMATS values with K/M/G/T/P suffix for Kilo/Mega/Giga factors Oct 2, 1999 (not 1024 byte-factors, but 1000 kilo-factors) for pretty printing of data with wide range of values compactly. It is not used in MXG Software, and will not replace MGBYTES format for true "mega-bytes" values, but if your manager demands that you use "million-byte" values to match the lies from your DASD vendor, you can use MGKILO in your reports to satisfy him/her, but I suggest you create a second variable and format it MGKILO and print both the MGBYTES and MGKILO values side-by-side, and use a LABEL to clearly identify which is which! Thanks to Alan Phelan, PKS Systems, USA.
VMAC115 SMF records adds new variables QISTMGET/QISTMPUT to the Oct 2, 1999 MQMMSGDM MQ Message Data Manager dataset. Previously reserved fields were used for the new data. Thanks to MP Welch, SPRINT, USA.
EX80ASEG (RACF or TOP SECRET) is added so that installation-unique VMAC80A RACFTYPE segments can be decoded external to the VMAC80A. Oct 2, 1999 Old-style macro _E80ASEG is defined so MACKEEP= logic can be used as an alternative to EDITing EX80ASEG. Thanks to Marc Matthys, Hudson Williams Europe, BELGIUM. Change 17.246 The subtype 3 TELEVIEW SMF record has four extra bytes VMACTELE inserted before the startup/shutdown times in the 4.3B Oct 2, 1999 release that is now supported. An additional internal TeleView error in the USERID field is corrected by their fix T19C017. Thanks to Tom Parquette, MONY Life Insurance Company, USA. Change 17.245 MXG 17.06 only. Change 17.213 typo caused VTS variables VMAC94 to have zero values, and ERROR.VMAC94.AUDITLEN INVALID Oct 1, 1999 messages printed. The line added by that change: IF SMF94XOF+SMF94VLN*SMF94XON-1 GT LENGTH THEN DO; should have been IF SMF94XOF+SMF94XLN*SMF94XON-1 GT LENGTH THEN DO; (and the SMF94VLN= in the following PUT statement should also have been SMF94XLN=). Thanks to Robert Carballo, WORLDSPAN, L.P. USA.
VMACDCOL because the test before the INPUT of DCAHURBC should have Oct 1, 1999 been GE 16 instead of GE 32, and the +16 after the INPUT of DCAHARBC should have been deleted. Thanks to Paul Naddeo, FISERV, USA. Thanks to Stewart Spyker, FISERV, USA. Change 17.243 The _BTY91xx By List macros and _STY91xx Sort macros are ANAL91 populated and will eliminate duplicate Batch Pipes SMF FORMATS records. The label for SMF91OW as changed from EMPTY to VMAC91 FULL, format $MG091XW was updated, and the new ANAL91 Oct 3, 1999 was intended to summarize TYPE91IC/TYPE91OC data to look for lost data as described in APAR PQ25641. However, as SMF91IEC/SMF91OEC are almost always zero (7 nonzero in 33,609 TYPE91IC obs, 3 nonzero in 23,570 TYPE91OC obs), ANAL91 is not much use (yet) in detecting that data loss. Also, type 91 is incomplete. These pipe criteria values (ALLOCSYNC,ALLOCNOW,FIT/FITDD,OPENSYNC,NOEOF,EOFREQUIRED, ERC,CLOSESYNC,TERMSYNC) are not reported in type 91s, nor are replacement values for WAITALLOC,WAITOPEN,IDLE,WAIT, WAITEOF,WAITCLOSE or WAITTERM reported when one of those values is overriden for a specific pipe connection. And the STEPNAME in TYPE91IC/TYPE91OC still does not match the SMF 30 record's STEPNAME for same job/step number! A new APAR PW31018 will correct some documentation for type 91 records, but a new ETR is still open on counts. Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA. Thanks to Chuck Hopf, MBNA, USA.
ASUMTALO one system whose last TYPETALO timestamp was on Aug 5th, Oct 1, 1999 (either that system went away, or the MXGTMNT monitor program that writes the SMF records was STOPped, or MXGTMNT was no longer automatically started at IPL, or MXGTMNT had shut itself down with an MXGTMNT message on SYSLOG, etc.) then PDB.ASUMTALO output had data only thru Aug 5, because the MXG SPIN logic in ASUMTALO put all of the TALO records for Aug 6-31 into the spin library!
Interval records (created just for this logic so that active allocations can be included) in TYPETALO input to get the timestamp of the last-complete-interval on each SYSTEM, and uses the minimum last-interval time across all SYSTEMs as the spin criteria: TYPETALO obs with timestamps greater than that criteria (both the TMNTTYPE=5 hourly and the TMNTTYPE=4 end-of-allocation event) go to SPIN.SPINTALO for tomorrow's ASUMTALO, because only records up thru the last complete interval from ALL systems can be used to count tape allocations when tape drives can be shared across systems. This SPIN logic works fine when you run ASUMTALO daily, (ASUMTALO is invoked by BUILDPDB), although if the last TYPETALO timestamp for one system is at 9:00am THU, the PDB.ASUMTALO built early Friday will contain data only up to 9:00am THU, but then the next day's PDB.ASUMTALO will have picked up the spun records, so PDB.ASUMTALO built early Saturday will contain 9:00am THU thru FRI end of day, so no data is really lost, but at most is delayed one day.
the ASUMTALO spin logic now calculates the delta between the minimums of each system last-complete-interval, and if there is more than 24 hours difference between systems, that execution of ASUMTALO will suspend the SPIN logic and will output all TYPETALO events in the input data. If you have missing data in PDB.ASUMTALO datasets that were created from multiple day's TYPETALO, you can delete the subtype 5 interval records and recreate ASUMTALO with: //PDB DD DSN=PDB.TO.BE.REPAIRED,DISP=OLD DATA PDB.TYPETALO; SET PDB.TYPETALO; IF TYPETMNT=5 THEN DELETE; %INCLUDE SOURCLIB(ASUMTALO); Deleting the subtype 5 interval records eliminates SPIN logic in ASUMTALO, so all dates will be output into the replacement PDB. The tail-end intervals will be missing in-flight tape allocations, but the real data will be correct. Note that if your PDB.ASUMTALO dataset is on tape, you cannot directly replace it, and would have to: //REALPDB DD DSN=REAL.PDB.ON.TAPE,DISP=OLD //TAPECOPY DD DSN=TEMPTAPE,DISP=(,DELETE,CATLG),UNIT=TAPE //PDB DD DSN=&&TEMPPDB,DISP=(,DELETE),UNIT=SYSDA, Yüklə 28,67 Mb. Dostları ilə paylaş:
|