DB2 Server for VSE: System Administration

Preparing to Use the Accounting Facility

To use the accounting facility, you must first set up the operating system, then set up the job control statements for the accounting files.

Setting Up Your System

  1. IPL the VSE operating system with the JA=YES option specified on the IPL SYS command. For more information, see VSE/ESA System Control Statements.
  2. If you have CICS, you must generate it with the restart resynchronization capability. (If accounting is active but restart resynchronization is not installed, the online support cannot be started; the CIRB transaction fails, and you receive an error message.) For a description of the CICS table entries required for restart resynchronization, see the DB2 Server for VSE Program Directory.

Setting Up a Job Control for the Accounting Files

When the VSE operating system is set up to use accounting, you need to set up a job control for the accounting files, within the job control that identifies your database. This job control must identify either one or two accounting files. It is recommended that you define two, so that you can use the alternate accounting file support.

If only one accounting file is used, you must shut down the database manager to process this file. With alternate accounting file support, you can switch from the current file to a second one while the database manager is running, which enables you to process the information in the first file without interrupting users. You can also use the alternate file support if there is a write error on the active file; or if you are accounting to DASD files, you can switch to the alternate file when the active file reaches the end of the extent.

If you switch to a second accounting file, you should process the closed file as soon as possible to prevent yourself from accidentally overlaying the previous session's accounting information.

The accounting files must be sequential files, and they can reside on either tape or DASD. If you define two, they must both be on the same storage medium: you cannot define one on tape and the other on DASD. If the files are on DASD, they can be native SAM files, VSE/VSAM ESDS files, or files managed by the VSE/VSAM space management for SAM feature. It is recommended that you define your accounting files on DASD as VSE/VSAM ESDS files.

Regardless of whether you use DASD or tape, you must specify the file name ARIACC1 for the first file on either the DLBL or TLBL statement. If you use two accounting files, the second file name must be ARIACC2. The database manager always opens ARIACC1 when it is started with the accounting facility active.

When the database manager ends (either normally or abnormally), it attempts to close the accounting file. If this file cannot be closed, accounting data may be lost.

Managing DASD Accounting Files

To use DASD sequential files for your accounting data, first determine the potential size of the accounting data set. Initially, you should overestimate it; then adjust it based on your experience.

To get a general idea of how many accounting records are likely to be generated, start the application server for normal multiple user mode access, and at the end of the day, issue the COUNTER BEGINLUW and COUNTER CHKPOINT operator commands. The number of accounting records generated at your installation will be smaller than, but proportional to, these values. The database manager writes an accounting record for each user on some ends of logical units of work, and on all checkpoints. Three more accounting records are written for each run: one for startup, one for operation, and one for shutdown: you can ignore these three records when making your estimate.

For example, assume your counters show that your installation does 2000 logical units of work and 200 checkpoints a day. On average, this can result in 1000 accounting records generated for users and 200 records generated for checkpoints. For environments with heavy ISQL usage, the number of records generated for users would probably be lower, while for preplanned transaction environments, it would probably be higher, so you should overestimate the number of records needed.

To get an initial estimate for the size of your accounting files, multiply your estimate of the number of records by 80 to get the approximate number of bytes. For help in determining the file size that you need, see Storage Capacities of IBM DASD Devices.

When you have gained experience using accounting, you can adjust your file sizes.

Files Managed by VSE/VSAM Space Management for SAM Feature

If you have the VSE/VSAM space management for SAM (sequential access method) feature, you

should use it to manage your accounting files on DASD. This feature provides the following advantages:

File extendibility
It allows files to be extended by the use of the DISP=(OLD) parameter on the DLBL statement. This prevents the database manager from overlaying the accounting records generated during its previous run. Otherwise, you would have to update EXTENT job control statements over multiple runs of the database manager

Secondary allocations
It gets up to 15 additional extents when the primary allocation is exhausted. This reduces the risk of filling the accounting file, which causes a loss of accounting data.

Monitor status
You can monitor the status of the accounting file using the access method services LISTCAT command. You can do this without interrupting processing.

No symbolic device collision
You do not need to worry about symbolic device address collisions, which can occur

The collisions must be resolved in the job control statements, as described on page 4.

Figure 75 shows sample job control statements for two accounting files managed by the VSE/VSAM space management for SAM feature.

Figure 75. Job Control for DASD Accounting Files (VSAM Space Management)

 
// DLBL ARIACC1,'ACCTFIL1',0,VSAM,DISP=(OLD,KEEP),RECORDS=(x,y),       C
               RECSIZE=80,CAT=SQLWK1C
