* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
message if it doesn't. With DSETEXST=YES, when the existence is already known, VGETOBS is bypassed, saving a read of the full input dataset if it happens to be on tape or in sequential format on disk. Because the redefinition text was DSETEXST=&DSETEXST, SAS errors about RECURSIVE REFERENCE to DSETEXST could have occurred, although (fortunately) none were reported. Change 29.053 Documentation. Since DB2 Version 7.1, when DB2ACCTP data TYPEDB2 was moved to SMF 101 Subtype 1, there has been no QWAC Mar 4, 2011 segment for Packages. The KEEP list for DB2ACCTP still had variables QWACBSC QWACESC and QWACWLME, which have been missing values in DB2ACCTP since then. I could drop them, but if I do, someone out there with an old report program that referenced them, would then fail, so they will still be kept (but if you are real picky, you can easily drop them by putting this macro definition MACRO _KDB2ACP DROP=QWACBSC QWACESC QWACWLME % in your IMACKEEP member in your "USERID.SOURLIB"). Thanks to Wayne Bell, UniGroup, Inc, USA. Change 29.052 The newest MONTHxxx fails, z/OS ONLY, SAS 9.1.3 only. MONTHBLD %CMPRES must be changed to %QCMPRES. As often is the Mar 3, 2011 case with %MACRO errors, the error message gives no clue: NOTE: LINE GENERATED BY THE MACRO FUNCTION "SUBSTR". ;SET MON.XXXXXX WEEK1.XXXXXX WEEK2.XXXXXX WEEK3.XXXXXX ___
___ ___
180 180
180 ERROR 180-322: STATEMENT IS NOT VALID OR IT IS USED OUT OF ORDER. The %CMPRES function was added to print the generated SET statement, for diagnostics, to verify the results of the 7x7 tests (7 Startdays, 7 Rundays), but was added after the z/OS MONTHxxx logic verification, and while it works just fine on SAS 9.2, the 9.1.3 %CMPRES function fails, inserting a semicolon that terminated the %LET statement. The stronger %QCMPRES function works on SAS 9.1.3. May 1: See CHANGE 29.102. Error occurred on SAS V9.2. Thanks to Kim Tyson, Toyota, USA. Change 29.051 Variable STORCLAS can be uninitialized, with hex zeroes VMAC42 for some system datasets (SYS1.MANX,SYS1.PROCLIB); now, Mar 2, 2011 hex zeros are translated to blanks. Thanks to John R. Paul, Highmark, USA. ====== Changes thru 29.050 were in MXG 29.02 dated Mar 1, 2011========= Change 29.050 DB2 IFCID 319, ACCESS CONTROL AUTH EXIT PARMS, specific FORMATS to IFCID=319 fields, are now decoded and output; three VMAC102 formats are created to decode three variables.
ASUM113 than one engine for a type of engine causing LPARBUSY Feb 25, 2011 to exceed 100%. The sum of the DELTATM across engine type Feb 28, 2011 is now stored in DELTASUM and used for LPARBUSY, while DELTATM has the interval duration and is used for the (now corrected) calculation of LPARCPUS. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
VMXGCICI of the CICS Statistics WORK.INTxxxx datasets have been VMXGINIT created (summarized), so they could be copied to a Feb 25, 2011 permanent data library. Change 29.047 DB2 variables QWACZIS1 QWACZIS2 QWACZIEL QWACZITR are now VMXGUOW added to PDB.ASUMUOW when DB2ACCT data is found. Feb 25, 2011
DOC if your program starts with an ASUM/TRND member, or it Feb 25, 2011 invokes VMXGSUM, and the internal macro VGETOBS is used (to detect the presence or absence of input datasets, intended to conserve resources and avoid strange errors), there are two potential exposures: SAS - if the LIBNAME is on tape, we cannot detect that, and the PROC SQL will read the entire tape volume(s) to populate the DICTIONARY.TABLES internal table we use.
LIBNAME(s) are opened, which causes these error messages: NOTE: No rows were selected NOTE: RUN has no effect in proc sql ... immediately. MXGERROR: WEEK.JOBSKED DOES NOT EXIST. VMXGSUM WILL MXGERROR: BE STOPPED. NOTE: Procedure SQL step took : In this case, you must have a LIBNAME statement for each data library to cause that table to be populated. Alternatively, you could also use PROC DATASETS DDNAME=xxxxx; to populate the table.
SYSIN statement eliminates VMXGSUM's call to VGETOBS to verify the dataset exists. However, if they don't exist, that will cause VMXGSUM to then fail for that reason. Thanks to Kare Martin Torsvik, Ergogroup, NORWAY. Thanks to Atle Mjelde, Ergogroup, NORWAY. Change 29.045 TRNDRMFI example TRENDINT should have been INTERVAL. TRNDRMFI UTILRMFI %IF J LT 5 should have been %IF &J LT 5. UTILRMFI Feb 27, 2011 Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
ASMDBLKU was uploaded to z/OS into a readable "RECFM=V/VB/VBS" Feb 25, 2011 dataset. This is the ASM equivalent of the SAS UDEBLOCK for sites that don't have a z/OS SAS license. Change 29.043 -If you needed to rerun a specific day, and you use the BLDSMPDB AUTOALOC=YES option, the FORCEDAY parameter was not found Feb 24, 2011 in the macro; it is now properly defined. To rerun with AUTOALOC=YES, the syntax is forceday=ddmmmyy, where the ddmmyy is the date to be rerun (e.g., 21feb11). -If you need to rerun a day and AUTOALOC=YES is NOT used, specify rerun= the day of the week to be rerun, MON, etc. Thanks to Cletus McGee, ALFA Insurance, USA. Change 29.042 NDM-CDI Version 5 records are read without actual errors, VMACNDM but the test file contained 'XO' records, which printed Feb 24, 2011 "NDM. HEADER ONLY" messages because no records had been available for validation. These records are now decoded and are output in NDMDT dataset.
VSETMNTH MONTHBLD/MONTHBL3/MONTHASC/MONTHDSK has a %%VSETMNTH(), MONTHBLD i.e., if the Last Change is 28.125 thru 29.017, i.e., MONTHBL3 if it was copied from MXG 28.04 thru 29.01 (yes, that MONTHDSK new version that was supposed to have fixed the MONTHs). MONTHASC YOUR MONTHXXX IS SAFE IF IT DOES NOT CONTAIN %%VSETMNTH. MONTHWEK It depends on the MONTHxxx member, the version it came Feb 27, 2011 from, and the STARTDAY of your week (MXG default is MON): NOTE: THERE IS NO ERROR MESSAGE; THE JOB DOES NOT FAIL. 1. IF YOU USE MONTHBLD/MONTHBLD/MONTHASC/MONTHDSK: The possible combinations that are good or bad: Using MONTHBLD or MONTHBL3: From version: MXG 29.01 MXG 28.04-MXG 28.28 (Last Change) Change 29.017 Change 28.125-28.324. STARTDAY SUN MON SUN MON VSETMNTH OLD NEW OLD NEW OLD NEW OLD NEW X ok ok ok ok X X X
(Last Change) Change 28.125-28.324. STARTDAY SUN MON VSETMNTH OLD NEW OLD NEW ok X X X X: MON's PDB data will be missing. The safe correction, of course, is to "drop in" MXG 29.02 before Tuesday's MONTHxxx, but I realize that's unlikely! To correct, you MUST download the new VSETMNTH file - VSETMNTH.SAS (ASCII) or VSETMNTH.EBC (z/OS) - and copy into your tailoring library. With MONTHBLD/MONTHBL3 from MXG 29.01, the new VSETMNTH is all that is required. If your MONTHBLD/MONTHBL3 was from 28.04-28.28, then you can download the new member and cut your list of the datasets you create (i.e., from 1st MACRO _DSET to the end of your MONTHBLx) and replace the default list in the new MONTHBLx), or you can EDIT your MONTHxxx (see below) to change the CALL SYMPUT.
you can download the new member and cut/paste your list of datasets (see preceding note), or you can EDIT your MONTHxxx (see below) to change the CALL SYMPUT. To EDIT/fix MXG's error in MONTHBLD/MONTHBL3 pre 29.01 or the MXG error in MONTHASC/MONTHDSK from 28.04-2901: Change the one line: CALL SYMPUT('LASTDAY',PUT(TODAY,WEEKDATE3.)); to CALL SYMPUT('WEEKDATR',PUT(TODAY,WEEKDATE3.)); The ftp credentials you already have for 28.28 or 29.01 are still valid, so you can either download MXG 29.02 and copy those new members to your Tailoring Library from it, or you can download only the specific files you need: The files with .sas are ASCII for MXG ASCII execution. The files with .ebc are EBCDIC (to avoid any code page translation issues), but they must be moved as binary to a PDS with DCB attributes of RECFM=FB and LRECL=80. And, what do you do when it after March 1st when you find this needed correction? Download/EDIT as described in the preceding paragraphs for your BUILDxxx programs and:
simply EDIT your MONTHxxx and change the statement TODAY=TODAY(); to TODAY='01MAR2011'D; (as is documented in the ADOCMNTH member). -If the rerun is not until the NEXT week, then you would use the MONTHWEK member (z/OS) or the MONTHASW (ASCII) member (from your current MXG version - it doesn't use the defective VGETMNTH that created all this flail), cut/paste your list of datasets to be created, and then read the last 5 WEEKly PDBs to rebuild your MONTHly. 2. IF YOU USE BLDMSPDB: You must have the new BLDSMPDB and VSETMNTH, then: To rebuild the past month's PDB on z/OS or on ASCII with AUTOALOC=NO (default), but ONLY if you are in the first week of the new month:
FORCEDAY=01MAR11); To rebuild the past month's PDB on ASCII with AUTOALOC=YES (ASCII ONLY), but ONLY if you are in the first week of the new month:
RUNMNTH=FORCE,FORCEDAY=01MAR11); To rebuild the past month when it is beyond the first week of the month: With AUTOALOC=NO: LIBNAME WEEK6 'your sixth week'; %LET USEWEEKS=YES; %BLDSMPDB(RUNDAY=NO,RUNWEEK=NO,RUNMNTH=FORCE, FORCEDAY=01MAR11); With AUTOALOC=YES: %LET USEWEEKS=YES; %BLDSMPDB(ALOCWEEK=YES,RUNDAY=NO,RUNWEEK=NO, RUNMNTH=FORCE,FORCEDAY=01MAR11);
the first of the month, or a following week, use: %BLDNTPDB(RUNDAY=NO,RUNNTINT=NO,RUNWEEK=NO,RUNMNTH=FORCE); To rerun a prior month, you must ensure the correct week pdbs are allocated to week1 thru week5, and then us: %BLDNTPDB(RUNDAY=NO,RUNNTINT=NO,RUNWEEK=NO,RUNMNTH=FORCE, FORCEDAY=01MAR11); Additional changes were made by this enhancement. -New macro variable (if you set it to) USEWEEKS=YES: -drives logic in VSETMNTH to use only the WEEKly PDBs when the rerun is in the week after the week with the first of the month. -allocates LIBNAME WEEK6 because some months need to read six months of weeklies when a MONTH PDB is created only from the past weekly pdbs. -Documentation in BLDSMPDB for RUNMNTH=FORCE, RERUN=YES, and FORCEDAY='date' are corrected and updated. -The default WEEKs kept is now 12 in both BLDSMPDB and VMXGALOC, but I recommend a MUCH LARGER number of WEEK PDBs be kept for historic reasons, with all of the PDB datasets (and only a few, if any, kept in MONTHly PDBs). -I believe only SUN and MON are commonly used for the Startday, but the below table shows all of the possible datasets that could have been missing prior to this change:
Eg.: On Feb 1 and Mar 1, which are RUNDAY=TUE, the table shows that "mon" PDB will be missing from your MONTH PDB if your week starts on SUNDAY, or that the "tue" PDB will be missing if MONDAY is STARTDAY, but in the worst case, it shows six dailies could have been skipped in building the monthly. Your RUNDAY = DAY OF 1st of MONTH Week MON TUE WED THU FRI SAT SUN Start: SUN mon tue wed thu fri su-fr ok MON ok tue wed thu fri sat mo-sa TUE tu-su ok wed thu fri sat sun WED mon we-mo ok thu fri sat sun THU mon tue th-tu ok fri sat sun FRI mon tue wed fr-we ok sat sun SAT mon tue wed thu sa-th ok sun Thanks to Michael Creech, Lender Processing Services, USA. Change 29.040 Variables MAXVMSIZ and VMDSSIZE in dataset XAMUSR were VMACXAM incorrectly input as PIB.4. instead of RB.4. so the Feb 23, 2011 formatted value printed as 1164M instead of 3071M. While XAM apparently prints 3072M, the actual RB value in the record, '48BFFFFF'x is only 3221225216 while the actual bytes in 3072M (megabyte) is 3221225472. Thanks to Craig Collins, State of Wisconsin DOA, DET, WISCONSIN.
FORMATS dataset TYPE70X2 variable R7024CT, Crypto Processor Type, Feb 23, 2011 was incorrect, expecting 'F5'x EBCDIC numbers in hex, but the actual values are hex (e.g.,'05'x); the hex value was printed; now the decoded '05X:PCIXCC' will be printed. Thanks to Giuseppe Giacomodonato, EPV Tech, ITALY. Change 29.038 Variable ASISDCCP in dataset ZRBASI is now a percentage, VMACRMFV as labeled; and divided by total samples. Previously, it Feb 22, 2011 was the (numerator) sample count. Thanks to Scott Wiig, USBank, USA. Change 29.037 DB2 V9.1, MXG 28.28-29.01, may print false messages about VMACDB2H INVALID DISTRIBUTED HEADER DELETED. The header is valid, Feb 21, 2011 but the test added in Change 28.326 (to detect a truly invalid header that ONLY exists in DB2 V10.1 and that is to be corrected by APAR PM32425) was off by one byte for DB2 V9.1 records. For either release, nothing is really "deleted"; the only impact is that the INPUT of variable QWHDRQNM, the Requestor Location Name, is skipped, so the "DELETED" in the message is changed to "QWHDRQNM SKIPPED" and the V10 APAR is printed in the message text. Thanks to Lorena Ortenzi, UniCredit Group, ITALY.
VMACEDGR messages that the date was invalid, but should have NOT Feb 18, 2011 printed the message; instead the invalid date is stored Mar 13, 2011 into RDEXPDCH as character, and RDEXPDTO is set missing, Mar 20, 2011 and the test covers COMEFROM=7/48/53 now. Mar 13: DATEDATE=1999/366 now also protected. Thanks to Douglas C. Walter, Citigroup, USA. Thanks to Brent Turner, Citigroup, USA. Change 29.035 SAS compiler error when _NNTSM was invoked to substitute COMPALLN _NULL_ replacement tokens, and a _NULL_ definition had VMACNTSM only one space between the macro name and "_NULL_" text: Feb 17, 2011 MACRO _WNTWFP _NULL_ %% Inserting an extra blank so that the definition now reads MACRO _WNTWFP _NULL_ %% eliminated this error (with full diagnostic options on, the generated code could be seen to be in error, with the next line in the source being 'swallowed' into _WNTWFP.) The error was replicated with other _NULL_'s in VMACNTSM. All of the VMACxxxx that define _NULL_'s with similar syntax were revised to eliminate the exposure, and some members either did not define _Nxxxx or did not have correct syntax (e.g., the MACRO keyword was missing). to have two blanks. And, in the process, I discovered several members did not have correct syntax for their _NULL_ definitions( the MACRO keyword was missing). these VMACxxxx members were corrected: 16 DECS 113 HURN SUIN OMVT WPMO TMVS SVIE AIM3 19 NTSM ZTPM FITA VIOP UNIC ULTM TPF SUNS SRMH SARR RSDF RSDA PMTR MVCI MRKV MPLX MOUN MBO INMV IISL GUTS FDR AIXT 97 42 109 CISM The error occurred with both PC SAS V9.2 and V9.1.3, but only on Windows (both XP and Seven, 32 and 64 bit). Thanks to Lars Fleischer, SMT Data, DENMARK.
VMAC30 message and hex dump, and left SMF30RGT a missing value. Feb 17, 2011 Datetime variable SMF30RGT (IXCARM REGISTER event) is input from two IBM fields, SMF30RGT (the time part) and SMF30RGD (the julian date part), but while SMF30RGT had a valid time value, SMF30RGD was null (i.e., hex zeros). The error is circumvented by inserting double question marks for the INPUT of SMF30RGT, while IBM will be contacted to correct their invalid data value in the Automatic Restart Management (ARM) segment of SMF 30-5. Change 29.033 Support for IMF Version 4.5 is in place; there were no VMACCIMS changes in the IMS F9/FA records between 4.4 and 4.5. Feb 14, 2011
FORMATS previously that was not true. PDB.IPLS is created from VMAC0 SMF type zero records, but ID=0 are written both when SMF VMAC90A is started (at SYSTEM IPL), and when SMF is RESTARTED VMACSMF (after an SMF address space ABEND, I/O error, etc). This Feb 13, 2011 is NOT new; at least since 1992, member ADOC0 has noted (albeit obscurely) that the ID=0 doesn't always report a system was IPL'd. -A true System IPL writes either an ID=90 subtype 8 (IPL PROMPT) or ID=90 subtype 10 (IPL SRM). Now, VMAC0 reads ID=0, ID=90.8 and ID=90.10 records, initially outputting all in dataset TYPE0, but when TYPE0 is sorted by _S0 (the product sort macro, invoked by BUILDPDB/PD3/TYPS0), now these two datasets are created: PDB.IPLS - actual system IPLS - ID=90.8 or 90.10 obs PDB.IPLSMF - all SMF ID=0 observations. -But, note that when SMF has to be restarted, there were SMF records that could not be written and were lost, and no ID=7 record would have been written. -VMACSMF required update because SMF ID=90 records do not have their subtype in the standard SMF header. -Cosmetic. TYPE90nn datasets now have variable CMDMVS to identify which command created the record, and CMDMVS is formatted with MG090CM to describe the command. -Format MG090CM was updated for new commands. -These "bogus IPL" events were overlooked because IBM has done such a fine job in those 19 years to eliminate unscheduled IPLs, that tracking them became unimportant! It was only after SMF ABENDs due to a non-IBM product required restarting the SMF address space that this need to redesign MXG's PDB.IPLS dataset surfaced. Thanks to Jerry Urbaniak, Acxiom, USA. Change 29.031 DB2 V9.1 only; most QGBxxx variables in DB2GBPST were not VMACDB2 correct; MXG had correct INPUT for V8.1 and V10.2 but did Feb 9, 2011 not have a separate INPUT segment for 9.1, and MXG missed the restructure in DB2 V9.1. Thanks to Rachel Holt, Fidelity Systems, USA. Thanks to Lori Masulis, Fidelity Systems, USA. Change 29.030 -For DB2 connections (DBMDPTYP='DSN', variable DBMDACCT is VMACTMDB input and kept in TMDBDB2 dataset; for Client connections Feb 9, 2011 these variables are now kept in TMDBDB2 dataset: Feb 18, 2011 DBMDPLAT $EBCDIC18. /*CLIENT*PLATFORM*/ DBMDAPPL $EBCDIC20. /*CLIENT*APPLICATION*NAME*/ DBMDATID $EBCDIC8. /*CLIENT*AUTH*ID*/ DBMDSFLN &PIB.1. /*DDCS*ACCOUNT*SUFFIX*LENGTH*/ DBMDSUFX $EBCDIC200. /*DDCS*ACCOUNT*SUFFIX*/ -TMDB Version 4.1 BF/BG/BH/BI/BJ/BK/BL/BM records were off by 2 bytes, causing DATABASE NAME and other fields to be misaligned. -Feb 18. Revisions to BI record's restructure. Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA. Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA. Thanks to Ernie Amador, UC Davis Health System, USA.
VMAC80A
Feb 9, 2011 Thanks to Kim Westcott, NYS Office of Technology, USA. Change 29.028 Yet another NDM 'RT' subtype INPUT EXCEEDED error because VMACNDM the records do not match the documentation, offsets are Feb 8, 2011 inconsistent (PACCT/SACCT sometimes -3, sometimes +1), ACCT values that are not EBCDIC, two segments after ACCT that are undocumented, with wide variances in the data from sites running the same CDI versions, so this change stops reading at the end of the fixed portion of the data record, and only looks for the CPUTIME= text string at that point in the record. If you REALLY, REALLY, need the NDMRT variable data, or the undocumented fields to be decoded, be prepared to open a support issue with the CDI vendor and have them contact me with their DSECT/data. Change 29.027 Cosmetic. Several variables were incorrectly spelled in ADOC110 the documentation of CICS variables. Feb 7, 2011 Thanks to Clayton Buck, UniGroup, USA. Change 29.026 Support for zVM APAR VM64794 adds variables to dataset VMACVMXA VXMTRSYS, and new format $MGVXENS to decode new variable Feb 11, 2011 SYSESTAT (Ensemble Status). Thanks to Al Holtz, MEDCO, USA. Thanks to Frank Bright, MEDCO, USA.
VMAC30 records have been observed in steps with CPUTCBTM=0, when Feb 7, 2011 the calculated ZIPUNITS (using normalized CPUZIPTM) is Nov 3, 2011 greater than the SM30CSUL (original CPU+zIIP+zAAP units). While not significant, MXG now forces CPUUNITS=0 when CPUTCBTM=0. The maximum negative CPUUNITS value was -169, but with LOSU_SEC=30018, that is only 0.009 CPU seconds. Nov 3: Original text corrected; negative CPUUNITS weren't set to zero, but CPUUNITS was set to zero if CPUTCBTM was zero. So small negative values (-1.59 in one record in 8 million type 30s) could still occur if CPUTCBTM non-zero. And, they printed a debugging message with _N_= CPUUNITS= that should have been and is now disabled.
VMAC26J2 INDEVICE=Nnnn.RDm and INTRDR=' ', printing messages that Feb 5, 2011 INREASON NOT DECODED. INREASON='RD' and SOURCE=INDEVICE Mar 24, 2011 is now set. INREASON and SOURCE are "my" variables that were only used in understanding NJE Purge Records and are not actually used for anything. Mar 24: SOURCE=INDEVICE wasn't set for INTRDR='Y'. Thanks to Jack Schudel, University of Florida, USA. Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|