* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
the "dsname/file-name" of the input data, but INFILENM is only "input" and is not kept in any DCOL dataset. You could add INFILENM to any DCOL dataset(s) with syntax %LET MACKEEP= MACRO _KDCOLxx INFILENM % ; (and repeat the MACRO _KDCOLxx for each dataset) in your //SYSIN, but this new alternative is now created: -New macro variable &MXGINFIL is created with null value in VMXGINIT, and is added to the KEEP= list for all DCOL datasets. So you could then insert this statement %LET MXGINFIL=INFILENM; in your SYSIN stream, and variable INFILENM will be kept in all of the DCOLLECT datasets Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND. Change 29.295 Version 5.0 of NDM/Connect-Direct added jobname and the VMACNDM JES JCTJOBID to the PS and RJ records. Jan 14, 2012 Thanks to Peter L., whose company won't allow him to be cited. Change 29.294 -Support for Velocity Software segments VNDNIC, LPARNW, EXXMLPAR and protection for USVCPU segment (no data of interest): EXXMDNIC dddddd dataset VMACXAM XMDNIC XMVNDNIC VMXGINIT XMLPAR XMLPARNW Jan 11, 2012 -Some values in XMLPARNW look wrong, and test data doesn't contain fields PCTMGTM nor PCTLOGICAL. Thanks to Robert Obee, IMSHealth, USA. Change 29.293 -Support for CICS Statistics STID=144 adds new dataset VMAC110 CICEPR. Jan 10, 2012 -STID=143 message SKIP=4 with STILEN=156 was eliminated. There was no new data in the record. Thanks to Joachim Sarkoschitz, DATAEV, GERMANY.
BLDSMPDB protected for these variants between WIN and UNIX: VMXGALOC -The XWAIT option is only supported on WIN, causing error Jan 14, 2012 conditions on UNIX and zOS but is now protected. -If NOT EXIST does not work on UNIX, so the logic now used is %SYSFUNC(FILEEXIST(FILENAME)) which returns a zero if the file does not exist, or a 1 when the file exists. Using SYSFUNC also allows the MXGNOTES to only appear when we actually create or delete a directory. -md (or MD) is not recognized on UNIX as make directory so the full mkdir command name (in lower case) is now used. -rmdir (rd) is used to remove directories under Windows, but the UNIX command is rm with different subparameters: on Windows the command is rd /q /s on UNIX the equivalent is rm -r -These changes do not impact z/OS execution of BLDSMPDB. They have been tested under AIX 5.3, RedHat LINUX, and should work on all xNIX platforms. Thanks to Ruth Larsen, CA Technologies, USA.
ANALGRID some arguments were not UPCASE'd, and some selection Jan 14, 2012 arguments were not printed on the log when used. Examples added and footnotes formats match grid formats. Thanks to David Bixler, FISERV, USA.
VMACSMF record (HISTORY FILE FOR TS7700 VTS TAPE SYSTEM) caused Jan 2, 2012 a USER ABEND 69, because MXG logic for a bad SMFTIME was VMACBVIR intended to catch the reading of a non-SMF file. This is VMACNAF the FIRST time an actual customer has ever ABENDed due to my choice, which I now realize is too harsh, so now, only the ERROR message is printed by default. You can enable the ABEND with %LET MXGABND=1; in your SYSIN. (BVIR records are supported in MXG's TYPEBVIR code.) -A second SMF record type, from VTAM SuperSession product, also caused the USER ABEND 69 because its Julian date had an invalid Julian date of 637 in 2012! Two in two days!! MXG's TYPENAF supports those SMF records, but the last update was in 2005, and they have been incompatibly changed, with new subtypes and inserted data fields; MXG will be updated when doc is available. Thanks to Jim Horne, Lowe's Companies, USA. Thanks to Jorge Fong, NYC Information Technology, USA. Change 29.289 The ASMDBLKU program is an ASM version of UDEBLOCK, that ASMDBLKU constructs a valid VBS file on z/OS from a V/VB/VBS file Dec 30, 2011 that was previously downloaded to an ASCII platform, as that file is just a serial stream of bytes that cannot be "back-loaded" and read on z/OS. You upload the file from your ASCII platform back to z/OS, and then UDEBLOCK or ASMDBLKU will read those chunks and reconstruct those records into a valid VBS file on z/OS. This would likely be needed only if IBM or another vendor needs for you to send the VBS file for a problem, and you only have the downloaded file. UDEBLOCK required SAS on z/OS while ASMDBLKU doesn't. Additionally, UDEBLOCK was functional but VERY expensive for DASD space, since it created a single block for each record and wrote one record per track. ASMDBLKU is smarter and wastes no DASD space. Multiple enhancements were made to the original ASMDBLKU: -The SMFOUT file is now generated as a true RECFM=VBS file so no DCB overrides in JCL are required to process it subsequently into a PDB build. -QSAM blocking is now used so that SMFOUT disk space requirements are significantly less than before when only one record per 32K block was output. -The PGSER macro system service SVC call to zero the output buffer after each I/O was replaced with MVCL logic thus providing up to a 64% CPU time reduction seen in testing.
-The SMFOUT file now has DCB BLKSIZE=0 to use System Determined BLKSIZE. Up to a 41% further reduction in disk space usage was determined in testing. -SMFIN and SMFOUT files now use DCB BUFNO=20 to reduce elapsed time with up to a 33% time reduction seen in testing. There was some corresponding increase in below the line storage, but the program ran successfully with REGION=2M. -Most ASMDBLKU messages are reformatted for improved clarity, legibility, and content. -There are now separate and distinct messages for length errors for the SMFIN physical block, BDW, and RDW values respectively. Previously, these types of error were not disclosed. -Length error messages now show the invalid length value and the related record number. -The SMFIN file is now checked for RECFM=U and DSORG=PS prior to any processing. -SMFIN and SMFOUT byte counts are now accumulated and reported. SMFOUT byte counts do NOT include the BDW fields added by QSAM. Up to 19 decimal digit totals are supported (9,999,999,999,999,999,999). -Minimum and maximum LRECL values read from the SMFIN file are now reported as message DBLKU25I. -Minimum and maximum LRECL values written to the SMFOUT file are now reported as message DBLKU26I. -A missing DD statement for SMFIN or SMFOUT now generates Return Code 16 as a severe error. -Two character Return Codes are now displayed. Before Return Codes higher than 8 were not supported. -Record counts for SMFIN and SMFOUT files are now scaled up to 9 decimal digits (999,999,999). -Message DBLKU30I indicating final utility status is now the last message displayed. -Message DBLKU30I ended message is consistent in appearance and format with DBLKU00I started message. -PRINT OFF/PRINT ON added to suppress printing of the change log during assembly. -Prologue comments outside of the assembler source have been updated. Change 29.288 Reserved Change. Dec 30, 2011 Change 29.287 Many VMWARE objects were revised to contain xxxxVMHO and EXNTDTSC xxxxVMGU (Host and Guest names), changing NRNAMES, which IMACNTSM caused MXG NRNAMES Messages. New DTS.ALERTCONFIG object TYPENTSM is supported. VMACNTSM VMXGINIT
Dec 31, 2011 Change 29.286 Variable LPARCPUS was incorrectly typo'd as LPARCPU. Been ANAL113 this way since 2010, so I assume either no use, or users Dec 22, 2011 recognized and fixed the typo without report to support, so Thomas gets this citation for finding the old error. Thanks to Thomas Puddicombe, CSC, USA.
FORMATS NO error with 9.3 TS0202M3 nor 9.1.3/SP4 nor 9.3 on z/OS. CREATEBC A split line in EBCDIC text for $MGZOSVT caused no error PROCSRCE when PROC FORMATS created $MGZOSST/$MGZOSVT, but the two Dec 22, 2011 formats could not be loaded when TYPEZOSA was executed by TESTUSR1. The original ASCII text had a unexpected '0A'x character (Line Feed) in that line, but that only caused the EBCDIC text to be split there; no unprintable text character was created in EBCDIC, and the longer right hand value was still valid syntax, and was handled fine on all other z/OS SAS versions. -However, the unexpected '0A'x in ASCII text reminded me to look for other unprintables in the EBCDIC text, and three values ('01'x,'1C'x,'1D'x) are now detected in the PROCSRCE/CREATEBC QA members, and corrected before EBCDIC members are created for distribution. Fortunately, none of these characters cause execution errors. Thanks to Scott Wiig, US Bank, USA. ====== Changes thru 29.284 were in MXG 29.08 dated Dec 20, 2011========= Change 29.284 ANALGRID creates a color-intense grid report of the value ANALGRID of any variable, with time intervals as columns and date Dec 20, 2011 as the row, to visually identify "hot spots". This is based on the original design that was contributed by Bob. See http://www.mxg.com/downloads, ANALGRID for examples. Thanks to Robert A. Obee, IMS Health, USA. Change 29.283 MXG 29.06-29.07. RMFINTRV with INTERVAL less than QTRHOUR VMXGRMFI created an invalid PDB.RMFINTRV dataset with too many obs Dec 20, 2011 but with ERROR: INCONSISTENT RMF DATA printed on the log. Change 29.194 added TYPE75 summary data to RMFINTRV, but had INTERVAL=QTRHOUR instead of INTERVAL=&INTERVAL. Thanks to Yves Terweduwe, CIPAL, BELGIUM. Change 29.282 The example summary of TYPE72GO to create ASUM72GO was ASUM72GO updated to support "SYNC59" data written at :59 or :00 Dec 20, 2011 intervals. Thanks to Brian Carter, HP Enterprise Services, ENGLAND. Change 29.281 New CPUTASKTIMETM=ADDRESS*SPACE*DISPATCHED*TASK CPU TIME VMAC30 and PCTTASKTIME=PCT WHEN*TASK WAS*DISPATCHED*ON PHYSICAL BUILD005 variables are created in TYPE30_V and PDB.SMFINTRV data BUIL3005 sets, to report the interval percentage of time when an Dec 18, 2011 address space was dispatched on a physical processor. PCTTASKTIME can exceed 100% when multiple tasks are used for parallelism; values more than 25% are probably of most interest. You can create the variables from your PDB.SMFINTRV (or TYPE30_V) dataset, using: CPUTASKGCPTM=CPUTCBTM-CPUASRTM-CPUENCTM-CPUDETTM; CPUTASKZAPTM=(CPUIFATM-CPUEFATM-CPUDFATM)*256/SMF30ZNF; CPUTASKZIPTM=(CPUZIPTM-CPUEZITM-CPUDZITM)*256/SMF30SNF; CPUTASKTIMETM=CPUTASKGCPTM+CPUTASKZAPTM+CPUTASKZIPTM; IF INTRVLTM GT 0 THEN PCTTASKTIME=100*CPUTASKTIMETM/INTRVLTM; Thanks to Bernie Pierce, IBM, USA. Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT: ASMTAPEE "YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO. Dec 20, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P." But there is NO NEED to ASM a new load module under 1.13; your currently executing MXGTMNT module works just fine!
incompatible change, which impacts OPEN/CLOSE macros, but doesn't mention any by name: DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement in DFSMS macros; required if you have code that invokes DFSMS macros (but not all!). Before z/OS V1R13, many DFSMS macros that did not support 64-bit or AR mode did not react to being invoked in 64-bit or AR mode, and generated code that might have been invalid in 64-bit or AR mode. Starting with z/OS V1R13, these macros are changed to issue an assembly-time message and suppress expansion if they are invoked in 64-bit or AR mode." -But as noted above, you didn't really need to ASM. Now, from MXG's "asmguy", his comments on this change: Nothing is going to happen to an existing site using MXGTMNT and in fact the modification I have to make for this does not result in any change to the executable code.
a flag that tells any macros that support AR mode (Access Register, used for cross memory access) to use their AR mode compatible expansion. Macros that don't have an AR mode expansion used to ignore this because they had nothing to do, and it's always the coder's responsibility to make sure that when those non-AR compatible macros are executed, that the system is not in AR mode. This is similar to switching back and forth from 24-bit to 31-bit mode: some macros can't tolerate 31-bit mode. Nothing has really changed though; it is still the coders responsibility to make sure the system is not in AR mode and macros that can't tolerate AR mode still can't, except now IBM is requiring the coder to explicitly set SYSSTATE to indicate to the assembler that the system is not in AR mode. Of course this is all very silly because the assembler can't know ahead of time that the system is or isn't in AR mode. So regardless of whether or not SYSSTATE is coded this way the system still could be in AR mode, OPEN/CLOSE will still expand the same way, and if the system really is in AR mode OPEN/CLOSE will abend when executed. So the bottom line is that nothing has changed except our need to do something for no reason at all. -This ASMTAPEE is now ML-48 in the MXGTMNT startup msg. Thanks to Thomas Maguire, CitiGroup, USA. Change 29.279 -ASMRMFV incorrectly calculated the RCDSDI offset, causing ASMRMFV an INPUT STATEMENT EXCEEDED RECORD LENGTH error, when an Dec 13, 2011 RCD Table Record had an RCDSD Subsystem Delay array, but the record didn't have an RCDRD Response Time array. -Also a formatting error in message RMFV102I was corrected *** END OF DATA *** showing record input count. Thanks to Scott Chapman, American Electric Power, USA.
VMAC28 buffer size of 180 Kbytes), and without the DATA segment Dec 8, 2011 for buffer size 64Kbytes. The segment length is the 176 expected length, so this circumvention skips the invalid segment if size is 180 and doesn't input the last data segment; when IBM fixes the record, the circumvention does not need to be removed. APAR OA38371 will correct the error, ETA Feb, 2012. Thanks to Karen Florup, Bank of America, USA.
VMACRMFV where ASIDMN, DOMAIN, was previously located. ASIDMN is Dec 8, 2011 set to zero, its value ever since domains departed z/OS.
CLRMFV from the TSO LISTCAT LEVEL command. Dec 8, 2011 -3 messages indicating the error, the data set name level, and the Return Code are now issued. -In addition, the first 4 lines of LISTCAT output for the error condition are displayed. -Prior to this change CLRMFV could issue a non-zero MAXCC message at completion and the reason was difficult to determine when LISTCAT was involved. -A non-zero LISTCAT Return Code is most commonly caused by a data set name level that does not exist. Thanks to Rodger Foreman, Acxiom CDC, USA. Change 29.274 CA-1 TMS "Extended Format TMC Catalog" records are COMPAT VMACTMS5 with ALL versions of MXG, as there was NO change in the Dec 7, 2011 TMC's 340 byte record's length. The text of Change 28.040 that thought there were new length(s) was wrong and gone. Change 29.273 -Support for subtypes 34 and 35 of SYSVIEW for IMS creates EXSV34DA dddddd dataset description EXSV34TR SV34TR SV34TRAN Subtype 34 Transaction EXSV35EV SV34DA SV34DAC Subtype 34 DAC Segment EXSV35TR SV35TR SV35TRAN Subtype 35 Transaction IMACSVIE SV35EV SV35EVNT Subtype 35 Event Segment VMACSVIE -There are errors in the subtype 34 and 35 that I have VMXGINIT circumvented in this iteration, and SYSVIEW support has Dec 7, 2011 confirmed the errors in the 34 and are looking at similar errors in the 35 record; both will likely be corrected in a future PTF from CA. The value in IMRA_DBIOTIME is appears to be defective, also. Thanks to Anthony G. Hurlston, CSC, USA.
VMAC120 were INPUT as PIB, so a negative field becomes a large Dec 7, 2011 positive value in MXG. They are now input as IB. IBM Support reports than when work does not complete, ENDTIME isn't populated, and since CI is calculated as END-START, you get a negative value. But you can also get a negative value of -1 if WebSphere was unable to reach its internal service that supplies the END time: for example, an in-flight transaction when the server was configured to "Drain" work during termination, but that transaction still could have completed normally, so all of the other fields could be completely valid. IBM chose to NOT suppress these records even when they might contain incomplete values, because many other data values could be useful in diagnosing problems, and there should be relatively few of these records. You probably should filter these records from your daily reporting totals, but rather than testing for a negative value in CI/CX, which have valid transaction data, IBM Support suggests to exclude transactions that have any value in the minor code, SM1209CJ, and perhaps to simply count the number that were excluded. -Variable SM1209BM now has value '7.0.0.15' instead of the value '7.0.0.*' when the fourth byte was GT 9. Thanks to Wayne Bell, UniGroup, Inc, USA.
VMAC79 connect/pending/disconnected time is not valid. All Dec 6, 2011 other bits were already decoded into unique variables. Thanks to Heimir Hauksson, Barclays, ENGLAND Change 29.270 Variable POUNAL was incorrectly multiplied by 4096 when VMACQACS it should have been multiplied by 1024 to convert KB to Dec 6, 2011 bytes. Thanks to Thierry Wehrle, BNP Paribas, FRANCE Change 29.269 CA TLMS tape library records were changed sometime since VMACTLMS 2003 when the MXG TYPETLMS was last updated, causing the Dec 5, 2011 TYPETLMS dataset to contain mostly trashed field as MXG INPUT BAUNIQUE and BAVOL1ST as PIB4 but they appear to be only 2-byte fields. Thanks to Gene Palmer, CitiGroup, USA Change 29.268 The new ASUM4HRS %macro calculates "Four Hour" running ASUM4HRS Average Values of the variable(s) you chose, but any VGETFMT integer number of hours can be used instead of "Four". VGETLABL -New VGETFMT/VGETLABL/VGETLEN internal macros retrieve the VGETLEN FORMAT, LABEL, and LENGTH of a variable so that the new VMXGDUR Average Value variable will have the same attributes as VMXGSUM the inputted variable. VMXGPARS -VMXGDUR,VMXGSUM adds duration tokens for EIGHTHR and Dec 13, 2011 TWELVEHR. These duration tokens now can be used: ANNUAL, SEMIANN, QUARTER, MONTH, WEEK, DATE, SHIFT, TWELVEHR, EIGHTHR, FOURHOUR, THREEHR, TWOHOUR, HOUR, HALFHOUR, TWENTYMIN, QTRHOUR, TENMIN, FIVEMIN, THREEMIN, TWOMIN, MINUTE OR SECOND, or DETAIL. -VMXGPARS now parses at two blanks to create a new line. Change 29.267 Variable MPL72, the average number of concurrent resident VMXGRMFI ASIDs, is now created in PDB.RMFINTRV dataset. Variables Nov 29, 2011 APPCAVG and APPCMAX to count those ASIDs are also added. Thanks to Chuck Hopf, Independent Consultant, USA. Change 29.266 In TYPE70PR dataset, variables SMF70MSU and SMF70LAC are VMAC7072 output in each TYPE70PR obs, but from the one TYPE70 obs Nov 29, 2011 for "THIS" LPAR, so they are repeated for all LCPUADDRs in this LPARNAME (being kept here only so they can be in ASUM70PR). Since they are z/OS-only relevant, they are now only populated in the SMF70CIN='CP' observations as their non-missing value in obs for VM, ZIIPs, etc, was unexpected and unwanted. Thanks to Lars Fleischer, SMT Data, DENMARK.
VMAC42 -Macro token PSUVMXA added in Change 29.120 was misspelled VMACCIMS as PSUMVXA in the GLOBAL statement in VMXGINIT. VMACNTSM Also, the hardcoded PDB. in MACRO _LTYVMXA PDB.VMXAINTV VMACTPMX in the (optional) ASUMVMXA member was corrected to the VMXGINIT default &PVMAINT macro destination DD for VMXAINTV. Nov 29, 2011 -TYPECIMS variables TRNSTRTA/TRNSTARTU/TRNSTOPA/TRNSTOPU are no longer kept in CIMSTRAN as they are GMT offsets that are already used to convert times to local zone. -Variable VWGMACBY was accidentally removed from the NTSMF dataset VMWGUMEM. -TYPETPMX variables JBL54051,JBL55044-JBL55051 were always missing values, DKROCOND=WARN printed warnings due to typos in the variable name in the assignment statements. All of the JBL54xxx and JBL55xxx are also now labeled. -TYPE42 variables SMF42PTE and SMF42PTS are now labeled. Thanks to Chris Weston, SAS ITRM Development, USA.
VMXGCNFG for z/OS for future cases when more than one temporary DD MXGSAS is required. Currently, only SMFSRCH uses that DDNAME. Nov 25, 2011 Change 29.264 Support for DFSORT for z/OS 1.13 adds COMPATIBLY two new VMAC16 variables to TYPE16 dataset: Nov 25, 2011 ICEMCPUZE='ZIIP*ELIGIBLE*CPU*TIME' ICEMCPUZP='ZIIP*ACTUAL*CPU*TIME' Change 29.263 Variables SMF30JQT/SMF30RQT/SMF30HQT/SMF30SQT are missing BUILD005 values in PDB.SPUNJOBS for jobs that had TYPE30_5 job BUIL3005 term obs with MULTIDD='Y' (which have only EXCP counts.) Nov 25, 2011 And those TYPE30_5 with MULTIDD='Y' shouldn't ever have been used in BUILDPDB logic; MXG uses the step records for EXCP counts and only wanted the TYPE30_5 values from the "real" TYPE30_5 that has MULTIDD=' '. So this change deletes MULTIDD='Y' observations during processing of the TYPE30_5 records in BUILDPDB and BUILDPD3. Yüklə 28,67 Mb. Dostları ilə paylaş:
|