* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
revised when that logic has been added and tested. Thanks to Jerry Urbaniak, Acxiom CDC, USA. Thanks to Lawrence Jermyn, Fidelity Systems, USA.
VMAC7072 created but not validated, and my guess to add SMF70HOF VMAC89 was incorrect; test data shows that SMF70HOF is to be Apr 7, 2006 subtracted in VMAC7072 to get back to true GMT. May 1, 2006 May 1: test 89 data confirmed SMF89HOF is also to be subtracted in VMAC89 to create MACHTIME; Change 24.063. Thanks to Manfred Giezendanner, Credit Suisse, SWITZERLAND. Thanks to Gion Cabernard, Credit Suisse, SWITZERLAND. Change 24.040 CICS/TS 3.2 iteration 2 time fields 12 bytes, April. VMAC110 CICS/TS 3.2 iteration 3 time fields Pib8.8/4096. Apr 7, 2006 Sep 21: UTILEXCL expanded for Iteration 3. Sep 19, 2006 Oct 14: Updates for the changed Statistics Subtypes Oct 14, 2006 (INCOMPATIBLE except for DST,DSR,MNG): STID DSNAME New Variables added. - 2 SMS ==> Nothing New in DSECT. - 64 CICDST DSTCIUHI DSTCIULO DSTNIUHI DSTNIULO
==> But 20 bytes added are not doc'd. - 65 CICDSR DSRCIULO DSRCIUHI ==> But 20 bytes added are not doc'd. - 67 CICFCR DFHA17DS DSECT. ==> Nothing New in DSECT - 74 MQG MQ Connection Statistics Global New
==> DFHMQGDS DSECT does not exist - 81 MNG New Compression Variables ==> DFHMNGDS DSECT is not current. -109 ISR IP Connection (Resource) New
==> DFHUSRDS DSECT does not exist -117 SJG
==> Nothing New in DSECT. -117 SJR
==> Nothing New in DSECT. Change 24.039 New example program to create a Monthly PDB from only the JCLMNTHW six weekly PDBs that might be required to span the prior MONTHWEK month when only WEEK PDBs are to be read. This example can be run on any day of the next month to create last Apr 7, 2006 Month's PDB library. You would still need to tailor: May 4, 2006 JCLMNTHW - the _SELDSN macro to list only the datassets that you want created, and MONTHWEK - delete two lines (MACRO _DSET, MACRO _BYLIST) for each dataset that you do not want created. May 4: Revised to read 6 weekly files; while only five are needed for the normal MONTHBLD on the first of the month, some months (July 2006) would need to read six weekly PDBs to create that month's PDB if only the week PDBs were to be read. Thanks to William Carroll, Grange Insurance, USA. Thanks to Jim Horne, Lowe's Companies, Inc, USA. Change 24.038 "ERROR: UNABLE TO CREATE PDB.MXGENG.DATA BECAUSE VIEW VMXGENG PDB.MXGENG.VIEW ALREADY EXISTS" with MXG 24.01 BUILDPDB Apr 5, 2006 occurs only if OPTIONS='USER=PDB' was specified For BUILDPDB that option should never be used. It tells SAS to write all datasets that would have been written to the //WORK DDname, to instead be written to the //PDB DD. But the BUILDPDB design is to write first to the //WORK DD, sort and write the output to the //PDB DD, so you can get I/O between volumes and not hammer the //PDB DATASET by read and write to a single PDB library for both work and output. The VMXGENG code used to create MXGENG as a VIEW, and with USER=PDB, that created PDB.MXGENG.VIEW in the //PDB library each day, but you can replace a SAS VIEW with a SAS VIEW of the same name. But Change 23.328 revised VMXGENG to create a DATASET of the same name, rather than a VIEW, and (for reasons I don't understand) SAS will not let you replace a VIEW with a DATASET, so this error occurred when the new MXG Version wrote to a //PDB that had been created by the prior version, that still had the VIEW. By removing the USER=PDB option, the MXGENG and similar MXG internal facilities' data will be written to //WORK which is temporary and goes away at job step end, so the replacement of a VIEW with a DATASET never is an issue. Thanks to Karen Fry, Comerica, USA. Thanks to Theresa Johnston, Comerica, USA. Change 24.037 A new version of the CLRMFV TSO Clist, the driver for the CLRMFV ASMRMFV RMF Monitor III decompression utility, plus major DOCLRMFV enhancements in the documentation in the DOCLRMFV member. Apr 4, 2006 This CLRMFV version reduces the number of ASMRMFV calls for users with many LPARs, and provides more flexibility to specify the input and output data sets, so perhaps it reduces the need to tailor CLRMFV or at least is easier. There are no changes required for the ASMRMFV program. Enhancements: A new parameter CALLBY() lets the user control the granularity of the RMF Monitor III data passed to ASMRMFV in each call. CALLBY(DSN) invokes ASMRMFV once for each and every RMF Monitor III data set. This setting is NOT recommended due to overhead and is only included for compatibility with earlier versions of CLRMFV. CALLBY(SID) invokes ASMRMFV once for each unique LPAR and is compatible with CLRMFV default behavior in prior versions. CALLBY(ALL) invokes ASMRMFV once for all LPARs and is ideal for users (such as our installation) who want to process many LPARs at once with ASMRMFV with minimal overhead. CALLBY(ALL) is the new default. The ONECALL() parameter is now obsolete. If ONECALL(NO) is coded, it is converted to CALLBY(DSN). If ONECALL(YES) is coded it is converted to CALLBY(ALL). ONECALL() will be removed entirely in a future version of CLRMFV, but is here so you have plenty of time to remove it and use the CALLBY() instead. A new parameter INLLQ() lets the user specify the low level qualifier if needed for the input RMF Monitor III data set names. The default is null. Similarly a new parameter OUTLLQ() lets the user specify the low level qualifer for the output sequential data set(s). The default is OUTLLQ(RMFIII) and produces the same data set name as in prior CLRMFV versions.
the allocation method for the output data set(s). There are three possible values: NEW, MOD, and OLD. The default is OUTDISP(NEW) and produces the same behavior as prior CLRMFV versions. See the DOCLRMFV documentation member for more details. Regardless of this parameter setting ASMRMFV always appends data from multiple input files into the output file(s). Only the initial output file allocation procedure is affected by OUTDISP().
SMS Data Class for the output file(s). The default is null. This is a companion to OUTMCL() and OUTSCL() parameters which were available in the prior version for SMS Management Class and SMS Storage Class respectively.
non-SMS volume serial(s) for the output file(s). The default is null.
maximum volume count for the output file(s). The default is null. The z/OS maximum is allowed 255 and CLRMFV will validate the value. A new parameter OUTDEV#() allows the user to specify a device count for the output file(s). The default is null. The z/OS maximum allowed is 59 and CLRMFV will validate the value. A new parameter TS() allows the user to specify time stamping on CLRMFV messages. The default is TS(NO) and only the very first and last messages are time stamped. TS(YES) causes all CLRMFV generated messages to be time stamped and so provides the behavior in prior CLRMFV releases. TS(NO) reduces CLIST overhead. CLRMFV will now validate that the length of the total PARM field passed to ASMRMFV does not exceed z/OS 100 character maximum and fail if this is not the case. As before the //SYSIN DD in JCL can be use to provide additional ASMRMFV parameters to overcome this z/OS limitation. The DOCLRMFV documentation member is enhanced, expanded, and clarified to explain all the new parameters. Migration Issues: With the new CLRMFV default of CALLBY(ALL) the single output file size will be now the sum of space used for all the prior LPAR files with the old CLRMFV version . The SPACE() parameter will need to be increased substantially if output is to DASD to avoid SB37 abends or alternately the output file will have to be directed to tape. The new OUTDEV#() parameter can also help with the additional space needs by spreading the space needed over multiple volumes.
because initialization, termination, and summary code is only used once instead of once for each LPAR. Users who prefer not to make changes to support CALLBY(ALL) should specify CALLBY(SID) to get the prior behavior.
of the form &OUTHLQ.ALL.&OUTLLQ where &OUTHLQ is the value of OUTHLQ() and &OUTLLQ will be the value of OUTLLQ(). So DSN= on the //RMFBSAM DD statement in the MXG RMF III PDB Build step will need to be changed accordingly. A DD concatenation of files from multiple LPARs will no longer be required and the extra DDs should be removed. Since all RMF Monitor III data sets will be dynamically allocated at once with CALLBY(ALL), users may need to substantially increase the value of DYNAMNBR= in their JCL invoking CLRMFV. Otherwise the Dynamic Allocations done by CLRMFV can fail. The TIOT SIZE parameter in the ALLOCxx member in SYS1.PARMLIB ultimately determines the maximum size value allowed for DYNAMNBR=. This is discussed in the DOCLRMFV member. As a side effect since CALLBY(ALL) results in ASMRMFV being invoked only once, the ASMRMFV summary report produced will be for the grand totals from all LPARs instead of 1 summary report per LPAR as in the prior version. Users who want the earlier behavior should use CALLBY(SID). A special thanks to Acxiom leadership for allowing this effort to continue to go forward. Thanks to Jerry Urbaniak, Acxiom CDC, USA.
VMACRMFV RMF III ASI table in z/OS 1.7, although IBM will issue Apr 4, 2006 a documentation change in the future. This change tests for ASIVERE3 GE '10'X to skip the extra 8 bytes. Thanks to Jerry Urbaniak, Acxiom CDC, USA. Thanks to Rodger Foreman, Acxiom CDC, USA. Change 24.035 XAM SYS error INPUT STATEMENT EXCEECED LENGTH was caused VMACXAM by an unexpected value of 'FFFF'x in the NSIMBUSY field, Apr 4, 2006 or 65536 decimal, for the number of fields in the array HFCHSIM that follow this count, which MXG tried to read when there were no fields following. Now, MXG detects this value, and bypasses the logic to read any elements of HFCHSIM array. The 'FFFF'x value is actually -1 if input as Integer Binary, and is set by XAM because IBM no longer keeps track of concurrent channels in use, so there no longer is an HFCHSIM array to INPUT. Thanks to Brian Carter, EDS UK Mainframe Hosting Services, ENGLAND. Thanks to Jeff Gribbin, EDS UK Mainframe Hosting Services, ENGLAND.
DOC (e.g., a four-byte character variable DEVCHAR='1F1A') Apr 4, 2006 into a numeric variable that contains that hex value Apr 20, 2006 (e.g., a two-byte numeric variable DEVNR=1F1Ax when it is FORMATed hex4.) can be done using the HEXnn INFORMAT in an INPUT function: DATA; DEVCHAR='1F1A'; DEVNR=INPUT(DEVCHAR,HEX4.); FORMAT DEVNR HEX4.; will store the decimal value 7962 in DEVNR, which will be printed as 1F1A with the HEX4. format. This change was rewritten on April 20, when the HEXnn. format was suggested in a SAS-L posting by Jiann-Shiun Huang. Below, is the original April 4 change text:
variable that contains a hex value in EBCDIC text into a numeric variable with the value formatted as HEX. For example, if DEVCHAR='1F1A' is DEVNR='1F1A'x, then this code will create numeric variable DEVNR: DEVNR= 4096*INPUT(PUT(SUBSTR(DEVCHAR,1,1),$MGHEXC.),2.)+ 256*INPUT(PUT(SUBSTR(DEVCHAR,2,1),$MGHEXC.),2.)+ 16*INPUT(PUT(SUBSTR(DEVCHAR,3,1),$MGHEXC.),2.)+ INPUT(PUT(SUBSTR(DEVCHAR,4,1),$MGHEXC.),2.); The $MGHEXC format was created to decode SYSLOG character Device Number, but can be used for any hex-text . Thanks to DJ Chen, Florida Department of Corrections, USA. Thanks to Jiann-Shiun Huang, AmerUs Group, USA. Thanks to Nick Johns, Sainsbury, ENGLAND. Change 24.033 When UTILEXCL detects CMODNAMEs of EZA01 and EZA02, you IMACICE2 must tailor members IMACICEZ, IMACICE1, and IMACICE2 to Apr 4, 2006 process those data. The fields INPUT in IMACICEZ and E2 are consistent at all sites, but the number of fields in the IMACICE1 exit varies from site to site, so if MXG's REPORT ONE lists IMACICE1 to be tailored, you must then look at REPORT THREE to see exactly which fields are in your data, and will have to change the INPUT and LABEL statements if your data does not contain all twelve of those fields. This list is an excerpt of REPORT THREE that is overlaid with the MXG variables that are INPUT.
CMODHEAD CMODNAME MXG VARIABLES EZA01 INIT S 001 8 TCPINITM TCPINICN EZA01 READ S 002 8 TCPREATM TCPREACN EZA01 WRITE S 003 8 TCPWRITM TCPWRICN EZA01 SELECT S 004 8 TCPSELTM TCPSELCN EZA01 OTHER S 005 8 TCPOTHTM TCPOTHCN
CMODHEAD CMODNAME MXG VARIABLES EZA01 EZA01 A 001 4 EZA01A01 EZA01 EZA01 A 002 4 EZA01A02 EZA01 EZA01 A 003 4 EZA01A03 EZA01 EZA01 A 004 4 EZA01A04 EZA01 EZA01 A 005 4 EZA01A05 EZA01 REUSABLE A 006 4 EZA01A06 EZA01 ATTACHED A 007 4 EZA01A07 EZA01 EZA01 A 008 4 EZA01A08 EZA01 EZA01 A 009 4 EZA01A09 EZA01 EZA01 A 010 4 EZA01A10 EZA01 EZA01 A 011 4 EZA01A11 EZA01 EZA01 A 012 4 EZA01A12 MEMBER=IMACICE2: CMODHEAD CMODNAME MXG VARIABLES EZA02 CONN A 001 4 EZA02CON EZA02 STARTED A 002 4 EZA02STA EZA02 INVALID A 003 4 EZA02INV EZA02 DISTRAN A 004 4 EZA02DIT EZA02 DISPROG A 005 4 EZA02DIP EZA02 GIVESOKT A 006 4 EZA02GIV EZA02 SECEXIT A 007 4 EZA02SEC EZA02 NOTAUTH A 008 4 EZA02A08 EZA02 IOERR A 009 4 EZA02A09 EZA02 NOSPACE A 010 4 EZA02A10 EZA02 LENERR A 011 4 EZA02A11 (See also text of Change 25.018.) Compare your UTILEXCL report with those three IMACICEx's. The IMACICEZ and IMACICE2 should always match; contact support@mxg.com (send UTILEXCL report) if they don't. If IMACICE1 in your REPORT THREE ends with "ATTACHED" as the last field (i.e, you only have 7 fields in EZA01), then must EDIT the IMACICE1 member into your tailoring: -change the test for MCTSSDRL to GE 28 instead of GE 48 -delete the LABELs for variables EZA01A08 thru EZA01A12 -change the INPUT statement to read INPUT (EZA01A01-EZA01A07) (&PIB.4.) @; -You create REPORT THREE with the _RPTEXCL macro run with or after your UTILEXCL execution: //SYSIN DD * %INCLUDE SOURCLIB(UTILEXCL); _BLDDICT; _BLDEXCL; _RPTEXCL; -This change added text in labels for EZA02A08-EZA02A11 with their contents (NOTAUTH,IOERR,NOSPACE,LENERR). -This text was revised Oct 10, 2007; see Change 25.215. Thanks to Erling Andersen, SMT Data A/S, DENMARK.
VMAC7072 to be too small, for CPs that were not online for a full Apr 3, 2006 interval. The recalculated PCTCPUBY used DURATM in the Apr 5, 2006 denominator instead of SMF70ONT for these CPs. -NRCPUS was wrong if an LPAR is WLM Managed AND the LPAR has any IFAs, which affected many PCT calculations. When an LPAR is WLM Managed, (LPARWLMG='Y'), MXG used variable SMF70BDA=SMF70BDA/SMF70DSA, documented as the average number of engines under WLM control, as NRCPUS, but impossible values of 10.27 for a system in a CEC with only 10 CP engines was observed. Using the sum of SMF70ONT (online time of each engine) showed there were only 8.27 CP engines online during that interval, and IBM's own Partition Data Report had 8.3 for the Average Processor NUM for that LPAR for that interval. In reply to my "impossible" value allegation, IBM RMF Development replied that SMF70BDA samples include both CPs and IFAs, and thus the 10.27 value was not impossible, as there were 8.27 CPs and 2 IFAs online; however it is a completely useless value to use for anything. As a result, the MXG calculation of NRCPUS is now always calculated from the sum of SMF70ONT for CP engines, and SMF70BDA is no longer used for NRCPUS. And SMF70BDA will also include zIIPs, if any exist. Thanks to Marco A. Micchia, Uniocredit Global Info Services, ITALY.
ASUMTAPE for their dictionary updates: VMAC80A -VMACTMNT: Variables SYSLDDN,SYSLDSN now labeled. VMAC94 -VMAC80A : Variables TSREADTI,TSTIME now formatted, TSTIME VMACTMNT is now KEPT in TYPE80TS dataset. VMXG70PR Variable TOKDANAM now labeled. VMACTMO2 -VMXG70PR: Formats for new variables added for 60 LPARs Apr 3, 2006 were missing in ASUMCEC dataset. Apr 10, 2006 Sort order in _BSU70PR was incorrect, but it was not used, so only caused confusion and deceptive documentation. Correct BY list is SYSPLEX SYSTEM SYSNAME SMF70GIE -ASUMTAPE: Instances of %VMXGWORL inside the MACRO _DEBUG require double percent signs. -VMAC79: Variables R799CNX2-5 were incorrectly decoded. R799CNX is now labeled even though its decoded. -VMAC94: Variables S94XLCSI/S94XLCLS are now kept; they had been misspelled as XCLSI/SCLSL. -VMACTMO2: Label for TAWRDCT corrected; QA stream now tests for duplicate/different labels. Thanks to Chris Weston, SAS Institute ITRM, USA.
TYPEUSAR YY to YYYY; code was revised to support either format. Apr 3, 2006 Thanks to Greg Meyer, ITresources, USA. Change 24.029 ERROR.CMRFILE. FILE SEGMENT LENGTH IS 16 BUT 220 EXPECTED VMACMVCI messages are eliminated. The two file segment sizes are Apr 2, 2006 supported. The short segment will cause missing values in most variables in CMRFILE, but the data is valid. Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
VMACDB2 Preemptable SRB CPU Time consumed by SRBs in the Address Apr 1, 2006 Space named in QWSnASID. Note that this SRB CPU time in the new QWSnPSRB variable is included in QWSnSRBT. Thanks to Roger L. Rush, Nav-International, USA. Thanks to James S. Lazowski, Nav-International, USA. Change 24.027 SQL Text in DB2 102 Audit Trace IFCIDs 140,141,142,145 VMAC102 was missing after Change 24.01, for DB2 Version 7 and Apr 1, 2006 earlier, because QW014nLE was only INPUT for DB2 8.1. Now, IF QW014nLE=. THEN QW014nLE=QW014nLL; corrects. Thanks to Jim Kovarik, AEGON USA, USA.
FORMATS $MGSYSIP format definition. Apr 1, 2006 Thanks to Lars-Olof Thellenberg, Svenska Handelsbanken, SWEDEN. Change 24.025 Five 4-byte SYNCSORT fields had expanded 8-byte fields VMACSYNC that MXG failed to use when the 4-byte fields were full. Apr 1, 2006 These variables are now reset if their 8-byte field is greater than their 4-byte field: CHARACTS INRECS OUTRECS INSERTS DELETES Unfortunately, the input and output byte count variables, SIBYTES and SOBYTES exist only as 4-byte fields and do not have 8-byte counterparts. Thanks to Lawrence Jermyn, Fidelity Systems, USA.
E2TY70 -Most MXG datasets are "SIMPLE" or "One Phase": obs are E2TY70PR OUTPUT to a _Wdddddd dataset in the _Edddddd exit macro VMAC7072 (which %INCs the EXdddddd exit member) from the raw data, Apr 1, 2006 then _Wdddddd is sorted to create the _Ldddddd (PDB). May 1, 2006 For those datasets, code in the EXdddddd member can be used to create new variables and label them, and the _Kdddddd macro is used to KEEP those new variables. -But when datasets are created in a "Second Phase", those original EXdddddd exit cannot be used for your SAS code that creates your new variables; instead, you must use a new exit member, the "Second Phase" exit. The name of the member is E2dddddd, to be somewhat consistent with the original EXdddddd naming; your SAS code to create or modify variables, and LABEL, FORMAT or LENGTH statements would be put in your E2dddddd exit member. Note: all variables you create in that exit member will automatically be KEPT, so you do not need to list them to be kept. In fact, if you create any temporary variables in your exit code, you would need to DROP them so they won't be kept in the output dataset. -The old EXdddddd exit member had an old-style macro counterpart, MACRO _Edddddd, which could be redefined in your IMACKEEP member. So this new "Second Phase" exit member also has an old-style macro counterpart, named MACRO _2dddddd, which can alternatively be used to tailor these datasets. -The SPLIT70 redesign changed the creation of TYPE70 and TYPE70PR datasets from "SIMPLE" to "SECOND PHASE", and thus invalided the use of EXTY70/EXTY70PR exit members to add variables to the TYPE70 and TYPE70PR datasets, so this first implemenatation of "Second Phase" exits are the E2TY70 and E2TY70PR members added by this change. May 1: SPLIT70 redesign documentation, related note: You cannot drop these variables SYSPLEX SYSNAME SMF70GIE SMFTIME from TYPE7xxx RMF datasets. They are required to reassemble the pieces, and the MXG logic. -Example to add SHIFT to the PDB.TYPE70 and PDB.TYPE70PR datasets you would need to add these two old-style macro redefinitions in your IMACKEEP tailoring member: MACRO _2TY70 %%INCLUDE SOURCLIB(IMACSHFT); % MACRO _2TY70PR %%INCLUDE SOURCLIB(IMACSHFT); % Thanks to Lawrence Jermyn, Fidelity Systems, USA. Thanks to Warren Cravey, Fidelity Systems, USA. Yüklə 28,67 Mb. Dostları ilə paylaş:
|