* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Oct 17, 2002: Support for TMON/MVS V3.0 and 3.1 is now in member TYPETMVS/TYPSTMVS/VMACTMVS and not in the TMV2 suffixes. See Change 20.201. Thanks to John Jackson, REDCATS (UK), ENGLAND. Thanks to Jim Horne, Lowes, USA. Change 19.296 While DCOLLECT is generally used to graze your DASD farm ASMVTOC for dataset space, etc., there are cases when ASMVTOC is Feb 13, 2002 needed, and this revision will make it easier and better when you need to look at all the VTOCs. -The program now allows Volume select/exclude processing, so you can avoid multiple scans of volumes shared between images. To invoke select/exclude, set PARM='VOLLIST' and add a //VOLLIST DD. -The program revised the CVAFSEQ access to handle UCBs that are above the line. Thanks to Brian Crow, British Telecom, ENGLAND.
VMXGDEL SAS Version 8.2; apparenly the ITSV %CMSTART macro now VMXGINIT sets the option USER='work', and VMXGDEL tried to compare Feb 13, 2002 work.DB2STAT2 with WORK.DB2STAT2, which was not equal, so VMXGDEL deleted the WORK.DB2STAT2 dataset it had built. This change protects the VMXGDEL test with UPCASE, but also VMXGINIT was enhanced to force the USER and SASWORK options to upper case if they had been lower case, for consistency. Thanks to Roderic Gass, British Energy Group, ENGLAND. Change 19.294 This user contribution processes unix sar reports files UNIXSAR created with the command sar -A -f sardata.mmmyy Feb 12, 2002 This preliminary code will eventually be revised into the normal MXG member naming, macros, etc, but this code will give you access to the sar information now. Thanks to Carmen Vitullo, Acxiom, USA Thanks to Uriel Carrasquilla, NCCI, USA.
VMAC110 inserted new fields in their SMF 110 subtype 1 records. UTILEXCL -New UTILEXCL program for EXCLUDEd fields in CICS records Feb 9, 2002 automatically creates the tailored IMACEXCL member from Feb 11, 2002 your CICS dictionary SMF records, eliminating any manual EDITing of the IMACEXCL member. In addition, using the UTILEXCL to create an IMACEXCL member, even if you don't exclude fields, will provide performance benefits: - a single INPUT statement for each APPLID is created; the default TYPE110 code has many conditional tests that break up the INPUT statement, and that is more CPU-expensive that a single INPUT execution. - conversion statements (times are multiplied by 16) are only generated for the fields that are input. The old IMACEXCL you created skipped over Exclude fields, but then all variables were converted, causing many unnecessary calculations on missing values, which is itself a performance negative in SAS V8. - all EXCLUDEd fields are DROPped automatically, so you do not have to tailor the KEEP or DROP macros for the CICSTRAN dataset. This is new and very powerful; see its comments. And this design will be enhanced: I would like to detect changes in your CICS dictionary and create a new IMACEXCL that can use SMFTIME to differentiate the old from the new records from the same APPLID, in a future revision. Change 19.292 Overdue cleanup of TRENDing for DB2 datasets has correct TRNDDB2A spelling of all variables and KEEPALL=YES is specified on TRNDDB2B each VMXGSUM invocation so they work. The TRNDDB2X member TRNDDB2S summarizes the DB2STATB, Interval Buffer Statistics, by TRNDDB2X Buffer Pool, named TRNDDB2X because TRNDDB2B is used for Feb 8, 2002 the DB2ACCTB (Plan Buffer Details, by Buffer Pool). Change 19.291 The NOAMSGID field in the Version 2.3 record is now an VMACNOAM 8-byte character variable, instead of a 2-byte numeric, Feb 6, 2002 so it is now input into new variable NOAMSGCH. Thanks to Mike Fry, HSBC, ENGLAND. Change 19.290 Support for IBM SMF 94 record, APAR OW52989 that added VMAC94 support for 8-way AX0 controllers (AX0 to AX7). MXG will Feb 6, 2002 input the additional 4 AXO's data fields when they are present.
Thanks to Alex MacFarlane, Bank of New York, USA. Change 19.289 MXG Support for OS/400 Release 5.1.0 Collections Services EXQAPJOL was added in the TYPEQACS member (introduced in 4.5 for EXQAPJOM IBM's first Collection Services), instead of the TYPEQAPM EXQAPJOM member, because the records were completely incompatibly EXQAPJOL restrucured, and in three instances, split apart. While EXQAPPOB the Member name you execute is changed from QAPM to QACS, EXQAPPOL all datasets created still start with QAPMxxxx and all of EXQAPPOT the former variable names are preserved. Three old files EXQAPSYC are split: JOBS, POOL, and SYS. For example, from IBM's EXQAPSYL Collection Services documentation: EXQAPSYT Performance data files: QAPMJOBS and QAPMJOBL. IMACQACS The QAPMJOBL file is provided for compatibilty with TYPEQACS the PM and combines data from QAPMJOBMI and QAPMJOBOS TYPSQACS files. The QAPMJOBS file is created when the PM VMXGINIT database files are migrated with the Convert Feb 6, 2002 Performance Data commmand (CVTPFRDTA) to the new Feb 9, 2002 release, but Collection Services does not create the QAPMJOBS file. MXG will create QAPMJOBL, or QAPMJOBM, or QAPMJOBO, from whichever those three files you create, but it appears the new "Logical" dataset, QAPMJOBL, contains all that was in the old QAPMJOBS dataset, so the JOBMI/JOBOS files probably are not needed. And similarly, the POOL records are split and create QAPMPOLB, QAPMPOLL (old QAPMPOOL), and QAPMPOLT datasets from those three Pool files, and the SYS records now create QAPMSYSC, QAPMSYSL (old QAPMSYS), and QAPMSYST datasets from those files. Your choice of macros you invoke in your copy of TYPEQACS determines what MXG will create. This changes has been validated with all of the above records, plus QACSCONF and QACSDISK, but there are three new records (JSUM, TCP, and TCPIFC) that have not been requested (i.e., test data). The list of specific LRECLs that must be used to upload to MVS (or to use in your FILENAME statement on ASCII) are listed in the comments in VMACQACS. Thanks to Paul Gillis, Pacific Management Systems, AUSTRALIA. Thanks to Gary Katerelos, Coles Meyer, AUSTRALIA. Thanks to Martyn Jones, ABN-AMRO, THE NETHERLANDS. ======Changes thru 19.288 were in MXG 19.11 dated Feb 4, 2002====== Change 19.288 MXG Support for Landmark's IMS, DB2, and MVS products is VMACTIMS changed INCOMPATIBLY, possibly, because all datetimes are VMACTMDB now converted from GMT to LOCAL, using the record's GMT VMACTMO2 offset, which is the way is should have been done. VMACTMV2 IF YOU USE THESE PRODUCTS, YOUR TIMES WILL CHANGE FROM Feb 3, 2002 GMT TO LOCAL, OR IF YOU ARE ALREADY CHANGING THOSE FIELDS IN MXG EXITS OR IN OUR REPORTS, YOUR REPORTS WILL CHANGE FROM RIGHT TO WRONG, and you will need to remove your tailoring code. (Of course, if your site's GMT offset is zero, no change in before or after values will occur.) Alternatively, you could use the new TIMEBILD/TIMETABL in Change 19.286 to change those local times back to GMT, using a TIMETABL just for these MXG jobs with the negative of the GMT offset in the LOCAL delta entry, and with SYSTEM blank. help. Note that ONLY Landmark IMS, DB2, and MVS were changed; the CICS support in TYPETMO2 is still unchanged, because there IS no GMT offset in those records. In fact, you can now use the new TIMEBILD architecture for your TYPETMO2 jobs to convert those GMT datetimes into local. Change 19.287 Utility UGMTCHEK selects all datetime variables in all UGMTCHEK datasets in a SAS data library, PROC PRINTs only those VMXGPRAL variables from the first observation, and PROC MEANS to Feb 2, 2002 get the min and max value of each datetime variable, so that you can see whether a datetimestamp is on the local or GMT time zone. Change 19.286 required knowledge of the zone of each datetime variable, rarely found in the record's documentation; only actual data can confirm the time zone of a datetime variable, hence this new utility.
local timezone, if a GMT offset is present in the record, and for the vast majority of data, times are local zone.
option (so variable names in MEANS output are appended with their statistic: SMFTIME_MIN and SMFTIME_MAX for these reports; it is still my intention NOT to create any real MXG variables in MXG datasets with names longer than 8-characters, but AUTONAME was perfect for this report. UGMTCHEK uses %VMXGPRAL to "PRint ALL datasets in a SAS Data Library"; VMXGPRAL was revised to choose any or all of the three procs (CONTENTS, MEANS, PRINT) to execute; in this instance, I only wanted a PRINT of each dataset. Change 19.286 LOCAL and GMT Time Zones Delta conversion in VMXGTIME. IMACINIT -This enhancement to Change 19.260 supports two time zones TIMEBILD in TIMETABL: a LOCAL delta for datetime variables on the TIMETABL local time zone, and a GMT delta for those few variables VMACmanymany still on GMT time zone (because there is no GMT-offset VMXGTIME in their record). All GMT-time-zone datetime variables VMXGINIT were put in separate %VMXGTIME source statements: Feb 2, 2002 %VMXGTIME(.list-of-GMT-vars.,SYSTEM,GMT=YES) Feb 5, 2002 so that VMXGTIME uses the GMT delta column in TIMETABL Feb 8, 2002 member to convert those variables. Feb 11, 2002 Almost all important variables are in local time zone, but actual data is the only way to know for sure, so all possible data records were run thru the UGMTCHEK utility that display the actual values of each variable that has a datetime format in all datasets in a PDB.
used when found, you should use UGMTCHEK against your own datasets to confirm and validate your datetimes.
change, and it will be revised if vendors add GMT offsets to their records, or if your validation shows that I've overlooked something. If there is a difference in your datetime values, check your "USERID.SOURCLIB" Exit members (EXdddddd) to see if the previous MXG-person changed those values in your installation tailoring exit member. The specific case that created VMXGTIME was a site with multiple LPARs, each on different time zones, and this change is running in production to bring all of those data to the common, local time zone of the data center. But for records that do not contain a GMT Offset, you can now enable TIMEBLD with a zero LOCAL Delta and your site GMT offset for the GMT delta, and convert GMT datetimes based on your instructions in TIMETABL. Most MXG datetimestamp variables contain local time; the SMFSTAMP/RMFSTAMP informats are local; most TODSTAMPs are GMT, but are converted if there is a GMT offset. Records that contain only the first 4-bytes of GMT offset were originally decoded with this calculation: INPUT OFFSET &IB.4. @; OFFSET=1.048576*OFFSET; but the result can be off by a second, it has no obvious reason for that constant, and must be "rounded" to give picture-pretty values. And now, real logic can be used to replace that engineering estimate: INPUT GMTCHAR $CHAR4. @; OFFSET=INPUT( (GMTCHAR!!'00000000'X),&IB.8.6)/4096; IF . LT OFFSET LT 0 THEN OFFSET=CEIL(OFFSET); ELSE OFFSET=FLOOR(OFFSET); Only a few members had the old code.
to match records together, READTIME and UOWTIME, are NOT converted by VMXGTIME: READTIME - its time zone is that of the SYSTEM that saw the job card, but the records on this SYSTEM do not tell where the job was input (except for the type 26 purge record), so it is not possible to correctly re-zone READTIME. And even if it were, you would have the READTIME in your PDB datasets different that READTIME in the other (unprocessed) SMF data. UOWTIME - similarly, it's time zone is unknown, and it must be unchanged to allow CICS and DB2 to be merged in ASUMUOW. The variables below are still in GMT time zone (because there is no GMT offset value in their data records) so they are in VMXGTIME (GMT=YES) statements, and will be converted only if you have a non-zero GMT-offset value in your TIMETABL member:
A06GOFTM A06GONTM A08GBKCD A08GBKDD A14GACT A14GADT A17GCLST A17GOPNT AUSGOFTM AUSGONTM D2GCONGM D2GDISGM DS2LSTRT DS2START DS3LSTRT DS3START DS4LSTRT DS5LSTRT DS6LSTRT DSGLRT DSGLSTRT DSGLSTRT DSGLSTRT DSGSTART GLRHGMT GLRUGMT SORCLOSG SOROPENG STACTIME STADTIME STGCSTRT STGLRTVL VMAC116:
WQCLOSTI WQOPENTI WTASINTE WTASINTS WTASSTRT VMAC119:
CITITIME CTTITIME CTTTTIME FCSETIME FCSTTIME FSSETIME FSSTTIME NIINTIME NTTITIME NTTTTIME STTIME TITIME TTETIME TTSTIME UCCTIME UCOTIME VMAC42:
STARTIME ENDTIME S42EXSTM S42EXETM S42CCSST S42CCEIT S42CCSET VMACCMF:
CMF29SCK CMF29TIM SMF29ECK SMF29PCK VMACACF2: ACSMFTOD LIDLUPT LIDPSTOD VMACAPAF: APAFTOD IMLTOD LITOD UPDATE VMACASXT: RSIOMT RSIO RCENDT VMACHURN: HU01RST HU02END HU05RST HU06RST HU08RST HU09RST HU10RST HU11RST HU12RST HU12TIM1 HU12TIM2 HU12TIM3 HU12TIM4 HU12TIM5 HU13ETIM HU13RST HU13STIM HU16SSTM HU22RST HU24RST HU25RST HU26RST HU40DRST HU42CRTM HU47ONDT HU47RST HU49ONDT HU49RST HU50CRTM HU51CRTM HU51DRST HU51RST HU52DRST HU52RST HU60CRTM HU60DRST HU60SSTM HU61CRTM HU61DRST HU61RST HU62CRTM HU62DRST HU62RST HU62SSTM HU72CRTM HU72DRST HU72RST HU72SSTM HU72TSTM VMACOMSM: OMFS2STM OMFS2ETM OMFS2JTM VMACSTC:
STC09TIM STC13MET STC13MST STC13TIM STC14TIM STC16MET STC16MST STC18MET STC18MST STC18TIM STC19RET STC19RST STC19TIM STC23TIM STC26MET STC26MST VARDATI VARDATL VMACSUNS: ENDTIME VMACTMV2: ENDTIME JDINTST JDITIME JDJETIME JDJSTIME JDOSTCK JDRDTIME JDSETIME JDSSTIME LMRKCARK STARTIME TRLAST TRSTCK TRSTK1 TRSTK2 TRSTK3
of existing BUILDPDB records) may cause an increase in the MXG CPU time for the "big DATA" step: perhaps 3% for an untailored BUILDPDB, and as much as 12% at one test site with a heavily tailored and extended PDB that contains almost all possible IBM and user SMF records. However, the CPU time for the post-big-DATA processing was significantly with 19.19 than with 18.18, so the net increase in the entire BUILDPDB job was only 5%: Extended BUILDPDB Timings 307MB SMF; Big DATA step BUILDPDB Job Total 18.18 110 sec 102MB 243 sec 104MB 19.19 123 sec 105MB 255 sec 107MB - Many %VMXGTIME() invocation statements were added in source code, but MXG initialization invokes %TIMEBILD with TIMEBILD=NO to create a dummy %VMXGTIME macro that has minimal impact on CPU and virtual storage costs. - Enabling %TIMEBILD in your //SYSIN will create the real %VMXGTIME macro, with a small, measurable compile cost, but the actual execution CPU costs depend on how many variables in how many records are actually changed. - BUILDPDB with only default SMF records with no DB2/CICS (375K records, 1.1GB) showed no increase between 18.18 and 19.19. Enabling VMXGTIME, CPU increased from 9 to 10 minutes. - BUILDPDB with only default RMF records (4.8GM) also had no increase between 18.18 and 19.19; enabling VMXGTIME increased 79 seconds CPU time to 98 seconds. MXG 19.07 base - 1637 CPU secs Virtual 69411K MXG 19.19 disabled - 1638 CPU secs + 0% Virtual 69574K MXG 19.19 enabled - 1839 CPU secs +12% Virtual 70951K
run shows there was no cost in adding that code. - The VMXGTIME-enabled increase of 201 seconds is the (small, fixed) compile-time cost of each %VMXGTIME statement, and the actual execution costs to change 377 variable's values across those 10 million SMF records to shift all records to the local zone.
change, with 1054 %VMXGTIME statements added that list in excess of 1,500 datetime variables.
at MXG Initialization to create a null %VMXGTIME macro, so there is NO cost for those %VMXGTIME() statements added in MXG source code to provide this enhancement. -Unrelated, but done as part of this change, there is a new IMACINIT, for user tailoring at MXG Initialization, which is included as the last statement each time that %VMXGINIT is initialized or re-initialized. Likely very few sites will ever need it, but now it's there.
variables were changed by adding this statement: %PUT MXG USED VMXGTIME TO CONVERT &MXGTIMEC VARIABLES.; at the end of your sysin. Change 19.285 Incorrect macro references caused syntax errors if you VMXG70PR used the OUT70PR= WORK.ASUM70PR or OUTCEC=WORK.ASUMCEC Feb 1, 2002 arguments of %VMXGRMFI to send those two datasets to WORK (VMXG70PR was wanted to only update the PLATxxxx vars in the PDB.RMFINTRV dataset). The correct macro references now work as documented. Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.
VMACEDGS past, but unless you wanted the MVDSNx fields, you would Jan 31, 2002 not have notices. The +58 in the INPUT for the V record is now +122 to skip over the new blank data inserted in the record. See Change 21.122, which changed the +122 back to +58, and externalized the value in MACRO _LNEDGS. Thanks to Bruce J. Danderline, Memorial Sloan Kettering, USA. Change 19.283 My very earliest (1972) heuristic, to identify steps that VMAC30 did not Allocate or Load by setting ALOCTIME or LOADTIME Jan 31, 2002 to a missing value, was based on exact zero values in the Feb 1, 2002 raw data, but has finally been exposed by a step that did allocate exactly at midnight (0.00), causing ALOCTIME to be wrong, ELAPSTM to be 24 hours, and ALOCTM negative in step and interval datasets. A heuristic is required here because IBM only provides times, without dates, for these events timestamps. This revision eliminates any exposure to incorrectly setting LOADTIME, now setting it missing only when virtual storage was not acquired; if PVTTOP=0 PVTTOP=0, the "PROGRAM FETCH" event never occurred. And with this external criteria to guarantee LOADTIME valid, ALOCTIME can be always valid when LOADTIME is nonmissing. One remaining exposure cannot be corrected: a step that did not load, so it has LOADTIME=., but had an allocation start time exactly at midnight, will still have ALOCTIME missing, rather than a midnight time on potentially the wrong date, because there is no separate criteria to tell whether that was a midnight or a no-allocate event, but since LOADTIME is missing in this case, ALOCTIME is far more likely to have also been missing, and not midnight. SMF 30 records for STCs for O/MVS a/k/a USS can be valid but appear inconsistent. Step records for JOB=BPXAS with both ALOCTIME and LOADTIME missing, but a SELAPSTM of 45 minutes, and with PVTBOT and PVTTOP both zero but with a small non-zero CPUTCBTM recorded have been observed; the examples all had PGM=IEFIIC, the initator program name. Because Change 19.056 reported that the ALOCTIME can be slightly earlier than INITTIME, and won't be fixed by IBM a 5-second fuzziness is included in the revision. Thanks to Randy Shumate, LEXIS-NEXIS, USA. Change 19.282 Explicitly specifying SYNC59=NO in $%VMXGRMFI invocations VMXGDUR did not work, printed "uninitialized variable NO " notes, Jan 30, 2002 and could create incorrect datetime value; even though SYNC59=NO is the default in VMXGRMFI and works. The user found that SYNC59=N circumvented this error, that occurs only if you add SYNC59 to your invocation of %VMXGRMFI(PDB=...,SYNC59=NO); The actual error was in the VMXGDUR macro that is called by %VMXGRMFI, and its handling of SYNC59 is now correct. Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY. ======Changes thru 19.281 were in MXG 19.10 dated Jan 29, 2002====== Change 19.281 Internal utility macro %VGETOBS is now modified to test VGETOBS that DDNAME is not blank; instead of failing, it will pop Jan 29, 2002 a warning message and will set the DDNAME to WORK. Thanks to Michael Oujesky, MBNA, USA. Change 19.280 WebLog read fails if the ASCII-to-EBCDIC conversion table VMACWWW in the ftp/upload program that moved the web log to MVS Jan 29, 2002 changed left/right ASCII square brackets into 'AD'x/'BD'x instead of the expected 'BA'x/'BB'x hex values. IBM's "Yellow Card" does show 'AD'x/'BD'x for EBCDIC square brackets, and some editors and (we now know!) some ftp packages also output AD/BD values, but IBM's own ISPF/PDF editor has always created the BA/BB value that is in MXG source code on MVS! Now, when MXG code that reads data records with brackets as delimiters is executed on MVS, MXG will use the TRANSLATE function to change 'AD'x/'BD'x into 'BA'x/'BB'x so either delimiter will be recognized. Thanks to MP Welch, SPRINT, USA.
AUTOEXEC compression of new SAS datasets, to significantly reduce CONFIGV8 the disk space required for work and PDB libraries: CONFIGV6 - primarily to eliminate unnecessary out-of-space ABENDs CONFIGxx that wake up a human at 3 am when BUILDPDB fails, Jan 28, 2002 - Avoid B37 ABENDS - Job that now needs two or more work volumes will still run without changing its JCL to UNIT=(SYSDA,3) - Big reduction in I/O time and I/O conflicts - Faster run time: lots on Intel, somewhat on IBM - Automatic; no human intervention or action on your part is required; many sites already made this choice Yüklə 28,67 Mb. Dostları ilə paylaş:
|