Using pubsets in UDS/SQL

The pubset management of BS2000 (see the “Introduction to System Administration”) offers you the option of determining the location at which files are stored on public disks. Both single-feature pubsets (SF pubsets) and system-managed pubsets (SM pubsets) can be used here.

The database administrator can exploit several advantages when utilizing the pubset administration facilities in UDS/SQL. It is possible to

• use the CREATE-FILE command to set up UDS/SQL files and thereby locate them on particular public volume sets

• use physical allocation to place files specifically on volume sets or individual volumes. To do this the BD2000 system administrator must make the SF pubset available with the corresponding attribute or grant the user ID the right to perform physical allocation on a pubset-specific basis. For details, please refer to the "Introduction to System Administration" and "Introductory Guide to DMS" manuals.

• use public volume sets, volume sets or volumes for database files exclusively to ensure that the disk space required for dynamic extension or online extension is also actually available.

• limit the consequences of a failure by positioning UDS/SQL files on a number of different public volume sets, so that, in the event of the failure of one public volume set, files on other public volume sets are still usable

• use state-of-the-art hardware technology (clones, snaps) by storing database files and RLOG files in a public volume set in order to be able to make database copies at any time during ongoing operation. For security reasons the RLOG file must, however, always be maintained in duplicate on a different volume set in these cases.

• restrict the UDS/SQL pubset environment (see section “Pubset declaration job variable”) to prevent the ambiguity of file names from having a disturbing influence on UDS/SQL operation.

• place the original files and their respective backup copies (.SAVE) on different public volume sets, in keeping with the principles of enhanced recovery

• achieve enhanced performance by expedient distribution of the UDS/SQL files over different public volume sets.

The UDS/SQL database administrator must take note of the following:

UDS/SQL does not treat existing database files and system files in the same way as new files.
Database files are: realms, ALOG file, HASHLIB and COSSD.
System files are: SLF, temporary realms, RLOG files and DB status file.

Existing database and system files

For such files UDS/SQL requires there to be no second file of the same name in any of the relevant public volume sets under their user ID in the local processor.
The public volume sets which are relevant for operating UDS/SQL can be specified for a program run by means of the pubset declaration (see section “Pubset declaration job variable”). If nothing is specified, the requirement for uniqueness applies for all public volume sets which are available locally.
Owing to this requirement for unique names, UDS/SQL itself is capable of ascertaining the catalog ID :catid: of any existing database or system file and then using it internally. Thus for such files it is not essential to specify the catalog ID explicitly at the user interface, and this is in fact partly forbidden by UDS/SQL so as to avoid discrepancies between the :catid: specified for a file and its actual :catid:.

In this way the database administrator can define the location of the major UDS/SQL files flexibly without having to inform UDS/SQL explicitly of the location of the individual files.

Existing files of other types

For all other files, such as load parameter files, DISTABLE files, UDS/SQL ENTER files, etc., the catalog ID can generally be specified together with the user ID when assignment takes place. However, a check is made to ensure that the scratch files of the utility routines (SCRTCH and SORTWK files) are unique in accordance with the pubset declaration. Consequently any catalog ID which is specified can be ignored.
Existing files which the database administrator has not assigned specifically must otherwise be under the default catalog ID (see the ADD-USER command in the commands manuals for "BS2000 OSD/BC").

As a rule, specifying the catalog ID is always permitted:

• when setting up files with the CREATE-FILE command,

• when assigning files for UDS/SQL with the ADD-FILE-LINK command and LINK-NAME and

• when declaring the configuration name with the SET-FILE-LINK command and LINK-NAME.

Files to be set up by UDS/SQL

Unless they have to be set up explicitly by the user, UDS/SQL creates any missing files under the default catalog ID of the database or configuration user ID (see the "BS2000 OSD/BC" command manuals, ADD-USER command).

Exception

RLOG file:

Catalog ID defined with PP LOG, PP LOG-2, PP RESERVE, MODIFY LOG, MODIFY-LOG-2 or MODIFY RESERVE.

ALOG file:

Catalog ID defined with BMEND statement START-LOG.

If the default catalog ID is to be changed in the user catalog, note that all files that are not searched in the available pubsets ("files of other types“) must also be transferred from the old default catalog identifier to the new so that they, too, can be found by UDS/SQL (see the MODIFY-USER-ATTRIBUTES command in the commands manuals for "BS2000 OSD/BC").

UDS/SQL accesses locally accessible public volume sets only, even if multiprocessor systems (MSCFs) and remote file access (RFA) are used.

No database or system files are opened by UDS/SQL until an FSTAT macro has been issued (SHOW-FILE-ATTRIBUTES command) for all public voume sets assigned in the currently valid UDS/SQL pubset declaration. Processing does not wait until public volume sets that are in QUIET state exit this state again. As a result, files located in these public volume sets are not included in subsequent processing even if they are included in the UDS/SQL pubset declaration.

The greater the number of public volume sets occupied by database and system files belonging to a given database, the greater the internal administration overhead required. Consequently, to avoid a degradation in performance, only the required number of public volume sets should be included in the UDS/SQL pubset declaration.

Restrictions on the assignment of files with respect to the catalog ID are possible with statements of the utility routines. These are described in the descriptions of the interfaces of the individual utility routines in the related manual.

The following table indicates the user/DBH interfaces at which specifying :catid: is and is not permitted:

User interface	Function
/SET-FILE-LINK LINK-NAME=DATABASE,    FILE-NAME=[:catid:][$admuserid.]configuration-name	Defines the configuration name
/ADD-FILE-LINK LINK-NAME=DATABASE,    FILE-NAME=[:catid:][$dbuserid.]dbname[.DBDIR]1	Defines the database for the utility run
PP DBNAME=[$dbuserid.]dbname[.copy-name],... ADD DB=[$dbuserid.]dbname[.copy-name],...	Specifies the name and optionally the database user ID
PP DISTABLE=[:catid:][$userid.]file-name ADD DIS,FILE=[:catid:][$userid.]file-name SAVE DIS,FILE=[:catid:][$userid.]file-name	Specifies the name of a DISTABLE file
/ADD-FILE-LINK LINK-NAME=PPFILE,    FILE-NAME=[:catid:][$userid.]file-name /ASSIGN-SYSDTA TO=[:catid:][$userid.]file-name	Assigns the load parameter file

Table 20: Overview of options for the catalog identifier at UDS/SQL user interfaces

¹ Specifying :catid: is permitted in this case so that an existing DBDIR can be utilized for the ADD-FILE-LINK command.

Key:
userid	user identification
dbuserid	database identification
admuserid	configuration identification