* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
IPLTIME so it is always on the Local time zone. Thanks to Rudolf Sauer, T-Systems, GERMANY.
ASMRMFV
Jul 5, 2011 Change 29.145 Revisions (again!) to enhance DB2 processing, especially ANALDB2R with large volumes of DB2 SMF data. ASUMDB2A -Macro variable DB2RSELA added in VMXGINIT. ASUMDB2B -New parameters in ANALDB2R: ASUMDB2G BUFFDETL=NO - suppresses reading the DB2ACCTB/DB2ACCTG ASUMDB2P JOB= - select only records with JOB=xxxxxxx TRNDDB2A -Values for Class 3 Suspension in ANALDB2R reports were TRNDDB2B corrected. Values for Global Contention are still being TRNDDB2G reviewed. TRNDDB2P -If selection criteria are specified in ANALDB2R: VMXGINIT With PDB=SMF they are passed to READDB2 Jul 5, 2011 With PDB=PDB they are passed to ASUMDB2x members in the READDB2 DB2RSELA macro variable so that only records that meet the criteria are summarized. Performance improvement in ANALDB2R: IF PMACC01=YES and PMACC02 NE YES Suppresses buffer data and ASUMs of buffer data If DB2ACCTP has 0 OBS suppress ASUMDB2P -New parameter in READDB2 JOB= - select only records with JOB=xxxxxxx -Some changes in ASUMDB2x/TRNDDB2x members are cosmetic to eliminate UNINIT messages; others are to pick up the time ranges of the records for heading and sorting and adding of a thread count for calculating averages. KEEPALL=YES reinstated in ASUMDB2P,ASUMDB2G,ASUMDB2B, and ASUMDB2A so that ANALDB2R can be used with user-tailored ASUMDB2x datasets (i.e., with dropped variables) without messages about UNINIT variables. -In TRNDxxxx, variable THREADs added to SUM list so that ANALDB2R could be executed against Trend datasets. Thanks to Neil Ervin, Wells Fargo Bank, USA.
IMACIMST Finally, you can track individual IMS transaction CPU and TYPEIMST Response times, without using the MXG circumventions VMACIMS (JCLIMSL6/ASMIMSL6/TYPEIMSA/TYPEIMSB, or IMS0708 data), Jul 2, 2011 and without ANY sorting/merging/etc. And, the IMF56FA dataset contains the ARRVTIME of the transaction, which is NOT contained in IMS0708 dataset, although it is contained in the IMSTRAN from JCLIMSL6. -The TYPEIMST member builds only the IMS56FA.IMS56FA dataset.
-MOST variable names are changed from the prior IMS56FA dataset, so its variables are now identical to those in the "circumvention" datasets IMS0708/IMSTRAN so that your existing reports should work without error or with minor revisions. -Most of the DLRxxxxx variables in dataset IMS0708 do not exist in the IMS56FA dataset, and variables DTOKEN IMSACCQ6 IMSSQ6TM LINTPSB LINEPGM LINTSY2 LINTSUM are also missing/blank in IMS56FA, but all of the really important variables are present. -References to IMS Version 11.0 were corrected to 11.1. -References to IMS Version 10.0 were corrected to 10.1. -Numerous duration variables in the LCODE=45x statistics records are now correctly divided by 4096. Thanks to Raymond J. Smith, UHC, USA.
VMACEXC1 ERROR.VMACEXC2.2 INVALID DEVCLASS/DEVTYPE IN 30 DD, but Jul 1, 2011 the DEVCLASS and ARGUMENT were both valid, and this was deep in the middle of a BUILDDB run. Fortunately, the search for the INVALID ARGUMENT message found this note: SAS Problem Note 13269: Various numeric functions may return incorrect results. The result returned by some numeric functions may be incorrect. This problem can occur if the result of the function is assigned to a variable that is also used as an argument to the function. The functions affected are: BETA, COALESCE, COMB, CONVX, CONVXP, DATDIF, DUR, DURP, GEOMEAN, GEOMEANZ, HARMEAN, HARMEANZ, IQR, LARGEST, LOGBETA, MAD, MEDIAN, MOD, ORDINAL, PCTL1, PCTL2, PCTL3, PCTL4, PCTL5, PERM, PROBDF, PVP, RXMATCH, SMALLEST, YRDIF and YIELDP. The function may also incorrectly return a missing value and issue a NOTE to the SAS log reporting that one of the arguments to the function is invalid. The SAS Note states: THIS PROBLEM IS FIXED IN SAS 9.1.3 SERVICE PACK 2 AND SAS 9.2. BUT THE ERROR WAS UNDER SAS V9.1.3 WITH SP 4!!! However, the text in the SAS Note and the MOD statement identified in the error message agreed; the same named variable was the input and the output BLKSIZE=MOD(BLKSIZE,32768); so the code now uses a different variable name, and the error was eliminated!!! Thanks to Jean-Denis Lacourse, CGI, CANADA.
VMAC90A SMF9030C='ENCLAVE*SERVICE*CLASS*RESET' Jul 1, 2011 SMF9030D='ENCLAVE*QUIESCED' SMF9030E='ENCLAVE*RESUMED' SMF9030H='ORIGINAL*INDEPENDENT*ENCLAVE' SMF9030K='ENCLAVE*OWNER' -Variable PRODUCT is added to all TYPE90nn datasets. Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY. Thanks to Willi Weinberger, Gothaer-Systems, GERMANY. Thanks to Sabine Richard, Gothaer-Systems, GERMANY. Change 29.141 Skipped Change Number. Change 29.140 Some DB2 Trace Records IFCID 6/7 have QWHSSTCK events VMACDB2 before the QWACBSC start time in their DB2ACCT and VMACDB2H DB2ACCP observations. IBM DB2 support answer: Jun 29, 2011 "The logic in DB2 does full thread allocation and then clocks the begin time for the transaction. If an I/O is required during allocation, you may see a 6/7 pair outside the transaction bounds. So in the end, this appears to be working without error." But the time value in QWHSLUUV in these transaction DOES precede the first IFCID 6, showing that the actual start time WAS captured when the LUUV was created, and that the LUUV creation event should be used for QWACBSC time. That suggestion is under discussion with IBM. While waiting, new variable LUUVTIME is created in both DB2ACCT and DB2ACCTP to be used in place of QWACBSC when analyzing DB2 trace records. For QWHCATYP=8 REMOTE UOW transactions, LUUV is not a valid time value, but for those records, LUUVTIME is set equal to QWACBSC so that all observations have a usable LUUVTIME for match up with other records. Note that for DB2PARTY='R' or ='P' (Rollup, Parallel), LUUVTIME can be MUCH earlier than QWACBSC, because in those records QWACBSC NOT the transaction start time, as is documented in Change 29.131. Note also that variable ACE rather than QWHSACE should be used to match up transactions; for DB2PARTY='P' obs, ACE is set to QWACPACE, which is constant for all of the records for that transaction (while QWHSACE in the parallel records is not consistent).
VMAC80A dataset TYPE8020 and CLASNAME-CLASNAM5 in TYPE8024 from Jun 29, 2011 DTP=43 segments were wrong because the segment count variables NR25SEGS and NR43SEGS were never reset to 0 for a new record. Thanks to Lars Fleischer, SMT Data, DENMARK. Change 29.138 If you use a LIBNAME statement to allocate a tape SAS zOS Only data library and VGETENG is invoked before any datasets Jun 25, 2011 are written to the tape, you may get a 413-18 error from zOS indicating a failure to correctly open the dataset. Your job will still get a CC=0 so it is not a serious error, but it is an annoying warning message. LIBNAME TEST V9SEQ; %VGETENG(DDNAME=PDB); Will cause: ERROR: OPEN FAILED. ABEND CODE 413. RETURN CODE 18. This can be suppressed by writing a 0 OBS 0 VARS dataset to the tape immediately after the LIBNAME, using LIBNAME TEST V9SEQ; DATA TEST.A;RUN; %VGETENG(DDNAME=PDB); to suppress the message (although it will also put a very small additional dataset on the tape).
UTILARCH similar to the way OUTLOOK archives its EMAIL store. Jun 25, 2011 All observations for chosen datasets dated earlier than the chosen archive date are written to the archive data library (which could be new, or archived observations can be appended to an existing archived dataset), and the observations that were archived are then removed from the original input dataset (which can be rewritten or could be written to a new "unarchived" data library). You can specify: INDD= LIBNAME of the input data library. OUTDD= LIBNAME of the output un-archived, reduced dataset. If OUTDD is NOT specified, the unarchived observations replace the dataset in the INDD library. OUTDD is required if INDD is on TAPE or DASD sequential format. INARCHIVE= LIBNAME of the current archive data library. If the dataset(s) selected exist in OUTDD, newly archived observations are APPENDed. ARCHIVE= The new archive data library. This could be the same as INARCHIVE, as long as they are not tape nor sequential format on DASD. DATEVAR= The name of the date variable to be tested. KEEPDAYS= The number of days of detail data to keep unarchived. Obs more days old are archived. KEEPDATE= The date literal (01JAN2011) to keep; obs earlier than this date are archived. Either KEEPDAYS or KEEPDATE but not both must be specified. ARCHDAYS= The number of days of data to keep in the archive. If not specified, the archive will continue to grow in size. ARCHDATE= The date literal (01JAN2010) of the oldest date to be kept in the archive. Either ARCHDAYS or ARCHDATE or NEITHER, but not both, must be specified. DATASETS= one or more SAS datasets to be archived
written back to the detail. If it is lt that value but GT today()-sum(keepdays,archdays) it is written to the archive (if archdays is specified - if it is not specified the archive grows to infinity.) Thanks to Brian A. Harvey, HCL America, USA. Change 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE). These new VMAC120 variables are added to dataset TYP1209E: Jun 25, 2011 SM1209FK='CLASSIFICATION*ONLY*TRACE?' Jul 17, 2011 SM1209FM='SMF*REQUEST*ACTIVITY*ENABLED?' SM1209FN='SMF*REQUEST*ACTIVITY*TIMESTAMP?' SM1209FO='SMF*REQUEST*ACTIVITY*SECURITY?' SM1209FP='SMF*REQUEST*ACTIVITY*CPU DETAIL?' SM1209FQ='PROPAGATE*TRANSACTION*NAME?' SM1209FR='STALLED*THREAD*DUMP*ACTION' SM1209FS='CPUTIMEUSED*DUMP*ACTION' SM1209FT='DPM*DUMP*ACTIO' SM1209FU='TIMEOUT*RECOVERY' SM1209FV='DISPATCH*TIMEOUT*VALUE' SM1209FW='QUEUE*TIMEOUT*VALUE' SM1209FX='REQUEST*TIMEOUT*VALUE' SM1209FY='CPUTIMEUSED*LIMIT*VALUE' SM1209FZ='DPM*INTERVAL*VALUE' SM1209GA='MESSAGE*TAG*VALUE' SM1209GF='CPU*USAGE*OVERFLOW?' SM1209GG='CEEGMTO*UNAVAILABLE?' SM1209GH='LENGTH*OBTAINED*AFFINITY*RNAME' SM1209GI='OBTAINED*AFFINITY*RNAME' SM1209GJ='LENGTH*ROUTING*AFFINITY*RNAME' SM1209GK='ROUTING*AFFINITY*RNAME' -Variable SM1209CE is expanded to 16 bytes. -Variables SM1209DX and SM1209DZ are deprecated; they are still set, but use SM1209GF and SM1209GG because DX/DZ may not exist, since the z/OS Request Info Section (and the Platform Neutral Request Info Section) might not be present if this is Async Work. -New values added to format MG1209T for SM1209CK and to format MG1209C for SM1209EM. -Jul 17: Updated VMAC120 was moved into SOURCLIB. This Change was NOT included in MXG 29.05 dated Jul 11, 2011. Thanks to David Follis, IBM, USA.
VMAC110 not announced until today when it became GA. See Change Jun 24, 2011 29.063 for details.
EXPOEXCL five new datasets: EXPOEXDB EXPOEXEX DDDDDD MXG MXG EXPOEXFI DATASET DATASET DATASET EXPOEXLI SUFFIX NAME LABEL FORMATS IMACPOEX POEXLI POEXLIST POWER EXCHANGE LISTENER TYPEPOEX POEXEX POEXEXPT POWER EXCHANGE EXCEPTION TYPSPOEX POEXFI POEXFILE POWER EXCHANGE FILE ACCESS VMACPOEX POEXDB POEXDB2 POWER EXCHANGE DB2 VMXGINIT POEXCL POEXCLIE POWER EXCHANGE CLIENT Jun 24, 2011 Only POEXLIST and POEXCLIE datasets have been validated with data records, and these problems have been reported to the vendor's support team: a. The STCK fields are in GMT but there is no GMT Offset; it is possible to use Fuzzy Logic to compare END time when it is populated (see below) to calculate a GMT Offset, but well-written SMF records always contain the GMT Offset that is in effect when the event records are created, when they contain time/date-times on the GMT clock. b. The records contain Subtypes but BIT 1 in SMFxFLG is not set; the SMF Manual Table 13-2 documents that bit that should be set for records containing Subtype. c. The Reserved Field at offset 290 in the General section is only 28 bytes, but was documented as 32 bytes.
d. For the Client Records: 1. In the General section, the Character START/END are LOCAL zone, but they are identical to each other and are the same as SMF time (except that SMFTIME has higher resolution). The STCK START/END are GMT zone, and are also identical to each other. 2. In the Extended section, the STCK START/END times are not populated. 3. The Reserved Field in the General Section contains an IP address in character format. 4. The Client IP Address is not populated. 5. The Client User ID contains hex rather than EBCDIC text; I don't know if that is correct or not, but if it contains HEX it needs to be documented. e. For the Listener Records: 1. The START fields are many days/hours prior to the SMF TIME, and are constant for each JOB. The CHAR field is Local Time Zone, the STCK field is GMT Time Zone. 2. The SMF times are at 5 minute intervals, but are not synchronized with TIME OF DAY, as all interval records should be. 3. The END TIME fields (both CHAR and STCK) are not populated, so it is NOT possible to use Fuzzy Logic to reset the Start Time to the local clock. Thanks to Bobbie Justice, Kohl's, USA. Change 29.133 -Variables LPARNAME and LPNUMBER are added and are kept in ASUMVMXA PDB.VMXAINTV and PDB.ASUMVMXA. But the LPNUMBER in z/VM VMACVMXA data is NOT the "LPARNUM" variable in TYPE70PR from RMF. Jul 5, 2011 In TYPE70PR, variable LPARNUM is a z/OS assigned sequence number that has no connection with the actual Partition number of each LPAR, which is precisely what is stored by MONWRITE in its LPNUMBER variable. In TYPE70PR, there is a variable PARTISHN, but that is the actual Partition that wrote that SMF 70 record, and since the IFL LPARs do not write SMF records, there is no possible way to match the z/VM MONWRITE LPNUMBER to the IFL LPAR data. However, merging the TYPE70PR IFL observations with the MONWRITE data does not need the LPNUMBER/LPARNUM; the data can be merged by matching the LPARNAME and ENDTIME. Jul 26: See MXG Newsletter FIFTY-EIGHT VM Technical Notes for comparison of synchronized MONWRITE and RMF data. And, only SHARED IFLs have actual utilization; DEDICATED IFLs always report 100% utilization in TYPE70PR/ASUM70PR. Change 29.132 -When sending the output to HTML, PROC GCHART creates GRAFCEC files with the name GCHART GCHART1 GCHART2 etc. If you GRAFWRKX send the output of both routines to the same place, the UTILWORK second one overwrites the output of the first. Added a Jun 22, 2011 NAME= to all the GCHARTS so the charts created by Jul 5, 2011 GRAFWRKX will be GRFWRK GRFWRK1 etc and the ones from GRAFCEC will be GRFCEC GRFCEC1 etc. -If COMPAT=YES was incorrectly specified (COMPAT went away years ago), UTILWORK generated an RMFINTRV member with USEREPRT and USECNTRL set to COMPAT=YES, causing VMXGRMFI to look for performance groups. Now, COMPAT=GOAL is set. -If run on ASCII in the background, your session will stop to display every graph being produced - a real pain in the butt. This can be suppressed using the GOPTIONS NODISPLAY; option and a graphics catalog will still be created. So you may want something like: GOPTIONS NODISPLAY; PROC GCHART GOUT=MYGRAPHS DATA=whatever; VBAR whatever; Run;
GOPTIONS DISPLAY; FILENAME HTML 'C:\MXG\'; ODS HTML PATH=HTML BODY='BODY.HTML' FRAME='FRAME.HTML' CONTENTS='CONTENTS.HTML'; PROC GREPLAY IGOUT=MYGRAPHS NOFS;REPLAY _ALL_; RUN;
ODS HTML CLOSE: RUN;
The graphs will be constructed and HTML put in C:\MXG\. Clicking on FRAME.HTML will display the graphs after the background task is complete. Thanks to Chuck Hopf, Independent Consultant, USA. Change 29.131 When DB2 ROLLUP is specified, DB2ACCT and DB2ACCTP will VMACDB2 have two observations, the Originating and the Rollup, Jun 21, 2011 but only DB2ACCT created DB2PARTY to identify which. This changes creates DB2PARTY in DB2ACCTP dataset. In DB2ACCT, with Parallelized DB2 and ROLLUP specified: -In the DB2PARTY='O' observation, QWACBSC/QWACESC are the start and end times, but in DB2PARTY='R' record, both BSC and ESC are set to the END time of the transaction. In DB2ACCTP, with Parallelized DB2 and ROLLUP specified: -In the DB2PARTY='O' observation, QPACSCB/QPACSCE both are missing values, and in DB2PARTY='R' record, both are set to the END time of the transaction. -Parallelization is only recognizable because the value in QPACSCT (and in QPACZITM if zIIPs exist) are much larger than the ELAPSTM in the DB2ACCT 'O' observation. In both DB2ACCT and DB2ACCTP, population of variables is inconsistent between the 'O' and 'R' record; in ACCTP the QPACPKID is blank in the 'O' but populated in the 'R', while most other QPACxxxx variables have values in both. In ACCT, the QBnxxxx and QXxxxxx variables are missing in the 'R', but most other variables are populated in both. Thanks to Glen Bowman, Wakefern, USA. Change 29.130 -Cosmetic - if you were running with AUTOALOC=YES, a SAS BLDSMPDB warning was generated when a PROC COPY was used to copy Jun 21, 2011 the contents of PDB to the day of the week. That is now suppressed unless AUTOALOC=NO. -New parameter AUTOTRND= added to allow you to add or subtract the TRNDxxxx members that are invoked when trending is being done. Default TRNDxxxx members are: TRNDCEC TRNDCELP TRNDCICX TRNDDB2A TRNDDB2P TRNDDBSS TRNDRMFI TRND72GO TRNDTMNT TRNDTALO
VMACVMXA ***MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT=8 WAS SKIPPED Jun 15, 2011 *ERROR* PROBABLE DATA LOSS DUE TO MONWRITE FAILURE. and subsequent misalignment, due to 32 undocumented bytes for that crypto subtype. Investigating further. IBM has confirmed the documentation of this record is in error; the MXG code and this change will be updated when the IBM correction is available. Thanks to Victoria Lepak, Aetna, USA.
VMACDB2H QWHDSVNM length (QWHDLOSL) was greater than 16 bytes even Jun 15, 2011 after Change 29.036 due to error calculating LENLEFT. Thanks to Lorena Ortenzi, UniCredit Group, ITALY. Thanks to Paolo Uguccioni, UniCredit Group, ITALY.
VMAC7072 the RMF 70 records for z/OS systems running under z/VM. Jun 14, 2011 New variable VMGUEST='Y' is added to PDB.TYPE70PR dataset if this z/OS is run under z/VM with the VMGUEST option specified in Monitor I options (in your ERBRMFxx member). Two observations in PDB.TYPE70PR exist with the option; one with LPARNAME='PHYSICAL' that contains the Dispatch CPU Time of z/VM itself for this z/OS system, and one with the LPARNAME='VMSystem' for the z/OS CPU TIME. In the RMF Reports: The header of the Partition Data section provides data about the z/VM partition running the z/OS guest, with 'VMSystem' reported as the MVS PARTITION NAME field. The IMAGE CAPACITY field displays the CPU capacity available to the z/VM partition; NUMBER OF VMSystem PROCESSORS presents the number of processors that are assigned to the z/VM partition. All other header fields in the RMF report will be N/A. The partition data reports data of the z/OS system running as z/VM guest. The CPU time used by z/VM itself is reported as partition name '*VMSystem*'. In the reported partition data, the physical processor utilization represents the logical processor utilization of the z/VM partition.
VMACXAM SYTEP1FL ECMCPBT ECMCPBTB Jun 13, 2011 and variables input that were not kept: Jun 15, 2011 SYTEP2FL $CHAR1. /*SYTEP1*FLAGS*/ CSCCMCMB &RB.4. /*MAXIMUM*INTERNAL*BUS*CYCLES*PERSEC*/ CSCCMCMC &RB.4. /*MAXIMUM*CHANNEL*WORK*UNITS*PERSEC*/ CSCCMCMM &RB.4. /*MAXIMUM*WRITES*PERSEC*/ CSCCMCMR &RB.4. /*MAXIMUM*READS*PERSEC*/ CSCCMCMU &RB.4. /*BYTES*PER*DATA*UNIT*/ ECMBCBCC &RB.4. /*BUSY*CYCLES*USED FOR*I/O*/ ECMCCWUC &RB.4. /*CHPATH*DATA*UNITS*TOTAL*/ ECMCCWU &RB.4. /*CHPATH*DATA*UNITS*LPAR*/ ECMCDWUC &RB.4. /*CHPATH*WRITE*DATA*UNITS*TOTAL*/ ECMCDWU &RB.4. /*CHPATH*WRITE*DATA*UNITS*LPAR*/ ECMCDURC &RB.4. /*CHPATH*READ*DATA*UNITS*TOTAL*/ ECMCDUR &RB.4. /*CHPATH*READ*DATA*UNITS*LPAR*/ SYTEP2FL is now kept in place of SYTEP1FL, ECMCPBT/B are no longer kept and the other twelve are now kept. Jun 15: All references to WORKUNITS and WORK*UNITS in the variable labels was changed to DATA*UNITS; while Barton documented them as WORKUNITS in the PL/1 descriptors that are the only XAM documentation, apparently later in the Velocity reports/documentation they are now called DATA UNITS so I've changed the labels as requested. Thanks to Patricia Hansen, ADP, USA.
VMAC102 of QW0022AN,'ACCESS INDEX NAME' was greater than 18, due Jun 10, 2011 to error in MXG logic in handling truncated name fields. Also, for DB2 V10, QW0022PA was incorrectly read as PIB2 Yüklə 28,67 Mb. Dostları ilə paylaş:
|