* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
| Change 23.275 Support for CA TopSecret SMF 80 records with SMF80DTP of
EXTY80TS 103,104,105,109,255 values. This is preliminary support, IMAC80A as the DSECT does not exactly match the SMF record, so VMAC80A further validation is required. Dataset TYPE80TS is VMXGINIT created from all of those DTP values. Oct 28, 2005 Thanks to Chris Hober, Charles Schwab, USA. Thanks to Neil Ervin, Charles Schwab, USA. Change 23.274 The MACRO definition for MACRO _N120 was missing the text VMAC120 MACRO for each of the _NULL_ entries; attempting to use Oct 27, 2005 the _N120 macro to null out all datasets failed. Thanks to Xiaobo Zhang, ISO, USA. ====== Changes thru 23.273 were in MXG 23.08 dated Oct 27, 2005========= Change 23.273 NOT SORTED error in building PDB.ASUMCEC (error was right VMXG70PR after the - IFA2 FOR CEC note on the log) can occur with Oct 27, 2005 some data values. The reset of STARTIME to the nearest minute (in EXCECTIM) caused the out of order condition, which is now corrected by a PROC SORT. Thanks to Joe Montana, Acxiom, USA. Change 23.272 -First MXG 23.08 only. ARRAY SUBSCRIPT OUT OF RANGE error VMAC7072 due to MXG logic introduced in Change 23.237 to count IFA Oct 27, 2005 and IFL engines using the (new-in-z9) SMF70CIN values in new NRIFACPU and NRIFLCPU variables (which are non-zero ONLY if you have a z9 processor that puts IFA and IFL in the SMF70CIN field). The new logic was fine, but the new LCPUADDR values that are greater than the number of real engines in the LPARNAME='PHYSICAL' caused the failure. The solution was to relocate the LPARNAME='PHYSICAL' test that sets MXGCIN='PHY' above the test for LCPUADDR. -New MACHTIME was in the year 2041; the SMF documentation had SMF70HWM after SMF70LAC, but the new SMF70HOF field was inserted between LAC and HWM in z/OS 1.7. Thanks to Joe Montana, Acxiom, USA. ====== Changes thru 23.271 were in MXG 23.08 dated Oct 25, 2005========= Change 23.271 An unknown NAF record segment caused the record to be VMACNAF DELETEd, so subsequent segments were not OUTPUT. The Oct 22, 2005 DELETE was removed and the number of messages limited, and a hex dump of the first five unknown records is now printed on the SAS log. When documentation for the 'C0' segment is found, the segment causing the problem will be supported. Thanks to Joe Babcock, JPMC, USA. Change 23.270 Due to popular demand, though I really fail to see the VMAC7072 need, I've put back the individual IFA engine percentage Oct 21, 2005 busy variables, PCTIFBY0-PCTIFBY9,PCTIFBYA-PCTIFBYX in Oct 25, 2005 the KEEP= list for dataset TYPE70. Oct 25: And now, they have non-missing values; those variables were added in 22.09 and then removed, but even in 22.09 their values were always missing. Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA. Thanks tO Lawrence Jermyn, Fidelity Systems, USA
VMACVMXA had not been data-tested for accumulated data values. Oct 21, 2005 Now, ESCON variables ECMCPBTC and ECMCPBTL and FICON variables ECMCBC ECMCCWUC and ECMCCWUL are DIF()'ed. ESCON and FICON observations have different variables populated; variable CSCCMCMG identifies FICON/ESCON. The default _TESTMW macro invokes the _SSYTEMP macro that does the actual deaccumulation. -Bit CALINIT was on in one observation, uncovering a data record that must be used to initialize the DIF() function but then must be delete. Thanks to Melanie Hitchings, BT, ENGLAND. Thanks to Brian Crow, BT, ENGLAND.
TYPE79 fields are accumulated and some are not, and IBM doesn't VMAC79 choose to document which is which, so real data is needed Oct 20, 2005 to know that these variables had to be deaccumulated: R799PCT R799ALC R799ATV R799CMR R799CNN R799CUB R799DIS R799DPB R799DVB R799MEC R799PEN R799SCC R799QUE R799UTL in the _STY799 "Dataset Sort Macro, which is invoked by the _S79 "Product Sort Macro". -The TYPS79 member did invokes the _S79 macro, but that is now also added to the TYPE79 member so you don't accidentally create only the accumulated datasets. -Variables R799DPB and R799PCT have clearly invalid values but IBM documents them as "not used". Thanks to Jerry Ellis, Liberty Mutual, USA.
IMACICO1 OPID variable in CICSTRAN dataset, but only if UTILEXCL UTILEXCL was used to create an IMACEXCL, and only if a dictionary VMAC110 record had that CMODHEAD entry, and only if the comment Oct 20, 2005 block in member IMACICO1. Thanks to Lucy Fukishima, California Health and Welfare, USA. Change 23.266 Documentation. DFSORT SMF Release 16 SMF 16 records are VMAC16 already supported; there have been no changes to the IBM Oct 20, 2005 SMF 16 SMF record since Release 14.
VMXGINIT IFA and IFE CPU times were always zero; Change 23.123 did VMXGRMFI not correctly create those workload variables. Oct 20, 2005 -Logic was added to VMXGRMFI in Change 23.215 to determine Nov 3, 2005 if a VIEW could be used, but macro variable name VGETENG was not GLOBALed in VMXGINIT, which caused SAS error that MACRO VARIABLE UNRESOLVED errors! Nov 3: Text updated. Adding VGETENG also required there be a //INSTREAM DD, which has been in MXGSAS JCL for years, but I never told ITRM this change made it now required that their JCL also have this DDNAME.
Nov 28: See Change 23.298 which eliminated the use of the //INSTREAM in VGETENG to avoid this exposure. Thanks to Wolfgang Vierling, Allianz, GERMANY.
VMACSARR IF SV31IOF+SV31ILN-1 LE LENGTH AND SV30ILN GE 1 THEN DO; Oct 19, 2005 should have been: IF SV31IOF+SV31ILN-1 LE LENGTH AND SV31ILN GE 1 THEN DO; Thanks to Wim Desmecht, NV INFOCO, BELGIUM.
VMXG70PR concatenation of CPUTYPE and CPCMODEL, was increased from Oct 12, 2005 $8 to $10 because an Amdahl GS2108E system has 2000-2108E for CPCFNAME, which wouldn't fit in 8 bytes. Thanks to Steve Rowe, DST Systems, Inc, USA.
BUILDPDB VARIABLE LOCLINFO HAS BEEN DEFINED AS BOTH CHAR AND NUM Oct 12, 2005 DATASET WORK.TYPE30_4 MAY BE INCOMPLETE The error is due to a corrupted SPIN library (due to a prior failure when testing a %UTILBLDP or BUILDPDB run that didn't complete successfully). - If this is still in testing, and there WAS nothing of value in the SPIN library, then you only need to use PROC DELETE DATA=SPIN._ALL_; and can then re-test. - If this should happen after BUILDPDB/UTILBLDP is in production and you had data in the SPIN data library (VERY RARE, because you had to have done something to MXG to cause this failure and then tried to run the production BUILDPDB job), then you must restore the //SPIN data library to the way it was prior to what you did that caused the failure, from the last PDB data library from the last succesful BUILDPDB. This is easy, because BUILDPDB backs up your SPIN library datasets into each PDB data library, so you would use: //YESTER DD DSN=YOUR.LAST.PDB,DISP=SHR //SPIN DD DSN=YOUR.SPIN,DISP=OLD PROC COPY IN=YESTER OUT=SPIN; SELECT SPIN: ; (the 'colon' is the wildcard in the SELECT statement). Change 23.261 Invalid Extended Segment section in SMF 14 record caused VMAC1415 INPUT STATEMENT EXCEEDED RECORD LENGTH error; MXG logic Oct 11, 2005 tried to read the rest of the record after detecting this bad segment, but the rest of this record was also trash, so now, the error messages are printed: ***ERROR.TYPE1415.EXTENDED INFO SEGMENT DEFECTIVE TYPE1415 OBSERVATION WAS NOT OUTPUT.' and the rest of the INPUT is now skipped. Thanks to Sidney Owens, District of Columbia Government, USA.
VMACVMXA said "PAGE*FAULTS*MINOR*ONLY" but the field contained the Oct 6, 2005 MAJOR*ONLY faults. This change creates PGFAUMJ with the Oct 13, 2005 MAJOR*ONLY faults, and corrects the value in PGFAUMI so it is the MINOR*ONLY to match it's label. Oct 13: Original divide changed to multiply. Thanks to Kris Ferrier, State of Washington DIS, USA.
VMACWYLB with _ID; this change adds the "standard" ID maro name of Oct 4, 2005 MACRO _IDxxxx nnn % to replace those archaic spellings, but the original macro can still be used, since the code IF ID=_oldname OR _ID= _IDxxxx THEN DO; is used in these members: Oldname Standard _WYLBUR _IDWYLB Thanks to Freddie Arie, Merrill Consultants, USA.
EXSYSIDL dddddd Dataset Description EXSYSIEV SYSITR SYSITRAN SYSITR: SYSV/IMS TRANSACTION EXSYSIPG SYSIPG SYSIPGM SYSIPG: SYSV/IMS PGM EXSYSISC SYSIDL SYSIDLI SYSIDL: SYSV/IMS DLI EXSYSITI SYSISC SYSISCH SYSISC: SYSV/IMS SCHEDULE EXSYSITR SYSITI SYSITIM SYSITI: SYSV/IMS TIMERS FORMATS SYSIEV SYSIEVT SYSIEV: SYSV/IMS EVENT IMACSYSI This code is still in early testing, but because all of TYPESYSI the test file has only the TRN, CNT and CLK segments, and TYPESYSI exactly one each, and multiple segments doesn't make any TYPSSYSI sense for the transaction, I now combine those three into VMACSYSI a single obs in the SYSITRAN dataset. Because none of VMXGINIT other segments are populated, the code, for now creates a Oct 5, 2005 separate dataset for each segment, which may or may not be the final design. -Also, there is undocumented data in the records. While the triplet count is 3 and the first three triplets are populated for the TRN, CNT, and CLK segments, the eighth triplet, "WRK" is also populated, pointing to a segment with at least 8 populated TODSTAMP fields, but the WRK segment is not described in the DSECT. Thanks to John Rivera, (i)Structure, USA. Thanks to Ken Steiner, (i)Structure, USA. Thanks to David Zelmer, (i)Structure, USA.
VMACTPMX though the actual INPUT was INPUT TEMP $VARYING16. And, Oct 4, 2005 variables JBBND and JLIMT should have had $VARYING17. as they can contain two levels and a period. So, lacking a clear knowledge of exact maximum lengths, I folded all of the $VARYINGnn (nn=6,14,16,64,80), into (nn=17,80) using only TEMP17 and TEMP80 variables to set the kept lengths. Note that as long as the MXG default option COMPRESS=YES is still in effect, essentiall no space was wasted even when the length was $200. Thanks to Lawrence Jermyn, Fidelity Systems, USA.
ASMRMFV could be incorrectly issued, ASI data would be missing Oct 4, 2005 and ASMRMFV would set Return Code 4. Thanks to Jerry Urbaniak, Acxiom CDC, USA. Change 23.255 The text for several TNG metrics in $MGTNGVN format were FORMATS truncated in their VALUE statement, printing MXG messages Oct 3, 2005 about UNKNOWN fields. Fields 31,34,36,37,46,and 113 for the NT data for the SMPT Server Object were corrected. Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
ADOCMWSU updated with the REPORT command syntax that creates the VMACMWSU data fiels with the fields that TYPEMWSU expects. Oct 3, 2005 -VMACMWSU's test for TYPE was expanded to test 'TRAN' so Oct 5, 2005 those records will now be output. Thanks to Albert Jacobs, KBC Bankverzekieringsholding, BELGIUM. Change 23.253 Initial rewrite of the ASUMTAPE program that combines ASUMTAPE MXG's Tape Mount TYPETMNT data with IBM's Tape Dismount VMACTMNT TYPE21 SMF data to create PDB.ASUMTAPE dataset, with the VMAC21 start and end times of the mount, the dismounted time, Sep 30, 2005 and bytes read, written, and any tape error counts. Oct 19, 2005 Because the "Exit-Driven" architecture of ASMTAPEE ML34+ captures all mounts and populates all JOB-related data, only the PDB.TYPETMNT and PDB.TAPES (a/k/a TYPE21) are needed to create PDB.ASUMTAPE. (PDB.TYPETALO was used to populate missing fields when mounts were sampled.) -The SPIN.SPINMOUN and SPIN.SPIN21 will hold incomplete mount/dismount records, to be reintroduced tomorrow. -These variables, from the allocation event, are no longer created in PDB.ASUMTAPE: ALEERROR ALOCEND ALOCSTRT ALOCVLTM RDRTM SMFUCB SMFVOL01 TERMNAME TMNT008I XMEMABND -These job-related variables were only in the Allocate record; they are now created in PDB.TYPETMNT and will be created in PDB.ASUMUOW, but they will be blank until the ASMTAPEE monitor program adds them to the mount record: PROGRAM RESGROUP RPTCLASS SRVCLASS WLMNAME -VMAC21 now sets BLKSIZE=. if SMF21LB is not on. -"Group" definition macros, _GRPMNNM and _GRPMNCD, are now added in ASUMTAPE to group SYSTEMs that have overlapping DEVNRs. Using the example in the comments to create a _GRPMNNM variable, ASUMTAPE groups BY _GRPMNNM DEVNR so each "location/group" is analyzed correctly. -A macro _DEBUG is defined in ASUMTAPE, and when invoked it will print a log of the sequence of mount, dismount and allocation records for diagnostics if there is a problem case observed; if you can also send the JOBLOG of the job(s) involved, it will help our investigations. -This revision is in early testing; it appears to work perfectly when there is a match of mount/dismount, and it recognized back-to-back dismounts (i.e., missed mount) in variable STATUS, but it needs extensive validation and comparisons to the SYSLOG of weird cases before I can fully say it's ready for prime time. -In testing this revision, I discovered that ASMTAPEE at ML-34 thru ML-36 do NOT capture all tape mounts in their exit logic: these are two known cases of missed mounts: - Multi Volume Mounts - Only first Mount is captured in the IBM Volume Mount Exit; STK's HSC exit sees all. - DFHSM Mounts to 3590s - None captured, but mounts for other jobs on 3590s are captured. An investigation by "asmguy" has just been started today as a result of this (unwanted!) discovery, which will likely require SLIP traps, dumps, and possibly multiple iterations to find out why these mounts were not seen. -Oct 19: Macros _grpALxx are renamed to _grpMNxx to be consistent; AL is for allocation and MN is for mounts, and ASUMTAPE should be used instead of TYPETMNT for tape mounts. -See further revisions in Change 23.300 and later. Thanks to Normand Poitras, IBM Global Services, CANADA. Thanks to Beau Chavis, Bank of America, USA. Thanks to Jim Sherman, Lockheed-Martin, USA.
VMACTMS5 now DEVTYPE='STK9840-C' is decoded for that TRTCH value. Sep 29, 2005 DEVTYPE='STK9842' already was decoded for TRTCH='E7'X. Thanks to John Gebert, FDIC, USA. Change 23.251 Enhancement to set TRANNAME in PDB.ASUMUOW from CICSTRAN VMXGUOW observation in each Unit of Work that was not the CSMI Sep 29, 2005 transaction but that had the longest IRESPTM duration, as a more robust identification of the "real" transaction. Thanks to Chuck Hopf, MBNA, USA.
TRNDCACH member; it is needed to protect the first-time-through, Sep 28, 2005 when the TREND.TRNDCACH member doesn't yet exist. All other TRND members had that option, so I assume it was inadvertently deleted. Thanks to Tom Kelman, Commerce Bank of Kansas City, USA. Change 23.249 Using %READDB2 to process DB2 Trace 102 SMF record now ANALDB2R decodes the DBID and OBID values, if you enabled 105/107 READDB2 IFCIDs, and those records are in the input SMF data file. VFMT102 (Previously, only the %ANALDB2R report printed the real Oct 22, 2005 names of the OBID or DBID). Formats $MGDB2DB/$MGDB2OB are created by VFMT102 member, used by both ANALDB2R and VMAC102, if 105 or 107 records were found, but only cover the time frame of the trace, since DBID and OBID can change. The 105/107 records are only written at OPEN, and the formats use the timestamp range of the data read by READDB2, so you may still find $HEX4. values for the DBID and OBID variables some of the time. Thanks to Chuck Hopf, MBNA, USA.
EXDB2ACC were subsequent end comments that apparently prevented an Sep 22, 2005 error, as this was observed by Bruce, rather than the result of a reported error condition. Sometimes, a missing end comment, even when there are subsequent ends for other comments, has caused strange errors. Thanks to Bruce Widlund, Merrill Consultants, USA.
ASMTAPEE Monitor introduced in ML-35 that cause a major increase Sep 22, 2005 in the CPU time of the MXGTMNT task. Thanks to Normand Poitras, IBM Global Services, CANADA. Change 23.246 Support for adding un-sorted datasets to your WEEKly PDB. WEEKBLD MONTHxxx programs supported adding unsorted datasets by WEEKBLDT using MACRO _BY % MACRO _SORTBY % in place of WEEKBLDD the normal MACRO _BYLIST var1 var2 % definition, but the WEEKBL3 WEEKxxxx programs were not revised to define those two WEEKBL3D macros, until now. As a reminder, once these two macros WEEKBL3T have been specified, all subsequent datasets will be Sep 16, 2005 treated as non-sorted, so the un-sorted dataset build macros should be at the very bottom of your EXPDBWEK or EXPDBMON tailoring member. Thanks to Cheryl Heiner, State of Montana, USA.
REXXWLM converted to two single quotes (''), which could cause a Sep 16,2005 SAS error. Thanks to Sam Bass, McLane Company, USA. Change 23.244 NO LONGER TRUE, FIXED BY SAS IN 2005. Original text: VGETDDS Using MXG's %VGETDDS(DDNAMES=XYZ: ...) and %VMXGSET to VMXGSET read from all SAS data libraries in your JCL that have Sep 16, 2005 DDNAMES starting with "XYZn" can fail to read all DDs, but ONLY if you have installed the IBM PATCH for HSM that is documented in IBM APAR OY63500, and ONLY if one of the "XYZn" datasets is independently being migrated by HSM! That PATCH allows HSM to bypass normal DSENQ protection; the site runs an HSM job every 30 minutes to migrate data from ML0 to ML2. The HSM task started the migration, and then the MXG job started to run (because DSENQ had been bypassed). VGETDDS tests each XYZn DD with PROC SQL to find its ENGINE, but SAS did not recognize that XYZ3 was a SAS Data Library in its DICTIONARY.MEMBERS table (due to its migration-in-progress status), so VGETDDS saw UNKNOWN engine, and stopped its search for other XYZn DDNAMES when the first UNKNOWN engine type is found.
was never opened by SAS, so the OPEN ABEND discussed in the IBM APAR text never happened.
PDBs to be migrated by HSM while trying to use one, there is no possible MXG fix for this error; the only clues that there was an error was that many fewer obs were read than expected, and/or the VGETDDS message on the log explicitly said it only found two XYZn DDNAMES. (But the whole point of VGETDDS/VMXGSET is so your JCL determines how many XYZn DDNAMES are read, and so you DON'T have to tell me how many to expect!). The only way to prevent I can think of is to put these PDB libraries in a dataclass that is not migrated by the interval task, to eliminate the exposure. Change 23.243 Enhanncement to RMF III VSAM support ASMRMFV/TYPERMFV. ADOCRMFV -ASMRMFV corrects a few issues, reduces CPU utilization by ASMRMFV use of MVCL instruction, and adds the ASI Extension that CLRMFV had been requested by Lawrence Jermyn, along with other DOCLRMFV minor changes. The ASI Extension improves the ability to VMACRMFV subset and group RMF Monitor III data for historical Sep 15, 2005 analysis at the Address Space level. This version also Sep 16, 2005 offers additional Assembly Language symbolics to let you tailor the ASMRMFV defaults. -CLRMFV: There are no changes to the CLIST; its just here as a reminder that it is used to process RMFV data. -ADOCRMFV: Extensive notes on what Jerry did are added! -DOCLRMFV: Updated notes. -VMACRMFV: Variables ASICNM ASICDE ASICWN ASICRN ASICPO ASICPN ASICGI ASICWI ASICRC ASIRNM ASIRDE ASIVERG3 were added to ZRBASI dataset. ASIVERG3 values '0F'x and greater indicate that the zAAP fields are present in the records.
-Sep 16: Old SVP Buffer Table cleanup added. Thanks to Jerry Urbaniak, Acxiom CDC, USA. Change 23.242 Support for SMF type 82 subtypes 20 and 21 is added. EXTY8220 Subtype dddddd Dataset Description EXTY8221 20 TY8220 TYPE8220 Crypto Coprocessor Timings FORMATS 21 TY8221 TYPE8221 ICSF Sysplex Group Change IMAC82 -In TYPE8220, MXG variables NQAPDQAP and DQAPWAIT are the VMAC82 calculated delta times between TNQ-TDQ and TDQ-TWT, after VMXGINIT using the TWT-SMFTIME delta to create GMT82OFF. Since it Sep 12, 2005 is the coprocessor duration, and not time of day, that is of interest, the original SMF82TNQ, SMF82TDQ and SMF82TWT variables are not kept. -SMF82TSF, Coprocessor sub function code is not documented in the SMF manual; it is a $HEX4. value, and will be formatted when it's possible values are known. -SMF82TRN will be missing until you install z/OS 1.7. -TYPE8221 code has not been tested with records, yet. Thanks to Ian Arnett, TD Canada Trust, CANADA. Change 23.241 Two more typos: NR25SEGS in the WHEN (24) group should VMAC80A have been NR24SEGS, and NR44SEGS in the WHEN(43) group Yüklə 28,67 Mb. Dostları ilə paylaş:
|