* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
| No ABENDing STEPS - No ABEND flag on in type30_5
CONDCODE=highest non-zero CONDCODE from STEPS ABEND='RETURN' ABENDS=0
CRSH PDB.JOBS only - Job active during SYS FAILURE PREEXE JOBS-only: Step had a pre-execution ABEND. SYSTEM System ABEND USER User ABEND RETURN Return Code CANCEX Cancelled in SMF Exit, CONDCODE tells which FLUSH Step Flushed or Pre-Execution ABEND RESTAR Step was RESTARTED NOTCTL Not Cataloged Dataset Error OMVSEX Open Edition/MVS Execution COND=J COND= was specified on JOB card OTHER Any other ABEND condition
must be removed and instead you use the new 16.04+ design that lets you add variables to PDB.STEPS/JOBS/PRINT with %LET ADDxxxx= syntax (placed in your IMACKEEP member) as described in the text of Change 16.341. This is because to support CONDCODE, a new dataset WORK.CONDCODE is now created in _PDBSUMS, but your old IMACPDB will override that with the old logic, causing a SAS error message: ERROR: FILE WORK.CONDCODE.DATA DOES NOT EXIST. MXG now protects execution errors by creating a zero-observation WORK.CONDCODE dataset just before _PDBSUMS is invoked, but if your IMACPDB is in place, you will end up with CONDCODE always zero in your PDB.JOBS dataset. (No matter what you do, the CONDCODE in PDB.STEPS is always correct!).
VMXGDEL _Wdddddd dataset, even when it was different from the Aug 31, 1998 _Ldddddd dataset. This left datasets in //WORK library.
VMACQAPM variable DMSTS was changed from $EBCDIC1. to &PD.1., and Aug 30, 1998 the INPUT of DIIDLT was changed from &PD.6. to &PD.6.8, as it caused the value of PCTIOPBY in dataset QAPMDIOP to be 10**8 too large. Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA. Change 16.180 The %BLDNTPDB macro for NTSMF processing is structurally BLDNTPDB functional for building daily, weekly, monthly PDBs or IMACNTSM for ad hoc analysis. Some reports exist, more to come! TYPENTSM -By default, %BLDNTPDB now will read your raw NTSMF data, TYPSNTSM (KEEPERS= or DROPERS= can be used if you don't want ALL), Sep 5, 1998 then SORT what you kept to your PDB, then create the PDB.NTINTRV at the raw data's interval, then create the PDB.ASUMNTIN summary hourly interval dataset, then copy your PDB datasets into the correct day-of-week library, and then print and graph the daily reports. Additional arguments RUNWEEK=YES or RUNMNTH=YES can be specified to create the WEEKLY, MONTHLY and TREND libraries, and all parameters are described in the BLDNTPDB member itself. For example, if you wanted no reports or summary data, but want only the four datasets PROCESS, PROCESSOR, MEMORY, and LOGLDISK, you would use this invocation: %BLDNTPDB(KEEPERS=NTPROC NTPROR NPMEM NTLDSK, RUNNTINT=NO,ASUMDUR=NO,RPTDAY=NO); to read those four objects and sort them into the PDB. There are more reports to be added, and eventually the logic will figure out when it is so a single invocation can be used in every day's run, but that's a while away! -Member TYPENTSM now only reads the NTSMF data and writes to the default WORK location using the _WNTdddd macros; TYPENTSM no longer sorts nor writes to the _LNTdddd macro names, because new member TYPSNTMS (with the "S" instead of the "E" to indicate "SORTs") performs the SORTs and invokes NTINTRV to create PDB.NTINTRV. If you were using TYPENTSM for your daily processing, you should now use TYPSNTSM instead. Member IMACNTSM no longer overrides the _L definitions.
VMXGSUM SAS Version 7 supports long variable names, and changed Aug 28, 1998 the length of variable NAME (created by PROC CONTENTS) Sep 8, 1998 from 8 to 32. MXG uses PROC CONTENTS in VMXGSUM and expected 8-bytes; there is also a new SAS V7 warning when different length variables are merged, and all of these V7 "features" conspire to change the job condition code from zero to four, which is just enough to cause your job scheduling system to take notice of the change! The MXG solution to this incompatibility between V6 and V7 is to insert the statement LENGTH NAME $8 ; after the first two statements DATA VAR1 (KEEP=NAME); in member VMXGSUM, as that forces SAS to expect length 8 (and it is NOT my intention to use long variable names in MXG, certainly not in this millennium!). -SAS Version 7 enhancement - OPEN=DEFER on SET statement. A long-wanted Version 7 enhancement, OPEN=DEFER, lets you read several datasets from different weekly PDBs using only one tape drive: SET TAPE1.JOBS TAPE2.JOBS TAPE3.JOBS OPEN=DEFER; However, inside VMXGSUM, if you used this logic for your input, and those datasets are on tape and KEEP= logic was also used, VMXGSUM could have caused unnecessary tape mounts, as it tries to figure out what data is where, but VMXGSUM has no real awareness of the individual datasets, and we are still examining the best solution, but this revision now recognizes the OPEN=DEFER parameter (and note it is not enclosed in parenthesis, since it is a SET option and not a dataset option. It might be that the best fix will be to build the output keep list rather than the input list when processing a tape, but that still is under investigation. The caveat is that if you use the OPEN=DEFER syntax with VMXGSUM, there will be multiple mounts if the OS datasets are all multi-volume and the default KEEPALL=NO is used. With this change, MXG 16.04 or later is required for MXG to execute under SAS Version 7. See MXG Newsletter, SAS Notes for additional Version 7 Compatibility Issues. -VMXGSUM now correctly figures out where the WORK option points, so we can do housekeeping without erasing what you just created. On an MVS system the value of the WORK option returned by PROC SQL is the DDNAME/LIBREF "WORK", but on Unix and PCs you get a full path name, for example "!sasfolder\saswork" or "c:/sas/saswork" depending on the platform. This change supports these idiosyncrasies. "Line generated by the macro variable "TEMP01" followed by E:\SASWORK.M was fixed by this change. Change 16.178 MXG 16.03 only. Variables added with _PDBADD2/_PDBADD3 BUILD005 were not added to PDB.STEPS or PDB.JOBS because ACCOUNT Aug 26, 1998 dataset was not output in the new architecture. In both members, OUTPUT ACCOUNT; was added before _EDBJOBS; Thanks to Dave Gibney, Washington State University, USA.
VMACNTSM for NT 3.51 and Service Pack 5A these were added: Aug 28, 1998 Dataset SYSTEM: ICABYTRT='TOTAL*ICA BYTES/SEC' WINSTNAC='ACTIVE*WIN*STATIONS' WINSTNIN='INACTIVE*WIN*STATIONS' Dataset PROCESS: IDLOGON ='ID*LOGON' IDUSER ='ID*USER' -Cosmetically, the LABEL statements in macro _CDENTSM were consolidated and alphabetized so that they will control the alphabetizing of the variables in each dataset. Thanks to Bill Feeney, Hennepin County, USA. Thanks to Leigh Ann Payne,Wachovia Operational Services, USA. Change 16.176 MXG 16.03 only. VMXGINIT "TALO" comments were corrected VMXGINIT and IMACKEEP spelling corrected. Labels added for the BUIL3005 SPIN datasets. BUILD005
Aug 21, 1998 Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA. Change 16.175 Support for Soft Audit's "Installed Products File" will EXSFTPR read from filename XPPROD to create new MXG dataset VMACSFTA SOFTPROD to track installed products. VMXGINIT
Aug 19, 1998 Thanks to Normand Poitras, ISM, CANADA. Change 16.174 MXG 16.03 only. The statement PUT ' DEBUG NDM .... ; VMACNDM clearly should have been deleted. Aug 15, 1998 Thanks to Chuck Hopf, MBNA, USA. Change 16.173 MXG 16.03 only. Macro variable PSUNTIN was not defined. VMXGINIT It must be added to the GLOBAL statement and then %LET to Aug 15, 1998 DEFAULT. Thanks to Greg Jackson, National Life of Vermont, USA. Change 16.172 MXG 16.03 only. The LABEL='NTTUDP: ...' should have been VMACNTSM 'NTUDP: ...', as the DDDDDD portion of the label is used Aug 15, 1998 to drive the _S sort macros. Thanks to Greg Jackson, National Life of Vermont, USA. ======Changes thru 16.171 were in MXG 16.03B4 dated Aug 11, 1998====== Change 16.171 Support for IMS Log processing for IMS 6.1. As stated in ASMIMSL6 MXG Newsletter TWENTY-FIVE, this code is not officially JCLIMSL6 supported. This code has not been fully tested, but the VMACIMSA ASMIMSL6 program's output was read, and the VMACIMSA code Aug 11, 1998 changes to the 07 and 08 record were lifted from VMACIMS. I have high hopes this code will work without problem, but plan validation against IMF records in September, as I ran out of time to squeeze this code in as it is! The logic in ASMIMSL6 stores the MSC time for ARRTIME when there is an MSC segment, which I think is a change from ASMIMSL5 - does it make any difference in your data? Thanks to Dario Franceschi, Nordbanken, SWEDEN. Thanks to Sal Fazio, IBM Global Services, USA.
ADOCTDTA user contribution works, and even has documentation in JCLTDTA ADOCTDTA, and the JCL will need to be tailored. This TYPETDTA was added to MXG 16.03B4 at the last minute and has not Aug 11, 1998 yet been added to the MXG QA stream. Nov 12, 1998 Nov 18: Members JCLTDTA and TYPETDTA actually added! Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
ASUMTALO library for backup, but it should have, so I added: Aug 11, 1998 PROC COPY IN=SPIN OUT=&PDBMXG;SELECT SPINTALO; BUILDPDB has backed-up its SPIN datasets into the PDB since Version 8, and all MXG components that use the SPIN library will now also backup their SPIN datasets. Why backup the SPIN library? Because if your daily PDB job fails, you can recover by copying all of the SPINxxxx datasets from your last good PDB library into your //SPIN library: PROC COPY IN=PDB OUT=SPIN; SELECT SPIN:; and then pick up processing with the SMF data from the day after the last good PDB was built! Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND. Thanks to David Ehresman, University of Louisville, USA. Change 16.168 Variable SMF88RAT was described in Change 13.156, but was VMAC88 not created in dataset TYPE88 until this change. Aug 11, 1998 Thanks to Martin Peck, iT-Austria, AUSTRIA. Change 16.167 Minor. Cleaned up VMACUNIK so it will execute under MVS, VMACUNIK just for MXG test stream. The real member for UNIKIX on JCLQAJOB MVS is unchanged, VMACUNIA. Aug 8, 1998 Change 16.166 Variables SMSHWMDS 'HWM SIZE' and SMSHWMDT 'HWM TOTAL' ANALCISH were reversed in their INPUT statement; DT is first, then VMAC110 DS is input. ANALCISH reports were correct, because it Aug 7, 1998 used the wrong names, so now it too must be changed to use DS for Peak DSA Size and DT for Peak DSA Total. Thanks to Andrew Adams, Australian Taxation Office, AUSTRALIA. Thanks to Craig Magill, Australian Taxation Office, AUSTRALIA.
VMAC79 two triplets, and IBM's documentation makes no note that Aug 7, 1998 there are only two, and since all other subtypes had 3, MXG expected three. Now, the number of triplets is tested and only two are input when there are only two! Thanks to Kenneth C. Jones, Boeing, USA. Change 16.164 MXG's MXGTMNT monitor misses too-fast VTS tape mounts. ASMTAPES Scratch Tape Mounts to VTS (Virtual Tape System) can be Aug 11, 1998 satisfied in much less than the 2-second sampling rate. Tests at 1/2 (500ms) and 1/10 (100ms) will be made, but the internal VTS log shows the Mount and Ready times can be in the same .01 second. It might be that the software delay can be captured with the 100ms sampling even when the VTS itself thinks it took less time, but it may also require a significant change to the architecture of the MXG Tape Mount monitor - we may have to capture the Mount message as an event to capture these too-fast mounts! There was no change made by this change, but this text will be revised when the tests have been completed. VTS is a pretty slick technology, even if it causes me design problems in the tape mount monitor. In the day in question, MXG missed about 300 mounts out of 1200. Note: Member ASUMTAPE was added after this change, and corrects the need to reduce the ASMTAPE interval time. Change 16.163 Variables JESNR, INITTIME, and READTIME were INPUT but VMACTMNT not kept in TYPETMNT dataset, so Mount and Step records Aug 6, 1998 can be combined.
ANALVTS SMF type 30 DD segment for tape allocations, the MXGTMNT Aug 6, 1998 Tape Allocation SMF record, the MXGTMNT Tape Mount SMF record, and the type 21 Tape Dismount record to construct a complete picture of each tape allocation and mount. The program needs some cleanup to deal with long running tasks and steps that span the time interval in the SMF file (start-before-end-in and start-in-end-after), but for events which all occur within the SMF file, it's pretty accurate. If you are interested, run the program and give me a call - there are lots of ways these tape events can be analyzed, now that we have total duration of allocation and mount and usage and bytes read/written! The ultimate name may change; this program was used to verify that MXGTMNT was missing Virtual Tape System tape mounts - see Change 16.163 and 16.165. Thanks to Chuck Olsen, Alltel, USA. Thanks to Ken Lamonda, Alltel, USA. Change 16.161 Variables ALOCTIME and LOADTIME were added to the KEEP VMAC30 list for dataset TYPE30_D (a/k/a PDB.DDSTATS) to support Aug 6, 1998 the ANALVTS utility.
EXTMDD6 three new datasets: EXTMDD6B TMDBD6 - Base segment stats, CPU, counters, etc. EXTMDD6S TMDBD6B - Per Buffer Pool counts VMACTMDB TMDBD6S - SQL Text Aug 4, 1998 Variable D6RECNR will be common for all observations in the Buffer Pool and SQL Text datasets for each record and is the merge variable to use to match observations. This was challenging: the SQL text field has either text in ASCII or in EBCDIC but there is no flag. I now test the first character of the first segment for EBCDIC or ASCII, and use that mode to decode the rest of the 100- byte segments of SQL text. Initially, I tested the first character of each 100-byte segment, until I hit a segment starting with '6D'x that is an ASCII "m" or an underscore in EBCDIC. Using the start of the SQL text will decode correctly since the start text is real text characters. (And the '6D'x was actually an EBCDIC underscore!). Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
VMXGSUM after the calculation of DURATM so that its value would Jul 31, 1998 be available in those exits.
USMFRATE second intervals) reads your SMF file and produces print Jul 31, 1998 reports and an export dataset to be sent if needed. If you have had SMF Buffer shortages, this analysis will let you know how much SMF data is being produced and how well it is being handled by your DASD and SMF Buffering. Read the comments, run the program, and send the listing. An MXG Technical Article on this subject will follow soon. Change 16.157 MXG CONFIG member's value of VMCTLISA=40K can cause a 0C4 CONFIG ABEND in function VMZGMAE that goes away if VMCTLISA=60K, Jul 29, 1998 and the SAS default value in 6.09 is now VMCTLISA=160K! That old value for VMCTLISA as well as old values for the VMPAISA VMPAOSA VMPBISA VMPBOSA PSUM SORT31PL PROCLEAVE and SYSLEAVE options were set years ago for SAS 6.06, but they are now deleted from member CONFIG so that MXG will no longer override those SAS memory options. Thanks to Lee West, Direct Line, ENGLAND.
VMAC7072 Now, both variable names exist to protect for past usage Jul 29, 1998 but R723CDQT is the correct spelling. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Change 16.155 Support for BGS I/O Monitor Version 5.1.0 (COMPATIBLE) VMACBGSI added new triplet to support of Goal Mode changes that Jul 27, 1998 creates new B1MONSRV dataset (I/O by Device by SRVCLASS), and the new version supports the year 2000. Change 16.154 ML-17 of MXGTMNT Tape Mount and Alocation Monitor adds: ASMTAPES - SMF interval support; MXGTMNT now listens for ENF 37 Jul 27, 1998 and automatically synchronizes to your global interval - Initialization messages are issued when MXGTMNT is run as a batch job instead of a started task. - Error recovery recursion was improved. - USINGs were cleaned up to prevent HLASM warning message and eliminate CC=4 due to USINGs. Note that ML-16 was never generally distributed.
VMAC110 causing it to be truncated by as much as 1.04 seconds. Jul 27, 1998 Since MCTMNTAD is added to STRTTIME/ENDTIME to convert to the local time-of-day, they were also slightly off. But now I see there is an 8-byte GMT offset value MCTMNDTO that is exact and eliminates the truncation, so now the variable MCTMNTAD will be set equal to MCTMNDTO as long as the two values are within two seconds (to protect for a zero value in DTO?), by the addition of the line: IF ABS(MCTMNTAD-MCTMNDTO) LT 2 THEN MCTMNTAD=MCTMNDTO; immediately after the MCTMNTAD=1.048576*MCTMNTAD line. (Back in MXG 14.14 I had tried to make MCTMNTAD exact with MCTMNTAD=3600*FLOOR((MCTMNTAD+900)/3600) logic, but but I had removed that approximation by MXG 15.15, and it was the comparison between MXG versions that provided this opportunity to use the exact GMT offset value.) Thanks to Andrea C. Schiro, Duke Energy Company, USA.
VMAC110M are deleted to save space and avoid wasting your time VMAC110S reading their comments to find out what they were! The VMACRRTM VMAC110's were for SAS 5.18, VMACRRTM became VMACROSC, VMACZRB VMACTMS became VMACTMS5, and VMACZRB became VMACRMFV.
IMACCMF has not been referenced in MXG since Change 7.119, when VMACCMF Boole added bits by which variable PRODUCT could be set Jul 25, 1998 to 'CMF...' instead of 'RMF'. The macro definition and its now-incorrect comments have been deleted. Thanks to Dan Worsham, Ohio Bureau of Worker's Compensation, USA. Change 16.150 Variable TYPETASK='A ' for both ASCH and OMVS address VMAC30 spaces, but in those SMF records that contain the SUBSYS VMAC32 field, it contains either ASCH or OMVS, so it makes sense VMAC42 to set TYPETASK=SUBSYS when TYPETASK starts with an 'A'. VMAC91 There are other SMF records that contain TYPETASK that do Jul 23, 1998 not contain the SUBSYS field: VMAC's 434, 6, 26J2, 26J3, BETA, CTLD, IPAC, NNAV, PROS, SFTA, TMNT, X37, XPSM, so they will still have TYPETASK='A '; While both type 6 26 have a variable SUBSYS, it is not the MVS SUBSYS field but the PDB.JOBS/STEPS/PRINT datasets will now have the correct TYPETASK value, from the type 30 records. Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY. Change 16.149 The SHORT ABAR message still existed after Change 16.025 VMACHSM because an INPUT @15+OFFSMF @; is also needed after the Jul 20, 1998 ELSE IF 15 LE FSRTYPE LE 16 THEN DO; statement. Thanks to Alan Freed, ADP, USA. Change 16.148 Dataset DB2STATR contained repeated outputs of the first VMACDB2 QLST segment because CHANGE 14.195 was dropped somewhere Jul 16, 1998 after MXG 14.14 and was not in MXG 15.15. Insert the statement OFFQLST=OFFQLST+LENQLST; immediately before the END; /* END TRACE SECTION FOR TYPE 100 SUBTYPE 0*/ as was described in CHANGE 14.195. Thanks to Warren E. Waid, JC Penny, USA.
VMACNSPY MXG between MXG 14.14 and MXG 15.15, because I did not Jul 9, 1998 think anyone was still using 4.4. The NSPYREC='N' logic had been changed to use only NSPNRECI in recognizing the subsubtype, but back with 4.4, NSPNRECI is always zero, so I have had to put back the test for NCPELTYP and NSPNSUBT to support these old records. Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND. Change 16.146 -VMXGSUM syntax for the "DATETIME" variable was kludgy; VMXGSUM you had to say DATETIME=xxxxTIME, and then use DATETIME Jul 9, 1998 in the SUMBY= list instead of the real xxxxTIME variable name. This was needed so that the variable DATETIME could carry the modified datetime values generated by VMXGDUR when you specified INTERVAL= and DATETIME= to create a new interval value. And, in order to retain the original labels for the variable used in the datetime calculations, you also had to use an ID statement and then manually drop the variable DATETIME. This change that logic; you no longer need to code the name "DATETIME" in the SUMBY or ID arguments. You only need to specify the argument DATETIME=xxxxTIME, to tell VMXGSUM what variable to use as the datetimestamp value, and now you can use the real xxxxTIME variable name in the SUMBY= argument. This change is backward compatible and will work properly if DATETIME is still used in the Yüklə 28,67 Mb. Dostları ilə paylaş:
|