* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Change 20.258 -Cosmetic. Labels for variables MCTSSDCN/MCTSSDRL added. VMAC110 Only if the new UTILEXCL is used to create IMACEXCL, will Nov 21, 2002 those variables (field count, segment length) exist in Nov 29, 2002 CICSTRAN, so that you can know which exclude code was in use to create these observations with excluded fields. -The debugging PUT statement for STID=82 was removed. Thanks to Craig Collins, State of Wisconsin DEG, USA. Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND. Change 20.257 Message VMAC80A.WARN. MORE DTP (44) SEGMENTS UNIMPORTANT VMAC80A is unimportant, but the for the 10/13 RACFEVENTS, MXG now Nov 14, 2002 will keep 15 segments (previously kept was 12, this site had 14) to suppress the warning message. Thanks to Hersch White, UICI, USA.
UTILEXCL Instead of creating a DO-GROUP for each APPLID+SMFPSRVR, Nov 15, 2002 only the SMFPSRVR (CICS Version), MCTSSDCN (field count) and MCTSSDRL ("record" length) combination are used to create a DO-GROUP for each unique record structure, so you won't have a separate DO-GROUP for each APPLID. And more important, you won't have to update IMACEXCL every time you add a new APPLID that clones an existing record structure. Thus to support a new CICS version (or any changes in existing EXCLUDED fields), you only need one dictionary record from a test run to create the IMACEXCL that will support the new record format for all APPLIDs. The reporting of UTILEXCL was enhanced. If optional CICS segments are found in your data, it prints the list of IMACICxx members whose comment blocks must be removed to input those optional segments. New reports show which APPLIDs are in which DO-GROUP, list the non-excluded dictionary fields for each DOGROUP, and print the text of the IMACEXCL that was created.
created two exclude lists for the same APPLID that have exactly the same number of fields and same record length, but have different fields excluded, UTILEXCL compares the internal sequence of fields, and will print an ERROR on its log if that conflict is discovered. The redesign is inside the _BLDEXCL macro that creates the IMACEXCL file from PDB.CICSDICT, so you don't need to re-read SMF dictionary records. You use _BLDEXCL to read your previously-built PDB.CICSDICT as shown in examples in the comments in the UTILEXCL member.
the previous design caused by multiple dictionaries for an APPLID+SMFPSRVR that had different DCN/DRL lengths. The old logic did not handle correctly, and it created an IMACEXCL that had repeated variables in the INPUT.
SYNCSORT as your host sort, you'll get WARNINGS that the BY list length is greater than 4092, which is a SYNCSORT limit, but then SAS recognizes that SYNCSORT failed and uses the internal SAS sort successfully. One site got a ERROR: WER723A: CONTACT YOUR SYNCSORT REPRESENTATIVE message, but I believe that was with SAS Version 6.09. Using OPTIONS SORTPGM=SAS should circumvent on V6. Thanks to Kevin Van Houten, Worldcom, USA. Thanks to Erling Andersen, SMF, DENMARK Change 20.255 MXG 20.08-20.07, only if VSAM SMF is read with TYPEDB2, VMACDB2 an INPUT STATEMENT EXCEEDED RECORD LENGTH error occurs; Nov 12, 2002 the test added by Change 20.202 should have been ELSE IF TR03OFF GT 0 THEN OFFSMF=TR03OFF; The original test with TR03OFF GT . THEN was always true because it is TR03OFF is initialized to zero in RETAIN, so when VSAM data (with OFFSMF=4) was read, the first 100 record resetn OFFSMF incorrectly to zero. Thanks to Michael Oujesky, MBNA, USA.
VMACDB2 The record was in fact not written by DB2, and MXG's code Nov 12, 2002 recognized the non-standard subtype, but because IBM puts the actual subtype in QWHSIID, in the DB2 product header, MXG has to INPUT from @LOC, but did not validate that the value in LOC was inside the record. The logic now checks and detects invalid (short) records, printing the first five on the log, but continuing to process the SMF file. Thanks to Chuck Hopf, MBNA, USA.
VMACTMO2 TCB Switch counts and durations were restructured in both Nov 10, 2002 TA and TI records, adding new count/duration variables: TAWRDCT/M TIWRDCT/M Ready Queue Wait for Dispatch TAAWTWRC/T TIIWTWRC/T Ready Queue Wait after Satis TADSPWRC/T TIIDSWRC/T Ready Queue Wait While Switched and making TADSPQCN/M and TIIDSQCN/M now reserved = zero. The new fields were added compatibly and will be skipped over without error with MXG 20.02 or later (Change 20.072 is required for base V2.1); this change will create and populate the new variables when found. Note: the order and location of the fields is a guess, as the documentation is unclear, and no records with the new fields have been tested. But since all are input as binary, no errors in MXG execution will occur, and I might have guessed luckily. Thanks to Frank Lund, EDB Teamco AS, NORWAY.
CONFIGV9 Benchmarks in Newsletter FORTY-TWO show there is no real AUTOEXEC change in resources between V8.2 and V9.00; this change Nov 8, 2002 is not required for V9, but turns on reporting options Mar 1, 2003 that can help in diagnosing problems with your SAS job. -In CONFIGV9 (used only for "MVS" execution) SAS options DLEXCPCOUNT FULLSTATS FULLSTIMER STIMER MEMRPT are now enabled to print those statistics by default. MXG's previous override to MSGCASE was removed so that the SAS default of NOMSGCASE is specified (to circumvent a SAS error in the DLEXCPCOUNT counts with MSGCASE). -In AUTOEXEC (used only for "ASCII" execution), FULLSTIMER was added; it had been removed due to problems way back in SAS V6 for PCs. -This change is not required, but has the recommended new options for SAS Version 9 on MVS-OS/390-z/OS systems. -SEQENGINE=V6SEQ is still required; see Change 20.150.
VMXGUOW variable TIMESTMP was added by that change only to the Nov 7, 2002 code used when CICSTRAN was input, and was not added to the separate macro used when MONITASK data is input. Thanks to Terry Warnke, CUNA Mutual, USA.
EXTANDIF TANDISKO (Disk Open) and TANDISKF (Disk File) from those EXTANDIO same filenames. If you do not have a tailored TYPETAND IMACTAND or TYPSTAND member, you will need to add //TANDISKO and TYPETAND //TANDISKF DD DUMMY, as the default MXG member TYPETAND TYPSTAND member always looks to read all possible Tandem files. VMACTAND -MXG code for TANDPROC G06 record expected 42 bytes of the VMXGINIT variables MSGSQTIM thru RPLCBYTE, but documentation shows Nov 6, 2002 only a 16 byte reserved field added by G05, and I can't Nov 25, 2002 find documentation that caused me to add those fields, so their input is made conditional to eliminate STOPOVER. In addition, the divide by DURATM was relocated until after all fields have been input, and PER SEC was added to several rate variables' label. Thanks to Erling Andersen, SMF Data A/S, DENMARK.
VMXGRMFI old TREND and new TREND be different datasets, i.e., be Nov 6, 2002 part of a GDG, so the Trend Job is recoverable by CA-11. Previously, the TREND parm was used for both the old and the new Trend Library, and that is unchanged unless you actually use the TRENDOLD= parameter in your VMXGRMFI. Also, the disfunctional NORM70= (obviously had never been used) was corrected to work as designed. Thanks to Chuck Hopf, MBNA, USA.
VMACHURN dataset HURN47, and variables HU49BJOB/HU49BSTP added to Nov 6, 2002 dataset HURN49. Thanks to Deborah Churchyard, IBM Global Services, AUSTRALIA. Thanks to Roger Stenlake, TELSTRA, AUSTRALIA.
VMXGUOW macro definition that was in VMXGUOW in 20.02 when 20.038 Nov 6, 2002 was tested was somehow deleted in the VMXGUOW in 20.03. Thanks to Terry Warnke, CUNA Mutual, USA. Change 20.246 Two STG THLD titles were corrected and TOTEFS is now ANAL88 spelled correctly as TOTALs in headings of this report Nov 6, 2002 example for SMF 88 System Logger data. Thanks to Fred Mathew, Nordstrom, USA. Change 20.245A Internal note. MXG's PROCSRCE program is used to create PROCSRCE the IEBUPDTE-format sequential file from the MXG Source Nov 6, 2002 directory, and it is part of MXG QA, checking line length and for unexpected ./ characters inside those files. It now also checks for 'E3'x and 'FC'x in my ASCII source, as they should have been ] '5D'x and u '75'x. Change 20.245 MACRO _THRDHST should have had INFILE THRDHIST instead of TYPSTHST SMF, which was left over from testing, and wasn't caught Nov 5, 2002 in QA because there was an //SMF file allocated. Thanks to Wolfgang Vierling, Allianz, GERMANY. =======Changes thru 20.244 were in MXG 20.07 dated Nov 4, 2002========= Change 20.244 A second instance of DSNLABEL= in TRNDCEC caused ERROR: TRNDCEC THE KEYWORD PARAMETER DSNLABEL PASSED TO MACRO VMXGSUM TRNDHSM WAS GIVEN A VALUE TWICE. The second instance was Nov 4, 2002 removed, and a similar error prevented in TRNDHSM. Thanks to Mike Kynch, International Paper, USA.
VMAC40 If TYPE40 is executed alone, SAS prints notes that Nov 3, 2002 VARIABLE ABEND, CONDCODE IS UNINITIALIZED because those variables don't exist in SMF 40 (dynamic deallocate). That note is caused by a PUT statement in included VMACEXC2 (common code that decodes the TIOT EXCP counts in SMF 30s and 40s) that prints ABEND and CONDCODE in an MXGERROR log message if an error is found in EXCPs, and ABEND/CONDCODE do exist in the type 30s. There is no impact on the TYPE40 dataset since those two variables are not kept nor used to create TYPE40.
or in spelling during alpha testing, so the QA test looks for those notes during error correction. But even when the cause is valid, like here, and even though they have no impact, those notes are eliminated (primarily because they cause confusion and unnecessary support questions), by a "compiler faker" statement: IF charvar=' ' THEN charvar=' '; IF numrvar=. THEN numrvar=.; an executable statement, but one that is placed after the RETURN; statement in VMAC40, they are never actually executed. Nevertheless, I considered replacing those executable statements with the RETAIN compiler statement: RETAIN ABEND ' ' CONDCODE .; to initialize, define length and char/numr type. However RETAIN can never be used if the variable is conditionally INPUT, because values from a prior record would then be retained and incorrectly output when they were not INPUT. When I asked Rick Langston about a RETAIN without retain he pointed out that ARRAY statements could be used: ARRAY INIC40 $ ABEND (' '); ARRAY ININ40 CONDCODE (.); as it initializes without retaining values. The ARRAY statement must be physically located before the variable name is used, and a unique token must be used for each array (some names are restriced, like ENTITY, and the array name cannot be the same as a variable name in some other member that can be compiled together, but with the naming convention INICxxxx and ININxxxx in VMACxxxx, the compiler faker statements in VMAC40 were replaced by two ARRAY statements, and I will likely replace others as I find them in other members. Thanks to Bruce Widlund, Merrill Consultants, USA Thanks to Freddie, TXU, USA. Change 20.242 STK HSC User SMF Subtype 29 (1Dx) caused INPUT STATEMENT VMACSTC EXCEEDED error; MXG expected +6 at the end of the record Oct 31, 2002 should have been +4, and STC29MVN is PIB4. and not NUM4. And that subtype was incorrectly OUTPUT into STCVSM28, but now those typos are corrected to OUTPUT to STCVSM29. Thanks to Dwain P. Majak, Blue Cross Blue Shield of Kansas, USA. Change 20.241 Support for APAR OW55968 replaced 4-byte R744RSST with a VMAC74 new 8-byte field (R744RSSE) to prevent overflow. When Oct 29, 2002 the new value exists, it is still stored in R744RSST, as keeping R744RSSE would be redundant. Also OW55586. Change 20.240 TYPE73 with SMF73CMG=0 still had missing PCHANBY/PNCHANBY VMAC73 because the initialization logic was still incorrect and Oct 29, 2002 had to be relocated, again. Thanks to Michael L. Kynch, International Paper, USA. Change 20.239 Trending for TYPE23 dataset (SMF Buffer Usage) was wrong; TRND23 the include of ASUM23 was incorrect and macro names were Oct 28, 2002 also corrected. Thanks to Diane Eppestine, Southwestern Bell, USA. Change 20.238 Documentation. Using TEMP01= with %VMXGSUM can cause VMXGSUM ERROR: FILE PDB1.MXGSUM1.VIEW IS SEQUENTIAL. THIS TASK Oct 28, 2002 REQUIRES READING OBSERVATIONS IN A RANDOM ORDER, BUT THE ENGINE ALLOWS ONLY SEQUENTIAL ACCESS. Remove the TEMP01=PDB1 argument in your tailored %VMXGSUM invocation to eliminate this error. MXG Change 19.151 documented the changes in use of the TEMP01/TEMP02/TEMP03 arguments; while you can make TEMP01= work (by changing your DD or adding a LIBNAME PDB1 V6SEQ; statement), MXG has recommended that you never use TEMP01, and you use TEMP02/TEMP03 only for specific large dataset cases, e.g. when you want to exploit hardware compression. "MXGSUM1" errors are in an VMXGSUM invocation. When the message is XXXX.MXGSUM1.VIEW instead WORK.MXGSUM1.VIEW, it shows that your %VMXGSUM invocation has TEMP01=XXXX. Thanks to Lawrence Jermyn, Fidelity Systems, USA. Change 20.237 IDMS Performance Monitor for Version 1500 circumvention; VMACIDMS MXG will skip over unknown sections, rather than failing Oct 25, 2002 with an INPUT STATEMENT EXCEEDED; new sub-subtype 13, 14 and 15 records are created, but I have no documentation of those record subtypes, nor of any changes to any of the existing subtypes (which, while seeming to be still correct, should be closely examined and validated). This text will be updated when those sub-subtypes are requested to be supported by a site with documentation.
VMACSASU was decoded with the table look-up, but was neither kept Oct 25, 2002 nor was the variable labeled. Thanks to Alfred Holtz, Merck Medco, USA. Change 20.235 Support for APAR OW54010 adds Large Virtual Memory (above VMAC78 2 GigaBytes) fields to RMF's Private Area Virtual Storage Oct 24, 2002 Job-Level Monitor SMF 78 subtype 2, in TYPE78PA dataset: SHBYHWM ='HWM*BYTES SHARED*ABOVE 2GB' SHBYMAX ='MAX BYTES*SHARED*ABOVE 2GB' SHBYMIN ='MIN BYTES*SHARED*ABOVE 2GB' SHBYNTME='TIME STAMP*OF MIN*SHARED*ABOVE 2GB' SHBYTOTL='TOTAL*SAMPLES*SHARED*ABOVE 2GB' SHBYXTME='TIME STAMP*OF NAX*SHARED*ABOVE 2GB' TOBYHWM ='HWM*BYTES ALLOCATED*ABOVE 2GB' TOBYMAX ='MAX BYTES*ALLOCATED*ABOVE 2GB' TOBYMIN ='MIN BYTES*ALLOCATED*ABOVE 2GB' TOBYNTME='TIME STAMP*OF MIN*ABOVE 2GB' TOBYTOTL='TOTAL*SAMPLES*ABOVE 2GB' TOBYXTME='TIME STAMP*OF MAX*ABOVE 2GB' You must have put JOB name(s) for VSTOR in your ERBRMFxx to monitor job-level and create 78-2s, and these new data are present only if the Detail Option was set for VSTOR. This change is required if you install this APAR; the MXG code was not prepared to skip over the new data. Thanks to Brian Currah, Performance Associates, CANADA.
VMACOMCI was added by adding 'V520' to the IF FOCVER test; visual Oct 24, 2002 scan of a PROC PRINT of first 20 observations showed no obvious errors (as would occur if a field was inserted). Thanks to Art Cuneo, Health Care Services Corporation, USA.
BUILD005 reversed to KEEP = LOCLINFO _PDB30_4 ; so that redefine BUIL3005 of _PDB30_4 could use DROP= syntax without accidentally Oct 24, 2002 dropping LOCLINFO; the MXG syntax in KEEP= must have the old-style macro name last, so that DROP overrides KEEP. Thanks to Brian Crow, British Telecom, ENGLAND. Change 20.232 Cosmetic. Labels for REGSEXAV/MN/MX are 'REG+SWA PAGES'; VMAC71 the original label mistakenly had 'REG+SQA PAGES'. Oct 23, 2002 Thanks to Tom Buie, Southern California Edison, USA. Change 20.231 Support for Control-D "SF2" User SMF record, described by EXTYCSF2 their CTDSF2 DSECT, for Batch, creates new dataset IMACCSF2 CTLDSF2, but the data does not exactly match the DSECT: TYPECSF2 Variable SF2VSMCP, CPU Writing to VSAM, contains data TYPSCSF2 values that are impossible ('0009CBEF'x, if that field VMACCSF2 is in milliseconds, as are the preceding four fields); VMXGINIT that value is greater than the elapsed time. Problem Oct 22, 2002 will be opened with the vendor and this note updated. Thanks to Kerstin Jansson, Tietoenator, FINLAND.
EXTYCPOD their CTDPSMF DSECT, for Web-Access creates new dataset IMACCPOD CTLDPOD, but the record does not agree with the DSECT: TYPECPOD Variable PODPTMLI (Login Time) is hex zeros with no TYPSCPOD time nor Julian Date. The next field, PODPCPUT, CPU, VMACCPOD is '91FD75D4'x in one record, but is '40404040'x in VMXGINIT two others, and the alignment of the rest of the fields Oct 22, 2002 are thus in question. Thanks to Kerstin Jansson, Tietoenator, FINLAND.
VMAC94 -VMAC120: New WebSphere subtype 7 variables SM120WAF and VMAC120 SM120WAG labels are Activity Begin and End datetimes. VMACNTSM The _B120WI had all the SM120aaa variables, but now has Oct 31, 2002 only these: SM120WIA-SM120WIE and SM120WIQ-SM120WIW. In all new interval datasets (TYP120JI,TYP120SI,TYP120WI) the interval duration is kept in variable DURATM. Some old event datasets still have DURATM as their elapsed time variable, but new event datasets like TYP120WA will have elapsed time variable SM120ELP instead of DURATM. Variable DURATM is kept in both TYP120CC and TYP120CM, but only subtype=4 records will have non-missing DURATM. Variable SM120ST is now labeled. -VMANTSM: Variables EXCHHTEX, EXCHHTI1 and ORDFDATA were input as $ but also in INFORMAT 16.2, which SAS did not raise as an error, but SAS/ITSV does! All were removed from the INFORMAT, and EXCHHTI1 added to $32 length. The MACRO _BNTMECO still had all variables, from testing; only the first five variables should have been listed. -These inconsistencies were uncovered in the QA process by ITSV/ITRM development while updating their dictionary with new variables and new datasets from MXG 20.06. Thanks to Chris Weston, SAS ITRM, USA.
VMAC102 were wrong, if GMT Offset is non-zero. Change 19.286 Oct 21, 2002 incorrectly added +GMTOFFDB to those variables, but they are already on the local time zone. Thanks to Scott McDonall, Southern California Edison, USA.
VMACNTSM increased from $32 to $64 in length; the original was too Oct 21, 2002 short for 'Compaq Ethernet_Fast Ethernet Adapter_Module'. Thanks to Xiaobo Zhang, ISO, USA. Change 20.226 Documentation example for RACF TYPE80A processing. VMAC80A The TYPE80A/TYPS80A member should be used for RACF SMF 80 Oct 17, 2002 (and not TYPE80), because TYPE80A creates a separate data set for each RACF command, keeping only the variables for that event. But that means there is an EXTY80xx exit for each dataset, and if you wanted to filter the type 80 SMF record and (for example, delete all events with RACFAUTH with BIT0:NORMAL AUTH set, so you only output the events with the other bits -SPECIAL, AUDITOR, etc-) you would have to put your test in each of those EXTY80XX exits. Fortunately, there is an MXG exit, IMACJBCK, that applies to all of the TYPE80A-built datasets (although designed just for "Job Checking"), and when it is taken, these RACF variable have been input: RACFDESC RACFEVNT RACFQUAL RACFUSER RACFGRUP RACFAUTH RACFREAS RACFTLV RACFERR RACFTERM JOB READTIME LOCLINFO RACFVRSN To use the exit instream and delete all records with the BIT0:NORMAL AUTH bit turned on (to output all the rest): // EXEC MXGSASV9 //SMF DD DSN=your.input.smf.data,DISP=SHR //PDB DD DSN=your.output.type80a.pdb,DISP=OLD //SYSIN %LET MACJBCK= %QUOTE( IF ID=80 AND RACFAUTH EQ '1.......'B THEN DELETE; ); %INCLUDE SOURCLIB(TYPS80); Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA. Change 20.225 Support for CICS APAR PQ63143 SMF 110 subtype 2 stats. FORMATS Incompatibly changed STID=24, CICAUTO dataset segment, VMAC110 added new fields at the end of other STIDs. Without the Oct 17, 2002 change, MXG log messages about new data for STID= print, but all other MXG datasets were still correctly built; only CICAUTO is incorrect without this Change, and it is seldom used. -STID=24 +4 byte insert: CICAUTO changed INCOMPATIBLY. In addition, time variables A04CIDLE/CMAXI/TIDLE/TMAXI are now input correctly; they were missing previously. -STID=60, reserved field now DSGTCBAF, variables DSnTCBAF are created for each of the 13 CICS TCBs. DFHDSGDS. -STID=81 +124 bytes added at end, eight new variables added to dataset CICM compatibly. DFHMNGDS. Yüklə 28,67 Mb. Dostları ilə paylaş:
|