* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
show "117" for the STID of that segment, so you cannot find that SJGDS is the DSECT for that STID. 2. The first SJRDS description is actually the PGRDS descrption for the STID=119 segment; the bold face title and the index entry need to be changed to PGRDS. The ID field does not show "119". 3. The second SJRDS description is correct for the STID=118 segment The ID field does not show "118".
ANALDB2R occurrence of QXCRTAB in CREATES=SUM( ... ) should have Aug 15, 2003 been QXCTABS. Thanks to Dr. Yaou-Chun Rickert, Bank One, USA. Change 21.150 -Support for CPU Time fields in SMF 120 WASserver that VMAC120 were put in the SMF record by APAR PQ74463, but were only Aug 13, 2003 documented in the HOLDDATA section of the PTF; Change Aug 19, 2003 21.107 added support for the other new fields. Dataset TYP120WI: SM120WJ4='AVERAGE*CPU TIME' TIME13.6 SM120WJ5='MINIMUM*CPU*TIME' TIME13.6 SM120WJ6='MAXIMUM*CPU*TIME' TIME13.6 Dataset TYP120WA: SM120CPU='CPU*TIME' TIME13.6 Variable SM120CPU was added by Change 21.107, but units were undocumented; I assumed divide by 4096, but the HOLDDATA documentation says microseconds, so the divide was removed. -Spurious "UN READ DATA FOUND" messages from SMF 120 were due to incorrect calculation of SKIP, now fixed. Thanks to Jan ter Laak, Rabobank, THE NETHERLANDS. Change 21.149 -Support for z990 CPUs. INCOMPATIBLE: Variables in data VMAC7072 sets TYPE70PR (LPARCPUS) and ASUM70PR (LPnNRPRC) have VMXG70PR the total number of engines, rather than the number of VMXGINIT online engines in RMF data with new CPUTYPE='2084'x. Aug 13, 2003 MXG tests in VMAC7072 had to be revised for that new Aug 15, 2003 value. The code was corrected in August in MXG 21.04. Aug 22, 2003 (This note was not in the original change; it was Sep 16, 2003 added Sep 16, 2003 to document the requirement). -New PDB.ASUM70LP dataset for LPAR Reporting is easier and safer to use than either the detail PDB.TYPE70PR dataset or the summarized PDB.ASUM70PR dataset. TYPE70PR - Most Detail - One obs for each LCPUADDR in each LPARNAME, so CPs, ICFs, PHYSICALs, and Linux engines are included; reporting must select which obs to use, how/what to summarize, and the criteria keeps changing with IBM hardware or OS level, making your report maintenance complex and exposed. Once PDB.ASUM70PR existed, MXG has always recommended its use, but many user reports were written using TYPE70PR before there was a PDB.ASUM70PR. ASUM70PR - "Platform" summary - All LPARs measured in a single observation, with a set of vars (LP0NAME,LP0DUR,PCTL0BY,LP0MSUHR...) for 32 LPARs. Summarized from TYPE70PR with MXG logic keeping track of what to count, calculating percentages and MSU variables, plus the totals for the "Platform". Very Very accurate and useful, but having all those different variable names makes for very messy coding in your reportings, so: ASUM70LP - A "vertical" dataset built from ASUM70PR. For each online LPAR, one observation is created in ASUM70LP for each LPARNAME, and with only one set of variable names, so you can select and sort and report easily. (This is probably how ASUM70PR should have been originally structured!) You still must select the "production" SYSTEM whose observations are used; each SYSTEM creates obs in all three of the above datasets. -Corrections/enhancement for PDB.ASUM70PR/PDB.ASUMCEC were made in both VMAC7072 and VMXG70PR: .Variables LPnDUR and LPCTnBY in PDB.ASUM70PR/ASUMCEC were sometimes incorrect, perhaps since Change 19.189! Obs with SMF70ONT=0 in PDB.TYPE70PR were included in LPnDUR, so it to be much greater than DURATM*LPnNRPRC, and LPnDUR is used to calculate LPCTnBY percentage.
SMF70ONT - missing - Pre 2064, does not have ONT SMF70ONT - zero - ONT valid and zero SMF70ONT - nonzero - ONT valid and non-zero to be more robust and consistent across hardware, and then VMXG70PR logic that decides to sum this LPARDUR was revised to include old and new but not spares: IF SMF70ONT=. THEN LPARDUR=DURATM; ELSE IF SMF70ONT GT 0 THEN LPARDUR=SMF70ONT; ELSE LPARDUR=0; .For LPARs with no CPUs (LPnNRPRC=0), these LPnXXXXX variables LPnDUR,LPnBDA,LPnLAC,LPnMSU70,LPnNSW,LPnWST are now set missing when LPnNRPRC=0, (i.e, when the LPAR had no CPUs assigned) to be consistent with the other variables that were already missing. .Divide by zero error was corrected in ASUM70PR. -Correction in VMAC7072 for PDB.TYPE70PR var SMF70CIN which could be blank for observations after an offline LPAR, because MXG's test to set SMF70CIN should have been IF NRCIXGTO (instead of NRICFCPU) as the flag that OW37565 was installed. -The CSTORE storage, SMF70CSF, is added for each LPAR in PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC. (ESTORE is a thing of the past; SMF70ESF not added.) See also Change 21.216 if you are back-level on OS/390 or early z/OS and SMF70WLA is not populated in SMF 70. Thanks to Brian Cummings, Federal Reserve Information Technology USA Thanks to Shirley Fung, HSBC, HONG KONG. Thanks to Joe Key, BOC Gases, ENGLAND.
UTILBLDP tailoring when you execute %UTILBLDP "instream", i.e., VMXGINIT when you invoke %UTILBLDP to create an OUTFILE= and then Aug 12, 2003 %INCLUDE that file to execute the BUILD program. Aug 14, 2003 (Previously, UTILBLDP disregarded any tailoring that you Aug 18, 2003 tried to use in a %LET MACKEEP= statement). - If you execute UTILBLDP "instream" with this syntax: %LET MACKEEP= ... tailoring code ... ; %UTILBLDP(..,OUTFILE=zzzzzzzz,...); %INCLUDE zzzzzzzz; the text in your %LET MACKEEP statement text will be stored in the new &MACBLDP macro variable, which is executed by a new &MACBLDP invocation appended to the end of the %LET MACKEEP= statement in zzzzzzzz. - So to execute %UTILBLDP a second time in the same data step to create a different zzzzzzzz program (not sure that you'd ever want or need to), you need to null MACKEEP, or set to a new value, before each %UTILBLDP execute.
this step, but you want to tailor it later with %LET MACKEEP= logic, then you must have a non-blank &MACKEEP when you run %UTILBLDP to create zzzzzzzz, and then you must use %LET MACBLDP= instead of the %LET MACKEEP= statement to pass your tailoring to the zzzzzzzz program. %LET MACBLDP= ... your MACKEEP text ... ; %INCLUDE zzzzzzzz;
there is no &MACBLDP statement created in zzzzzzzz. - The %UPCASEs of macro variables OUTFILE, EXPDBOUT, and IMACKEEP was removed because unix permits mixed case file names. (This is not an exposure under Windows, which sees the same name regardless of the case in its file and directory names).
program to contain the _EPDBOUT invocation, you can specify EXPDBOUT= _EPDBOUT, to create that text. A later iteration of UTILBLDP may let you put SAS statements in its EXPDBOUT= argument.
misspelled and should have been _STY30xx. Thanks to Scott Barry, SBBWorks, INC, USA.
VMXGUOW dataset PDB.ASUMUOW to be wrong, although temporary Aug 11, 2003 internal variable TIMESTMP (which should not have been Sep 23, 2003 kept) was correct and could be used for STRTTIME. The variables HOLDSTRT and HOLDEND were not initialized, but now they are, and so STRTTIME will always equal TIMESTMP. I'd should also drop the redundant variable TIMESTMP, but since you may have used it, I'll hae to continue to keep both STRTTIME and TIMESTMP variables. Note: This change was not in MXG 21.04 nor 21.05. You can correct those versions by inserting HOLDSTRT=TIMESTMP; HOLDEND=TIMESTMP; after EARLIEST=TIMESTMP; Thanks to Pat Curren, SuperValu Inc, USA.
VMACNTSM NRDATA=31 with one new variable added. Aug 9, 2003 Thanks to Roger Zimmerman, Hewitt Associates, USA. Change 21.145 MXG 21.02-21.03, Change 21.090 made variable DATETIME not ASUMCICS exist in the PDB.CICS dataset. Variable STRTTIME should ASUMCICT be used in reports, and it was just fine. Even though ASUMCICX variable DATETIME is a temporary variable that is created Aug 7, 2003 inside VMXGSUM logic, and should not have been kept, it was accidentally added to some datasets, and since some users have used it instead of STRTTIME, it is again created in PDB.CICS so your existing reports that still uses DATETIME won't fail. Thanks to Pat Curren, SuperValu Inc, USA. Change 21.144 Protection for truncated (invalid) SMF 119 subtype 7 VMAC119 record with offsets for 32760 bytes of data, but the Aug 6, 2003 maximum SMF data bytes are 32756. This invalid SMF record caused INPUT STATEMENT EXCEEDED RECORD LENGTH error condition. There either is, or will be, an APAR to correct the SMF 119 record, but this type of bad record is now recognized and the last segment is not input. Thanks to Dan Doan, Verizon, USA. Change 21.143 Support for HMF Release 2.7 (INCOMPAT) changed the EXTYHMFW subtype 29 and 30 records, and added subtype 32 and 33 EXTYHMFX that create new TYPEHMFW and TYPEHMFX datasets. IMACHMF See Change 22.162, which corrected this change. VMACHMF VMXGINIT
Aug 6, 2003 Thanks to John Mitchell, IBM Global Services, USA. Change 21.142 SMF 118 TCP Statistics TYPETCPS dataset values are not VMACTCP interval values, like in the other TYPETCPx datasets. Aug 6, 2003 The _STYTCPS dataset sort macro is revised to sort and deaccumulate the TYPETCPS variables. And to ensure you don't overlook this need, the _STYTCPS dataset sort macro is added in the TYPETCP member; if you have added TCP processing to your BUILDPDB and have added either _STCP (to sort all dataset) or at least the one _STYTCPS sort macro, then your BUILDPDB-built TYPETCPS data will contain legitimate interval values. Thanks to Brian Crow, BT, ENGLAND.
FORMATS message for CPUTYPE=2084 is printed; R2.10 does not Aug 6, 2003 contain SMF70CPA, so MXG must use a table lookup in the Aug 17, 2003 $MG070CP format table. The message only impacts the CECSUSEC and MSU variables, and is eliminated by adding the new CPUTYPE and CPCMODEL to the format. The $MG070CP has been updated for the CPCMODEL=307. 17Aug03: FORMATS updated for all 2084's by Al. Thanks to Jim Horne, Lowe's Companies, USA. Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA. Change 21.140 -Dataset PDB.DB2GBPST DB2 Global Buffer Pool has always VMACDB2 had correct values for the QBGLxxx variables for each Aug 6, 2003 Global pool, but the summarization of those data into the Aug 24, 2003 QBGLxxx variables in PDB.DB2STATS was never right. MXG summed those variables by interval as SMF data was read, but that logic can never work because the data is accumulated by buffer pool within each interval. Since those variables in PDB.DB2STATS have never been valid, all QBGLxxx variables were removed from both PDB.DB2STAT1 and PDB.DB2STATS datasets. -Dataset PDB.DB2STATB DB2 Buffer Pool has always had correct values for the QBSTxxx variables for each of the buffer pools, but their sum in PDB.DB2STATS into the four QB1Txxx/QB2Txxx/QB3Txxx/QB4Txxx variable sets were only correct when there was only one buffer pool in a variable set. Those variables are no longer created in DB2STAT1 during SMF read, but are created by summarization of the PDB.DB2STATB dataset after it as been built by the _SDB2STB macro in SUMSTATB temp dataset that is then merged in _SDB2STS macro to add those variables back into PDB.DB2STATS. -Some old variables that have not existed for several DB2 versions were going to be dropped, but their absence caused TRNDDB2S/MNTHDB2S to die with VARIABLE NOT FOUND errors, so they are added back in, but are always missing value:
QBnTBPX QBnTPFDC QBnTPID QBnTPWU QBnTSWU QBnTWMAX. -B3HITRAT had negative value, due to QBnTxxx errors. -To document in one place, the four buffer sets are: QB1T=BP0 QB2T=BP1 QB3T=BP2-49 (other 4K) QB4T=BP80-89 (32K) BP100-109 (16K) BP120-129 (8K) -And in DB2 V7.1, data for a buffer pool can just stop, perhaps when a pool is no longer used, and that caused MXG's deaccumulation logic to require refinement. Thanks to Sim Williams, Fidelity, USA.
ASUMPRTR dataset with Goal Mode; TYPE72GO was added to the SET Aug 5, 2003 statement to populate SU_SEC. -The second ELSE THRUPUT=.; is now ELSE PCTAFP=.; Thanks to Diane Eppestine, SBC, USA.
VMAC7072 the wrong KEEP= list. These variables: Aug 4, 2003 R723RAPP R723RW01 R723RW02 R723RW03 R723RW04 R723RW05 R723RWRR R723RWRT R723RWST are now relocated to the MACRO _VTY72DL's KEEP list for the TYPE72DL datasets, instead of TYPE72SC's list. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
ASMTAPES devices, creates new SMF subtype to record which job was EXTMNTAR delayed for how long and which tape devices, real or IMACTMNT virtual, were unavailable for allocation. The new subtype VMACTMNT creates observations in new dataset TYPETARC. VMXGINIT The MXG Allocation Recovery Monitor, "ARCV", feature of Aug 4, 2003 the MXG Tape Mount and Tape Allocation Monitor is created Oct 23, 2003 as a sub-task of the MXGTMNT monitor's main task. ARCV's purpose in life is to establish, under Main Console Services, an Extended MCS console whose purpose is to look at those specific console messages that are related to device allocation recovery. When an allocation recovery event starts, information related to that event is maintained for the duration of the event. When the event concludes (device allocated or request cancelled), an SMF record containing information about the event is written.
the existing MXGTMNT address space, both for isolation from the current functionality, and to exploit MVS multiprocessing. The "ARCV" function can be enabled in the ASMTAPES source before assembly with the DOARCV flag (default is ARCV=NO), or the ARCV=YES/NO can be specified in a PARM= or via a Modify operator command, so it can be enabled or disabled at any time without having to restart the MXGTMNT address space. To clean out ASUMTAPES codewebs that were there only for seriously-old-releases of MVS, ML-29 eliminated exposures in archaic code by eliminating the archaic code; ML-29 of ASMTAPES now requires a minimum OS level of OS/390 2.8. Six sites have had ML-29 for several weeks and none have reported any failures, but then none have reported they have tested it yet, either. 22Aug03.
MXG 21.05 did NOT contain ML-29 version. Now it does.
VMACNTSM input CATQUELN, causing the subsequent 85 variables to be Aug 1, 2003 incorrect. And with test data, I found that these variables BYTESRCV BYTESSNT BYTETOTL CONNERRS CONNINBD CONNOUBD MSBYSRCV MSBYSSNT MSBYTOTL MSGRCVD MSGSENT MSGTOTS are accumulated values, rather than interval values; the _SNTSMTP sort macro now does the deaccumulation of those variables. (Others variables may also need to be deaccumulated, but only when I have non-zero data values can I determine what needs to be deaccum'd.) And the Instance Name is only one character long in the NTSMF record - being investigated by NTSMF. Thanks to Xiaobo Xhang, ISO, USA.
ANALSTC MXGTMNT (TYPETMNT) datasets to track STK Virtual Tape Aug 1, 2003 activity. Documented in comments in the member. Note that all of the internal timestamps in the STC records are on GMT; you may need to enable VMXGTIME to set the GMT times back to local time zone before running these reports. Thanks to Chuck Hopf, MBNA, USA. Change 21.134 ASG-TMON V2.2 only. VMACTMO2 Dataset MONITASK, variables NETSNAME UOWID and UOWTIME Jul 31, 2003 were incorrectly input, and TALOUOWID was not input at all. Only critical if you use ASUMUOWT to create PDB.ASUMUOW from MONITASK data. Dataset MONIUTG, variable TAUTGICT was not input, and variable TAUTSTIM has been removed, since it does not exist.
Thanks to Shantha Hallett, CGEY, ENGLAND. ====== Changes thru 21.133 were in MXG 21.03 dated Jul 28, 2003========= Change 21.133 Support for NDM Release 4.3 has been tested with most VMACNDM existing subtypes, but only partial documentation has Jul 26, 2003 been found. New subtypes exist and are protected, but until users require the new subtypes, and their DSECTS are located, the new subtypes are skipped. See the comments in member VMACNDM as to status of individual NDM subtypes. Thanks to Thomas Heitlinger, FICUCIA Karlshruhe, GERMANY. Change 21.132 Tailoring MXG to only create some datasets can cause ADOCDB2 ERROR: NO DATA SET OPEN TO LOOK UP VARIABLES DOCMXG which is the result of trying to PROC SORT a dataset that Jul 25, 2003 doesn't exist. This can happen even when you use _Nxxxx "product null" macro to null out all datasets, redefine a _Wdddddd "work dataset" macro for each one you want, and redefine the _Sxxxx "product sort" macro to list only the _Sdddddd "dataset sort" macros for those datasets that you created: if a later part of your job has an _Sdddddd macro invoked. Most MXG programs use the _Sxxxx product macro, but there are some cases where the individual _Sdddddd macro is invoked, and the SAS/ITSV "BUILDPDB" job invokes several _Sdddddd members, because they were created in MXG before the more-recent _Sxxxx product sort macro was created. The _Nxxxx,_Sxxxx,_Sdddddd etc macros are documented in the DOCMXG member. This example for either MXG or ITSV will keep only the DB2ACCT.DB2ACCT and PDB.DB2STATS datasets. Mar 4, 2004: The earlier example, below, was replaced. See the text of Change 22.020. //SYSIN DD * %LET PDB2ACC=DB2ACCT; %LET PDB2ST0=WORK; %LET PDB2ST1=WORK; %LET PDB2STB=WORK; %LET MACKEEP= %QUOTE( _NDB2
MACRO _WDB2ACC _LDB2ACC % MACRO _WDB2ST0 DB2STAT0 % MACRO _WDB2ST1 DB2STAT1 % MACRO _WDB2STB DB2STATB % MACRO _SDB2 _SDB2STB _SDB2STS % MACRO _SDB2ACP % MACRO _SDB2ACB % MACRO _SDB2ACG % MACRO _SDB2PAT % MACRO _SDB2ST2 % MACRO _SDB2STR % MACRO _SDB2PST % ); %INCLUDE SOURCLIB(TYPSDB2); RUN;
Thanks to Chrisa Neven, KBC, BELGIUM. Change 21.131 The value in SAS macro variable &SYSSCP is the operating VMXGINIT system of this execution, and it returns "OS", "CMS", or VMXGGETM "others" (listed in comments in VMXGINIT). MXG copies VMXGTAPE &SYSSCP into &OPSYS, and tests for "OS", "CMS", or ELSE, VMXGVTOC creating different code on different execution platforms. VMXGTAPE I was misinformed that SAS had changed values of &SYSSCP, VMXGSUM and in revising my code, found inconsistent testing for VMXGDSNL both &OPSYS and &SYSSCP, so all logic now uses only the VMXGDEL MXG-created &OPSYS macro variable, whose value is set in VMACVMXA VMXGINIT. Then my mis-informant RTFM and discovered that VMACVMON it was not the macro &SYSSCP, but instead macro &SYSSCPL VMACUNIK that SAS changed ("MVS" became "OS/390" or "z/OS", with a VMACTPF lower case z!), but MXG never uses &SYSSCPL, so this VMACTAND change was not actually required. But consistent coding VMACOPC is the end result, and I consider the time well spent. VMACMVCI
VMACEREP VMACDCOL See SAS Notes SN/004/004358, SN/006/006346 on &SYSSCPL. VAXPDS Note: If you did want to test &SYSSCPL for that new UTILBLDP "z/OS" value, in macro language, the syntax is PRINTNL %IF %QUOTE(%UPCASE(&SYSSCPL)) EQ %QUOTE(Z/OS) %THEN .. GRAFWRKX
BLDNTPDB ANALDB2R
ANALCISH VMXGRMFI
Jul 24, 2003 Change 21.130 Support for APAR OW56656 for RMF for z990 family adds VMAC7072 variables to existing datasets: VMAC73 - TYPE70X2 dataset VMAC74 R7024EN /*NUMBER OF*CRYPTO*ENGINES*/ VMAC78 - TYPE73 dataset VMAC79 SMF73CSS /*CHANNEL*SUBSYSTEM*ID*/ Jul 23, 2003 SMF73SFL has new bit 2 value Hardware Allows Multiple Channel Subsystems SMF73FG4, MXG variable CHANINDY, has new bit 5 value Chan Characteristics Changed in Interval - TYPE74 dataset SMF74ENF (not kept, has new bit 0 "Extended Mode") - TYPE78 dataset R783GFLG MXG variable IOPIFLG has new bit 6 value Initial-Command-Response measure supported - TYPE78CU dataset new variables: R783CBTM='CU BUSY*TIME FOR*DCM MANAGED*CHANS' R783CMRM='CMR*TIME FOR*DCM MANAGED*CHANS' R783SBSM='SWITCH*BUSY COUNTS*FOR DCM*MANAGED' R783CSST='CHANNEL*SUBSYSTEM*WAIT*TIME' - TYPE78CF dataset new variables: R783CBT ='CU BUSY*DELAY TIME' R783CMR ='INITIAL*COMMAND*RESPONSE*TIME' R783CPXF='CHANNEL*PATH*EXTENDED*FLAGS' R783SBS ='SWITCH*BUSY*COUNTS*ALL PARTITIONS' - TYPE799 dataset R799CNX - new bit 3 value. - TYPE79C dataset R79FLAG - new bit 5 value. New variable: R79CCSS ='CHANNEL*SUBSYSTEM*ID' R79CFG3 - new bit 5 value. - TYPE79E dataset Yüklə 28,67 Mb. Dostları ilə paylaş:
|