* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
the new "exit" MXGSTNFX macro variable: %LET MXGSTNFX= %QUOTE( IF LPARNAME='EJQ1' THEN SMF70STN='EJQ1'; ELSE IF LPARNAME='EJQ2' THEN SMF70STN='EJQ2'; ); That statement can be put in "USERID.SOURCLIB(IMACKEEP)" so it is always used when TYPE70s are processed, or it can be the top of the SYSIN for a specific job. But it may not be required with the PARTISHN fix. Thanks to Jim Poletti, EdJones, USA. Change 34.166 Support for SMF Type 87 Subtype ENQ/DEQ records. EXTY8702 Code has been syntax checked, await subtype 2 records to VMAC87 validate the updated code. VMXGINIT
Jul 14, 2016 Change 34.165 -RMF Type 74 dataset TYPE74SL variable R748LFBC was input FORMATS as RB4. but it is a binary value, now input as PIB4. VMAC74 R748LFBC /*FI CHAN*BIT*ERROR*RATE*/ Jul 13, 2016 -Format MG0748L had value decimal 7 for 10GB Ethernet but that may have been a guess for the undocumented value that is now documented as 10x or 16 decimal. Thanks to Scott Barry, SBBWorks Inc., USA
VMACIDMS when you install IDMS PTF R084146)! There was no change Jul 13, 2016 in the V19 SMF record's format, but R084146 changed the value of SMFHDR to 1900, which caused this error message: UNKNOWN IDMS RECORD PMHRTYPE=201 FOUND AND SKIPPED. SMFHVER=1900 _N_=2 START COL=25 because MXG had one test for SMFHVER='1800' that needed to be changed to GE '1800' to read records with the PTF. Thanks to William Marshall, Ensono, USA.
EXT120BL created three new datasets: EXT120BC dddddd dataset description EXT120BU T120BL TYP120BL Liberty Server Request Network FORMATS T120BC TYP120BC Liberty Classify Segments VMAC120 T120BU TYP120BU Liberty User Segments VMXGINIT For the User segment, SM120BDH is $CHAR32 with $HEX64 Jul 13, 2016 format, and can be decoded in EXT120BU and _KT120BU can be tailored to add the new variables you created. Unfortunately, NONE of these new fields have IBM-provided field names; MXG had to create names beginning SM120Bxx to be somewhat consistent with previous IBM name choices. You will have to use the variable label to actually map back to the marginal documentation of these new records. -Subtype 11 datasets TYP12011 and TYP120BU both have zero observations now, with internal record version 2 records. Thanks to David Follis, IBM, USA Thanks to Steve McKee, FMR, USA. Change 34.162 Support for z/OS 2.2 JES2 8-character JOBCLAS8 variable, BUILD005 which is now added to the JES2 PDB.JOBS and PDB.STEPS VMAC26J2 datasets, so both the 1-char JOBCLASS and the 8-char Jul 11, 2016 JOBCLAS8 variables are kept. JOBCLAS8 variable has been Jul 24, 2016 kept in SMF 30s, from either JES2 or JES3, but TYPE26J2 Jul 29, 2016 is now updated to also keep JOBCLAS8 variable. Note that JES3 PDB.JOBS and PDB.STEPS, changes variable JOBCLASS to 8-characters. Jul 24: UNINIT JOBCLAS8 in SPIN.SPIN26J2 corrected. Jul 28: JOBCLAS8 added to TYPE26J2 dataset. Thanks to Jan Tielemans, KBC, BELGIUM.
VMAC116 in dataset MQMQUEUE were created from (only) subtype=2 Jul 11, 2016 records. IBM does NOT provide a GMT offset field in 116, but MXG heuristically created the offset value in the subtype 1 (where the WTASINTE interval end can be used with SMFTIME), but there is no similar end time field in subtype 2 records. Now, GMT116OFF is created and retained and used for subtype 2 records. The name was changed to not impact other SMF records with GMTOFF. -Missing values were created for variable WTASPRET for old WTASVER LT 8 records; the /4096 was always executed but is now only calculated for GE 8 records. Change 34.160 -VMXGALOC did not check for the valid YYMMDD format in the VMXGALOC DATEFMT= parameter and could then fail with an invalid Jul 11, 2016 format error. If you used YYMMDD6 or YYMMDD8 it worked. -VMXGALOC previously upcased directory names, anticipating possible name comparisons with upper case source text; this was fine for Windows, but only worked on Linux if the directory name was all upper case, because names on Linux are case-sensitive (i.e., directory A is NOT a). The upcase was removed, but on Linux you must use the exact casing of the directory name in your BASEDIR=. -The BASEDIR= directory must exist, or VMXGALOC will shut itself down, setting MXGRTRN to ABEND, and printing an additional message on Linux with the name you supplied to remind you casing is required there. Thanks to Joe Varkey, Verisk Analytics, USA.
ANALAVAI looking for a macro variable created by VMXGODSO, which Jul 11, 2016 was not executed. Now checks the value of ODSTYPE and if it is NO or NULL, suppresses VMXGODSC. Change 34.158 Cosmetic. If you specified BUILDPDB=NO, the display of UTILBLDP parameters you entered showed the internal default list Jul 11, 2016 MXGINCL of members to be included. Those members were NOT included with BUILDPDB=NO, but the displayed list was not accurate. Now only the USED (i.e., non-blank) members included are displayed on the log. Change 34.157 Support for SMF 117 IBM Integration Bus Version 10.0.0.5 VMAC117 which INCOMPATIBLY removed fields in the FLOW segment. Jul 10, 2016 But MXG didn't keep some identity variables from FLOW in the other three datasets. Previously known as Websphere Message Broker. Thanks to Betty Wong, Bank of America, USA. Change 34.156 RMF III NOTE: INVALID DATA FOR ASIQSCANxxxxx because some VMACRMFV variables with PIB informat were input with RB informat. Jul 10, 2016
IMACJBCK include the IMACJBCK Job Name Check macro that allows you VMAC42 to select observations to be output. IMACJBCK has been Jul 9, 2016 added for these TYPE42xx datasets: 4220/4221/422A/4222/ 4223/424A/4224/4225/4227/4237/42VS. In case you were not aware, these comments document IMACJBCK selection: SPECIFIC JOB CAN BE SELECTED. WHEN INVOKED, ALL OF THESE VARIABLES HAVE BEEN READ AND ARE VALID FOR TESTING: ID JOB READTIME SMFTIME SYSTEM NOT ALL RECORDS WITH JOB NAME HAVE A JESNR FIELD, BUT 6 25 26 30 32 42 59 91 RECORDS HAVE INPUT JESNR WHEN THIS EXIT IS INVOKED. FOR SMF 30 RECORDS, NRCPU=0 IF THIS IS A MULTIDD='Y' RECORD. AND %LET MACJBCK can be used instream. Thanks to Michael Oujesky, DTCC, USA.
BLDSMPDB function that should have been converted to UPCASE(). Jul 6, 2016 Thanks to Richard Krueger, Sentry, USA. Change 34.152 -DOW= filter was not working and all days of the week were ASMRMFV selected instead. Jul 5, 2016 -Message RMFV014W ALL DATA SETS BYPASSED was not shown when applicable. Thanks to Randy Hewitt, HPE Enterprise Services
VMXGSUM output dataset created but rather at an intermediate Jul 1, 2016 dataset created. Now when VMXGSUM is done SYSLAST is set to the output dataset created so that you can then do a PROC whatever without a dataset name.
FORMATS values of 4:ATOM and 5:JVMSERVER. Jun 30, 2016 Thanks to Wayne Bell, UNIGROUP, USA. Change 34.149 Reserved Change. Change 34.148 Support for ODM Version 8.8.0.1 SMF type 120 subtype 100 VMAC120 adds variables to TY120100 dataset: Jun 30, 2016 SM120RULEXETYP='RULESET*ENGINE*TYPE' SM120RULEXEVER='RULESET*ENGINE*VERSION' SM120RULEXFBOM='RULESET*IS*BOMS*SUPPORT*ENABLED?' SM120RULEXFDEB='RULESET*IS*DEBUG*ENABLED?' SM120RULEXFMON='RULESET*IS*MONITORING*ENABLED?' SM120RULEXFTRC='RULESET*IS*TRACE*ENABLED?' While the SMF 120 record is created by WebSphere, the subtype 100 was given to ODM and is not from WAS. Thanks to Paul Volpi, UHC, USA.
BUILD005 records that have no matching 30s nor 26s were left in VGETJESN SPIN.SPIN6 until SPINCNT expired when they were finally VMAC6 output to PDB.PRINT dataset. There are two types of Jun 28, 2016 PRINTWAY records. MXG decodes them setting variables BASIC: TYPETASK/SUBSYS/SUBSYS6 are set to 'TCP'. EXTENDED: TYPETASK/SUBSYS/SUBSYS6 are set to 'TCPE' and the logic in BUILDPDB outputs all 'TCP ' records to PDB.PRINT, while 'TCPE' records that didn't match today are held in SPIN.SPIN6 to match the other records from those jobs. Trivia: JCTJOBID for BASIC contains PSnnnnnn which is not documented and is different than PSFnnnnn for type 6 records created by PDF. Thanks to Paul Maradin, HP Advanced Solutions, USA. Thanks to Grayg Mitrou, HP Advanced Solutions, USA. Change 34.146 FORMATS MGSRDFC/M/G/S decode SRDCONST/MODE/GROUP/CONSI. FORMATS
VMACSRDF Jun 28, 2016 Thanks to Joseph J. Faska, DTCC, USA
VMAC102 input and kept in dataset T102S106. VMACDB2H -QWHSRELN value could be truncated and print 10.0999999. Jun 27, 2016 Now it is forced to print as 10.1. Jul 3, 2016 -QWPRRENAMETABLE decoded from QWP4MISB and kept. Thanks to Scott Barry, SBBWorks Inc., USA Thanks to Lai Fai Wong, Bank of America, USA.
VMXGRMFI actual impact; LENGTH was defined in R72HOUR but those VMXGSUM variables are not initialized until the MERGE RMF70HOUR. Jun 23, 2016 Relocated the LENGTH statement to eliminate messages. -VMXGSUM with NOSORT=YES printed note that MXGSUM2 could not be deleted, but it doesn't exist with that option, so also no actual impact. Note no longer printed.
VMACXAM zero because new SYTCUV segment also input CPUUTIL for Jun 21, 2016 each CPU and the last value was kept in XAMSYS. Now, from SUBSUM segment is renamed at input and renamed back at XAMSYS output. Thanks to Douglas C. Walter, CitiCorp, USA. Thanks to Brent Turner, Citigroup, USA.
VMXGRMFI variables created and could result in multiple length Jun 21, 2016 error messages when running TRNDRMFI.
VMXGSRCH
Jun 20, 2016 Change 34.140 Housekeeping. BUILD001 intentionally leaves all of the ANALID CICS Statistics Data Sets in //WORK after the SMF DATA ASUMTAPE step, so they are available to be copied by EXPDBOUT if BUIL3005 desired, and so that CICINTRV can be created in BUILD004, BUILD005 by VMXGCICI, but now those datasets are deleted after the PDBAUDIT PDB.CICINTRV has been created. Other members similarly SPUNJOBS left unneeded datasets in //WORK that are deleted now, to VMAC113 minimize the required disk space. VMAC73 VMAC74
VMACDB2 VMXGCICI
Jun 19, 2016 Change 34.139 The highest memory usage in BUILDPDB was in the VMXGSUM BUILD005 step that created INTVSIOS, but that dataset is already BUIL3005 sorted, so the option to use CLASSNWAY is suppressed and Jun 17, 2016 NOSORT=YES is specified to bypass the sort and PROC MEANS is executed with a BY statement which reduced memory from 242MB to 195MB, and now the DATA step is largest, also requiring 195MB for this tailored BUILDPDB execution.
TYPETMS5 period in byte 20 unless Site Tailoring for Multiple CA/1 Jun 16, 2016 catalogs was used (Change 27.111). Period is now gone. Thanks to Doug Medland, IBM Global Services, CANADA. Change 34.137 Major revision to VMXGSUM that could save CPU time. ASUMCACH This change creates a new parameter, CLASSNWAY with the VMXGINIT default value of &MXGSUMCLASS, which itself has default VMXGSUM value of blank, so that you can enable the new logic with Jun 17, 2016 only %LET MXGSUMCLASS=YES; in //SYSIN, which changes the current summarization logic to use the CLASS/NWAY feature of PROC MEANS, instead of the original default. -The default VMXGSUM logic can be a four step process with an optional DATA step created (if INCODE=, NORMx=, or INTERVAL=x arguments are used) to feed the PROC SORT that feeds the PROC MEANS which may be followed by another optional DATA step (if NORMx= or OUTCODE= are used). -The MXGSUMCLASS=YES revision alters the default logic to remove the SORT and instead invokes the CLASS and NWAY options on the PROC MEANS, which can greatly reduce the amount of CPU time consumed since the SORT is eliminated (in one simple test the zOS CPU time went from 68 seconds to 28 seconds! -But, it is VERY possible for the use of CLASS to require a significant increase in the virtual storage (REGION) required, in return for reduced CPU time. -The original MXG design was required because when first created, virtual memory was an extremely limited resource and the algorithm minimized memory required. But now, with memory no longer so restricted nor expensive, using MXGSUMCLASS option lets test and observe the trade off to see which options is of benefit to your invocation. -Executing MXG on z/OS using MXGSUMCLASS=YES: It is possible you could save some CPU time but the cost is an increase in high memory usage - more than doubled in some tests and the CPU time saved will be primarily in ASUM* TRND* ANAL* GRAF* members run after BUILDPDB (BUILD005 only has 3 VMXGSUMs, but VMXGCICI for PDB.CICINTRV has many that may or may not be helped.) MXGSUMCLASS=YES did fail once because the utility files used filled the //WORK space, so that specific case in ASUMCACH has disabled MXGSUMCLASS to circumvent. The amount of CPU time saved is a complex function of the complexity of the data - the number of OBS, BY groups, and count of intersects - each impact memory utilization so that you must test across several day's data since the results can vary from day to day as the complexity changes. -%LET MXGSUMCLASS=YES; applies to ALL VMXGSUM invocations after that statement in that job step. You can change any VMXGSUM invocation after that to revert to the original logic by adding CLASSNWAY=NO to that VMXGSUM invocation. -Executing on ASCII thus far has not shown a significant benefit with MXGSUMCLASS but 'your mileage may vary'. -These are test results from zOS running SAS 9.3 and using UTILBLDP with inclusion of many of the ASUMxxxx members, all of which are VMXGSUM invocations: %UTILBLDP(USERADD=42 6156,OUTFILE=INSTREAM,BUILDDB=YES); %INCLUDE INSTREAM; JOB CPU % CPU CPU CPU % CHG READING READING PROCESSING TEST TIME CPU DATA DATA DATA
CLASS USED 1:10:19.36 9.72 0:47:12.14 67.12 0:23:07.22 % CPU % CPU PROCESSING CHANGE TOTAL % CHANGE TOTAL TEST DATA PROCESSING EXCP EXCP IO TIME
CLASS USED 32.88 26.43 1199259 18.87 0:17:11.95 HIGH % CHANGE % CHANGE MEMORY HIGH TEST IO TIME USED MEMORY
CLASS USED 39.99 242M 13.38 And here are some further tests comparing BUILDPDB on zOS and Windows 10. The same input data was used in both but the DB2/CICS data was compressed so on zOS the CICS SMF INFILE exit was used but on Windows more CPU time was consumed to read the data. zOS is running SAS 9.3 and Win 10 is running 9.4. Test BUILDPDB Only zOS NWAY zOS BY Win NWAY Win BY Data step elapsed 0:10:35 0:10:59 0:07:07 0:07:03 Data step CPU 0:08:51 0:08:53 0:07:09 0:07:02 Data Step MAX K Memory 173496 173496 320388 320388 Job elapsed Time 0:14:30 0:14:54 0:08:35 0:08:32 Job CPU 0:11:25 0:11:30 0:08:13 0:08:08 Job MAX K High 173496 173500 449928 449928 Step with HIGH memory DATA STEP DATA STEP SORT SORT DB2ACCTP DB2ACCTP Test with ASUMs Win 10 NWAY Win 10 BY Data step elapsed 0:07:28 0:07:08 Data step CPU 0:07:15 0:07:09 Data Step MAX K Memory 320388 320388 Job elapsed Time 0:10:02 0:10:58 Job CPU 0:09:24 0:09:54 Job MAX K High 727880 449928 Step with HIGH memory ASUMCACH SORT DB2ACCTP DB2ACCTP
Thus far this applies only to zOS. There are no known exposures on ASCII. Members that have failed: BUILD005/BUIL3005 - automatically suppressed on zOS ASUMCACH - automatically suppressed on zOS ASUMCICS ASUMCICX
ASUMDB2A ASUMDB2P
1) UTILITY files fill up work and cannot expand 2) Memory failures as memory expands The problems will occur if you have many OBS (at least tens of millions possibly hundreds) and many BY groups which create a large number of intersections.
USERID.SOURCLIB. The simplest change is to add CLASSNWAY=NO to the parameter list of the VMXGSUM invocation. That will revert to the original logic for VMXGSUM of DATA STEP/SORT/MEANS/DATA STEP but also means you will not be saving any time. A more complex option is to modify the parameters. For each BY group MEANS must build a counter for each of the variables in any of the SUM MEANS MAX etc parameters. That can quickly add up to a lot of space. So you can either reduce the complexity by reducing the variables in the BY list or by reducing the number of variables being SUMMed MEAned MAXed etc. An example using ASUMCICX (only a partial copy): MACRO _BSUCICS APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME SYSTEM SHIFT % Are OPERATOR USER TERMINAL really necessary in your summarized data? In many cases TERMINAL is an IP address that is largely meaningless. OPERATOR and USER may be the same. Reducing the number of variables in the BY list can help. %VMXGSUM(INVOKEBY=ASUMCICX, KEEPALL=&KEEPALL, INDATA= _LSUUOW , OUTDATA= _LSUCICS , DSNLABEL=SUCICS: CICSTRAN &SUCIINTV SUMMARY, DATETIME=STRTTIME, SUMBY= _BSUCICS , DURATM =INTERVAL, INTERVAL=&SUCIINTV, SYNC59=NO, NEWSHIFT=Y, MAX= RESPMAX, SUM= DSPDIOCN DSPDIOTM FCAMCNT IRESPTM RESPBKT1-RESPBKT8 TASCPUTM TRMCHRCN WTDISPCN WTDISPTM WTFCIOCN WTFCIOTM WTIRIOCN WTIRIOTM WTJCIOCN WTJCIOTM WTRLIOCN WTRLIOTM WTTDIOCN WTTDIOTM WTTSIOCN WTTSIOTM SSQELAP CPUTM CLASS3TM CLASS3WT DB2CONCN DB2CONTM DB2IDLE DB2RDYCN DB2RDYTM DB2REQCT DB2SRBTM DB2TCBTM DB2TRAN DB2WAICN DB2WAITM MROTRAN,
variables? If not eliminate those variables. Do any of your CICS transactions use DB2? If not eliminate the DB2 variables.
zOS with these members is reducing the complexity. Change 34.136 Support for up to six USERCHAR fields, and revisions UTILEXCL to support USER fields that are in the middle of the IMACIC3U segment, which were not correctly handled. IMACIC4U
IMACIC5U IMACIC6U
IMACIC3D IMACIC4D
IMACIC5D IMACIC6D
Jun 8, 2016 Change 34.135 Additional Q8ST variables are INPUT if they exist: VMACDB2 Q8STINSC='INSERT*STATEMENTS*SENT TO*IDAA FROM DB2' Jun 7, 2016 Q8STUPDC='UPDATE*STATEMENTS*SENT TO*IDAA FROM DB2' Q8STDELC='DELETE*STATEMENTS*SENT TO*IDAA FROM DB2' Q8STDRPC='DROP*STATEMENTS*SENT TO*IDAA FROM DB2' Q8STCRTC='CREATE*STATEMENTS*SENT TO*IDAA FROM DB2' Q8STCMTC='COMMIT*STATEMENTS*SENT TO*IDAA FROM DB2' Q8STRBKC='ROLLBACK*STATEMENTS*SENT TO*IDAA FROM DB2' Q8STOPNC='OPEN*STATEMENTS*SENT TO*IDAA FROM DB2'
VMXGCOPY to one output Data Library with member selection, etc. Jun 7, 2016 If your parameters were lower case nothing was found to copy since the values passed back for LIBNAME and MEMNAME are uppercase and the compare was always false. To make it worse it also failed with a bad macro variable name reference because the variable was not constructed when nothing was found. Thanks to Tim Hare, Southwood Shared Resource Center, USA.
ASMRMFV improved MXG00 table data, and other minor enhancements. ADOCRMFV -The GMT offset feature scales RMF MONITOR III Sample Set JCLCRMFV begin (SSHTIBEG) and end (SSHTIEND) timestamps to a JCLDRMFV common user specified GMT time offset ranging from -12 to JCLRMFV +12 hours or -720 minutes to +720 minutes. VMACRMFV IMPORTANT: This support does NOT modify any timestamps Jun 11, 2016 in the output RMFBSAM file. The SSHTIBEG and SSHTIEND time stamps are modified temporarily ONLY during the FROMDATE=/TODATE= FROMDATE=/TODATE= filter processing. -The purpose of the support is to allow an installation to input RMF III data sets from different time zones and build a PDB with data relative to a specific time zone. -Although GMT (Greenwich Mean Time) is technically an obsolete term replaced by the modern UTC (Coordinated Universal Time) term, GMT still appears extensively in RMF documentation and within MXG itself. So the term GMT is still used for historical consistency. -The new ASMRMFV keyword to specify a GMT offset is GMTOFFSET=. Aliases are GMTOFF=, GMT=, GMTOFFSET, GMTOFF, and GMT. -When the '=' is missing then GMTOFFSET=0 is implied. The '=' is required to specify a non-zero GMT offset value. -Any of the following formats are supported for GMTOFFSET= (and aliases GMTOFF=,GMT=) :
hh -hh +hh hH -hH +hH hhH -hhH +hhH where h ranges from 0 to 9 and hh from 00 to 12. Values over 12 are flagged as errors and will abend ASMRMFV. An Yüklə 28,67 Mb. Dostları ilə paylaş:
|