* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Aug 13, 2011 invalid prior to this correction. Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA. Change 29.182 -Invalid ASP.NET Applications record caused ERROR: INPUT EXNTNEDP STATEMENT EXCEEDED RECORD LENGTH (record had NRDATA=40 IMACNTSM but header said 75 should exist, which is what MXG VMACNTSM expected). Circumvention detects number of words in the VMXGINIT NT SMF record and deletes with an MXGERROR: message. Aug 11, 2011 -New Object .NET DATA PROVIDER FOR SQLSERVER supported -Segments ACSR,SQGS,SQDA,SQSS,QLSS and SQBS have IDPROCES and SQLVERSN variables added. -After circumvention code was implemented, user found out the data file had been truncated during ftp transfer, but I left the update in place since it was tested and safe. Thanks to Xiaobo Zhang, FISERV, USA. Change 29.181 %ANALDB2R argument PMIOS05 was not %UPCASED by MXG, so no ANALDB2R IO SUMMARY REPORT was produced if PMIOS05=yes was used. Aug 11, 2011 Thanks to Howard L. Curtis, Progress Energy, LLC, USA. Change 29.180 Harmless MXGWARN: DURATM=INTERVAL WAS SPECIFIED message ASUMMIPS is eliminated; DURATM was in the SUM= list when it should Aug 10, 2011 not have been. Thanks to Bernhard Bablok, Allianz, GERMANY. Change 29.179 Undefined TOKEN= $ZEKE_Z with TOKENID=59674 now skipped, VMACTPMX as are all of the defined-but-not-used ZEKE fields. Aug 10, 2011 Thanks to Scott Wiig, U.S. Bank, USA. Change 29.178 Variable CECSER, a 6-byte text variable with only the VMAC89 left four positions populated, with two blanks at the Aug 9, 2011 right end, is now created in TYPE89 and TYPE892 datasets to match CECSER in the RMF TYPE70xx data. SMF89SER is a three-byte character variable containing text in hex with format $HEX6., so it printed '0178E0', including the 01x CPUID value. But CECSER in RMF records is only the text '78E0 ' value, and that is now the value in CECSER in the TYPE89 and TYPE892 datasets. Thanks to Warren Cravey, FMR, USA. Change 29.177 Support for APAR OA35175, logstream statistics in SMF 23, EXTY23LS creates new TYPE23LS dataset with these new data: IMAC23 SMF23LFA='AMOUNT*OF EACH*BUFFER*ALLOCATION' VMAC23 SMF23LFG='VARIOUS*FLAGS' VMXGINIT SMF23LFH='HWM*BUFFER*ALLOCATION' Aug 9, 2011 SMF23LFL='CURRENT*BUFUSEWARN*IN EFFECT' SMF23LFM='CURRENT*DSPSIZMAX*IN EFFECT' SMF23LFT='TOTAL*BUFFER*STORAGE*CURRENTLY*USED' SMF23LSL='LENGTH*OF LOGSTREAM*NAME' SMF23LSN='LOGSTREAM*NAME' SMF23LF1='BUFUSEQARN*FROM THE*GLOBAL*OPTION?' SMF23LF2='DSPSIZMAX*FROM THE*GLOBAL*OPTION?' APAR OA37002 (see NEWSLTRS) adds new DSPSIZMAX argument for SMFPRMxx to set logstream buffer size(s). Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
FORMATS that is now decoded by $MG113FL format to display: Aug 9, 2011 '08X:LOST COUNTER DATA' when SM113CF1 is printed. -And it adds new option of interest to HIS SMF 113 users: The DATALOSS parameter for the F HIS command has been enhanced to control what action is taken by HIS when any type of instrumentation data is lost. Prior to this enhancement, the DATALOSS parameter only reacted to sampling data lost due to a buffer overflow. The DATALOSS parameter now reacts to instrumentation data lost due to a Loss Of Sample Data Measurement Alert and a Loss Of Counter Data Measurement Alert. By specifying DATALOSS=IGNORE these types of instrumentation data loss can now be ignored, and the instrumentation run may continue.
VMAC30 creating SMF30CRM (ASID IS VELOCITY GOAL MANAGED) and Aug 9, 2011 SMF30PIN (INCOMPLETE WLM DATA?), one-byte flag variables. SMF30PIN was just observed (overlooked) and now created. The APAR documents SMF30CRM with this note: the address space matched a classification rule which specified "manage region using goals of both", which means it is managed towards the velocity goal of the region. But, transaction completions are reported and used for management of the transaction service classes with response time goals. This option should only be used with CICS TORs, the associated AORs should remain at the default "manage region using goals of transaction". Change 29.174 Support for APAR OA34895 adds new EXCP/IOTM SMF 30 fields IMAC30IO (transparently) with step/interval total I/O Count and VMAC30 I/O Connect times (new MXG variables EXCPMISS/IOTMMISS) Aug 9, 2011 with counts that would have also been in a DD segment(s), Aug 27, 2011 but weren't, because an SMF Lock (to update the TIOT for VMAC434 serialization) could not be obtained. The xxxxMISS counts VMAC40 ARE included in the asid/step totals, EXCPTOTL/IOTMTOTL, read directly from the SMF record, but were not counted in any of its DD segments, so they are ALSO already in EXCPNODD/IOTMNODD, the "NOT COUNTED IN DD SEGMENT" vars MXG creates with EXCPNODD=EXCPTOTl-EXCPTODD. All of the above is true, WITH OR WITHOUT this change. This change only creates the new variables and keeps them in datasets in TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6 and PDB.SMFINTRV, and in BUILDPDB's PDB.STEPS/PDB.JOBS (where member IMAC30IO controls which SMF 30 I/O variables are kept in the those BUILDPDB/BUILDPD3 datasets. These new "missed" variables would be useful to at least partially explain steps with large values in NODD and TOTL fields, if the xxxxMISS values are non-zero. See NODD in ADOC30. -Compiler faker added in VMAC434/VMAC40. -Transparently added, but if you (incorrectly) have an old VMAC30 in your tailoring library, that will cause ERROR: EXCPMISS NOT FOUND in BUILDPDB at MXGSUM3. Thanks to Christa Neven, KBC Global Services, BELGIUM.
VMAC57 four bytes in SMF 57 record. Aug 9, 2011
EXPRCMFC the z/VM MONWRITE data on z/10 and later processors. PTFs VMACVMXA will be available for z/VM 5.4 and z/VM 6.1 and 6.2. Aug 8, 2011 Dataset VXPRCMFC contains the same variable names as TYPE113, but there is no SYSTEM variable in z/VM so it wasn't added into ASUM113. This support was in MXG 29.04, but undocumented.
WEEKBLDT should have been spelled _WEEKBLD; they caused a SAS Aug 7, 2011 180 syntax error, after creating WEEK.TYPE72 dataset. Thanks to Ron Wells, American General Finance, USA. Change 29.170 The insertion of the _TODAY old style macro caused BLDSMPDB the forceday option to fail. Aug 7, 2011 Thanks to Cletus McGee, ALFA Insurance, USA. Change 29.169 MXG examples that use ODS HTML on ASCII that did not have ANAL72GO a PATH= statement failed with ANALACTM ERROR: a COMPONENT C:\.... IS NOT A DIRECTORY." ANALAVAI but only in QA Tests with SAS V9.3; no user had reported ANALDB2B this error, which can occur with SAS V9.1,V9.2, or V9.3, ANALHTML nor had we seen the error with earlier SAS Versions. ANALIDMS SAS Note SN15046 says to eliminate the error you should ANALINIT use this recommended syntax on ASCII platforms: ANALPKGS ODS HTML PATH="C:\mxg\"(URL=NONE) body="temp.html"; ANALRAID Previously, MXG had inconsistent ODS examples; this ANALRANK change formalizes MXG support to create HTML output. ANALS225 -We use two new %macros VMXGODSO/VMXGODSC to OPEN/CLOSE GRAFCEC ODS output in our examples, and they can be used in your GRAFRAID report programs, to create HTML output. The macros can be GRAFRMFI invoked on z/OS to send html output to either a PDSE or GRAFTAPE to a ZFS filesystem, or on ASCII to .html files. GRAFWLM -A consistent set of macro variables are used in arguments GRAFWRKX so %LET's can be used to change ODS argument's values. VMXGODSO change revised all of the MXG members with ODS examples. VMXGODSC -SAS ODS inconsistencies we discovered and handle: Aug 14, 2011 the URL= must be either a quoted string or unquoted NONE, and the STYLE= and TRANTAB= arguments are unquoted. -SAS HTMLBLUE default does not break PROC PRINT output lines, requiring scrolling across to see all variables. ODS LISTING; will change the default back to what you were used to for all interactive output. Change 29.168 Velocity Software XAM variable PERFCPU is now in seconds VMACXAM and formatted TIME12.2 in datasets XMHSTAPP and XMHSTSFT. Aug 1, 2011 Those datasets contain HSTAPP resource usage of a group of processes that form an application (in snmpd.conf or ESATCP 'guessing'). If you want to look at individual processes, you would use dataset VXVSISFT instead. Thanks to Joseph J. Faska, Depository Trust, USA.
VGETWKLD workload names created with (now archaic) IMACWORK logic. Aug 1, 2011 The VGETWKLD internal macro will parse the workload names created by the (now-recommended) WORKnn= arguments that should be used to define workload names in RMFINTRV.
VMACDB2 two 4-byte reserved fields (after QBGLXR and QBGLMR) were Aug 1, 2011 not input, causing all subsequent variables to be wrong. Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY. Change 29.165 -Variable POSIT was incorrectly zero, as only the first 8 VMACRACF bytes of the 10-byte POSITCH field were INPUT as numeric. Jul 31, 2011 -Vars OTHRSPEC/OTHRSPE1 are renamed to FRSTSPEC/OTHRSPEC and re-labeled. Thanks to Bill Arrowsmith, Euroclear, BELGIUM. Thanks to Christopher Roberts, Euroclear, BELGIUM. Change 29.164 Variables S17FBKNM S17SEXNM S17FMFNM are now kept in the VMAC117 S117THRD dataset. Jul 31, 2011 Thanks to Fabio Massimo Ottaviani, EPVTECH, ITALY. Change 29.163 MXG 29.05, Change 29.129 for z/VM Crypto Record (5,10), VMACVMXA from z/VM 5.4, if PRCAPMCT=6, because that subtype does Jul 29, 2011 NOT have the undocumented 32 bytes found in 4 and 8, and this was the first instance of that subtype. Since MXG can so readily circumvent the IBM error (see 29.129), and since this is an (ancient?) z/VM 5.4 record, fixing the doc does not have (appropriately, IMO) high priority, as this is a fairly obscure event - how many do use crypto on z/VM systems, especially z/VM 5.4 systems. Thanks to Tom Draeger, Aurora Health Care, USA. Change 29.162 -Corrections/enhancements to TYPEIMST (IMS56FA TRANSACTs): VMACIMS -STRTTIME and ARRVTIME were reversed in MXG logic. Aug 2, 2011 -But, after fixing, ARRVTIME can be greater than STRTTIME: - Case 1: WFI and PWFI, because the UOR Start Time begins when the previous transaction completes, then the program waits for the next message to appear, so the STRTTIME=ARRVTIME is the wait time of the program. - Case 2: Message Switch; the first transaction's STRTTIME should be greater than the ARRVTIME unless it is a WFI; see case 1, but the Message Switch transaction afterward will have the UOR STRTTIME of the first transaction, therefore the ARRVTIME of the message will be greater than the STRTTIME. In both cases, IF ARRVTIME GT STRTTIME then QUEUETM=0 and SERVICETM=RESPTM and STRTTIME=ARRVTIME to match IMF. -Comparison of QUEUETM/INPQUETM between IMS56FA and IMS has differences of up to 0.1 seconds, because ARRVTIME in IMF has only to 0.1 second resolution while in IMS56FA it has TODSTAMP resolution; this also caused similar small differences between RESPTM/RESPNSTM variable's values. -PROGTYPE in prior data was a one-byte text character, but in IMS56FA it is a more robust bit map, so the data value in the 56FA record is now input into PROGTYHX with $HEX2. format, then PROGTYPE is constructed as a test character. One-byte flag variables are created from PROGTYHX bits: BMP='BMP?' DBCTL='DBCTL?' IFP='IFP?' JAVA='JAVA?' MODE='MODE*MULTI*OR*SINGLE?' MPP='MPP?' REMOTE='REMOTE?' WFI='WFI?' -These variables are now not kept in IMS56FA dataset: TPCPTICH TPCPSOXN and removed from the BY list for that dataset, as they do not exist in that record. -NMSGPROC=1 is set ONLY if CALLMSGU is GT 0 because 56FA records are also written for a Message GU-CALL that did not get a message from the IMS Message QUEUE; for MPPs these show only a small CPU time, TPLTERM is blank, and no calls are counted at all. -TPLTERM was renamed LTERM in IMS56FA dataset. -IMSVERSN is set to 10.1 instead of 10.10. -Either SYSABEND or USRABEND, but not both, are populated; COMPCODE='00000C4000'X correctly set SYSABEND='0C4'; but also incorrectly set USRABEND='U16E3' (i.e. 16,000+). -If there are no GU calls to the message queue, then there is no ARRVTIME, so neither QUEUETM nor RESPTM exist; they are both set to missing values when CALLMSGU LE 0. -IBM APAR PK773284 TPEXTIME IN X'56FA' TRANSACTION LEVEL STATISTICS RECORD IS INVALID WHEN THE UNIT OF WORK ABENDS exists to correct this intermittent problem: TPEXTIME is IMSCPUTM in MXG IMS56FA dataset; values 'FFFFFFFBAFBA5708'x &'FFFFFFFCC4B4F0C8'x occurred in two transactions with SYSABEND='0C4' (but the other 0C4's had zero values. MXG prints an error message for the first five instances, and sets IMSCPUTM to a missing value when an invalid CPU time value is found. Thanks to Rudolf Sauer, T-Systems, GERMANY Change 29.161 MXG 29.03-MXG 29.05, dataset MQMCFMGR was wrong, with 64 VMAC115 identical outputs of only the first segment for each SMF Jul 29, 2011 ID=115 record, if QESTSTR was non-blank in that segment, so there were MANY more obs created than should have been and many valid segments were not output. Thanks to Paul Volpi, UHC, USA. Change 29.160 VMXGFIND failed when dataset names created by SAS were VMXGFIND 32-characters, because VMXGFIND added a prefix of text Jul 28, 2011 "LIBNAME_" to that SAS-created dataset name. Now, if only a single input LIBNAME is found, that prefix is omitted and when there is more than one libname, if the result exceeds 32 characters, only the first 32 are used. Change 29.159 -Support for SAS Version 9.3 requires SAS Hot Fix SN43828. FORMATS This error in SAS Portable Code, in compiling the %macro Jul 26, 2011 %LET statement, and the %SYSRPUT and %SYSLPUT statements, could impact SAS V9.3 on ALL platforms, although it was only detected in MXG QA tests on z/OS, in the members ANALCNCR and VMXGRMFI, both of which invoke %VMXGSUM. The compiler error caused misalignment between the left half (variable name) and the right half (value) of the %LET statement. -On ASCII, 32-bit and 64-bit SAS versions are different operating systems, even on the same platform; so separate "bit-specific" FORMAT directories are required, but the same FORMATs can be used for V9.2 or V9.3 for the same "bit" version. Member FORMATS errored when I tried to run it under 32-bit V9.3, writing to a V9.2 64-bit directory. -On both ASCII and z/OS, SAS Data Libraries can be read or written by either V9.2 or by V9.3, and on ASCII, under either 32-bit or 64-bit environments. Change 29.158 NDM-Connect Direct CT Version 5 record has 4 new fields. VMACNDM There is no version value in the record, but there is a Jul 26, 2011 new offset to 2 of the 4 new fields, so that offset is used to conditionally assume all four are present. NDMJOBID='JCTJOBID' NDMJOBNM='JCTJBNAM' NDMRIP6 ='IPV6*ADDRESS' NDMTYPFK='TYPE*FILE*KEY' Thanks to Eric R. Carlson, Kroger, USA.
VMAC7072 -VMAC7072: These variables removed from DROP statement Jul 24, 2011 LCPUDEXD-LCPUDEXZ LCPUDEVA-LCPUDEUI LCPUWAXD-LCPUWAXZ LCPUWAVA-LCPUWAUI because they never existed; QA test enabled DKROCOND=WARN which caused spurious warning messages. Change 29.156 IDMS/R Performance Monitor for Version 18 adds variables: VMACIDMS -Dataset IDMSTAS: Jul 24, 2011 TASCPTI ='SRB*TIME*ON*CP' TASENTI ='ENCLAVE*SRB*CPU*TIME' TASSYTI ='CPU*TIME*ON*CP' TASTITI ='TCP*CPU*TIME' TASUSTI ='USER*MODE*CPU*TIME' TASZPTI ='SRB*TIME*ON*ZIP' Initial observations were that TASSYTI (.920) = TASTITI (.777) + TASENTI (.143) CPU = TCB ENCL SRB TASCPTI (.016) TASZPTI (.127) TASENTI (.0007) -Added to all datasets, and inserted into the header, so it caused INVALID DATA FOR PMHSDATE messages: SMFHJOB ='PM*JOB*NAME' Thanks to Scott Barry, SBBWorks Inc, USA. Change 29.155 CICS/TS 4.2 Statistics variables now input: VMAC110 Dataset CICISR: Jul 24, 2011 ISRTDBYR='IPCONN*PS*TD*REQS*BYTES*RECEIVED' ISRTDBYS='IPCONN*PS*TD*REQS*BYTES*SENT' ISRTDREQ='IPCONN*PS*TRANSIENT*DATA*REQUESTS' ISRTSBYR='IPCONN*PS*TS*REQS*BYTES*RECEIVED' ISRTSBYS='IPCONN*PS*TS*REQS*BYTES*SENT' ISRTSREQ='IPCONN*PS*TEMP*STORAGE*REQUESTS' ISRUNSUP='ISR*UNSUPPORTED*REQUESTS' Dataset CICWBR: WBRATOMS='URIMAP*ATOMSERVICE*NAME' WBRAUTHE='URIMAP*AUTHENTICATE*USE' WBRREDIR='URIMAP*REDIRECTION*TYPE*USE' WBRSOCPK='URIMAP*SOCPOOL*PEAK*IN*POOL' WBRSOCRC='URIMAP*SOCKETS*RECLAIMED*FROM POOL' WBRSOCTO='URIMAP*SOCKETS*TIMEDOUT*WHILE INPOOL' WBRSOCTV='URIMAP*SOCLOSE*TIMEOUT*VALUE' WBRSOCUR='URIMAP*SOCPOOL*CURRENT*IN*POOL' Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
VMXGSUM that were also perfectly cloned into WPS V8 architecture. Jul 24, 2011 While SAS V8 is no longer supported by SAS Institute and while MXG officially does not always work under V8, these errors encountered in VMXGSUM from VMXGRMFI in BUILDPD3 with both SAS V8 and WPS were circumvented in MXG, and could be useful in avoiding AUTOCALL issues in SAS V9s: -%IF %LENGTH(&A &B) GT 0 THEN %DO incorrectly returned 1 when &A and &B were both null with V8/WPS but returned 0 with all SAS V9s. The error was circumvented by replacing the test string of multiple macro variables with single ORed tests of each macro variable, to avoid the exposure. -The SAS provided-in-SASMACRO-library AUTOCALLed %macro functions %CMPRES/%QCMPRES (which call %QLEFT, %VERIFY, %QTRIM, %LEFT, %QLEFT, %VERIFY and %TRIM) were removed from VMXGSUM, as they were never actually needed, and their removal circumvented V8 and WPS macro errors. I had thought they were needed to compress blanks from the %macro arguments, which are limited to 65584 bytes, and long ago longer argument errors had occurred, but that error occurs when the %macro is invoked, prior to these functions execution. Hindsight is beautiful. Thanks to Scotie Mills, TI, USA.
VMAC111 which incorrectly calculated the SKIP value of bytes to Jul 19, 2011 be skipped in the SMF ID=111, CTGRECID=7 record. Thanks to Victoria Lepak, Aetna, USA. Change 29.152 VMSYSTEM='Y' (Change 29.127) support was revised when RMF VMAC7072 70 records were read. A divide by zero (creating TYPE70 Jul 19, 2011 from WORK.SORT70SP, because ONTM(LCPUADDR+1) was zero, because the VMSYSTEM='Y' records do NOT populate the "on time" in SMF70ONT (which populates ONTM array, and I believe this is a defect that IBM needs to correct, and a PMR has been opened to address this and other issues). However, knowing SMF70ONT is NOT populated, MXG code was revised and SMF70ONT=DURATM when VMSYSTEM='Y', which then corrected calculations of PCTCPUBY for these new records, and logic was revised to correctly capture the actual LPARNAME of the z/OS system that was running under z/VM. ====== Changes thru 29.151 were in MXG 29.05 dated Jul 11, 2011======== Change 29.151 Support for RCD record in ASMRMFV is completed in time to ASMRMFV be included in MXG 29.05, but I procrastinated and did Jul 10, 2011 not complete the updates in VMACRMFV to actually process and create the new variables. You can safely install the new ASMRMFV program to create the RMFBSAM file with RCD data, so that it could be examined when the VMACRMFV has been updated. Contact support@mxg.com if you want the updated VMACRMFV when it's ready. This change will be revised when RCD support is completed. Jan 18, 2012: MXG 29.29 DATED JAN 18, 2012 IS REQUIRED TO PROCESS RCD RECORDS. YOU MUST USE THE NEW ASMRMFV AND THE UPDATED VMACRMFV TO READ RCD DATA. Change 29.150 New ONLYJOBS program creates 'only' the PDB.JOBS dataset ONLYJOBS (but also creates PDB.STEPS, PDB.PRINT, which are needed Jul 9, 2011 to create PDB.JOBS, and creates PDB.SMFINTRV, which may be useful for long running jobs, from SMF 6/30/26, with selection for only some JOB names in the example. Thanks to Jerry Ellis, Liberty Mutual, USA. Change 29.149 CICS/TS 4.2 (SMFPSRVN=67), INVALID VALUE FOR PHTRANNO, VMAC110 in MNSEGCL=5 record; eight bytes were inserted by 4.2. Jul 7, 2011 See Change 29.135, which added Support for CICSTRAN and CICS Statistics records (which was in MXG 29.03 but was not announced). This change is required for CICS/TS 4.2 if your site creates MNSEGCL=5 (dataset CICSRDS) records, but luckily it only causes messages and hex record dumps; it does NOT cause an ABEND. Thanks to Tom Buie, Southern California Edison, USA.
BLDSMPDB control the format of the date in the directories created VMXGALOC by VMXGLOC. The default of DATE7 does not allow you to Jul 7, 2011 sort the directories into an order that puts the directories in calendar order. The only formats that would do that are JULIAN and YYMMDD but the code will accept: DATE MMDDYY DDMMYY YYMMDD and JULIAN with whatever length you specify. If you use one of the MMDDYY etc formats and you specify MMDDYY8. you will get 07-05-11 but if you use MMDDYYN8. you will get 07052011. Change 29.147 Change 29.032 revised dataset PDB.IPLS to only report a VMAC0 true SYSTEM IPL, but the IPLTIME from SMF 90 is on GMT, Jul 5, 2011 so this change uses the SMFTIME of the SMF 90 record for Yüklə 28,67 Mb. Dostları ilə paylaş:
|