// EXTENT ,SQLWK1
// DLBL ARIACC2,'ACCTFIL2',0,VSAM,DISP=(OLD,KEEP),RECORDS=(x,y),       C
               RECSIZE=80,CAT=SQLWK1C
// EXTENT ,SQLWK1

Notes:

  1. The DLBL file name for the primary accounting file must be ARIACC1, and for the secondary file ARIACC2.

  2. The DLBL parameter VSAM indicates that these are VSAM managed files.

  3. The example assumes that the files are implicitly defined to VSAM the first time they are opened.

  4. Every time the application server is started, it directs output to the file identified by file name ARIACC1 (even if you are using two accounting files). To avoid having the accounting information from the previous run of the database manager erased, specify the DISP=(OLD,KEEP) option on the DLBL statement for the accounting file to indicate that the files are not to be reset at OPEN time (OLD), and are not to be deleted at CLOSE time (KEEP). This allows you to implicitly define the files the first time they are used, and to extend them (add records to them) in subsequent runs.

    If you run the database manager continually, it is advantageous to specify DISP=(NEW,KEEP) to have the accounting file erased every time it is opened. Here, you would be switching between the two accounting files, using the ALTACCT command, so that you can process the current file. If you specified DISP=(OLD,KEEP), the files would never be erased; they would keep growing. If you do specify DISP=(NEW,KEEP), be sure to process the accounting file immediately after you close it. If you do not, the accounting data will be erased the next time you switch accounting files.

  5. When implicitly defining the files, VSAM uses the RECSIZE and RECORDS parameters to determine how much primary and secondary space to allocate for the files.

    Set RECSIZE to 80, because that is the size of an accounting record.

    For RECORDS=(x,y), set x to the number of accounting records you expect to be generated during your accounting period. The value you specify for x is multiplied by 80 (the RECSIZE) by VSAM to determine the size of the primary space allocation. For example, if you have determined that you expect 500 accounting records to be generated for each accounting period, set x equal to 500. The number of bytes set by VSAM for the primary space allocation is 40000 (500 x 80). The value you specify for y determines the size of the secondary allocation. If you set y to 100, VSAM allocates 8000 bytes (100 x 80).

    If the primary allocation is full, VSE/VSAM gets up to 15 additional extents. The VSAM catalog must own sufficient unallocated space on the specified volume to satisfy the space allocation requirements for the file.
    Note:If you use an explicit definition for the VSAM clusters, then specify a maximum record size of 2000 on the RECORDSIZE parameter of the IDCAMS utility DEFINE CLUSTER command.

  6. For an implicit file definition, an EXTENT statement with a volume serial number (SQLWK1 in the example) is required.

  7. An ASSGN statement is not required for VSE/VSAM-managed files.

Files Managed by SAM

If you use native SAM, which cannot extend files, to manage accounting files on DASD, you must devise operating procedures to avoid overlaying the accounting information from the previous run of the database manager. This can be done by updating your job control EXTENT statements every time you start the application server, or by using two sets of job control with different EXTENT statements. When starting the application server, you would alternate between the two sets of job control statements.

If you use this approach, be certain to process the accounting file as soon as you close it; otherwise it will be overlaid the next time you start the application server by using the job control that identifies the file. If you load your accounting data into tables, consider prefixing your normal start-up job control with a DBS utility job that runs in single user mode (with ACCOUNT=N specified). This job would run the DBS utility to load accounting data from the previous session into tables to prevent it from being overlaid by the next job.

Figure 76 shows sample job control statements for native SAM accounting files.

Figure 76. Job Control for DASD Accounting Files (Native SAM)

 
// DLBL ARIACC1,'ACCTFIL1'
// EXTENT ,SQLWK1,1,0,57,38
// DLBL ARIACC2,'ACCTFIL2'
// EXTENT ,SQLWK1,1,0,95,30
// ASSGN SYS007,DISK,VOL=SQLWK1,SHR

Notes:

  1. The DLBL file name for the primary accounting file must be ARIACC1; that for the secondary file must be ARIACC2.
  2. In this example, the DASD allocation for the primary accounting file is 38 tracks on SQLWK1. The 38 tracks start at relative track 57. The secondary accounting file has an allocation of 30 tracks on the same volume starting at relative track 95.
  3. If you are only using one accounting file, you must specify a new DASD allocation every time you start the application server. Otherwise, you will write over the old file. (You should also specify a different file-id.)

    Even if you are using alternate accounting files, you would have to change the extents unless you ensure that the accounting data from the previous run is processed before it is overlaid.

  4. This example uses the DB2 Server for VSE default symbolic unit for DASD output (SYS007). If you do not want the default, specify the symbolic unit of your choice as the first EXTENT parameter. Also specify it in the ASSGN statement. If you are also using DB2 Server for VSE tracing with output directed to DASD, either the trace or accounting output must be directed to a symbolic unit other than SYS007. In single user mode, DBS utility output or trace output to DASD causes the same problem. You must ensure that the output from only one of the facilities is directed to SYS007.

