* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
IMAC103 TY130D TYPE130D HTTP PROCESS Thread Statistics VMAC103 TY130E TYPE130E HTTP LOGGING REQUEST/RESPONSE VMXGINIT The T103ELAP elapsed time units are not documented. Aug 27, 2014 -APAR PI24782 reports subtype 14s are only written when SMFLogDebug ON has been specified. Thanks to Dave Moreau, Royal Bank of Canada, CANADA.
VMACNDM NDMRTSID='SUBMITTER*JCTJOBID' Aug 27, 2014 NDMRTSUB='SUBMITTER*JOB*NAME' NDMRTCP0='RUN-TASK*CPU TIME*ON CP' NDMRTCP1='RUN-TASK*CPU TIME*ON ZIIP' NDMRTCP2='ZIIP*QUALIFIED*PART OF*NDMRTCP0' Dataset NDMDT variables were removed that shouldn't have been kept in that dataset, listed in comments in KEEP. Thanks to Michael Oujesky, DTCC, USA.
FORMATS in PROC CHART is harmless and does NOT set a return code. Aug 26, 2014 Format MG116TY for QWHCXTYP had one 18-character value, but this PROC CHART decided it needed some of that space for other things. But that format value was reduced to 16 characters so this error should not reoccur. Change 32.206 PDBAUDIT code can set Return Code 4 due to this message: PDBAUDIT "WARNING: Multiple lengths specified for the variable Aug 26, 2014 MEMLABEL by input data set(s). This can cause truncation of data." but the message makes no sense; it is in a single data step: DATA PDBAUDIT; LENGTH MEMLABEL $64; SET CONTENTS; where CONTENTS was created from DICTIONARY.TABLES. Removing that LENGTH statement from this step and adding it in a subsequent new step to reset the MEMLABEL length eliminates the warning and creates expected lengths. Thanks to Robert B. Richards, OPM, USA.
VMAC50 SMF 50 VERSN50 04 new variables kept in TYPE50: Aug 25, 2014 INBDNLPS='INBOUND*NLPS*INLP' OUBDNLPS='OUTBOUND*NLPS*ONLP' BYINNLPS='BYTES READ*FROM*INBOUND*NLPS*BFNLP' SMF 50 VERSN50 02 new variables kept in TYPE50: TY50SBCO='OSA-EXPRESS*SBAL*COUNT*OVERFLOW*READ Q' TY50SBCT='OSA-EXPRESS*SBAL*COUNT*READ Q' TY50EICO='OSA-EXPRESS*EARLY*INTER*OFLOW*COUNT READ Q' TY50EICT='OSA-EXPRESS*EARLY*INTERRUPT*COUNT READ Q' TY50E2CO='OSA-EXPRESS*EARLY*II INT OFLO*COUNT READ Q' TY50E2CT='OSA-EXPRESS*EARLY*II INTERRUP*COUNT READ Q' TY50PKCO='OSA-EXPRESS*PACKET*COUNT*OVERFLOW READ Q' TY50PKCT='OSA-EXPRESS*PACKET*COUNT*READ Q' TY50ACCO='OSA-EXPRESS*ACCEL*PKTCNT*OVERFLO*READ Q' TY50ACCT='OSA-EXPRESS*ACCEL*PACKETCOUNT*READ Q' TY50ACBO='OSA-EXPRESS*ACCEL*BYTE*OVERFLOW*READ Q' TY50ACBT='OSA-EXPRESS*ACCEL*BYTE READ Q' TY50NVCO='OSA-EXPRESS*INVALID*FRAME*OFLOW*READ Q' TY50NVCT='OSA-EXPRESS*INVALID*FRAME*READ Q' TY50RDQN='OSA-EXPRESS*READ*QUEUE*NAME' -The record LENGTH is stored into LENTYP50 to identify the old 262 byte or new 274 byte record.
VMAC119 length in the IP Programmers Guide and Reference was 8 Aug 24, 2014 which MXG used, but the offset of the next field was only 4 bytes, and SYS1.MACLIB(EZASMF77) had length 4, which was confirmed by IBM Support, so these fields are now correctly all input as length 4: SMF119ML_HC_JESDPERC &PIB.4. /*PCT JES DEST TASKS BUSY*/ SMF119ML_HC_JESWUSED &PIB.4. /*JES WRITER TASKS BUSY*/ SMF119ML_HC_JESWPERC &PIB.4. /*PCT JES WRITER TASKS BUSY*/ SMF119ML_HC_MDIRPFREE &PIB.4./*PCT FS SPACE FREE SYSWIDE EXTRTY*/ SMF119ML_HC_MDIRPUSED &PIB.4./*PCT FS SPACE USED SYSWIDE*/ Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA. Change 32.203 32.08 Only: two errors related to %ANALID / BUILDPDB: ANALID ERROR: DATASET NOPRINT NOT FOUND ONLYJOBS ERROR: THE REQUESTED TYPE OF VIEW (INPUT OR OUTPUT) Aug 26, 2014 were corrected by this change in MXG 32.09, or they can be circumvented with 32.08 by inserting in your //SYSIN: %LET VMVMACID=; -UTILBLDP with USERADD=ID that also had %ANALID statement got ERROR: DATASET NOPRINT NOT FOUND because a second execution of ANALID was not expected. The ONLYJOBS invokes UTILBLDP, but it already had a %ANALID statement, but Change 32.192 to UTILBLDP inserted a %ANALID execution when USERADD=ID was specified, causing the second execution. The %ANALID; statement is removed from ONLYJOBS, and ANALID now bypasses the second or more executions in the same data step/session by default to avoid the error with an accidental second execution, by setting a value of YES for the new macro variable DONEANALID. -It's unlikely you will need ANALID twice in the same job-step, but if you do, you can bypass the MXG bypass with %LET DONEANALID=; to set a blank value, before each of your %ANALID executions. -If you have a locally-tailored BUILDPDB SYSIN code that invokes _RPDBID, and 32.08, its removal would avoid the need for the circumvention to suppress the VIEW. Thanks to MP Welch, Bank of America, USA. Thanks to Paul Maradin, HP, USA.
VMAC102 MXG WARNING log messages will only be printed for the Aug 23, 2014 first three instances.
ANALRANK to the report that is created. So (for example) if you Aug 21, 2014 were ranking, JOBS based on CPUTM you could also see the Sep 4, 2014 total EXCP and IOTM counts by specifying: VARSINCL=EXCPTOTL IOTMTOTL In addition, if there is only a single variable being ranked, the report is in RANK order rather and alpha. -New parameters: VARSINCL= a list of variables to include in the report that are not being ranked PAGEBY=Y/N YES/NO if YES or Y then the report is broken into pages using the GROUPBY variable. Thanks to Tom MacCabe, Dominion Resource Services, USA.
ANAL119 corrected; the average bytes were a rolling average and ANAlTCP did not match the values in the detail records. Aug 19, 2014 Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
REXXWLM with a missing trailing quote on new Application Aug 19, 2014 Environments in the generated code for some AESP values. The padding on new AEs on the parms was changed from null to blanks; the Rexx code was revised. Thanks to Michael Oujesky, DTCC, USA. Change 32.198 MXG 32.06-32.07. Protection for _IDxxxx EQ 512 failed Many VMACaaaa if your _IDxxxx had multiple SMF record types, e.g.: Aug 19, 2014 MACRO _IDNDM 132 OR ID=133 % Aug 30, 2014 Zero observations were created for that product AND the message was printed that the _IDxxxx macro wasn't set. The 512-detection code was revised to support the two-id syntax by testing both the length and the value, with IF LENGTH(_IDNDM) EQ 3 AND _IDNDM EQ 512 THEN DO; and this worked for the two-id syntax. However, only accidentally. The LENGTH(_IDNDM) was 12 which is what prevented the false positive 512 message. And, even with MACRO _IDNDM 123 %, the LENGTH(_IDNDM) is still 12! To circumvent this defect, the logic was revised again: IF LENGTH(COMPRESS(_IDNDM)) EQ 3 AND _IDNDM EQ 512 ... which uncovered yet another defect; the length of the compressed two-id text is ONE, but the length of the compressed one-id text is THREE, so the LENGTH of the COMPRESSED macro text is used to only detect 512 with three characters. Any other text in _IDxxxx will not have length 3 so those records will be processed. These XXXX product's VMACs were updated: ACF2 BE91 BE97 BETA BVIR CTCP EDGS EJES ENDV FTP HSM HURN IDMS M204 MIM NDM NETM NTCP PROS RSDA RSDF SHDW STC SYNC TMNT TPMX X37 ZCOS (There are MANY other user SMF records that have NOT yet had the protection code added; deferred until an actual need/request is received.) -Notes: "Numeric values have been converted to character string" will be printed, underscoring the "132" value in the _IDxxxx macro; they are unavoidable but are compile time conversion with no cost. SEE CHANGE 32.234. Thanks to Richard Wendland, U.S. Bank, USA.
ANALZIPC with ERROR: PDB.TYPE70PR NOT FOUND when _SMFZIPC was used Aug 18, 2014 to read SMF. _SMFZIPC still used _STY70PR, which was replaced by _STY70 (Change 23.321, SPLIT 70 processing). Clearly, ANALZIPC users have NOT read SMF data but have instead used the PDB.SMFINTRV and PDB.TYPE70PR datasets from their already-created PDB data library! Thanks to Ian Porter, Nissan-NEDC CO, ENGLAND. Change 32.196 Preliminary summarization of PDB.DB2STATS from its fixed ASUMDB2S one-minute interval to a larger interval of your choice, Aug 18, 2014 defaults to 15 minute in this iteration, but this member may be changed into a %macro to externalize options. Thanks to Glenn Bowman, Wakefern, USA.
GRAFWRKT dataset and linear regresses by SHIFT WORKLOAD SYSTEM, Aug 17, 2014 then summarizes by SHIFT and WORKLOAD and uses SGPLOT to display which workloads are growing over time. Change 32.194 Support for NDM-CDI 5.2 HW2 subtype creates new dataset. EXNDMHW2 DDDDDD DATASET DESCRIPTION IMACNDM NDMHW2 NDMHW2 hw2 highwater mark record VMACNDM This record is not a standard NDM-CDI record as it has VMXGINIT 'CDHW' where the record length and record type normally Aug 17, 2014 are located. Thanks to Rich Wendland, U.S. Bank, USA.
VMACRMFV ASILMEMO ASMLPGSZ ASILVNMO ASIHVCOM ASILVSHR Aug 15, 2014 ASILVABY ASIHVCBY ASILVSBY ASIHVVBY ASILVMEM ASI1MBFF ASI1MBPF -Cosmetic. Debugging PUTLOG statement in line 5565 PUTLOG _N_= SSHRMFVN= SSHSMPNR= GEIRSTRF= GEIRPOOL=; is now removed. Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA. Change 32.192 BUILDPDB/BUILDPD3/BUILD001 now use a VIEW for WORK.ID, ANALID which eliminates completely the (potentially large) disk BUILD606 space previously required to produce the SMF AUDIT REPORT BUIL3606 (created by %ANALID, added to PDB in MXG Version 30.02.). VMXGINIT -You can suppress the %ANALID invocation and the creation UTILBLDP of the PDB.SMFRECNT dataset with %LET MXGSMFAUDIT=NO in Aug 15, 2014 your SYSIN. (Previously, MACRO _RPDBID % bypassed the report, but that is no longer used; if it exists in your SYSIN it will just be ignored.) (Only SAS supports Data Step Views.) -UTILBLDP constraint that ID had to be first with USERADD= (Change 32.154) is removed. -Views are not executed when OPTIONS OBS=0 is in effect, which is sometimes used in QA syntax tests, but since no data will be read with OBS=0, &VWVMACID is nulled when OBS=0 value is detected. Change 32.191 Adding a View to BUILDPDB processing for the ID dataset ANALDUPE exposed a SAS error (since 9.1) that corrupts the value ANALDUPE of the internal _INFILE_ variable when a View is used. ASCISMFC The error was detected when the MXG decompression logic VMAC102 (MXGDECOM/DB2DECOM, for CICS/DB2) incorrectly expanded VMAC110 the _INFILE_ internal variable. SAS confirmed the error, VMAC112 recommending that the _INFILE_= argument instead of the VMACDB2 _INFILE_ internal variable be used to circumvent, which VMACSMF was verified in MXG QA tests. However, then the WPS QA Aug 16, 2014 test failed because WPS doesn't support the _INFILE_= argument, but their _INFILE_ variable is valid with or without a View, so this change splits the logic to use the _INFILE_=SMFINFILE argument for SAS but for WPS uses the SMFINFILE=_INFILE_ statement, so SMFINFILE can then be used in MXGDECOM/DB2DECOM macros in all of the listed members that invoke the internal SAS code algorithms. -MXGDECOM/DB2DECOM are always used on ASCII, and are used on z/OS ONLY if the (recommended) EXITCICS/CICSIFUE exit is not installed. -Change 32.192 implemented the use of the VIEW for ID. Change 32.190 BVIR variable VECDLEVL='VIRTUALIZATION*ENGINE*CODE LEVEL' VMACBVIR is now converted to node notation, so the hex value Aug 13, 2014 '0008 001F 0000 0059'X will now contain and print as 8.31.0.89 in character/decimal node notation. Thanks to Scott Barry, SBBWorks Inc., USA.
VMACDB2 FSPSCCPL - CONTROL*CONNECTION*PROTECTION*LEVEL Aug 13, 2014 FSPSDCPL - DATA*CONNECTION*PROTECTION*LEVEL Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA Change 32.188 DB2STATS variable QISEKLRU is not accumulated but was not VMACDB2 detected as such in Change 30.113 because my test data Aug 11, 2014 values were all zero. It is no longer deaccumulated. Thanks to Rachel Holt, Fidelity Systems, USA. Thanks to Lori Masulis, Fidelity Systems, USA.
ANALDSET occurs in MULTIDD='Y' obs), in VMAC30, is now avoided. VMAC30 -ANALDSET enhanced with OPENTM calculated for TYPE64 since Aug 11, 2014 OPENTIME was added after this was originally written. Variables are now ordered for default PROC PRINT, grouped with common first, then 1415, 64, and steps variables. New RECFOUND variable identifies which records were found for each observation. JESNR kept in both output datasets. Thanks to Douglas C. Walter, Citigroup, USA.
ANAL116 the new report was contributed by Scott and its absence Aug 8, 2014 was noted by David. Thanks to Scott Barry, SBBWorks Inc., USA. Thanks to David Carr, Blue Cross Blue Shield of Kansas, USA.
IMACUOW IF (TRANNAME=:'CSM' OR TRANNAME=:' ' OR TRANNAME=:'CPM' Aug 7, 2014 180 is due to IMACUOW line 226: /* CASE ONE LOGIC BEGIN */ , added by Change 32.178 for the new CASE FIVE example, which was a comment within a comment and must be deleted. But MY real error was that I failed to QA test the new IMACUOW. The default IMACUOW doesn't create observations, so I have a tailored copy in my QA.PRODTEST library, but as only a new commented block was added (I thought!), I didn't update the new member into QA.prodtest. Mea Culpa. Worse, the QA report that compares QA.PRODTEST members flagged IMACUOW as changed, but I also failed to take heed of that notification. Mea Mea Culpa. Thanks to Jack Basile, PCH, USA.
EXOMSMTD (INCOMPATIBLE, INPUT EXCEEDED because the offset to the EXOMSMTG next JOB segment is 112 bytes, but only 96 bytes are FORMATS documented in each segment, requiring MXG protection.) IMACOMSM -Two variables added to OMSMSJOB dataset: VMACOMSM OMFS2DAO='DEVICE*ACTIVE*ONLY*TIME' VMXGINIT OMFS2IOQ='IOQ*TIME' Aug 6, 2014 -BY List macros for OMSMSDEV and OMSMSJOB datasets to remove duplicates. -New datasets created from subtype 4 records: DDDDDD DATASET DESCRIPTION OMSMTG OMSMSTPG TAPE GROUP OMSMTD OMSMSTPD TAPE DEVICE -Invalid Subtype 4 records are created with offset greater that the record length; the first three instances are printed on the log for pursuit with the vendor. -Several fields with -1 value are now properly decoded. -Some TAPE datasets have lots of blank character variables that should be populated. Thanks to Robert Chavez, Florida Power and Light, USA. Change 32.183 New %PDBAUDIT audits all DATASETS in all LIBNAMES created BUILDPDB by today's "BUILDPDB" in the "AUDIT" report, and compares BUILDPD3 today's "PDBs" with yesterday's "PDBs", reporting any PDBAUDIT changes in observation length, number of variables, or VMXGINIT any datasets with zero obs in one PDB and non-zero obs Aug 4, 2014 in the other PDB, in the "COMPARE" report. Aug 15, 2014 -%PDBAUDIT is automatically called in BUILDPDB/BUILDPD3. -You can use %LET MXGPDBAUDIT=BYPASS; in your SYSIN to bypass that default execution of %PDBAUDIT. -%PDBAUDIT creates the PDB.PDBAUDIT dataset with today's statistics and copies that dataset into SPIN.SPINPDBAUDIT which will be used for tomorrow's compare, and then backs ups the dataset into PDB.SPINPDBAUDIT. -If your "Build PDB" creates additional datasets after the %INCLUDE SOURCLIB(BUILDPDB), for example, when ASUMs are %INCLUDEd, you would bypass the default execution by adding %LET MXGPDBAUDIT=BYPASS; in your //SYSIN and then by adding the statement %PDBAUDIT; at the end of your "BUILD PDB" step. -All of the LIBNAMEs that have been opened/referenced in this SAS step when %PDBAUDIT is invoked will be reported and written to today's PDB.PDBAUDIT dataset. -You can suppress the report printing but still build the PDB.PDBAUDIT and SPIN.PDBAUDIT datasets by using %LET MXGPRINTAUDIT=NO; -Macro variables &PDBMXG, &SPININ and &SPINOUT are used to set the output and SPIN input/output, with the normal defaults of PDB/SPIN/SPIN, but can be changed if needed. -It is possible to run %PDBAUDIT in a separate step, but then you must use a LIBNAME statement for each library you want to be audited, so the LIBNAME is referenced. Having just a //DDNAME DD does NOT reference the LIBNAME. You must have "PDB" and "SPIN" LIBNAMEs with DISP=OLD for the complete COMPARE and AUDIT reports, but those could separate dsnames just for audit: // EXEC MXGSAS //PDBAUDIT DD DSN=YOUR.PDBAUDIT.PDB,DISP=OLD //SPNAUDIT DD DSN=YOUR.PDBAUDIT.SPIN,DISP=OLD //PDB DD DSN=YOUR.REAL.PDB,DISP=SHR //SPIN DD DSN=YOUR.REAL.SPIN,DISP=SHR //CICSTRAN DD DSN=YOUR.CICSTRAN.DISK.PDB,DISP=SHR //IMSTRAN DD DSN=YOUR.IMSTRAN.DISK.PDB,DISP=SHR //SYSIN DD * LIBNAME PDBAUDIT 'YOUR.PDBAUDIT.PDB'; LIBNAME SPNAUDIT 'YOUR.PDBAUDIT.SPIN'; LIBNAME PDB 'YOUR.REAL.PDB'; LIBNAME SPIN 'YOUR.REAL.SPIN'; LIBNAME CICSTRAN 'YOUR.CICSTRAN.PDB'; LIBNAME IMSTRAN 'YOUR.IMSTRAN.PDB'; %LET PDBMXG=PDBAUDIT; %LET SPININ=SPNAUDIT; %LET SPINOUT=SPNAUDIT; %PDBAUDIT; RUN;
-The default MXGEXCLUDESEQ=YES prevents expensive reading of LIBNAMES that are Sequential Format SAS Data Libraries to save resources, since DICTIONARY.TABLES cause the full dataset to be read (even then, SAS does not report the number of observations!). The cost can be significant: processing a day's PDB with a 6,000,000 obs SEQ DB2ACCT: EXCLUDESEQ NO (reads) YES (doesn't read) CPU 4.8 seconds 1.2 seconds Elapsed 5.5 minutes 58 seconds EXCP Count 255,000 3,313 If you still want to read sequential libraries, you can use %LET MXGEXCLUDESEQ=NO; -ITRM sites can produce the report simply by adding %PDBAUDIT; at the bottom of the SAS SYSIN stream. -These five variables that are not created by WPS FILESIZE NPAGE NUM_CHARACTER NUM_NUMERIC PCOMPRESS will be missing values in reports and PDBAUDIT datasets.
ASUM113 caused Return Code 4, but had no other impact. A length Aug 4, 2014 statement was added when TYPE70PR does not exist. Thanks to Jim Horne, Lowe's, USA. ====== Changes thru 32.181 were in MXG 32.07 dated Aug 3, 2014========= Change 32.181 -New MOBWRKX3 member for Mobile Workload Processing uses MOBWRK01 the CICDS Dispatcher Interval CPUTCBTM with selection by MOBWRKX3 APPLID in MOBWRK01 instead of using CICSTRAN. MOBWRK06 -Documentation in MOBWRK06 and MOBILWRK was updated. MOBILWRK Aug 3, 2014 Thanks to Michael Marcus, UPS, USA.
VMACTMNT plus The delete statement discussed below was removed from Aug 2, 2014 the new code added by Change 32.149 in these members: ACF2 BE91 BE97 BETA BVIR EDGS EJES ENDV FTP HSM HURN IDMS M204 MIM NDM NETM NTCP PROS RSDA RSDF SHDW STC SYNC TMNT TPMX X37 ZCOS ERROR: 32.06: ZERO OBS IN ALL USER-ADDED BUILDPDB/UTILBLDP DATASETS: If you use UTILBLDP(BUILDPDB=YES,USERADD=...) or EXPDBVAR/CDE/OUT members in your USERID.SOURCLIB to add other SMF record types to your BUILDPDB/BUILDPD3, AND YOU DO NOT PROCESS MXGTMNT/TYPETMNT SMF records (i.e., you do NOT set MACRO _IDTMNT 238 %), then ALL of the datasets built AFTER TYPETMNT will have zero observations. This error was introduced in Change 32.149, which incorrectly had added a DELETE statement that should not be there. CIRCUMVENTIONs for this 32.06-Only ERROR: (INSTALL 32.07!!) -Remove the DELETE; statement in line 265 of VMACTMNT, OR -Add this statement in your //SYSIN at the top: %LET MACKEEP= MACRO _IDTMNT 999 % ; -Or: with USERADD= in UTILBLDP, add TMNT/999 Change 32.149 added protection for each User SMF record to detect when the IF ID= _IDxxxx THEN DO code block had the default _IDxxxx value of 512, which would cause those datasets to have zero observations, printing an MXGNOTE to alert you to the needed correction to create obs. But these code block for IF _IDxxxx=512 (STUPIDLY) had a DELETE statement, and because the TYPETMNT processing of that user record is inside the "standard" BUILDPDB, if you had not set MACRO _IDTMNT 238 % to tell MXG to read that type in the TMNT code block, then any record type that was not processed in the preceding IBM type blocks was deleted, and never examined by the subsequent code blocks you had added with USERADD= or EXPDBetc. SEE CHANGE 32.234. Thanks to Robert Chavez, Florida Power and Light, USA. Change 32.179 Cosmetic, confusing. These variables now have VIRT in VMAC71 their label, for VIRTUAL, instead of VERT, which could Jul 31, 2014 make you think of VERTICAL Polarized Processors: SMF71SRA='AVG*HI VIRT*SHARED*FRAMES BACKED*RSTORE' SMF71SRM='MIN*HI VIRT*SHARED*FRAMES BACKED*RSTORE' SMF71SRX='MAX*HI VIRT*SHARED*FRAMES BACKED*RSTORE' Yüklə 28,67 Mb. Dostları ilə paylaş:
|