Work files

For the REORGANIZE functions, BREORG requires different work files on disk. These files are automatically created and stored on public disk under the appropriate user ID and erased again after normal completion of the run.

Work files for the REORGANIZE-CALC and REORGANIZE-SET statements

The statements REORGANIZE-CALC and REORGANIZE-SET require two work files using the standard file link names SCRTCH1 and SORTWK:

SCRTCH1

BREORG requires this file in order to reorganize direct and indirect hash areas or multi-level tables.
It contains an intermediate version of the CALC entries or table lines to be processed.

SORTWK

Requires the SORT used by BREORG for sorting internal evaluation records (see manual “SORT (BS2000)”).

If these work files are to be explicitly created, they must be assigned the following attributes:

Work-file-1

File link name SCRTCH1

Access method = PAM

Primary allocation, calculated as follows:

The data population for buffering can be calculated using the following formulae

• for the reorganization of indirect hash areas:

  (12 + key length ) * number of entries Bytes

• for the reorganization of direct hash areas:

  8 * number of entries Bytes

• for the reorganization of multi-level tables:

  12 * number of entries Bytes

key length

Length of CALC key

number of entries

Number of CALC index entries or occupied table lines

Work-file-2

SORT needs Work-file-2 if there is not enough virtual memory for pre-sorting. The primary allocation should be based on the data population that is to be sorted while taking account of the safety factor recommended by SORT (see the discussion of work files in the manual “SORT (BS2000)”). There should always be an appropriate secondary allocation in case it is necessary to extend the storage space.

File link name SORTWK

Access method = PAM

The data population for sorting can be calculated using the following formulae

• for the reorganization of indirect hash areas:

  (12 + key length ) * number of entries Bytes

• for the reorganization of direct hash areas:

  (record length + key length + 7) * number of entries Bytes

• for the reorganization of multi-level tables:

  12 * number of entries Bytes

key length

Length of CALC key

number of entries

Number of CALC index entries or occupied table lines

record length

Length of records or table lines. Secondary allocation in case the storage space must be enlarged; secondary should be not less than 120, and not zero.

If you do not create the two work files yourself, BREORG sets them up automatically with the following names and sizes:

UTI.tsn.SCRTCH1	(360,360) for REORGANIZE-SET and for REORGANIZE-CALC
UTI.tsn.SORTWK	(120,120)

tsn       

stands for the task sequence number of the current task.

Work files for the REORGANIZE-POINTERS statement

With the REORGANIZE-POINTERS statement, BREORG uses work files for the record types and an additional work file for sorting.

You can also create the work files for the record types yourself via the file name, and the work file for sorting via the file link name.

Work files for the record types

• File names UTI.BREORG.dbname.xxx.yyyyy

  dbname

  Name of the database

  xxx

  Realm number of the specified realm

  yyyyy

  Number of the record type whose probable position pointers (PPP) are updated in the realm;

  yyyyy=0 is used for probable position pointers in SYSTEM sets if required.

  Access method: SAM

  The data population for buffering can be calculated using the following formula

  number of ppps * 11 Bytes

  If you do not set up the files yourself, then BREORG uses the size of the DBTT for the record type yyyyy together with the size of the realm xxx to calculate the expected data population.

  The minimum size is based on 5000 objects for buffering.

• File name UTI.BREORG.dbname.xxx.00001

  dbname

  Name of the database

  xxx

  Realm number of the specified realm

  Access method: SAM

  The user schema does not contain any record type with record type number 1. All the updated probable position pointers (PPP), sorted by their position in the realm, are stored in the work file with record type number 1. The size of this file therefore depends on the total size of required individual files UTI.BREORG.dbname.xxx.yyyyy (yyyyy=0 bzw. yyyyy>1).

  The work files are deleted once the probable position pointer (PPP) update has been completed.

Work file for sorting

SORT needs this work file if there is not enough virtual memory for pre-sorting. The primary allocation should be based on the data population that is to be sorted while taking account of the safety factor recommended by SORT (see the discussion of work files in the manual “SORT (BS2000)”). There should always be an appropriate secondary allocation in case it is necessary to extend the storage space.

File link name: SRT1WK

Access method: PAM

Approximate size: maximum size of all files UTI.BREORG.dbname.xxx.00001

If the work file was created explicitly for sorting, it must also be deleted again explicitly if need be.