Files Managed by VSE/VSAM ESDS

It is recommended that you define your accounting files on DASD as VSE/VSAM ESDS files because they handle the End-of-Extent situation better than VSE/VSAM managed by SAM files. All advantages of using VSE/VSAM files still remain for VSE/VSAM ESDS files, except that the files will have to be defined explicitly. Figure 77 shows sample IDCAMS commands to define two VSE/VSAM ESDS accounting files. See Converting VSAM ESDS Accounting File Records into VSAM Managed SAM Feature Records for related consideration of loading the accounting records using VSE/VSAM ESDS accounting files.

Figure 77. IDCAMS Commands to Define VSE/VSAM ESDS DASD Accounting Files

 
// EXEC IDCAMS,SIZE=AUTO
 
DEFINE CLUSTER (NAME(ACCTFIL1) -
                  VOLUMES(SQLWK1) -
                  ORDERED -
                  REUSE -
                  RECORDS(x y) -
                  RECORDSIZE(80 80) -
                  NOINDEXED) -
                  DATA(NAME(ACCT.FILE1.DATA))
 
DEFINE CLUSTER (NAME(ACCTFIL2) -
                  VOLUMES(SQLWK1) -
 
                  ORDERED -
                  REUSE -
                  RECORDS(x y) -
                  RECORDSIZE(80 80) -
 
                  NOINDEXED) -
                  DATA(NAME(ACCT.FILE2.DATA))
/*

Note:
  1. Set RECORDSIZE to (80 80) because that is the size of an accounting record.
  2. For RECORDS=(x y), set x to the number of accounting records you expect to be generated during your accounting period. The value of y determines the size of the secondary allocation.

Figure 78 shows sample job control statements for two VSE/VSAM ESDS accounting files.

Figure 78. Job Control for DASD Accounting Files (VSE/VSAM ESDS)

 
// DLBL ARIACC1,'ACCTFIL1',0,VSAM,                C
         CAT=SQLWK1,DISP=(OLD,KEEP)
// DLBL ARIACC2,'ACCTFIL2',0,VSAM,                C
         CAT=SQLWK1,DISP=(OLD,KEEP)

Note:
  1. The DLBL file name for the primary accounting file must be ARIACC1, and the secondary file name is ARIACC2.
  2. The DLBL parameter VSAM indicates that these are VSAM managed files.
  3. The example assumes that the files are explicitly defined using the sample IDCAMS commands illustrated in Figure 77.
  4. Every time the application server is started, it directs output to the file identified by file name ARIACC1 (even if you are using two accounting files). To avoid having the accounting information from the previous run of the database manager erased, specify the DISP=(OLD,KEEP) options on the DLBL statement for the accounting file to indicate that the files are not to be reset at OPEN time (OLD), and are not to be deleted as CLOSE time (KEEP).
  5. If the RECSIZE parameter is specified in the DLBL statement, its value should be set to 80.

Managing Tape Accounting Files

To write accounting records to a tape file, specify a TLBL statement in your database job control. The file name on the TLBL statement must be ARIACC1. If you will be using alternate accounting files, specify a TLBL statement for a second accounting file, and call the file ARIACC2.

When accounting to tape, the database manager uses the VSE dynamic tape ASSIGN macro. The operator is prompted for the address (cuu) of the tape drive.

If you switch the output to the alternate file, the cuu of the first accounting file is unassigned by the VSE dynamic tape ASSIGN macro, and becomes available for use for any purpose, including reuse for the alternate file. Figure 79 shows an example of job control statements for two accounting files.

Figure 79. Example Job Control for Accounting Files on Tape

 
// TLBL ARIACC1,'ACCTFIL1'
// TLBL ARIACC2,'ACCTFIL2'

To avoid overlaying accounting information from the previous session, the database manager does not rewind the accounting tape at OPEN or CLOSE time. Therefore, when the application server is next started, another accounting file is written starting after the file from the previous session.

A block size of 2000 is used for the tape file. This provides efficient performance, and minimizes the amount of accounting data lost due to a system failure or a write error on the tape.

While it is unlikely that you will reach end-of-volume for a tape accounting file, multivolume tape support is provided. You must use only IBM standard label tape files.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]