IMPORTANT PLEASE READ:The Enhanced UNIX Accounting Support was written primarily for us as a foundation for UNIX accounting. The use of this data for performance analysis or reporting needs a careful understanding of how the data is summarized and stored in the various levels of the PDB. See Discussion of Summarization for more information.
The original UNIX accounting support (ACCTON) implemented by IT Service Vision had several restrictions that have been removed by this new support. The new Enhanced UNIX Accounting support (ACCUNX) includes the following features:
Although the metrics recorded by UNIX Accounting are similar across all flavors UNIX, the layout of the binary file to which the data is written can vary across UNIX platforms and across releases of the same platform. For this reason, the format of the UNIX Accounting file is determined using the Operating System/Operating System Release pair obtained by the uname command.
The following table lists the Operating System/Operating System release pair for which the UNIX Accounting binary files have been tested and are supported by ITSV. If your OS/OS Release pair is not listed here then you should refer to the section Adding Support for OS / OS Release pairs not listed
|Operating System||Operating System Release|
This section is divided into three sections, Overview, Quick Reference and finally a Details section. I recommend reading the Overview and then the Quick Reference sections as these will direct you to the appropriate parts of the Details section.
The approach you use to process your UNIX accounting data will depend on several factors, such as, data volumes, number of data files from unique machines, number of unique passwd and group files.
Your first decision will be regarding how to build the passwd and group formats that the IT Service Vision UNIX Accounting processing uses to map user and group numbers to user and group names.
The simplest approach is to include the passwd and group information with each data file which can be done using the itsvacct shell script that is provided. This is the approach to use when you have either a small number of files to process or each machine has its own unique passwd and group file. When the data file is processed the passwd and group formats are build dynamically. The drawbacks to this approach are that processing takes longer due to having to build the formats and you have to transfer larger data files.
The second approach is to pre-build the formats on a per DOMAIN basis. For example, if you have two domains that each have unique passwd and group files that are common to all the machines in their respective domain, we can use the itsvfmt shell script and the %CPACCFMT macro to pre-build the format information. Once built, %CPPROCES will detect which domain a UNIX accounting file comes from and will apply the appropriate format. The advantages of this approach are that the format building is not done as part of the processing and the passwd and group data is not included in each of the data files. The drawback is that the user will have to ensure that the formats are kept up to date.
The final approach is really only an option if the machine running the ITSV Server also has the passwd and group files stored locally, and it is these passwd and group files that should be used for all the files being processed. If no passwd or group information is pre-built and the passwd and group data is not included in the data file, then %CPPROCES looks in the default location locally for the information.
Prior to ITRM 2.7 the passwd and group data where treated as one, that is, they both had to be either included with the binary rawdata using the itsvacct script, both pre-built using itsvfmt and the %CPACCFMT macro or both stored locally. As of ITRM 2.7 the group and passwd data are treated independently. For example, the passwd data could be included with the binary pacct file using the itsvacct command and the group data could be derived from pre-build formats.
You should ensure that the OS / OS Release value pair is supported. To do this you should use the %CPACCUTL macro. If your OS / OS Release pair are not listed as supported they will have to be added. See "Adding Support for OS / OS Release pairs not listed" for further information or contact SAS Technical Support with the information listed in that section.
Now that you have decided how the passwd and group information is going to be handled, you will have to run the itsvacct shell script in order to prepare the UNIX accounting data for processing. If this shell script is run on the machine on which the UNIX accounting file was created it uses the uname system command to create a header that contains the OS id, OS Release information, Domain name (if necessary). If you run this command on a machine other than the one on which the binary pacct file was created then you will have to manually provide the appropriate values. For further information you should refer the itsvacct documentation.
itsvacct shell script has to be run, however, you have two options:
Once this file is created for each UNIX accounting file, they should all be placed into a common directory (PDS or sequential file on MVS, or UNIX System Service is supported) which will be pointed to in %CPPROCES macro.
By default, running %CPPROCES will process all files in directory referenced by RAWDATA= parameter. If any file is determined to be invalid (e.g. it does not have valid header records) it will be skipped, a message put in SAS log and remaining files will be processed. data will be summarized at hour level (this can be altered) prior to be placed into DETAIL level of PDB and processing will use SAS data set views internally which reduce IO and space requirements (it is also possible to NOT use views which can have advantages in terms of handling certain errors).
original UNIX accounting support only allowed one data file to be processed at a time which meant associating it with its appropriate passwd and group files relatively straight forward.
new UNIX accounting support allows you to process multiple data files some of which could use same passwd and group files, others that may use different ones. challenge here is to provide necessary functionality to allow passwd/group file to accounting file mapping to occur automatically.
approach you take will depend on characteristics of your environment. Your options are:
If you supply itsvacct shell script with UNIX accounting binary file and location of passwd and group files, then all this information is packaged into one file. This file should then be transferred (in Binary mode for FTP) to a common directory (PDS or sequential file for MVS) for processing.
MVS ONLY:USS (UNIX System Services) is supported for this collector and files should be treated same as a UNIX file. If you are processing a single file, then you can FTP (binary mode) data to MVS into a sequential file, or if you are processing multiple files place each file in a unique member within a PDS. following tables detail data set attributes required:
If passwd and group data is contained in file then %CPPROCES will use this information to dynamically construct formats and use them for processing this file only.
advantages of this approach are that each data file is self contained and passwd and group formats are refreshed for each process.
disadvantages of this approach are that extra processing time is required to build formats, and raw data files will be larger due to format information being passed. If same passwd and group files are used across several machines then that information is duplicated and is a waste of resources (both time and space).
If you have a large number of machines that use common passwd and group files then this approach may be most efficient. only drawbacks are that you will have to refresh formats to ensure that they are up to date.
This approach assumes that a passwd and group file are common for all UNIX accounting files created on machines in that domain. When a UNIX accounting data file is processed domain value is obtained from header record and a format is applied. result of this format is a value that represents suffix for passwd and group formats that were pre-built for this domain. If these formats exist they are used in processing.
If you have a few machines in that domain that do NOT use same passwd and group files then make sure that passwd and group information for those machines is included in UNIX accounting file as this will override pre-built format.
To pre-build format use itsvfmt shell script. Internally shell script uses domainname command to set domain value in header. This value can be overridden using -d switch if domainname command does not return a valid value.
itsvfmt shell script will output an ASCII file to standard out and this file should be transferred (ASCII mode for FTP) to IT Service Vision Server machine. Start up ITSV with appropriate UNIX accounting PDB active and use %CPACCFMT macro to store formats in an appropriate location.
passwd and group formats for any UNIX accounting data file coming from this domain will now be ready for use in %CPPROCES macro. only maintenance that you will be required to do is to ensure to refresh these formats if passwd and/or group files are updated.
Finally, if you do not pre-build formats and you do not include passwd and group information in data file, %CPPROCES will use local copies of passwd and group files located in /etc/passwd and /etc/group respectively. If your local files do not reside in this location, then you can specify locations of files in CPACCPWD and/or CPACCGRP macro variables prior to running %CPPROCES.
Note:If processing on PC or MVS then there is no default location to look for passwd and group files, therefore you will have to provide location via CPACCPWD and CPACCGRP macro variables.
As of ITRM 2.7 group and passwd data are treated independently. For example, passwd data could be included with binary pacct file using itsvacct command and group data could be derived from pre-build formats.
order of preference is:
Bearing this in mind you can mix methods by which formats are built.
Typically, binary UNIX accounting file is located in /var/adm/pacct (pacct# - where # is a number). In order for ITSV process to obtain necessary information such as DOMAIN, MACHINE NAME etc, you must use itsvacct shell script to prepare file.
itsvacct shell script places a header record on a copy of pacct file and also, if necessary will include passwd and group information too.
standard output of itsvacct shell script should be redirected to a file and transferred to platform where it is going to be processed (in binary mode if using FTP).
On UNIX and NT all files should be placed in one directory, and %CPPROCES will process all files in that directory. On MVS you should place each file in its own PDS member or, if there is only one file then it can be placed in a sequential file. MVS data set attributes are as follows:
following code is an example of %CPPROCES macro invocation for processing UNIX accounting data.
%let cpsumdur=15; (1) %let cpusevew=Y; (2) %let cpaccpwd=/etc/mypasswd; (3) %let cpaccgrp=/etc/mygroup; (4) %let cpacchdr=/myhome/header.only (5) %CPPROCES(, (6) COLLECTR=ACCUNX, (7) RAWDATA=/dataLocation/, (8) TOOLNM=SASDS, (9) EXITSRC='ADMIN.EXITS', (10) DUPMODE=DISCARD, (11) _RC=retcode); (12)
Once processing has complete you should review SAS log. By design, if an invalid file is encountered, then it is skipped and processing will continue. You may want to fix this file and re-process just that file at a later date.
IT Service Vision already has 'Process Exits' that can be used to enhance processing for all data sources that use %CPPROCES macro. UNIX Accounting User Exits have been added to allow access to UNIX accounting specific code. One example that is given below is use of exits to output a SAS data set of data prior to it being summarized.
Warnings and Disclaimers
In any situation where you have ability to affect and alter intended flow and execution of code, there exists possibility of error. As such, SAS Institute makes following warnings and disclaimers with regard to use of exits with IT Service Vision.
bottom line is this: use exits with great caution.
%macro endian; %global _pre; %global _fmt; %let _pre=%str(); %let _fmt=%str(); %if &sysscp eq os %then %do; %let _pre=%str(put%(); %let _fmt=%str(,$ascii2.%)); %end; %mend; %endian; #1 DATA WORK.A1 ( KEEP= ACCCOMM ACCETM ACCGRP ACCIO ACCKMIN ACCMEMA ACCRW ACCSTM ACCUSR ACCUTM DATETIME DOMAIN HOUR LSTPDATE MACHINE OBSCNT SHIFT RNDDATM #2 ) #3 / VIEW=WORK.A1 ; ATTRIB ACCBTM LENGTH=6 FORMAT=DATETIME21.2 LABEL='Begin time' ; ATTRIB ACCCOMM LENGTH=$8 LABEL='Cmd name' ; ATTRIB ACCETM LENGTH=6 FORMAT=TIME11.2 LABEL='Elapsed time' ; ATTRIB ACCFLAG LENGTH=$1 FORMAT=$HEX2. LABEL='Acct flag' ; ATTRIB ACCGID LENGTH=6 LABEL='GroupID' ; ATTRIB ACCGRP LENGTH=$16 LABEL='Group' ; ATTRIB ACCIO LENGTH=6 LABEL='Chars transferred' ; ATTRIB ACCKMIN LENGTH=6 LABEL='Memory Kcore mins' ; ATTRIB ACCMEM LENGTH=6 LABEL='Memory clicks' ; ATTRIB ACCMEMA LENGTH=6 LABEL='Avg memory' ; ATTRIB ACCRW LENGTH=6 LABEL='Blks read/written' ; ATTRIB ACCSTAT LENGTH=$1 FORMAT=$HEX2. LABEL='Status' ; ATTRIB ACCSTM LENGTH=6 FORMAT=TIME11.2 LABEL='System time' ; ATTRIB ACCTTY LENGTH=6 FORMAT=HEX4. LABEL='Cntrl tty' ; ATTRIB ACCUID LENGTH=6 LABEL='UserID' ; ATTRIB ACCUSR LENGTH=$16 LABEL='User' ; ATTRIB ACCUTM LENGTH=6 FORMAT=TIME11.2 LABEL='User time' ; ATTRIB DATETIME LENGTH=6 FORMAT=DATETIME21.2 LABEL='Datetime' ; ATTRIB DOMAIN LENGTH=$16 LABEL='Domain name' ; ATTRIB HOUR LENGTH=3 LABEL='Hour' ; ATTRIB LSTPDATE LENGTH=8 FORMAT=DATETIME21.2 LABEL='Last process date' ; ATTRIB MACHINE LENGTH=$32 LABEL='Machine' ; ATTRIB OBSCNT LENGTH=8 FORMAT=BEST12. LABEL='Count of observations in Summary' ; ATTRIB SHIFT LENGTH=$1 LABEL='Shift' ; ATTRIB RNDDATM LENGTH=6 FORMAT=DATETIME21.2 LABEL='Datetime'; RETAIN _DOABORT _EOFONLY 0; RETAIN DATETIME RNDDATM 0; RETAIN FLAG INDEX P 0 LOOP 1; RETAIN SEP 'ITSVHEADEND'; LENGTH LINE $1; RETAIN MACHINE "node01"; RETAIN DOMAIN "DOMAINXX"; RETAIN GMTDEV -18000; #4 INFILE a1 RECFM=N END=_LAST EOF=EOFLABEL; ACCMEMA=0; /* Initialize */ DO WHILE (LOOP); P=P+1; INPUT @P LINE $ascii1.; IF FLAG OR LINE='I' THEN DO; IF LINE = 'I' THEN DO; FLAG=1; INDEX=1; END; ELSE DO; INDEX=INDEX+1; IF SUBSTR(SEP,INDEX,1) NE LINE THEN DO; FLAG=0; INDEX=0; END; END; IF INDEX = 11 THEN DO; LOOP=0; INPUT @P+2; END; END; END; /* DO WHILE */ input accflag $ascii2. accstat $ascii2. accuid s370fpib4. accgid s370fpib4. accprm s370fpib4. acctty s370fpib4. datetime s370fpib4. autm $ascii2. astm $ascii2. aetm $ascii2. amem $ascii2. aio $ascii2. arw $ascii2. acccomm $ascii8.; #5 IF ACCCOMM EQ '0000000000000000'X THEN --* DO; | PUT _ALL_; | IF ACCUTM EQ . AND MVS ONLY ACCSTM EQ . AND | ACCETM EQ . THEN STOP; | ELSE DELETE; | END; --* ACCSTAT= &_PRE.ACCSTAT&_FMT; ACCUSR = PUT(ACCUID,P&FMTSUFF..); IF ACCUSR = "UNKNOWN" THEN ACCUSR = LEFT(PUT(ACCUID,10.)); ACCGRP = PUT(ACCGID,G&FMTSUFF..); IF ACCGRP = "UNKNOWN" THEN ACCGRP = LEFT(PUT(ACCGID,10.)); DATETIME = DATETIME + &_DATCON + GMTDEV; ACCUTM = INPUT(&_PRE.AUTM&_FMT.,BITS13.3) * 8**INPUT(&_PRE.AUTM&_FMT.,BITS3.0); ACCMEMA=ACCMEMA + ACCUTM; ACCUTM = ACCUTM/&ctick; ACCSTM = (INPUT(&_PRE.ASTM&_FMT.,BITS13.3) * 8**INPUT(&_PRE.ASTM&_FMT.,BITS3.0)); ACCMEMA=ACCMEMA + ACCSTM; ACCSTM = ACCSTM/&ctick; ACCETM = (INPUT(&_PRE.AETM&_FMT.,BITS13.3) * 8**INPUT(&_PRE.AETM&_FMT.,BITS3.0))/&ctick; ACCMEM = (INPUT(&_PRE.AMEM&_FMT.,BITS13.3) * 8**INPUT(&_PRE.AMEM&_FMT.,BITS3.0)); ACCMEMA = ACCMEM*&psize/ MAX(ACCMEMA,1); ACCKMIN = (ACCMEM*&psize) / (60 * &ctick); ACCIO = (INPUT(&_PRE.AIO&_FMT.,BITS13.3) * 8**INPUT(&_PRE.AIO&_FMT.,BITS3.0)); ACCRW = (INPUT(&_PRE.ARW&_FMT.,BITS13.3) * 8**INPUT(&_PRE.ARW&_FMT.,BITS3.0)); ACCCOMM= SCAN(ACCCOMM,1,'00'X); intrvl = int((datetime - intnx('hour',datetime,0))/3600); rnddatm = intnx('hour',datetime,0)+3600*intrvl; #6 OUTPUT WORK.A1 #7 ; return; EOFLABEL: #8 RUN; #9 DATA COLLECT.ACCMSTR #10 --* / VIEW=COLLECT.ACCMSTR; | SET | WORK.A1 END=_LAST | ; CPUSEVEW='Y' ONLY | #11 | OUTPUT COLLECT.ACCMSTR #12 ; | RUN; --* PROC APPEND BASE=COLLECT.ACCMSTR --* NEW=WORK.A1 FORCE; CPUSEVEW='N' ONLY RUN; --* #13
|Exit Number in Code Example||Exit Point Name||Placement||Purpose||Frequency of Execution|
|#1||acct010||Directly before SAS data step that processes raw data file.||Enable open code processing.||Once per input file.|
|#2||acct020||Allows KEEP list to be modified.||At end of KEEP list before closing parenthesis.||Once per input file.|
|#3||acct030||Directly after KEEP list closing parenthesis and before closing semi colon. (Also before / view= statement if views are being created.||Allows setting of data set options as well as including extra output data sets.||Once per input file.|
|#4||acct040||Directly after ATTRIB and RETAIN statements.||Allows open data set code to be inserted.||Once per input record.|
|#5||acct050||Directly after INPUT statement.||Allows variables read in to be examined.||Once per input record.|
|#6||acct060||Directly before OUTPUT statement.||Allows open data set code to be inserted.||Once per input record.|
|#7||acct070||Directly before closing semicolon on OUTPUT statement.||Enable user OUTPUT statements.||Once per file.|
|#8||acct080||Directly after EOFLABEL label.||Allows open data step code when end of file encountered.||Once per input file.|
|#9||acct090||Directly after RUN statement.||Enable open code processing.||Once per input file.|
|#10||acct100||Before "/ view=" on data statement.||Allows setting of data set options as well as including extra output data sets.||Once per process (Only used if CPUSEVEW macro variable is set to "Y" (default).|
|#11||acct110||Directly after SET statement.||Allows open data set code to be inserted.||Once per process. (Only used if CPUSEVEW macro variable is set to "Y" (default).|
|#12||acct120||Part of OUTPUT statement.||Allows additional output data sets to be specified.||Once per process.|
|#13||acct130||After COLLECT data set has been created.||Enable open code processing.||Once per process.|
Please familiarize yourself with information provided in "Shared Appendix 8: Exits for Process Task -- General Information" as this information also applies to UNIX Accounting exit points. only differences are as follows:
%macro acct005; /* actual exit-specific code goes here */ %mend; %acct005
enhanced UNIX Accounting support automatically summarizes input data in order to reduce amount of data that is stored and DETAIL level of PDB. Sometimes it may be necessary to retain a copy of actual data prior to it being summarized.
How this is done will depend on your goals and what value is associated with CPUSEVEW macro variable. For this example, we are going to assume default value of CPUSEVEW='Y' for this macro variable and we will therefore use exit point acct100.
In sasuser.exits.acct100.source I saved following code,to place an extra output data set on DATA statement where view COLLECT.ACCMSTR is built:
%macro acct100; work.alldata %mend; %acct100
Finally, %CPPROCES macro invocation has to be updated to include exit source location. For example:
%CPPROCES( ,COLLECTR=ACCUNX ,RAWDATA=/accton/tmp/itsv.pacct ,EXITSRC=SASUSER.EXITS ,TOOLNM=SASDS );
UNIX accounting files can vary in structure across different UNIX platforms and even between releases of operating systems. One of objectives of this enhanced UNIX accounting support was to enable new formats to be added easily by either customer or SAS Institute.
This section discusses how ITSV identifies requirements for processing each input file, and how to add support for a new format. If you do not wish to attempt to add support yourself, you should contact SAS Technical Support with information listed in Information Requirements.
Each UNIX Accounting file has to be processed by itsvacct shell script prior to being sent to server. reason for this is that header information is added to file which will enable server to determine format of binary file. following is an example of header placed on a binary file:
|Field 1||ITSVACCTON||This is a keyword and is always set to ITSVACCTON.|
|Field 2||Operating System||This field contains operating system value as returned by uname -s command.||Field 3||Operating System Release||This field contains operating system release value as returned by UNIX command uname -r.|
|Field 4||Node name (Machine name)||This field contains node name value as returned by UNIX command uname -n.|
|Field 5||Domain name||This field contains domain name value as returned by UNIX command domainname.|
|Field 6||GMT Offset||This field contains GMT offset based on information from UNIX command date.|
|Field 7||Hardware||This field contains hardware value as returned by UNIX command uname -m.|
|Field 8||Clock Ticks||This field contains a value that represents number of clock ticks per second for this machine.|
|Field 9||Page Size (in Kbytes)||This field contains a value that represents page size for this machine.|
|Field 10 - 19||Optional Fields||user can use these fields to pass additional information into IT Service Vision.|
Where possible, above header record is constructed automatically in itsvacct shell script, however this script is supplied with switches to allow values to be overridden if necessary.
Each unique OS/OS Release pair has a format applied to it to determine file structure of input file.PGMLIB.ACCUNX.OSFMT.SOURCE contains information to OS/OS Release pairs that have been tested. For example:
HP-UXB.10.20 ACC001 HP-UXB.11.00 ACC002 SunOS5.7 ACC003 OSF1V4.0 ACC004An OS/OS Release pair of HP-UXB.10.20 will result in input statements contained in PGMLIB.ACCUNX.CPACC001.SOURCE to be used to read data.
If during processing an unsupported OS/OS Release pair is detected, following WARNING message will be issued in SAS log and this file will not be processed, however, processing will continue for any other valid files.
WARNING: Format unknown for OS, OSREL pair in file: accton/tmp/itsv.pacct3/
In order to process this files data we need to add support for this OS/OS Release pair and also validate that data is processed correctly.
Let us assume that we have a UNIX Accounting file that has been rejected by ITSV due to OS/OS Release pair not being recognized. You have two options, 1) is to add support yourself using procedures described below, or 2) contact SAS Institute Technical Support with following information and we will add in and validate support and provide you with necessary updates.
following information is required to add and validate support for a new OS/OS Release pair.
supplied CPACCnnn source entries are stored in PGMLIB.ACCUNX.CPACCnnn.SOURCE and these should NOT be modified, as any modifications would be overwritten when installing next IT Service Vision release. nnn for supplied CPACCnnn entries can be from 001 to 899, however non-supplied entries are limited to CPACC9nn to avoid name space collisions.
UNIX Accounting process will automatically search following SAS catalogs for new/modified CPACC9nn entries which if found will take priority over PGMLIB versions. catalog search/preference order is ADMIN.ACCUNX, SITELIB.ACCUNX, PGMLIB.ACCUNX.
Copy a supplied CPACCnnn source entry from PGMLIB to destination catalog listed previously. You should note that ADMIN.ACCUNX catalog entries will be associated with a single PDB and SITELIB.ACCUNX entries will be associated with any PDB using that SITELIB.
following SAS code should be submitted from PROGRAM EDITOR of an ITSV SAS session that has appropriate UNIX Accounting PDB active. You will need to modify COPY OUT= statement and CPACCnnn part of SELECT statement as necessary.
PROC CATALOG CAT=PGMLIB.ACCUNX; COPY OUT=ADMIN.ACCUNX; SELECT CPACCnnn.SOURCE; QUIT; PROC CATALOG CAT=ADMIN.ACCUNX; CHANGE CPACCnnn.SOURCE=CPACC9nn.SOURCE; QUIT;
On opening your libref.ACCUNX.CPACC9nnn.SOURCE you will see something similar to following:
input accflag $ascii2. accstat $ascii2. accuid s370fpib4. accgid s370fpib4. accprm s370fpib4. acctty s370fpib4. datetime s370fpib4. autm $ascii2. astm $ascii2. aetm $ascii2. amem $ascii2. aio $ascii2. arw $ascii2. acccomm $ascii8.;
code contained in CPACC9nn source entries are actual input statements used to process UNIX Accounting files. informats that are used have been chosen to ensure that data is processed correctly on UNIX, NT and MVS systems.
Typically all that is necessary is for you to modify order of variables or maybe width of formats, for example, $ascii2. may become $ascii4. order and width information can be obtained from acct.h file although it may be necessary to examine binary pacct file directly.
IT Service Vision needs a way to map new libref.ACCUNX.CPACC9nn.SOURCE entry to OS/OS Release values so that it can use new input statements to process data.
For this reason, you should create your own libref.ACCUNX.OSFMT.SOURCE entry that just contains information for your OS/OS Release pair. PGMLIB.ACCUNX.OSFMT.SOURCE entry should not be modified as any updates would be lost when IT Service Vision was updated.
%CPACCUTL macro is used to LIST, ADD and DELETE these OSFMT.SOURCE entries, it is fully documented in Macro Reference guide. LIST command will list contents of libref.ACCUNX.OSFMT.SOURCE entries, ADD and DELETE will work against ADMIN and SITELIB librefs. If OS/OS Release pair being added needs to be accessed across several PDB's, then it should be added to SITELIB, otherwise if it is specific to one PDB it can be added to that PDB's ADMIN library.
Using list function of %CPACCUTL macro you are able to list contents of existing entries in all three libraries (ADMIN, SITELIB and PGMLIB).
%CPACCUTL macro interface has been provided to ensure that OSFMT.SOURCE entries are created correctly. following code gives and example of how this macro works:
%CPACCUTL(LIBREF=ADMIN ,FUNCTION=ADD ,OS=HP-UX ,OSREL=B.10.20 ,INSRC=1 ,_RC=&RETCODE); %put Return code is &retcode;
result of this macro would be following line added to ADMIN.ACCUNX.OSFMT.SOURCE.
Now, when you pass your data file to IT Service Vision %CPPROCES macro, it extracts OS/OS Release information that was prefixed on file and uses that information to locate correct input statements (e.g. ADMIN.ACCUNX.CPACC901.SOURCE). final requirement is to validate values being stored in PDB.
default processing is for IT Service Vision to pre-summarize UNIX Accounting data to hour interval prior to being added to DETAIL. In order to be able compare values in PDB to output created by acctcom command we have to switch off this pre-summarization.
Create a PDB which is going to be used for validation purposes only and add ACCTON table (others are not required for validation). Process UNIX accounting file as usual except set CPSUMDUR macro variable to a missing value (i.e. %let cpsumdur=.;) before %CPPROCES macro.
%let cpsumdur=.; %cpproces(......);
result is to effectively switch off pre-summarization. data in DETAIL.ACCTON can now be compared with output of acctcom command although it is in a different sort order. To make it slightly easier, you can use COLLECT.ACCTON for comparison as it will be in same sort order as incoming data.
Once validated, this PDB can be deleted and UNIX Accounting file can be included as part of your normal batch run.
There are 10 optional parameters on itsvacct shell script that can be used to populate data fields in PDB. These fields make it easier to include machine or domain information which may be useful as accounting data that is not available in existing script.
You can use optional fields either by specifying value you want to pass to PDB via a switch or you can modify script to use a system command that provides information. Next you will have to mark as KEPT=YES in appropriate table ACCOPTn variable that you are using (where 'n' is a number). In addition to this you will then need to make this variable an ID variable. All ACCOPTn variables are treated as character by PDB, if you want to convert them to numeric you will have to create either formula or derived variables that perform conversion.
For this example we are going to assume that user wishes to add a 'processor type' field to their ACCTON table only (although other ACC* tables will pick up value if set up correctly). This value can be obtained by some operating systems by using 'uname -p' command.
You should only modify shell script according to documentation, any other modifications could cause a failure or a file with an invalid format.
Below is an extract of part of itsvacct shell script and comments describe how to update DEFOPT0 value to hold processor value.
# User may modify following variables which represent defaults # to be supplied to optional values -o0-9. # # e.g. DEFOPT0="`uname -p`" stores output of this command in # $DEFOPT0 variable. DEFOPT0="" DEFOPT1="" DEFOPT2="" DEFOPT3="" DEFOPT4="" DEFOPT5="" DEFOPT6="" DEFOPT7="" DEFOPT8="" DEFOPT9=""
DEFOPT0 line would look like:
This change means that result of this command will be stored in optional field 0 whenever this script is run.
ACCOPTn variables by default are marked as KEPT=NO and treated as character variables. If you want to convert them to numeric values you will have to use formula or derived variables.
Once above changes have been made result of 'uname -p' command will be stored in ACCOPT0 variable of ACCTON table. If ACCOPT0 variable was marked as KEPT=YES and made an ID variable in other UNIX Accounting tables it would be populated in them too.
ACCTON data that ITSV processes is typically EVENT type data, that is, a process started, consumed some resources over time and then ended completing event. supplied ACCUNX tables (ACCCOM,ACCUSR,ACCGRP,ACCTON) are all defined as EVENT tables.
Due to potential large volumes of ACCTON data, by default, we summarize data by HOUR prior to storing it in DETAIL level of PDB, keeping sums of numeric variables. For example if five 'ls' command events started and completed within same hour, then one observation would be stored at DETAIL, with value of each numeric variable summed and an OBSCNT variable that would contain value 5 for number of events summarized into that one observation. INTRVL variable indicates summary duration (by default 3600 seconds) at which records are summarized, yet this does not make these INTERVAL type tables.
Interval tables in ITSV require a DURATION variable as many of numeric variables will be weighted by duration when summarizing them into reduction levels. To weight any numeric variables in our ACCUNX tables by DURATION would be invalid, instead they are weighted by OBSCNT (or ELASPED TIME of event could be used). Weighting by OBSCNT will result in an mean value per event, whereas weighting by elapsed time will result in a rate.
Summed values for variables are typically sufficient for UNIX Accounting purposes. However, sites may wish to use this data for performance analysis where averages and rates may be more useful. To use event information in these ACCUNX tables for performance analysis then user should carefully examine and understand data prior to using it.
You may find it more useful to output detail data into a separate SAS data set and process separately for performance analysis purposes, in which case refer to Exit Point Example: Output a Detail SAS Data Set for further information.
metric ACCKMIN (K core minutes) is marked as KEPT=NO by default in all ACC* tables. Typically, this variable will not be useful for chargeback purposes, however if you decide to keep data for this metric then you will need to consider how it is calculated on different platforms.
For example, AIX, DEC OSF and HP UX all use different formulas when calculating K Core Minutes value and IT Service Vision maintains consistency by using appropriate formula for appropriate platform. result being, that if you have ACCTON data from a mixture of platforms you should consult documentation for those systems to understand how this value is calculated.