Previous Topic: DQU: User TableNext Topic: DQWFI Initializing the DQE, DQF, and DQW (DQWFINIT)

Preparing and Maintaining the CA Dataquery System Tables › DQW: Work Table

DQW: Work Table

The DQW (Work Table) is the batch equivalent of the DQF. The DQW stores and manages found sets that result from batch queries. This table is segmented into partitions to allow the concurrent execution of several batch queries. (The KEEP and EXTRACT commands are not available in batch CA Dataquery so no Saved or Extracted sets are present on the DQW.) The DQW is accessed to write the pointers to the data or the data resulting from a query to it. The DQW is read when you want to report on the results of a query.

Description

The logical row length of the DQW (Work Table) is 772 bytes long. The default block size is 4096 bytes. Each physical block holds four logical blocks, which are used as an intermediate area for holding the logical rows selected during a batch query execution.

The DQW (Work Table) is very similar to the DQF in structure and use. It provides CA Dataquery batch jobs with space for the storage and manipulation of query results. Subsets of the table are dynamically assigned to individual batch jobs as required and later released when the job is terminated.

Estimating the DQW Allocation

When estimating the minimum size for your DQW, consider the following:

The number of batch CA Dataquery jobs which can run simultaneously is limited to the number of operating system partitions or regions available for the CA Dataquery job class. You must specify this number in the DQW control statement when you execute DQWFINIT. The DQW is divided into segments of which one is required for each batch query running at once.

Since the entire DQW is divided into segments, one per job, each job can only make use of the space in one segment. To determine the appropriate size for your DQW, you must first calculate the approximate number of physical blocks required per DQW segment for the successful execution of your largest anticipated query. To do this, perform the following calculations:

Step 1:

Find the Logical Record Length:

6 + (18  x AVG-FILES) = (Average Logical Record Length)
6 + (18  x ______________) = _________________________________
Step 2:

Calculate the number of logical records per block:

760 / n = (Logical Records per Block)
(where n = average logical record length from Step 1)
760 / _____________ = ___________________
Step 3:

Calculate the number of logical blocks needed to process a query with the largest number of logical records found.

(Logical Records Found) / (Number of Records per Logical Block)
___________________________ / ________________________ = ___________
Step 4:

Calculate the number of logical blocks needed to execute a query. (The factor of 8 allows for SET statements and SORT keys which are kept in the Found File.)

(Number Logical blocks)  x 8 = (Logical Blocks for Execution)
___________________________  x 8 = ________________________
Step 5:

Calculate the number of logical blocks needed for the entire DQW. Multiply the results of Step 4 by the number of batch DQ jobs which you want to allow to run concurrently. (Number of DQ segments.)

(Results of Step 4) * (Number DQ Segments) = (Number Logical Blocks
for DQW)
___________________________  x ________________________ = ____________
Step 6:

Calculate the number of physical blocks needed for the entire DQW. Divide the results of Step 5 by 5 (which is the number of logical blocks, 760, in a physical block).

(Results of Step 5) / 5 = (Number Physical Blocks for DQW)
______________________ / 5 = _________________
Step 7:

Calculate the total number of tracks required by dividing the results of Step 6 by the number of blocks per track considering the block size of the DQW is 4096.

(Results of Step 6) / (Number Blocks per Track) = (Tracks Required)
_____________________ / ________________________ = _________________

(Example: The number of blocks per track on a 3380 is 10.)

Note: If batch CA Dataquery jobs terminate due to space limitations, re-evaluate the size of your DQW.

Maintaining the DQW

No extracts are ever kept on the DQW table. (Extract is an online function.) If problems arise with DQW, reinitialize and run the DQWFINIT to format. If the DQW is large, reinitializing may take a lot of resources. Consider backing up a freshly formatted DQW using DBUTLTY and in the event of corruption, use it instead of reinitializing.

In DBUTLTY Directory (CXX) reports, the DQW always shows 99 percent full after DQWFINIT has been run. A lack of available work space on the DQW is indicated by error messages. The percent full value on the report for the DQF and the DQE shows the maximum used at one time (a "high-water mark"). Space that has been used and freed shows on the report as being in use.

Enlarging the DQW

If batch CA Dataquery jobs terminate due to space limitations, you should re-evaluate the size of your DQW.

To enlarge your DQW, perform the following procedure:

  1. Initialize the space using the DBUTLTY INIT Data Area function. See the CA Datacom/DB DBUTLTY Reference Guide for details.
  2. Null load the DQW using the DBUTLTY LOAD Data Area function. See the CA Datacom/DB DBUTLTY Reference Guide for details.
  3. Initialize the DQW using the DQWFINIT utility. See Initializing the DQE, DQF, and DQW (DQWFINIT) for details.

    When the table is initialized with DQWFINIT, all the logical blocks are assigned to partitions and allocated to different batch CA Dataquery jobs as those jobs are started.

Note: Because the DQW is preformatted by the DQWFINIT utility, it will always show 99 percent full on the CA Datacom/DB Directory (CXX) report.

Recovering the DQW

If the DQW is lost due to catastrophe:

Note: Once the DQW has been formatted with DQWFINIT, it may be backed up using DBUTLTY BACKUP and reloaded using DBUTLTY LOAD instead of using a null load and DQWFINIT, unless you want to change the number of DQW partitions. This is true only for the DQW table. You may not use DBUTLTY to load DQF or DQE. They must always be formatted with DQWFINIT.