* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
value, and have not been divided by their sample count. Please validate that the variables of interest to you do match their RMF III screen values, and let me know if you find any needed corrections for MXG variables. Thanks to Thom Kight, Fidelity Systems, USA.
VMACDB2 QWAX segment, but I failed to realize that most of those Feb 5, 2001 QWAX fields were existing QWACvvvv variables, with some new QWAX fields. Instead of extending QWAC, IBM created the new QWAX segment; if it exists, your QWAC fields are all zero. I should never have created the QWAXvvvv names. So this change now stores the QWAXvvvv values in QWACvvvv variables that exist, and creates new QWACvvvv variables for the new QWAX fields. I should DROP the QWAXvvvv variables now, but I can't do that without warning, as those few of you who found the QWAX variable names would have reports failed, so this is your warning: Do Not use QWAXvvvv variable names. Use their QWACvvvv counterpart instead. Variable names starting with QWAXvvvv will go away soon! And if you want to drop them now, with this change, you can use the _KDB2ACC macro to drop them, with: MACRO _KDB2ACC DROP= QWAXALCT QWAXALOG QWAXANAR QWAXARNC QWAXARND QWAXAWAR QWAXAWCL QWAXAWDR QWAXOCSE QWAXSLSE QWAXDSSE QWAXOTSE QWAXOCNS QWAXSLNS QWAXDSNS QWAXOTNS QWAXAWFC QWAXFCCT QWAXIXLE QWAXIXLT QWAX fields so your existing and future programs work with the same QWACvvvv names in your future reports, and this change accomplishes that: use QWACvvvv instead of QWAXvvvv in any reports you write. QWAXxxxx variables should not have been created at all, but since I can't safely DROP them without warning, here is your warning: Don't USE DB2ACCT variables named QWAXxxxx; Instead, use QWACxxxx with the same suffix Thanks to Alan Winston, MBNA,USA. Change 18.347 Support for SYNCSORT Release 3.7 (COMPAT) adds variables. VMACSYNC SYNCSORT now permits up to 100 SORTWORK DDs, so VMACSYNC Feb 8, 2001 can creates up to 100 sets of variables for each sort work area, but the MXG default is 32, previously the max that SYNCSORT allowed. You can increase the number of sets of variables if you have more than that: -You can change it permanently by adding this statement in your IMACKEEP member to re-definite the default value: MACRO _NSYNCWK 100 % -Or, to increase it just for this execution of TYPSSYNC, you can change it "Instream" with this in your //SYSIN: %LET MACSYNC= MACRO _NSYNCWK 99 % ; (you can track variable NRWRKUSE in TYPESYNC to see if more than 32 sort works are being used). Note: Dec 2001: The DDnames are SORTWK00-SORTWK99, but SAS will start with SORTWK01 and not use SORTWK00. Thanks to Chuck Hopf, MBNA,USA.
ASUMTALO when tape drives are switched between systems, because of Feb 3, 2001 slightly different timer pops on different systems. One event with ALOCEND=11:22:05.79 on SYSA was followed by an event with ALOCSTRT=11:22:05.60 on SYSB. The overlap is always less than the monitor interval (2 second default); code inserted into an existing step now detects any such overlap and resets the ALOCSTRT to the previous ALOCEND. Thanks to Bruno Peeters, Dexia, BELGIUM.
VMXGRMFI MAX'ed for each interval and added to PDB.RMFINTRV. The Feb 2, 2001 variables that are added are these: CSFRSRAV CSFRWLAV CSFRFXAV CSFRLSAV CSFRTOAV CSFRAVAV CSFRHIAV CSFRLOAV CSFRMEAV ESFRSRAV ESFRWLAV ESFRHSAV ESFRLSAV ESFRTOAV ESFRAVAV ESFRHIAV ESFRLOAV ESFRMEAV Thanks to Peter Smith, SEMA, ENGLAND.
VMAC30 because the BY list did not force adjacency if there was Feb 1, 2001 a real step and a flushed step with the same TERMTIME. Variable INITTIME was needed at the end of the BY list defined in MACRO _BTY30U4. Thanks to Michael Oujesky, MBNA, USA. Change 18.343 MXG 18.12 only. Typo in label had *' instead of * in VMACIAM one label in this (fortunately) seldom-used code; typo Jan 31, 2001 was made incorrectly after final QA.
VMAC71 were missing. The correct equations are: Jan 31, 2001 CSFRLSAV=CSTORE-(CSFRTOAV-CSFRFXAV); ESFRLSAV=ESTORE-(ESFRTOAV-ESFRHSAV); Thanks to Peter Smith, Sema plc, ENGLAND.
VMACCTLG caused notes on the log, but no error. The record is now Jan 30, 2001 decoded and the time stamp text string is printed on log. Thanks to Len Rugen, State of Missouri Department of Education, USA. Change 18.340 BETA93 variable JESNR was missing for JOB/TSU/STC. Add VMACBETA ELSE DO; Jan 29, 2001 JESNR=INPUT(SUBSTR,JCTJOBID,4,5), ?? 5.); END;
in two places so JESNR will be populated. Thanks to Klaus Messer, COMLAB GmbH, GERMANY. Change 18.339 Divide by zero protected in two places in this analysis ANALCACH example. Jan 29, 2001 Thanks to Greg Jackson, National Life of Vermont, USA. Change 18.338 New MXG enhancement defines new MACRO _Vdddddd that DOC lets you use this simple and straightforward syntax: Jan 28, 2001 %LET MACKEEP= MACRO _Vdddddd KEEP= A B C % ; (or you can put that MACRO _Vdddddd in member IMACKEEP) to KEEP only those variables want kept in an MXG dataset! The original design of the _Kdddddd macro will still be supported (documented in DOCMXG), but that syntax still requires you to list those variables that you do not want to keep, using a DROP= statement; kludgy! This change moves the text of the KEEP= and its list from inside the _VARxxxx macro into a new _Vdddddd for each MXG dataset, and the syntax of the _VARxxxx definition was changed to use that new _Vdddddd token: _Wddddddt (LABEL='THE*LABEL*FOR*THE*DATASET' _Vdddddd _Kdddddd ) While being easy to use, the new _Vdddddd will also truly keep only what you want; using _Kdddddd to DROP variables only drops variables you listed; all new MXG variables (a new release of CICS?) will be kept in your output data set until you edited your DROP= list. You can put the MACRO _Vdddddd definitions in IMACKEEP if you ALWAYS want only those variables kept in that data set, or you can tailor a job in its //SYSIN "instream", so the macro changes only what's created by that job. Using the CICSTRAN dataset as an example, you look up the "dddddd" dataset-suffix name in the IMACxxxx member for the TYPExxxx product, so IMAC110 tabulates the dddddd for each MXG dataset built from the type 110 SMF record. The IMAC110 member show you that "CICTRN" is the dddddd name for the "CICSTRAN" dataset, so this instream tailoring creates CICSTRAN.CICSTRAN with only three variables kept:
%LET MACKEEP= MACRO _VCICTRN KEEP= APPLID TRANNAME TASCPUTM% ; ; %INCLUDE SOURCLIB(TYPE110); This is an internal text change inside VMAC members, and it should be transparent to your existing tailoring. Since datasets with lots of variables are the ones most likely to need KEEP= tailoring, datasets with the most variables were revised first; most have been enhanced but not all MXG members were finished when 18.18 was ready. These members that already defined an _Vxxxxxx macro were set aside to be examined later: TYPEAXC,TYPECMA,TYPEFTP,TYPEICE,TYPEIMS1,TYPEOMCI, TYPEPW,TYPEQACS,TYPEQAPM,TYPEQTRT,TYPETUX,TYPEVMXA, TYPEXAM,TYPE102,TYPE28,TYPE79,TYPE84
EXTAI001- AIX, CISCO, WIN-NT, and SOLARIS platforms creating these: EXTAI005 MXG EXTC2001- Platform Object Max Max Max DATASET EXTC2002 Instance Vars Rows NAME EXTC7001 AIX411: BUFFER 1 8 95 AI001 EXTNT001- CPU 1 5 95 AI002 EXTNT020 PAGING 1 4 95 AI003 EXTSO001- QUEUES 1 4 95 AI004 EXTSO015 SWAPPING 1 1 95 AI005 FORMATS CIS2500: CISCO 7 130 76 C2001 IMACTNG MIB-2 34 89 76 C2002 VMACTNG CIS7500: CISCO 24 166 76 C7001 TYPETNG NTS400I: BROWSER 1 20 95 NT001 TYPSTNG CACHE 1 27 95 NT002 UTILTNGO ICMP 1 27 95 NT003 VMXGINIT IP 1 17 95 NT004 Jan 28, 2001 LOGICALDISK 5 21 95 NT005 MEMORY 1 27 140 NT006 NBT CONNECTION 8 3 95 NT007 NETBEUI 2 39 71 NT008 NETBEUI RESOURCE 13 3 71 NT009 NETWORK INTERFACE 3 17 140 NT010 OBJECTS 1 6 95 NT011 PAGING FILE 2 2 140 NT012 PHYSICALDISK 3 19 140 NT013 PROCESSOR 2 10 95 NT014 REDIRECTOR 1 37 95 NT015 SERVER 1 26 140 NT016 SERVER WORK QUEUES3 17 140 NT017 SYSTEM 1 25 140 NT018 TCP 1 9 95 NT019 UDP 1 5 95 NT020 SOL240S: BUFFER 1 8 12 SO001 CPU 1 5 12 SO002 DISK 3 6 12 SO003 FILE-ACCESS 1 3 12 SO004 FILESYSTEM 2 3 12 SO005 IPC 1 2 12 SO006 KERNEL MEMORY ALLOC1 8 12 SO007 MEMORY 1 2 12 SO008 NETWORK 5 5 12 SO009 PAGING 1 11 12 SO010 QUEUES 1 4 12 SO011 SWAPPING 1 5 12 SO012 SYSTEM-CALLS 1 7 12 SO013 TABLES 1 7 12 SO014 TERMINAL 1 6 12 SO015 The dataset names in this implementation are structured: Dataset Name: PPOOO WHERE PP= Platform Type 2-Character Abbreviation: AI=AIX411 C2=CIS2500 C7=CIS7500 NT=NTS400I SO=SOL240S OOO= Object Number within Platform (see above) Variable Name: PPOOOVVV VVV= Variable (metric) number within object. The Label for each MXG dataset is the Object Name; the Label for each MXG variable is the Metric Name. Use the PROC CONTENTS DATA=PDB._ALL_ DETAILS; to display what is what in the AInnn,C2nnn,C7nnn,NTnnn and SOnnn datasets. This is a departure from MXG variable naming. Most MXG names are abbreviations for what it is, but these names are all cryptic, except for the common BY variables of PLATFORM SYSTEM INSTANCE and STARTIME. If it turns out that having "real MXG variable names" is needed, perhaps to match existing variables from other data sources, an optional rename with PROC DATASETS will be developed.
new objects and metrics on the log, telling you to run UTILTNGO program, and email me the report and the OBJECTS dataset. I can create the needed code from those files. The next major enhancement to TNG support (2nd Quarter?) will make the processing of TNG data completely dynamic: I will only create datasets for those objects that had data in the input file, and will only keep variables for metrics that were found in the input file. That will minimize the space required and remove the clutter of the un-measured variables, and the completely new algorithms in this support were designed with that intention. Standard MXG PDB: You will continue to have the option of building the standard all-variable all-datasets PDB library from TNG data, so your PDB libraries are consistent, with missing values in variables that were not measured, and with zero observations in datasets for objects that were not found in today's data.
You can tell MXG to construct the datasets and variables that were found in today's input data stream, using only the amount of storage and processing to be determined by the data stream.
that have one row of raw data describing the object and the metric followed by that one column of data values.
TNG was a find source of data, and sent me code that read the TNG data, but it took me a year to finally realize how I could write supportable code. This development was actually triggered by a phone call after CMG from the mid-west insurance company that had written a C-program to "decode the performance cube data". I had all along assumed that some API-issuing C program or a vendor-provided utility was needed to read the data, but when I realized this C program read a flat file and wrote a flat file, and then actually looked at a faxed dump of three records, I saw that the raw data could be processed with SAS. -My first pass took two days, and I read each record to create one dataset for each variable, outputting an obs for each data value, and then merged those datasets together to create a dataset per object. I tested the prototype with an NT cube with four objects and twenty metrics, and the logic performed as designed. -Then I wrote a SAS utility to generate all of the SAS statements I would need to create a dataset for all of the other objects and variables in all cubes for five platforms, executed the generated code, and it worked. However, with a small performance cube (64KB in size), the program used 330 MegaBytes of disk storage and 10 minutes to create those 800+ datasets! -Examining the structure of these data, I realized that with fairly limited numbers of observations and limited numbers of objects in one single input cube, arrays to store a single performance cube was all that was needed and that generated names for variables and datasets was the best solution for this type of data structure; at the end of each input cube, one dataset per object is created, containing all of that object's metrics, so there are 44 datasets created, one per object. -The final run with multiple input of 24 daily cubes, at 15 minute intervals, 10,000 records, 6.6MB of raw data, now took 25 seconds (12 to read and create datasets, and 13 seconds to sort them into the PDB), used 17MB of disk work space, with less than 6MB virtual storage for all arrays, so the algorithm should scale well as new objects and metrics are added in the future. The MXG output PDB library was 6MB of disk for 24 days data, using COMPRESS=YES under Win98 on a 500MHz Pentium III. COMPRESS=NO took 2 seconds longer, needed 37MB for work space and created a 12MB PDB on disk; I've previously reported that COMPRESS=YES saves time and disk space on Pentium architecture. Change 18.336 -Device Number variables STC13DID/STC14DID are character VMACSTC variables formatted with $HEX4., which do not translate Jan 24, 2001 correctly between EBCDIC and ASCII platforms. New DEVNR variable is created as numeric and formatted HEX4., so it matches DEVNR in other MXG datasets like TYPE74. See Newsletter "Executing SAS on PCs and Workstations" -STC does not store anything into the channel interface name field, variable STC11INM, so we will now store the channel interface number as a character in STC11INM with: IF STC11INM LE ' ' THEN STC11INM=PUT(_I_,8.); so that if they change their mind and store a value in the future, you'll get it, but for now, we need to sort by STC11INM. (The LE ' ' catches both blanks and hex zeros).
Thanks to Chuck Hopf, MBNA, USA. Change 18.335 Testing statement PUT RTYPE= $HEX2.; should have been VMACNAF deleted, and now it is. Only impact was a large SASLOG. Jan 24, 2001 Thanks to Robert A. Brown, Arthur Anderson, USA. Change 18.334 XRC dataset TYPE42XR had trash; the INPUT was misaligned. VMAC42 The following INPUT statement was inserted before the Jan 23, 2001 existing DO statement in member VMAC42: INPUT @S42XRSSO @; DO _I_=1 TO S42XRSSN; Thanks to John Nalesnik, The Prudential, USA. Thanks to Brenda Rabinowitz, The Prudential, USA.
IHDR110S STID segments allows you to skip unwanted subsubtypes VMAC110 and thereby save CPU time for the INPUT statements, if Jan 22, 2001 you only want to output one or a few STID's (like STID=25 a year's CICLDR observations). See IHDR110S comments; you simply set variable STIDWANT to 1 or zero, using: IF STID =25 THEN STIDWANT=1; ELSE STIDWANT=0; or IF STID IN (1,5,9, ..) THEN STIDWANT=1; ELSE STIDWANT=0; to skip unwanted STID segments, you should also throw away the unwanted subtype 1 transaction record and other unwanted statistics subtypes using the MACFILE tailoring: %LET MACFILE= %QUOTE ( IF ID=110 ; IF SUBTYPE=2; ); so only (in this case) subtype 2 records, which contain subsubtype 25 records, are input past the SMF header. Note these mappings of subtypes to STID's: 0 - Journal 1 - Transaction, Exception, Dictionary 2 - Statistics - all other STIDs 3 - Statistics - STIDs 121,122,123 4 - Statistics - STIDs 126, 127, 128, 129 5 - Statistics - STIDs 124, 125 Change 18.332 Support for Solve SMF subtypes 1 and 2 create new dataset EXTYSOL1 TYPESOL1 for FTS File Send/Receive. FORMATS IMACSOLV
VMACSOLV VMXGINIT
Jan 20, 2001 Thanks to Aubrey Tang, Westpac Banking Corporation, AUSTRALIA. Change 18.331 Validation of Shadow SMF subtype 6 changed variable VMACSHDW SM06SQSR from numeric to variable length 32000 if under Jan 19, 2001 V8 with COMPRESS=YES, or will be broken down into 100 byte pieces and output in multiple records (with resource counts set to missing values in the SM06SEGN=2nd and subsequent observations). All test records had SQL text truncated at byte 255, with the rest of the SM06SQLN bytes filled with hex zeroes. That may be an error or an installation choice; it is under investigation, but MXG prints one instance if found. Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND.
VMAC102 were truncated to 100 bytes if run under SAS V8 without Jan 19, 2001 COMPRESS=YES. The tests to decide to break the long text into 100 byte chunks was IF &SASVER GE 7 THEN DO; but that was changed to IF &SASCHRLN LE 100 THEN DO; because the &SASCHRLN length is set greater than 100 only if both SAS V8 is being used AND COMPRESS=YES is used.
ANALDB2R the DB2 Version 6 DB2PM reports. Jan 18, 2001 Jan 30, 2001 Change 18.328 The MQIN view/dataset was not deleted at the end of the VMXGUOW program, causing no error, but inconsistent with MXG's Jan 17, 2001 deleting of temporary datasets from the work file. Thanks to Chris Weston, SAS Institute ITSV, USA. Change 18.327 IBM Domino WebServer logs are readable with TYPEWWW code, TYPEWWW but the statement FULLURL=SUBSTR(FULLURL,1,LOC-1); was Jan 16, 2001 changed to FULLURL=SUBSTR(FULLURL,1,LOC-10). Without the change, variable FULLURL contained the URL plus the variable HTTPCLVS. Thanks to Greg Meyer, Isuzu Motors, USA. Change 18.326 Interval specification of MINUTE are now supported in the ANALCNCR VMXGSUM, VMXGDUR, and ANALCNCR functions, if you need the ASUMTALO minute details. Hardcode INTERVAL=HOUR and divides by VMXGDUR 3600 were replaced with _TALOINT and _TALOSECS macros VMXGSUM that can be changed to MINUTE and 60 to get minutes. Jan 15, 2001 Thanks to Luc Mattheus, DEXIA Bank, BELGIUM.
VMACRMFV the RMF Monitor III dataset ZRBASI to track the sizes of Jan 15, 2001 those memory areas allocated to each ASID/JOB, and the variables GEICSAAS and GEISQAAS are divided by samples. Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
VMAC110 the MSEC8. format still does not support values greater VMACTMDB than 24 hours. I thought I had replaced all uses of the Jan 12, 2001 MSEC8. informat with &PIB.8.6 and a divide by 4096, back in Change 12.030, a few MSEC8 crept back in the IBM CICS and the Landmark DB2 code. All have been replaced. Thanks to Roman Jost, Gjensidige, NORWAY.
VMACNSPY
Jan 11, 2001 Thanks to Tom Neurauter, Fidelity Investments, USA. Change 18.322 Support for DFSMSRMM 1.5 changes (COMPATIBLE, new fields EXEDGRK were added at end, new subtype added): IMACEDGR -Dataset EDGRDEXT (DSN Record) new variables: VMACEDGR RDVRSSCH='PRIMARY*VRS*SUBCHAIN' VMXGINIT RD2VJBN ='SECONDARY*VRS*JOBNAME*MASK' Jan 9, 2001 RD2VNME ='SECONDARY*VRS*NAME*MASK' RD2VSCH ='SECONDARY*VRS*SUBCHAIN*NAME' RD2VXDS ='SECONDARY VRS*SUBCHAIN*START DATE' RDVRSXDS='PRIMARY*VRS*SUBCHAIN*START DATE' -Dataset EDGRVEXT (VOL Record) new variables: RVCONTNR='IN*CONTAINER*NAME' (appears to be updated only for exported tapes). RVRQPRTY='MOVEMENT*PRIORITY' -New dataset EDGRKEXT created from new type K record. RKCOUNT ='VITAL RECORD COUNT' RKCRDATE='VITAL*RECORD*CREATE*DATE' RKCRSID ='CREATE*SYSTEM*ID' RKCRTIME='VITAL*RECORD*CREATE*TIME' RKCRTJBN='JOBNAME' RKDELAY ='DAYS*DELAY*BEFORE*SELECTION' RKDELDAT='DATE VRS*IS TO BE*DELETED*BY RMM' RKDESC ='DESCRIPTION' RKDSNAME='DATA*SET*NAME' RKDSNG ='DATASET*NAME*MASK IS*GDG?Y/P/N?' RKGENKEY='DSET/VOL*GENERIC*CHARACTERS?' RKLCDATE''LAST*CHANGE*DATE' RKLCSID ='LAST*CHANGE*SYSTEM ID' RKLCTIME''LAST*CHANGE*TIME' RKLCUID ='LAST*CHANGE*USER ID' RKLOC ='NAMEAOF LOCATION TO BE STORED' RKLOCTYP='LOCATION*TYPE?*A/M/S/ ' RKNAME ='VRS*NAME' RKNEXT ='NAMEAOF NEXT VRS IN THE CHAIN' RKOWNER ='VITAL*RECORD*OWNER' RKRETNC ='RETAIN*BASED ON*CYCLES?' RKRETND ='RETAIN*BASED ON*ELAPSED DAYS?' RKRETNR ='RETAIN*BASED ON*UNREFERENCED DAYS?' RKRETNW ='RETAIN*ONLY WHILE*CATALOGED?' RKRETNX ='RETAIN*UNTIL*EXPIRED?' RKSTNUM ='STORE KEEP NUMBER' RKTYPE2 ='VRS*TYPE*V=VOL*D=DSET*N=NAME' RKVOLSER='VOLUME*SERIAL' Thanks to Carl Kyonka, Enbridge, CANADA.
TRND72GO argument was valid, but of no impact. RPRTCLAS was added Jan 9, 2001 to the SUMBY= by Change 18.189 but should have also been Yüklə 28,67 Mb. Dostları ilə paylaş:
|