* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Jan 5, 2013 and sets OPTIONS FMTSEARCH=(USRFORMAT LIBRARY) to search the user formats first, before the MXG format library. If you use CONFIMXG and you have an MXGNAMES DD in a PROC pointed pointed at a dataset AND you override the MXGNAMES DD with //MXGNAMES DD * the following message will be in the JOBLOG - but it is not a failure IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED
ASUM113 if this is a one book machine, if L4RP LE 0 (one book) or VMAC113 SM1132MM='M10' (2818 - z114). Jan 2, 2013 Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
VMXGALOC correctly calculate the preceding month; when run with Jan 2, 2013 normal _TODAY, on Jan 1, 2013, the monthly data was written to November instead of December. Using FORCEDAY of 1JAN2013 with MONTH did copy correctly. Thanks to Richard Krueger, Sentry Insurance, USA. Change 30.272 MXG 30.09 only. ERROR 48-59 FORMAT EBCDIC WAS NOT FOUND, VMAC102 flagging the input of QWHSSSID. This occurred only in a VMACDB2 user-constructed program that %INCLUDEd VMAC102 alone, or Jan 2, 2013 before VMACDB2 (but that SHOULD have worked correctly!). QWHSSSID and QWHSRELN were added to a PUT in DB2DECOM to identify the system/release, but they had not been input until after DB2DECOM. In VMACDB2 there happened to be a LENGTH QWHSSSID $4 statement that avoided the error when it was %INCLUDEd first. But now, both variables are removed from that diagnostic PUT statement. Thanks to Paul Volpi, UHC, USA.
VMAC102 the _Wdddddd dataset after _Ldddddd dataset was built; Jan 2, 2013 the %VMXGDEL(DDDDDD=102nnn) invocation was added to each of the _S102nnn macros. Note that most of these "sort" macros for ID=102 DB2 Trace don't actually sort the data; most only copy the dataset with a DATA step, because the NODUP duplicate-removal that is normal in _Sdddddd macros requires data and time to validate the completeness of the BY list, but over time, all _S102nnn dataset sort macros will be changed to use PROC SORT NODUP. Change 30.270 IDMS PERFMON Version 18 has a second segment subtype=4 VMACIDMS record which was previously unknown and was creating an Dec 27, 2012 additional observation in IDMSINS that had all of the Jan 2, 2013 variable names from the first segment. Second segment is now decoded and new variables kept in IDMSIMS dataset: INSSYTI ='CPU*TIME' INSCPTI ='SRB*TIME*ON CP' INSZPTI ='SRB*TIME*ON ZIP' INSUSTI ='USER*MODE*CPU*TIME' INSENTI ='TOTAL*ENCLAVE*SRB*CPU*TIME' -Short third segment (PMHRLEN=68) from IDMS Version 17 is now protected. Thanks to Kim Westcott, NYS Office of Technology, USA.
SMFSRCH error in VMXGGETM introduced in Change 30.224 which lost VMXGGETM lost the & ahead of &SMFOUT, and testing of that change VMXGSRCH overrode SMFOUT= so the missing & was not detected. Dec 27, 2012 -Then, an extraneous PUT statement in VMXGSRCH caused a 22-322 syntax error (but the program continued to run). The PRINTIT parameter was not correctly implemented, with both a PROC PRINT and VMXGPRAL of the data found being printed. Now only VMXGPRAL is printed if PRINTIT=YES. Thanks to Dan Case, Mayo Clinic, USA. Change 30.268 RACF317='BPX*DEFAULT*USER*USED?' is added to TYPE8028 VMAC80A thru TYPE8065 to identify if the FACILITY class profile Dec 25, 2012 BPX.DEFAULT.USER is being used; that facility will NOT exist in z/OS 2.1 (because it allowed many users of UNIX system services to share a UID and GID, no longer a good idea and FACILITY class profile BPX.UNIQUE.USER or other alternatives are REQUIRED with z/OS 2.1). RACF317 will be Y/N if a SMF80DTP=317 segment exists, otherwise, blank. Note that APAR OA37164 added detection in the Health and Migration Checks, for an alternative to determine if the profile is being used. Thanks to Randy Shumate, Reed Elsevier Technology Services, USA. Change 30.267 -New IFCID 361 Audit Admin Authority (new with DB2 V10) ANALDB2R added to Audit reports with new AUDIT= parameter value Dec 24, 2012 of ADMIN. -A fault in the logic for the multiple possible database and object names in the IFCID 145 records was fixed.
VMXG70PR and variables LPnIFLS in PDB.ASUM70PR and PDB.ASUMCEC now Dec 23, 2012 counts the number of IFL engines allocated to each LPAR. Dec 28, 2012 The existing NRIFLCPU variable is the number of IFLs in the CEC. DEDICATED IFL, OR SHARED IFL WITH WAIT COMPLETE=YES ARE ALWAYS 100% BUSY IN RMF TYPE 70 (TYPE70PR/ASUM70PR) DATA. For those environmens, z/VM MONWRITE (MXG TYPEVMXA) must be used to measure IFL utilization. For SHARED IFL with WAITCOMPLETE=NO, RMF 70 does capture actual utilization of IFL engines. See Newsletter FIFTY-EIGHT "1. MONWRITE" for comparison. The Wait Complete=YES is set when the box "Do not end time slice if a partition enters a wait state" was checked. Thanks to Andrew Petersen, CSC, AUSTRALIA. Change 30.265 Support for DB2 Trace IFCIDs 361 and 362 populates the FORMATS existing T102S361 and T102362 datasets. VMAC102 Dec 22, 2012 Change 30.264 Support for APAR OA39562 creates new TYPE70Y3 dataset for EXTY70Y3 zEC12 processors new PKCS11 Crypto Co-Processor providing VMAC7072 CEX4P measurements. (Input statement corrected Jan 3 VMXGINIT after IBM support finally clarified the 10 was 10'x.) Jan 3, 2013
IMACICUS longer populated nor needed, you can cause them to be UTILEXCL skipped (so variable USERCHAR will be blank) simply by Dec 21, 2012 creating an IMACICUS member in your "USERID.SOURCLIB" that has only a comment to document that you are skipping over the USER segments. This is only documentation. Thanks to James Olson, Dominion Resource Services, Inc, USA.
VMAC105 numeric hex value; IBM documented the two bytes as binary Dec 19, 2012 but the actual field contains two EBCDIC characters for a one byte hex value (e.g., 'F1C1'x for 1Ax; the original MXG input as PIB2 created SMF105LID=61889 from 'F1C1'x. Thanks to Jeffrey A. Johns, UHC, USA. Change 30.261 TMON/MQ latency variables QAMINLAT/MAXLAT/TOTLAT are now VMACTMMQ correctly input as STCK time values, and formatted with Dec 19, 2012 TIME13.3, now that TMON support informed me they are STCK Jan 17, 2013 units (so the values input with PIB8.6 informat are now divided to 4096 to convert from STCK). Thanks to Homayoun Riaza, United Health Group, USA. Change 30.260 The count in variable ABENDS in PDB.JOBS was incorrect as BUILD005 it could include jobs that ended with ABEND='RETURN'. It BUIL3005 now contains the correct count of STEPS that had either Dec 13, 2012 a 'SYSTEM' or a 'USER' ABEND code, plus a count of one is added for jobs that had a PRE-EXECUTION error in a step (i.e., the step initiated but either was not allocated or was not program-loaded, ALOCTIME or LOADTIME are missing) and for this instance, variable ABEND='PREEXEC' is set. Thanks to Louis Deledalle, BNP Paribas, FRANCE.
FORMATS FCMechanism value A='A:AT_TLS' and $MG119ME value of 'T' Dec 13, 2012 is corrected to T:TLS. Thanks to Richard Wendland, USBank, USA. Change 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch data. EXTY99CC New datasets created: EXTY99CI Subtype DDDDDD DATASET DESCRIPTION EXTY99CP 12 TY99CI TYPE99CI HD INTERVAL EXTY99EH 12 TY99CC TYPE99CC HD CAPACITY EXTY99EM 12 TY99CP TYPE99CP HD PROCESSOR EXTY99EN 14 TY99EH TYPE99EH HD HEADER EXTY99EP 14 TY99EP TYPE99EP HD PROCESSOR EXTY99EQ 14 TY99EN TYPE99EN HD NODES IMAC99 14 TY99EM TYPE99EM HD MQWP VMAC99 14 TY99EQ TYPE99EQ HD MPWQ HNODE VMXGINIT These datasets have been tested with z/OS 1.12 data. Dec 12, 2012 Every 10 seconds, five subtype 12 records are written Jan 2, 2013 with the same SMFTIME but each is a 2 second duration with S99CCITOD containing the start of each interval. -Initially, a pair of subtype 14 records are written every five minutes, but APAR OA39058 changes that architecture to write only one record each interval. Until I have test data with that APAR, the duplicate removal for TYPE99EH/EM/EQ in their _Sdddddd macro is not validated. -The IBM labels for S99EEPNL1/NL2 are reversed, so the MXG labels are now corrected to match data vs documentation: S99EEPNL1 ='TOPOLOGY*NESTING*LEVEL 1*BOOK' S99EEPNL2 ='TOPOLOGY*NESTING*LEVEL 2*CHIP' Thanks to Dave Cogar, Wells Fargo, USA.
VMACBVIR NODUP option in the PROC SORT in macro _SBVIR21 because Dec 11, 2012 the BY list did not include ADHBAD and ADHSLOT. Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY Change 30.257 -If you specified IFCIDS=STATS, the sorts of the datasets READDB2 input to the DB2STATS dataset were suppressed and steps Dec 11, 2012 failed with variables not in order. You SHOULD use the Jan 1, 2013 IFCIDS=STATS instead of IFCID=STATISTICS because STATS creates ONLY DB2STATS/DB2STATR/DB2STATB/DB2GBPST whereas IFCID=STATISTICS also writes these redundant datasets DB2STAT0/DB2STAT1/DB2STAT4/DB2ST225/DB2STATB) that are completely contained in PDB.DB2STATS; IFCIDS=STATS is now set as default instead of IFCID=STATISTICS. -READDB2 now invokes the _S102nnn sort macros so that the work copy is deleted after copy to minimize disk space. But this creates 23 lines of log messages for each data set instead of proc copy's two lines per data set. See Change 30.271. -Comments document where data is written for combinations of PDBOUT= and ACCTSORT= and IFCIDS=. -If you asked for IFCIDS=261, sorts on statistics caused errors when those dataset did not exist. The test on the macro variable was checking the length and should have been checking the value. Thanks to Alyona Bertneski, JPM Chase, USA.
VMAC30 was removed as a bad idea. Dec 10, 2012 Dec 16, 2012 ====== Changes thru 30.256 were in MXG 30.09 dated Dec 8, 2012========= Change 30.255 If you used WEEKKEEP or WEEKDROP parameters and the BLDSMPDB length of the dataset name(s) specified was longer than Dec 7, 2012 the current dataset name being checked (for example you said TYPE64: and the current dataset was IPLS) then the length of the first was greater than the second and an invalid substr length message was created. Everything still ran correctly since it created a FALSE on the condition being tested but it did generate a bad return code when run in the background. A check on the length is now used in addition to comparing the values. Thanks to Robb Hermes, Sentry Insurance, USA.
VMACVMXA UNDECODED message was printed, but then MXG failed with Dec 5, 2012 INVALID BLOCK messages because the undecoded detection Dec 19, 2012 didn't properly set the SKIP value, so subsequent INPUTs Dec 20, 2012 were misaligned. There are three sub-subtype values in PRCAPMMT of 8, 9, and 10, but only 10 has new variables now kept in VXPRCAPM dataset, and only sub-subtype 9 has been "data-tested". Previous Crypto cards have names for values in PRCAPMCT: PCICC PCICA PCIXCC CEX2A CEX2C CEX3A CEX3C 3 4 5 6 7 8 9 but no names are identified for the new Crypto Type 10 nor its three sub-subtypes in PRCAPMMT. The new PRCAPMCT=10 was observed on zEC12 processors and is thought to be a Crypto Express 4S. -Dec 20: PRCAPM support for PRCAPML4=0 records corrected a program loop. -Support for new HIS (SMF113) counters in zEC12 processor, eliminates "ERROR. PRCMFC HARDWARE COUNTER UNEXPECTED", message with CFVN=1 and CXVN=3, which fortunately was harmless to the rest of zVM processing. Thanks to Kim Morrell, Royal Canadian Mounted Police, CANADA. Thanks to Jim Dammeyer, State Farm Mutual Auto Insurance, USA.
dir3009.zip That DIR3009.ZIP distribution file dated Dec 3 has files Dec 4, 2012 that end with a single X'1A (EOF) character. While that character is ignored on Windows, when that unzipped 30.09 directory's files were copied from Windows to unix, those X'1A' characters were preserved, and when read on unix by SAS %INCLUDE, they caused SAS 180 SYNTAX errors (and may have printed a left-arrow for that character). All X'1A' characters were removed from this Dec 4 DIR3009.ZIP file.
NOT exist (created when I mix up LF and CRLF profiles), and since I have done this before, the PROCSRCE program that creates the other MXG distribution files has a test for X'1A' characters, so those files are not exposed, but that dir3009.zip file is a direct zip of the .sas files in the MXG Sourclib directory.
X'1A' are usually created AND detected when I email ASCII new/updated code to a z/OS test site, and that test fails when the translated X'1A' on EBCDIC is read by %INCLUDE. I correct these updated files, and then search all of MXG files for any others overlooked since the last search. But why didn't PROCSRCE's test find them in 30.09 QA? Because I've just discovered that X'1A' is IGNORED by SAS V9 on Windows, whether read by %INCLUDE or an INFILE. (And, since they ARE End Of File Markers, on Windows, when found at the END of the file, they should be.) I cannot prove that PROCSRCE ever found a match; perhaps that test was added for safety, not realizing it wouldn't ever be true on Windows SAS. So I now searched all 30.09 files using SPF/PRO, and it DID find 5 files, but did NOT find EXTY74HO that caused the error! BUT: EDITing EXTY74HO in that same session showed there WAS an X'1A' at the end of that file. Now, it was clear that SPF/PRO can not be trusted to find all instances of '1A'x in a large directory. But SPF/PRO is ancient, so I searched with nearly-as-old SPF/SE and it found these files in dir3009.zip that all ended with an X'1A' character, and which were all removed Dec 4: aaaaaaaa achap32 achap99 asmrmfv asmtapee copyrite copywrit docver docver30 doqa9364 ex102366 exty74ho imac102 jcltes92 jcltess8 jcltess9 jcltest6 jcltest8 jcltest9 qa9364 qa93641 qa93642 qa93643 qa93644 qa93645 qa93646 qa93647 qa93648 qa93649 qadoc qawps qawps1 qawps2 qawps3 qawps4 qawps5 qawps6 qawps7 qawps8 tessothr tessusr1 testothr testusr1 typetmo2 typetms5 vmac79 vmacbbmq vmacdb2 vmacdcol vmacommq vmactmnt vmactms5 vmacvmxa Thanks to Sterling James, DST Systems, USA.
VMAC74 formatted with $MG0748C, nor was it LENGTH $1 nor was it Dec 03, 2012 in the &MXGNOTRA list of character hex variables. Thanks to Patricia J. Jones, DST Systems, USA. Change 30.251 ANALCPU compares two different week's TYPE72GO CPU time, ANALCPU creating one plot for each Service and Reporting Class, Dec 03, 2012 with one line for each week, showing CPUTM vs STARTIME, which is aligned to midnight Sunday of each week. These plots could show which service class CPU time increased or decreased, and show if he shape of the daily profile had changed between the two weeks. SAS/GRAPH is not used, but SAS Version 9 is because the \ plots are created with PROC SGPLOT in Base SAS V9.
ANALZIPC fail. Change 15.320 stated all hardcoded "PDB." LIBNAMEs Nov 30, 2012 were to be replaced with "&PDBMXG.." to interface with ITSV, but these members have been overlooked and are now revised with no hardcoded PDB libnames: ANAL113 ANAL120 ANAL307X ANAL4HRS ANAL72GO ANAL80A ANAL91 ANALAAAA ANALABND ANALACF2 ANALALOC ANALAVAI ANALAVAL ANALBLSR ANALBNC1 ANALBNCH ANALCACH ANALCAPD ANALCISH ANALCPUV ANALDATE ANALDB2R ANALDB2T ANALDB2V ANALDBJO ANALDBJS ANALDBTR ANALDMON ANALEAS ANALFIOE ANALGRID ANALHPCS ANALHTML ANALNAT ANALNPMR ANALNSPY ANALPGM ANALRACF ANALRAID ANALRMFR ANALS225 ANALSRVC ANALTMVT ANALUAFF ANALUOW ANALUSAG ANALWHO ANALXAMR ANALZIPC ANALZIPU ASUM4HRS ASUM72GO ASUM78CF ASUM94 ASUMCICR ASUMCLDR ASUMRAID ASUMSMFI ASUMSTC ASUMSTGP ASUMSYTA ASUMTAPE ASUMTCPT ASUMV11 ASUMV14 ASUMVMNT ASUMVTVM CHANGES CICSSTAT COMPINTV COMPIPLS DB2PDB MRGDB2 NEWSLTRS VMXGINIT Thanks to Christelle Abily, Groupe Informatique Credit Mutuel, FRANCE
VMAC119 to 80 byte fifth segment when MXG expected 88 bytes. The Nov 28, 2012 last two fields are now conditionally input. Thanks to Robert B. Richards, US Office of Personal Management, USA. Change 30.248 Cosmetic. SMF Header Messages didn't clearly identify VMACSMF back-to-back header/trailer nor header-to-trailer with no Nov 27, 2012 intervening SMF record; text in messages was clarified.
VMAC7072 in TYPE70PR dataset. VMAC78 -Variables R783PB, R783CUB, R783zzz in TYPE78CF are kept Nov 22, 2012 so those raw values are available. Thanks to Erling Andersen, SMT Data A/S, DENMARK.
VMACDB2 ('FFFFFFFF'x) and variable QWOSFLG='F2'x, but IBM did not Nov 22, 2012 document those bit values nor document the FFFFx values. Nov 28, 2012 Change 26.201 has IBM notes about the proper APAR install to capture this RMF data, but it didn't note that you must set the DB2 option ZOSMETRICS=YES to populate them. -This change tests the first variables for the large value and if both are found, all 14 QWOSxxxx are set missing. -The four utilization values have values greater than 100 as input, and there is no IBM documentation that the must be divided by ten, but now they are. Thanks to Charles Savikas, DCF, State of Florida, USA. Change 30.245 -Support for BMC Mainview IMS 4.6, a/k/a IMF, a/k/a CIMS, VMACCIMS adds new zIIP and zAAP metrics to the CIMSTRAN dataset: VMACIMS TRXZTCPU='TOTAL*DEP RGN*APPL CPU' Nov 21, 2012 TRXZONCP='TOTAL*DEP RGN*APPL CPU*ON CP' TRXZAOCP='DEP RGN*ZAAP ELIGIBLE*RAN ON CP' TRXZIOCP='DEP RGN*ZIIP ELIGIBLE*RAN ON CP' TRXZFL1 ='TRXZFL1*FLAG' TRXZTCPU='TOTAL*DEP RGN*APPL CPU' TRXZONCP='TOTAL*DEP RGN*APPL CPU*ON CP' TRXZAOCP='DEP RGN*ZAAP ELIGIBLE*RAN ON CP ' TRXZIOCP='DEP RGN*ZIIP ELIGIBLE*RAN ON CP' -The zIIP/zAAP values are NORMALIZED to the speed of the CP engines if your CPs are slower than Specialty Engines. -Note that ZTIME=YES must be specified in BBPARM IMFECP00 member to populate zIIP/zAAP fields in the IMF records; the default value is NO. -Some missing value calculations observed in testing that could be protected in VMACCIMS and VMACIMS now are. Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
EXT12010 creates new TYP12010 dataset. FORMATS IMAC120
VMAC120 VMXGINIT
Nov 20, 2012 Thanks to Mark Wittie, Fidelity Systems, USA. Change 30.243 VMXGCOPY copies SAS datasets from MULTIPLE input LIBNAMES VMXGCOPY whereas PROC COPY only allows from a single input ddname. Nov 20, 2012 Parameters: LIBNAMES= One or more SAS data libraries to be read. Each value is a "starting with" string, so PDB reads ALL LIBNAMEs starting with PDB. On zOS each libname must have been opened with either a LIBNAME statement or a data step, or it will not be found. OUTDD= The output LIBNAME where output is written. Default is WORK. DATASETS= One or more SAS dataset names to be copied. Each value is a "starting with" string, so the string TYPE will select ALL datasets starting with TYPE. If a dataset is in multiple inputs the output will contain ALL observations from ALL of those datasets. NOBS= the number of OBS to copy ZEROOBS YES, all datasets are copied. NO, datasets with zero observations are NOT copied and won't exist in the output LIBNAME. INCODE= Optional argument with your SAS code to select which observations to copy, PROVIDED THAT THE variable(s) you use exist in ALL datasets. For example, INCODE= IF SYSTEM=:'ABCD'; Change 30.242 New parameter CRITERIA= inserts SAS code for selection. VMXG2DTE For example, if you want to keep SMFINTRV data ONLY for Nov 15, 2012 your started tasks, at a weekly or monthly level, and you want APPEND the new data, you would use: %VMXG2DTE(DDIN=WEEK,DDOUT=WEEK,PDB=PDB, DATASET=SMFINTRV,CRITERIA=TYPETASK=:'STC',APPEND=YES); or, if you want to use GDGs and a DATA step, use: %VMXG2DTE(DDIN=WEEKIN,DDOUT=WEEK,PDB=PDB, DATASET=SMFINTRV,CRITERIA=TYPETASK=:'STC'); In either case, you don't supply the IF or the ending semi-colon; the text of CRITERIA= just needs to be a SAS expression that is TRUE for observations you want kept. Change 30.241 There are cases where the object name can change within ANALDB2R a database ID and object ID and possibly cases where VFMT102 the database name might change so timestamps are needed Nov 21, 2012 to correctly build the formats to extract the correct database name and object name from the IFCID 105 and 107 records. This can create a massive format that requires a large amount of memory. In one case on zOS with 16M Yüklə 28,67 Mb. Dostları ilə paylaş:
|