* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
- For MXG under ITSV: no impact; ITSV has always used COMPRESS=YES default option. - Reversible; just specify OPTIONS COMPRESS=NO; as your first statement in the //SYSIN stream. Those benefits far outweigh the only possible negative: a moderate increase in CPU time on old CMOS pre-G6 CPUs. The savings in human intervention alone is worth the very small increase in CPU time of your MXG jobs. Benchmarks in Newsletter FORTY justify this change. -All CONFIGs now have OPTION SOURCE, so that the SAS code statements in your //SYSIN stream will be printed on the SAS log (so I can figure out what program you are running if you have a problem).
FORMATS with several new variables in TYPERMDS, and new Sign On VMACRMDS and Sign Off RMDSORG=4 RMDSACT=U/X events with no new Jan 28, 2002 data fields. FORMATS was updated for RMDSORG values. Thanks to Bruno Peeters, Dexia Bank, BELGIUM.
ANALAVAI a/k/a PDB.SMFINTRV data from type 30 interval records. Jan 27, 2002 Thanks to Chuck Hopf, MBNA, USA, Change 19.276 NTSMF object MSEXCHANGE DS has two added fields: VMACNTSM MSEXCMTA='MSEXCHANGE*MTA' Jan 27, 2002 ABANRRRT='AB*ANR*PER SEC' Thanks to Terry Heim, ECOLAB, USA. Change 19.275 Support for NDM Connect Direct for OS/390 CPU time that VMACNDM was added to the end of PT, CT and RT statistics record. Jan 27, 2002 MXG variable NDMCPUTM now exists in those datasets, and will be non-missing if the extra field is found. Thanks to John Rivera, (i)Structure, Inc, USA.
VMACDB2 changed when BPHITRAT in DB2STATB was, by Change 17.338. Jan 26, 2002 Now all Buffer Hit Ratios use that same equation. Thanks to Helmut Roese, COM Software GmbH, GERMANY. Change 19.273 IMACEXCL now defines MACRO _CICXC22 for CICS/TS 2.2, if IMACEXCL your CICS guru has excluded CICSTRAN fields from the SMF VMAC110 type 110 subtype 1 record. Jan 24, 2002 Change 19.272 The default stored length of numeric variables is changed VMACmanymany from 4 bytes for most and 8 bytes for MGBYTES-formatted Jan 24, 2002 memory variables, to 5 bytes for most, and 5 bytes for Jan 28, 2002 memory, on EBCDIC, and to 6 bytes for both under ASCII. Two macro variables were created so you can change either default back; %LET MXGLEN=4; for most numerics, and with %LET MXGBYLEN=8; the variables will be their original stored lengths. MXGLEN=5 ON EBCDIC MXGLEN=6 ON ASCII. MXG Newsletter FORTY, SAS Techical Note 2 documented the truncation of up to 255 counts when a large-value 4-byte binary input field is stored in 4 bytes (floating point). It was SAS's original choice of using floating point that made SAS shine in 1972; other programs used integer values in fixed length fields, and truncated the high-order digits with large values! Using FP keeps track of the decimal point, avoiding errors! All LENGTH DEFAULT=4 are now LENGTH DEFAULT=&MXGLEN, and all variables with MGBYTES format lengths are now set with &MXGBYLN instead of ' 8 ' bytes.
initialized, but can be changed in your //SYSIN code or in IMACKEEP with %LET MXGLEN=4; %LET MXBYLN=8; to restore the pre-MXG 19.10 default values. There is only one exposure when I change variable length: If you use your own PROC APPEND, you must make certain that it uses the FORCE operand, which has always been an MXG reconnendation, so that datasets with dissimilar attributes can be concatenated. The only use of PROC APPEND in MXG is optional in the VMXG2DTE member, which has always specified FORCE.
it was DB2 Statistics records, which contain accumulated counters, that precipitated the change, which was not needed until now (because DB2 and OS/390 used to crash before the counters got this large: QB2TGET=301,219,072). Two adjacent intervals with truncated large values with a delta less than 255 resulted in a zero delta value.
accumulated and could get "big" enough now, but that is both human-intensive and high-exposure-to-missing-one; the real exposure should never have existed, and the default length of 5 for a PIB4 has absolutely integrity. Historical choice of 4 versus 5. In early 70s, sorts with SYNCSORT failed when lengths other than 4 or 8 were used; SYNCSORT thought only FORTRAN *4 and *8 FP could exist. Old memories of 3am ABENDS remain strong! But MXG has had length 3, 5, and 6 for sometime, so I now deem it completely safe to use! Datetimestamp variables are still kept in 8 bytes stored length, as are a few other variables that need the full resolution possible (like SERVUNIT, which may be used directly for billing, and there, pennies ARE important!).
and 19.09 showed many variables are slightly larger now than before, but the magnitude of the difference is very small; a 60 minute time value was 0.006 seconds larger. But PROC COMPARE will not show exact values before and after MXG 19.10. The net impact of changing the default stored lengths on the size of the //WORK space and the //PDB libraries, as usual, depends! It depends on how many numeric variables were increased from 4 to 5, and how many were reduced from 8 to 5, in the datasets that interest you.
now, there is NO increase in the disk space required. Without compression, the storage increase depends on how many records of what type you keep, but here are a two examples of what we have measured with MVS defaults:
datasets; PDB increased from 350MB to 390MB, 11%. b. A 456 MB all-record SMF file, 30 RMF intervals, full PDB increased from 316MB to 356MB, 12% increase. c. Chuck's big 1160 Cyl PDB increased by 30 Cyl, 3%.
for a big job like BUILDPDB. Chuck's Total Memory went from 69MB to 71MB, but that 2MB increase did cause one one site to fail with an out-of-memory error: viloada: autoload failed for module SASXKRN2 because they were limited to 64M by their defaults: In V6: set by the MEMSIZE=64M default in CONFIGV6. In V8: Do not have MEMSIZE in CONFIG, use REGION=80M You should compare the Total Memory used reported on the SAS log, or in the IEF374I message on the job's SYSLOG, with your REGION= parm to make sure you have VS left! -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I. Thanks to M.J.H. Elbersen, Rabobank, THE NETHERLANDS. Thanks to F. Nijdam, Rabobank, THE NETHERLANDS. Change 19.271 This conversion utility, used to convert $HEX FORMATed UTILCVRT character variables in PDB libraries moved from EBCDIC Jan 23, 2002 to ASCII platforms (if you move your MXG processing from MVS to PCs/unix, you'll copy your historical PDBs), never did work right, but it now works as designed. CPORT/EXPORT changes all characters variables values, like '40'x EBCDIC to '20'x ASCII, during download, but we need the original '40'x value so bit tests work and so that the CPU Model is '9672'x and not '96B7'x. The 1994 iteration used $EBCDIC, but Change 19.163 shows that won't work. Instead, UTILCVRT now uses the $MGAS2EB mapping ASCII-2-EBCDIC, defined in member FORMATS, and selects variables with FORMAT=:'$HEX', no longer using the original and 'not happening' INFORMAT=:'NOTRAN' test. Of course, this conversion works only if the table that SAS uses in your country matches that format; some sites may find it necessary to edit the $MGAS2EB format into the IMACFMTS tailoring member to match your tran table. But any MXG datasets that you create under ASCII, reading SMF,etc, data, are correct and do not need UTILCVRT. Thanks to Mark Darvodelsky, Royal Sun, Australia
VMAC71 frames, CSFRLSAV and ESFRLSAV were found to be negative Jan 22, 2002 CSTORE=1040MB,CSFRTOAV=920,CSFRFXAV=142==>CSFRLSAV=-4MB which printed as -42E5. The problem is subtracting two average values on a system with essentially no logical swapping, the "zero" is slightly negative. I now test the calculation, and when negative, the variable is set to a missing value, so that a real zero value would still be preserved as a zero value, but these negative values will just be missing. Thanks to Kenneth D. Jones, xwave, CANADA.
BUILD005 added to the type 30 subtype 1 (job initiate) record when BUIL3005 you install the Assembly code in SMF exit IEFU84 that IEFU84 will move those values into the subtype 1 record. VMAC30 -This change creates and keeps those two new variables in Jan 23, 2002 dataset TYPE30_1, and updated BUILDPDB logic to add them Jun 24, 2004 to the PDB.JOBS dataset as well. The variables will be missing/blank if the SMF exit has not been installed. Jun 24, 2004: The IEFU84 exit code member was added by MXG Change 22.136; the original IEFU83 references were wrong, as it is IEFU84, not IEFU83, that writes the SMF 30 subtype 1 SMF record. Text was changed from 83 to 84. -The SMF exit IEFU84 source code is in member IEFU84, along with notes, so your SYSPROG can see what it does. The exit moves the initiator number (in binary) into the first four bytes of PROGRAM (SMF30PGM) name field, and the initiator name (character) into the second four bytes of PROGRAM name. SMF30PGM is not populated at job initiate since PROGRAM doesn't exist until after the step initiates. -However, it is your System Programmer's responsibility to install and test any SMF exit, and thus your company, and not Merrill Consultants, must take all risk in choosing to adapt this enhancement SMF exit into your systems: recognize that the risk with an SMF exit-in-error could be as bad as a system outage. I would not provide this example if I did not think it is safe, and almost every MVS site uses an SMF exit, but you should read up on SMF exits in the SMF manual before you convince your friendly SysProg to install the exit. Remind them that the exit will let you to help them track which job us which initiator, to help in chasing ABENDS with overlaid initiators, or in measuring which init is used how often, etc. This exit is provided because IBM does not currently provide this information in their SMF type 30 record. I have provided them with the tested exit code in the hope that they will eventually add the fields so that you don't have to install an SMF exit to get them.
precipitated this change, but the guys who suggested and coded the solution, respectively, get the CodeShark cite! Thanks to Mike Shaw, MVS QuickRef/Chicago Soft, USA. Change 19.268 Under very strange circumstances: when %LET MACKEEP= was VMXGDEL used to redefine an old style macro that contained an VMXGOPTR %VMXGDEL(DDDDDD=dddddd) invocation, the internal call to VMXGSUM %VMXGOPTR by VMXGDEL generated this error message: Jan 23, 2002 ERROR 14-12: Invalid option OBS=;; for SAS option OBS. Jan 26, 2002 VMXGOPTR was needed by VMXGDEL solely because PROC SQL doesn't execute if OBS=0, but PROC SQL/VTABLE had to run in VMXGDEL (even when OBS=0 was specified) to populate macro variables, and OBS=0 is commonly set for testing. We had used VMXGOPTR to store the old OBS=value, set it to OBS=MAX (so PROC SQL would execute), and then restore the original OBS= value, all inside VMXGDEL. But when we could not diagnose this particular macro error, Rick Langston at SAS showed us the GETOPTION() function, which allowed us to remove the PROC SQL/VTABLE in both VMXGDEL and in VMXGOPTR, with a cleaner, safer approach. The GETOPTION() function can be used in two ways: - DATA step solution: %GLOBAL OBSVALUE; DATA;CALL SYMPUT("OBSVALUE",GETOPTION("OBS"));RUN; - pure macro solution: %MACRO GETOBS; %GLOBAL OBSVALUE; %LET OBSVALUE=%SYSFUNC(GETOPTIONS(OBS)); %MEND GETOBS; %GETOBS;
We chose the pure macro solution in VMXGDEL and VMXGOPTR. We also changed the design of VMXGOPTR so that it resets the option value to what it was in the prior VMXGOPTR execution; the original design kept the value of the option only from the very first invocation of VMXGOPTR, and did not recognize if you changed the option between paired invocations of VMXGOPTR. See comments in VMXGOPTR. -In QA tests of these VMXGOPTR and VMXGDEL changes, Bruce set OPTION OBS=10, and found two places inside VMXGSUM where we had failed to use %VMXGOPTR to protect for user change of OBS=; VMXGSUM was corrected to now protect. With OBS=11, this error would not have been corrected! Thanks to Bruce Widlund, Merrill Consultants, USA. Thanks to Rick Langston, SAS Institute, USA. Thanks to Rosalind Howe, IBM Global Services, USA.
EXT11901 Communications Server, which replaces the SMF 118 record EXT11902 from the current IBM TCP/IP product. The data content is EXT11903 significantly enhanced beyond what is in the current 111, EXT11905 with many new subtypes and these datasets created: EXT11906
EXT119A7 SUBTYPE DATASET description EXT119B7 1 TYP11901 TCP CONNECTION INITIATION EXT11908 2 TYP11902 TCP CONNECTION TERMINATON EXT11910 3 TYP11903 FTP CLIENT TRANSFER COMPLETION EXT11920 5 TYP11905 TCP/IP STATISTICS EXT11921 6 TYP11906 INTERFACE STATISTICS EXT11922 7 TYP119A7 SERVER PORT STATISTICS - TCP EXT11923 7 TYP119B7 SERVER PORT STATISTICS - UDP EXT11970 8 TYP11908 TCP/IP STACK START/STOP EXT11972 10 TYP11910 UDP SOCKET CLOSE FORMATS 20 TYP11920 TN3270 SERVER SNA SESSION INIT IMAC119 21 TYP11921 TN3270 SERVER SNA SESSION TERM TYPE119 22 TYP11922 TSO TELNET CLIENT CONNECTION INIT TYPS119 23 TYP11923 TSO TELNET CLIENT CONNECTION TERM VMAC119 70 TYP11970 FTP SERVER TRANSFER COMPLETION VMXGINIT 72 TYP11972 FTP SERVER LOGIN FAILURE Jan 18, 2002
VMACEDGR did not know that, and character data caused a non-fatal Jan 16, 2002 INVALID DATA FOR RVSTBIN message. New variable RVSTBINC is now Character; RVSTBIN is still numeric, but missing value now if RVSTBINC has non-numeric characters. Thanks to Joe Ellis, American Century, USA. Change 19.265 Dataset STCHSC has zero observations, because STK changed VMACSTC the length of the record; long ago MXG had to protect for Jan 16, 2002 records shorter than the then-written 140 bytes, but now their subtype=7 record is only 120 bytes. Logic revised. Thanks to Fraser Wong, CitiCorp, USA.
FORMATS missing; MXG tested NRPDTYP=1 for Cisco, but the records VMAC28 contained NRPDTYP=0, so nothing was input. Now, the test Jan 14, 2002 is for NRPRTYP=2 (Record Type, not Data Type) for the Jan 16, 2002 Memory Pool data. IBM lists two other NRPRTYP values of NRPRTYP=1 - CPU and Memory NRPRTYP=3 - Interface but does not document the contents of the NRP segment for those (as yet) unsupported values. Variables NRPRTYP and NRPDTYP are now kept in NPMINNRP so you can see if any of the new Record Types are in your SMF data; contact MXG support when you find any, so we can decode them! New format MG028PT decodes Cisco pool type variables NRPCPTYP and LNCDCPTY: 1='1 PROCESSOR MEMORY 4='1:FAST MEMORY' 2='1:I/O MEMORY' 5='1:MULTIBUS MEMORY' 3='1:PCI MEMORY' Jan 24: IBM APAR OW53087 documents that the DTYP=0 in the NRP and NRT segments is now a reserved field, but that APAR does not document the RTYP=1 and RTYP=3 data. Feb 15: IBM will correct OW53087. The xxxRTYP field has only one value in each record: NRPRTYP==2 NRT=1 NIT=3, so there are no undocumented segments, and the misleading documentation will be revised by IBM. See Change 20.003. Thanks to Howard Swift, HSBC Bank, UK. Thanks to John Wilmot, HSBC Bank, UK.
VMACDB2 were defined as blank, to prevent an accidental sort of Jan 14, 2002 that potentially large dataset, but since the _SDB2ACC reference in _SDB2 is commented out, both macros are now defined, in case you do need to sort and remove dupes from your DB2ACCT dataset. Thanks to Rosalind E. Howe, IBM Global Services - South, USA.
ANALQAPM Monitor data. Jan 11, 2002 Thanks to Stephen Hoar, TSB, ENGLAND Change 19.261 Support for IBM AIX Performance Toolbox and Performance ADOCAIX AIDE for POWER, PTX Version 2, refs: SG24-2011-00. EXAIXPTX This internal design is extremely robust, and is similar IMACAIX to the new WebLog support; the list of fields in your TYPEAIX data is read and used to input the record, so you can TYPSAIX have different sets of fields defined for different AIX VMACAIX servers, and the one MXG program will work on all their VMXGINIT data, transparently. Jan 15, 2002 This implementation supports the default set of 55 fields Jan 17, 2002 and the heavy work is done; expansion to keep any of the other 2000 possible fields is easy, when anyone actually has actually created those additional fields! Thanks to Glenn Bowman, Wakefern, USA. Thanks to Al Sias, Wakefern, USA. Change 19.260 New optional design will change timezones of all datetime TIMEBILD variables read from SMF records, based on a table lookup TIMETABL of SYSTEM/SYSPLEX/datetime-range in which you set the VMACmanymany offset to be added to all datetime variables. VMXGTIME This is needed when you have SYSTEMs with different time Jan 11, 2002 zones, so you can have a common timezone for analysis of Jan 15, 2002 shared dasd, time of day, etc. Jan 26, 2002 The table is defined in member TIMETABL (copied into your USERID.SOURCLIB tailoring library) with a syntax of: SYSA 01/01/2002 00:00:00 01/31/2999 23:59:59 -21600 to change SYSA datetimes back 6 hours, for a datetime range from now until infinity.
nothing happens until you enable time change with this statement in your //SYSIN stream:
reads the TIMETABL member with the TIMEBILD program that creates the (temporary) format $MGTMPTM that is the look up table that is used by %VMXGTIME. The default table is the TIMETABL member in your SOURCLIB concatenation, but you can use %TIMEBLD(TIMETABL=XYZ); to use a different time change table; see its comments.
only exists in some records, so it is really there only for future selection. Only in the case where you know that all records you want to change (RMF is the only one at present) contain SYSPLEX, then and only then could you have a value for SYSPLEX in the TIMETABL, and you could not then use that same TIMETABL to select TYPE1415 data that does not contain a SYSPLEX variable. To make the actual time change itself, this statement %VMXGTIME(var1 var2 var3,system,sysplex); was inserted in the correct place in every VMACxxxx member that creates datetime variables from SMF records. All MXG members that process IBM or User SMF records have been updated, as were most other products that contain a SYSTEM variable. Some non-SMF products that do not have a "SYSTEM" field were set aside until a need arises. VMXGTIME statements were inserted 874 places in 380 MXG members, listing 1,300 variables that can be changed in 'one felt swoop': update TIMETABL, invoke %TIMEBILD.
and memory cost measurements in Change 19.286/MXG 19.11. Change 19.259 The MXGTMNT Tape Mount and Tape Allocation Monitor SMF ASMTAPES record had the wrong DDNAME if the tape UCB was a 4-digit VMACTMNT address (the incorrect DDNAME was the last DDNAME in the JAN 20, 2002 TIOT). The previous logic compared UCB address to get the the correct DDNAME; this revision compares device numbers for the UCBs, so this logic will work regardless of whether the tape UCB address is above or below the 16MB line, or 3 or 4-digit device address. The revision also gets the correct DSAB allocation flags for tape mounts.
SysProg must re-assemble ASMTAPES and link edit the new MXGTMNT program that is executed by your MXGTMNT started task that writes the SMF records, to get the corrected DDNAME into those SMF records, but you don't need to do anything to your daily MXG SMF processing jobs; they will get the correct DDNAME without any change. Only if you want the new DSABFLAG variable (which is not currently used by MXG) in your TYPETMNT dataset, will you need to use the revised VMACTMNT member. Thanks to Chuck Hopf, MBNA, USA. Thanks to Jim Sherman, FDC, USA. Change 19.258 Variable XCPUFLAG is now formatted with new $MGXCMCP FORMATS format to decode the CPU type of the ftp transfer, and VMACXCOM the list of old and new values for XCPUFLAG in ADOCXCOM Jan 9, 2002 was updated with the new values. Thanks to Tony P. Steward, Post Office, ENGLAND.
ANAL16
ANAL30 Program ANAL16 reads SMF to create TYPE16 (sort) obs for Jan 8, 2002 selected sorts (in this example, those with concatenated Jan 15, 2002 SORTIN datasets, because only the first DSNAME is in the Yüklə 28,67 Mb. Dostları ilə paylaş:
|