The DBH load parameters define the basic characteristics of a session. With the exception of PP DBNAME and PP PASSWORD, no load parameter may be specified more than once.There are default values for any DBH load parameters left unspecified. Only PP END and PP LOG must be specified. You use PP END to terminate the input and PP LOG to determine whether or not the DBH is to maintain an RLOG file.
The DBH load parameter names may not be truncated, with the exception of a number of operands. The mandatory character string is underscored.
The operands must not be separated by blanks, since every entry after the first blank is interpreted as a comment.
Example
PP DBNAME=dbname,'BLANK'
n
In this case, the value ”n“ will be interpreted as a comment.
Input records which begin with "#" or "*" are interpreted as comments.
All DBH load parameters may be used both for the linked-in DBH and for the independent DBH. If load parameters which are not evaluated in the current DBH variant are specified, a warning is issued.
Evaluation of DBH load parameters
The specified DBH load parameters are evaluated only on starting the DBH. The values which apply in the event of a session restart are those which were present in the SLF at the time of a session abort: some of the session characteristics may have been redefined by the database administrator in the course of the session using the Database Administrator Language (DAL).
The DBH indicates by means of the following message that it skips the specified DBH load parameters in the event of a session restart:
% UDS0709 UDS SESSION RESTART, PROGRAM-PARAMETERS WILL BE SKIPPED.
It is possible, however, to modify the default procedure and respecify the DBH load parameters explicitly after a session abort. This entails deleting the contents of the SLF (see section “Session log file (SLF)”).Once the SLF file has been deleted, the DBH starts a new session and evaluates the DBH load parameters.
Responses in error situations
If a DBH load parameter is entered more than once (except in the case of PP DBNAME or PP PASSWORD), the DBH evaluates only the first correct parameter and ignores the rest.
If the DBH fails to identify the keyword, it issues an error message and aborts the DBH start.
Load parameters must be no more than 72 characters in length. Longer character strings are rejected by the DBH and treated as syntax errors.
If DBH load parameters are entered interactively, the DBH issues an error message in the event of syntax errors. In such cases, the error can be corrected by re-entering the load parameter correctly. If this is not done, the DBH aborts the DBH start after PP END.
Exception
No direct corrections are possible in the case of PP PASSWORD and PP DBNAME. If the error that occurred for PP DBNAME is a syntax error, however, you may specify additional statements for PP DBNAME, but these will only be checked for syntax. The DBH start is aborted by the DBH after PP END even if valid statements for PP DBNAME are present.
If stored DBH load parameters are entered from a cataloged file, direct error correction is not possible. In the event of an error, the DBH aborts the DBH start. The error must be corrected in the file.
If DBH load parameters containing numeric values outside the permitted ranges are entered, the DBH assumes the highest or lowest permitted value, as appropriate, and issues a warning for the corresponding load parameter.
The independent DBH processes the following load parameters.
Parameter | Default value | Meaning |
| 1 | Defines size of the 2-Kbyte system buffer pool in Mbytes; |
| 1 | Defines size of the 4-Kbyte system buffer pool in Mbytes; |
| 0 | Defines size of the 8-Kbyte system buffer pool in Mbytes; |
| REMOTE | REMOTE: |
| - | Defines password for administration via DCAM ENTRY: not permitted |
| SUD$ | Defines a prefix for names of user tasks which execute on virtual hosts |
| STD | Defines password for files created by the DBH, such as ALOG files and temporary realms |
| 60 | Specifies period in seconds for connection and transaction checking by the UDS-D task |
| 1024 | Specifies minimum size in Kbytes of common pool; |
| MONO- | Specifies processor type used |
| 10241 128 2 | Specifies minimum size in Kbytes of communication pool; |
| - | Names databases in DB configuration; |
| YES | Enables deactivation of UDS/SQL tasks due to computer workload |
| 60 | Time in seconds to resolve interconfiguration deadlocks or deadlocks involving openUTM |
| 10241 642 | Specifies minimum size in Kbytes of distribution pool; |
| 1 | Maximum number of remote databases that can be accessed per transaction; |
| - | Specifies input file for creating distribution table |
| NO | Controls participation in UDS-D operation STANDBY START |
| ALL | Determines the scope of a dump |
| - | Terminates input of load parameter |
| ASYNC | Executes I/Os in server tasks asynchronously or synchronously |
| STD | Defines locking protocol |
| - | Maintains the RLOG file |
| - | Maintains the duplicate RLOG file |
| 192,192 | Specifies amount of storage (number of PAM pages) in RLOG files |
| Sum of | Specifies maximum number of databases in DB configuration; |
| STD | Specifies segment size |
| STD | Controls system behavior if new UPDATE transactions or processing chains collide with the execution of pending requests |
| NO | Lists parameters used |
| STD | Defines password that the DBH must use along with PP CATPASS in order to open files |
| STD | Controls handling of privacy checks |
| WAIT,WAIT | Controls handling of transactions in PTC state; |
| NONE | Specifies reserve volumes for RLOG files |
| 0 | Groups together request results for user tasks; |
| SYMMETRIC | Controls optimization of communications between the user task and server task and the processing of pending DML jobs in the server task |
| 1 | Defines number of server tasks under independent DBH |
| 10241 1282 | Specifies size of the SSITAB pool in Kbytes; |
| 4 | Defines maximum number of simultaneously active SQL conversations; |
| 10 | Sets minimum time for which UDS/SQL maintains the conversationspecific data for inactive conversations; |
| NO | Writes standard checkpoints in AFIM logging at a DBH start, DBH end, and a session restart |
| 1 | Defines maximum number of subschemas that can be used at one time in a database; |
| 0 | Defines maximum number of logical file names open at one time per database (KDBS only); |
| STD | Defines usage modes for transactions |
| (4,1) | n: |
| C' <U' | Defines operator terminal (UCON) on which DCAM administration is to be logged |
| EVENT | Sets wait mode |
| STD | Determines duration of a warm start |
Table 8: Load parameters of the independent DBH
1 if PP MPSEG=STD is specified
2 if PP MPSEG=64K is specified
The linked-in DBH processes the following load parameters:
Parameter | Default value | Meaning |
| 1 | Defines size of the 2-Kbyte system buffer pool in Mbytes; |
| 1 | Defines size of the 4-Kbyte system buffer pool in Mbytes; |
| 0 | Defines size of the 8-Kbyte system buffer pool in Mbytes; |
| STD | Defines password for files to be created by DBH, such as ALOG files and temporary realms |
| NO | Outputs linked-in DBH messages to operator console as well |
| - | Names databases in the DB configuration; |
| - | Terminates input of load parameters |
| - | Maintains the RLOG file |
| - | Maintains the duplicate RLOG file |
| 192,192 | Specifies amount of storage (number of PAM pages) in RLOG files |
| Sum of | Defines maximum number of databases in DB configuration; |
| NO | Lists load parameters used |
| STD | Defines password that the database must use along with PP CATPASS in order to open files |
| STD | Controls handling of privacy checks |
| NONE | Specifies reserve volumes for the RLOG files |
| NO | Writes standard checkpoints in AFIM logging at a DBH start, DBH end, and a session restart |
| 1 | Defines maximum number of subschemas that can be used at one time in a database; |
| 0 | Defines maximum number of logical |
| 1 | Defines number of simultaneously active transactions |
| STD | Determines duration of a warm start |
Table 9: Load parameters of the linked-in DBH
The value of the load parameter PP TRANSACTION is fixed; any attempt to define a different value is ignored. It is therefore not necessary to specify this parameter.
Defining the 2-Kbyte system buffer pool size (2KB-BUFFER-SIZE)
|
Default value: | |
1 | |
n | Size, in Mbytes, of the system buffer pool in which realm pages of databases with a 2-Kbyte page format are buffered: n = 1..2047 |
The size of the system buffer pool determines how often the DBH must access realms of the databases belonging to the DB configuration. Selecting a large buffer size will reduce the number of accesses required. Depending on the available main memory, however, this may increase the paging rate and thus delay database operations in certain circumstances.The start phase of UDS/SQL is also prolonged, as is the setting of consistency points and database reconstruction (see also the load parameter “PP WARMSTART” in chapter "DBH load parameters").
For the specified value to be meaningful, the system configuration must have the necessary resources. It is not a good idea to use the maximum value, since all the available address space would then be taken up by the system buffer pool alone.
Defining the 4-Kbyte system buffer pool size (4KB-BUFFER-SIZE)
|
Default value: | |
1 | |
n | Size, in Mbytes, of the system buffer pool in which realm pages of databases with a 4-Kbyte page format are buffered: n = 1..2047 |
The size of the system buffer pool determines how often the DBH must access realms of the databases belonging to the DB configuration. Selecting a large buffer size will reduce the number of accesses required. Depending on the available main memory, however, this may increase the paging rate and thus delay database operations in certain circumstances.The start phase of UDS/SQL is also prolonged, as is the setting of consistency points and database reconstruction (see also the load parameter “PP WARMSTART” in chapter "DBH load parameters").
For the specified value to be meaningful, the system configuration must have the necessary resources. It is not a good idea to use the maximum value, since all the available address space would then be taken up by the system buffer pool alone.
Defining the 8-Kbyte system buffer pool size (8KB-BUFFER-SIZE)
|
Default value: | |
0 | |
n | Size, in Mbytes, of the system buffer pool in which realm pages of databases with an 8-Kbyte page format are buffered: n = 0 or n = 3..2047 |
If no databases with an 8-Kbyte page format are to be processed in the session, you may optionally prevent the creation of an 8-Kbyte system buffer pool by omitting the load parameter entirely or by specifying PP 8KB-BUFFER-SIZE=0.
The size of the system buffer pool determines how often the DBH must access realms of the databases belonging to the DB configuration. Selecting a large buffer size will reduce the number of accesses required. Depending on the available main memory, however, this may increase the paging rate and thus delay database operations in certain circumstances.The start phase of UDS/SQL is also prolonged, as is the setting of consistency points and database reconstruction (see also the load parameter “PP WARMSTART” in chapter "DBH load parameters").
For the specified value to be meaningful, the system configuration must have the necessary resources. It is not a good idea to use the maximum value, since all the available address space would then be taken up by the system buffer pool alone.
Defining DBH administration (ADM)
Independent DBH only!
|
Default value:
REMOTE
REMOTE
DBH administration via DCAM is possible either using the UDSADM administration program (recommended) or by connecting a display terminal directly to DCAM (see section “Administration of UDS/SQL via UDSADM” and section “Administration of UDS/SQL via DCAM”). A DCAM application is opened at UDS/SQL initialization. The application name is identical with the configuration name or the first 8 characters of configuration-name.
LOCAL
The master task reserves the terminal permanently or administration is effected from the console using the INFORM-PROGRAM command. No DCAM application is opened.
Defining a password for administration via DCAM (ADMPASS)
Independent DBH only!
|
admpassword
Defines a password for administration if PP ADM=REMOTE has been specified (see the section “Administration of UDS/SQL via UDSADM” and section “Administration of UDS/SQL via DCAM”). It may be up to four bytes in length and is represented as follows:
C’xxxx’:
one through four alphanumeric characters
X’nnnnnnnn’:
one through eight hexadecimal digits
The value of PP ADMPASS can be changed dynamically with the DAL commands ADD (see "Attaching databases, realms and passwords (ADD)") and DROP (see "Detaching databases, realms and passwords (DROP)").
Defining a prefix for user tasks in UDS-D distributions (BCAM-PREFIX)
Independent DBH only!
|
Default value: | |
SUD$ | |
prefix | Defines a prefix for BCAM names for distributed communication between the user task and the remote UDS/SQL configuration. This prefix is required specifically when different virtual hosts are defined in a BS2000 system and multiple UDS/SQL configurations are to be distributed over virtual hosts (see also section “Using the UDS/SQL configuration on a virtual host”). prefix must be four characters long and ensure that the BCAM names generated with it are permitted names and that these differ from the names of other BCAM applications in their first four characters. The prefix UDSD is not permitted because it is reserved for the downwardcompatible connection to DCAM_BAS configurations. |
Defining a password for files to be created by the DBH (CATPASS)
|
Default value:
STANDARD
STANDARD
UDS/SQL protects newly created files with a default read password: C’UDS'BLANK'’
password
The password may be up to four bytes in length and is represented as follows:
C’xxxx’:
where xxxx comprises one through four alphanumeric and special characters
X’nnnnnnnn’:
where nnnnnnnn comprises one through eight hexadecimal digits
d:
where d is a decimal number (comprising up to eight digits and a sign) to be converted to a binary value
The syntax conventions for BS2000 apply (see the description of the ADD-PASSWORD command in the commands manuals of "BS2000 OSD/BC").
The PP CATPASS parameter is used to specify a read password to protect all those files which are created by the DBH as required, such as ALOG files and temporary realms. The specified password is applicable to all these files. The password for ALOG files created by the utility routines is C’UDS'BLANK'’.
The DB status files created by the user and the session log file (SLF) are always protected by C’UDS'BLANK'’, regardless of any PP CATPASS specification. This password is not designed to protect the contents of the files against unauthorized access; it is used to prevent these files which are employed in various sessions from being inadvertently deleted. These files only contain database management data. In the case of DB status files it is possible that status files external to the configuration will be needed for openUTM status requests to UDS/SQL. In this case the default password precludes the possibility of conflicting passwords (see section “Assigning passwords to UDS/SQL files”). In the case of the SLF the default password is required to enable the DBH to access the SLF even before it has evaluated the DBH load parameters.
The password C’UDS'BLANK'’ and read passwords specified via PP CATPASS, PP PASSWORD or the DAL command ADD PW should not be used for other files. This is because UDS/SQL issues these passwords internally, so in special situations files would become accessible which users want to protect.
The RLOG files are protected by a password which is derived from the timestamp of the RLOG file.
The password is designed above all to prevent inadvertent deletion. As the RLOG files are extremely important for ensuring the consistency of the data during ongoing operation, each RLOG file is protected by a password of its own. Generally the DBH deletes RLOG files when they are no longer required. If in exceptional circumstances an RLOG file has to be deleted for other reasons, you can issue the password using the RLOGPASS utility routine in the UDS-SQL-T delivery unit.
Monitoring connections and transactions (CHCKTIME)
For UDS-D
|
Default value: | |
60 | |
n | Period in seconds in which the UDS-D task checks whether any of the server tasks is still processing a DML statement. If this is the case the UDS-D task also sends a timing acknowledgment to user tasks waiting for a response to a DML statement still being processed in a remote CPU. This acknowledgment indicates that the DML statement is still being processed and that the logical connection is still being The period set with PP CHCKTIME is also used for a number of other monitoring n = 60..900 |
PP CHCKTIME is operative in UDS-D mode only.
Displaying linked-in DBH messages on the operator console (CONSOLE)
Linked-in DBH only!
|
Default value: | |
NO | |
YES | UDS/SQL is to output all messages to the operator console as well. This applies irrespective of whether the linked-in DBH was started as an interactive task or as an ENTER job. |
NO | Once the DBH load parameters have been read in, UDS/SQL is to output all messages only to the display terminal from which the linked-in DBH was started (or in the corresponding SYSOUT log in the case of batch jobs). |
Specifying the minimum size for individual common pools (CP-SIZE)
Independent DBH only!
|
Minimum value: | |
1024 Kbytes | |
n | Size of a common pool in Kbytes n = 1..16384 n is rounded up to the nearest integral multiple of 1024. If n > 16384, the DBH uses 16384 Kbytes. |
Common pools are created dynamically in a session. The individual common pools are created with size given in PP CP-SIZE or, if this minimum value is insufficient, by using the size value required by the DBH.
The minimum size of a common pool can be displayed by means of the load parameter PP PARLIST or as the CP-SIZE value of the DAL command DISPLAY PP.
Specifying the processor type (CPU)
Independent DBH only!
|
Default value:
MONO-PROCESSOR
MONO-PROCESSOR
The UDS/SQL session is to run on a monoprocessor CPU.
MULTI-PROCESSOR
The UDS/SQL session is to run on a multiprocessor CPU.
The PP CPU parameter is used to specify whether UDS/SQL is to run on a host computer with a monoprocessor or a multiprocessor CPU. On the basis of this information UDS/SQL selects the best holding mechanism to enable it to serialize its internal processing sequences. If PP CPU is incorrectly specified, runtime performance is likely to be impaired.
Specifying the minimum size for the communication pool (CUP-SIZE)
Independent DBH only!
|
Minimum value: | |
1024 Kbytes if PP MPSEG=STD is specified | |
n | Size of communication pool in Kbytes n = 1..16384 n is rounded up to the nearest integral multiple of 1024 for PP MPSEG=STD and up to the nearest integral multiple of 64 for PP MPSEG=64K. For PP MPSEG=64K, values above 8192 are not advisable. If n > 16384, the DBH uses 16384 Kbytes. If the storage space requirement calculated by the DBH exceeds the minimum or the specified value, the value computed by the DBH is used when creating the communication pool. |
If PP MPSEG=STD, the communication pool is created in the upper address space of the UDS/SQL tasks (> 16 MB). In user tasks the communication pool is created in the lower or upper address space depending on AMODE (24/31). If PP MPSEG=64K, the communication pool is located in the lower address space in all tasks. If applications in AMODE 24 are also used in the session, the size of the communication pool must be set such that it fits into the lower address space of this application.
The size of the actually created communication pool can be obtained with the load parameter PP PARLIST or from the CUP-SIZE value output by the DAL command DISPLAY PP. If the average subschema size or job length of an SQL statement exceeds 16 Kbytes, you should increase the actual size by using PP CUP-SIZE.
Naming databases (DBNAME)
|
Default value:
Depends on whether or not PP MAXDB has also been specified:
without PP MAXDB
DBH start with only one database (mono-DB operation)
PP DBNAME=confname
with PP MAXDB
DBH start with empty configuration
(multi-DB operation is possible if PP MAXDB > 1).
$userid
User identification assigned to the database. $userid is mandatory here only if the database is cataloged under a different identification from that used on starting the DBH.
dbname
Name of the database
copy-name
Name of the shadow database
copy-name consists of up to seven characters.
SHARED-RETRIEVAL
The database to be attached can also be accessed by other DBHs using SHARED-RETRIEVAL.
In other words, the application programs of all these DBHs will have read access to the attached database.
Default value:
If SHARED-RETRIEVAL is not specified, EXCLUSIVE-UPDATE applies, i.e. the DBH has exclusive access to the database to be attached; application programs have both read and update access.
Default value for a shadow database: SHARED-RETRIEVAL
n | Size of the user buffer pool for the database in Mbytes. If the parameter bufferid is specified, the buffer pool specified by n is created as a shared user buffer pool (see below): | |
n = 1 .. 2047 | ||
In the case of a database with an 8-Kbyte page format, at least 3 Mbytes are created. | ||
n = 0 | The size of the user buffer pool has already been defined in another database. | |
n not specified and bufferid not specified | ||
The database is buffered in the system buffer pool corresponding to its page format. If this system buffer pool does not exist, activation of the database is rejected. | ||
n not specified and bufferid specified | ||
The size of the user buffer pool has already been defined in another database. | ||
The value n must be specified immediately after the comma and must not be separated by blanks (see "DBH load parameters"). Example | ||
bufferid | buffer pool identifier | |
up to 6 alphanumeric characters (no special characters) | ||
The PP DBNAME parameter is used to specify which databases are to be attached to the DB configuration on starting the DBH. If a database that is to be attached is inconsistent, it is made consistent by means of a warm start.
It is also possible to specify whether access to the given database is to be read-only. If the SHARED-RETRIEVAL operand is omitted, both read and update access to the database are allowed.
If desired, you can also specify the size of an exclusive buffer pool for the named database. This buffer pool will be created in addition to the system buffer pool and only be used to buffer pages of the specified database. If you assign an identifier to the buffer pool with the parameter bufferid, you can assign it as an exclusive, shared user buffer pool to several databases.
There can be several shared user buffer pools in a single session.
PP DBNAME must be specified once for each database to be attached. This applies to all databases that are to be attached immediately on starting the DBH. PP DBNAME may be specified a maximum of 222 times.
No two databases within a DB configuration may have the same dbname.
If there are any databases not cataloged under the user ID with which the session was started, all realms, ALOG files, and the HASHLIB must be declared shareable (SHARE=YES).
CAUTION!
The database files must not be write-buffered or write/read buffered on volatile media (see section “Using DAB caching for UDS/SQL” ).
The effects of specifying RETRIEVAL or omitting the option are shown in the table below:
Option | No option | SHARED- |
Effect | ||
Which usage mode is set when the realms are opened? | UPDATE | RETRIEVAL |
If AFIM logging is activated, are the ALOG files opened and written to? | yes | no |
Does the DBH allow a warm start to be performed if an inconsistent database is attached? | yes | no |
Is READY UPDATE permitted for this database? | yes | no |
Can realms be dynamically attached and detached by means of DAL commands? | yes | no |
Can multiple DBHs access this database concurrently in SHARED-RETRIEVAL mode? | no | yes |
Table 10: Effects of the RETRIEVAL option in PPDBNAME
When a DB is attached while the DBH is being initialized, the compatibility of the ALOG specifications with a UDS/SQL pubset declaration which has already been tested is checked. A DB cannot be attached if one of the ALOG logging specifications which were made using the DEFAULT-SUPPORT or RESERVE-SUPPORT parameter of the BMEND statement START-LOG is outside the pubset space of the current UDS/SQL pubset declaration.
Errors are indicated by one or more of the following messages:
UDS0755 UDS USER ERROR: CATID MISSING IN UDS PUBSET DECLARATION (CURRENT): <catid> , ALOG-DEFAULT ,DB: <dbname> (...,tsn4)
or
UDS0755 UDS USER ERROR: CATID MISSING IN UDS PUBSET DECLARATION (CURRENT): <catid> , ALOG-RESERVE ,DB: <dbname> (...,tsn4)
The following message is then displayed:
UDS0720 UDS ADD ORDER REJECTED: ALOG-SUPPORT NOT WITHIN SCOPE OF UDS PUBSET DECLARATION (...,tsn4)
Message
UDS0719 UDS ENFORCES DROP DB=dbname FOR ERROR HANDLING (...,tsn4)
enables the error to be assigned to the database. The specifications for ALOG DEFAULT-SUPPORT and RESERVE-SUPPORT can be displayed using the BMEND statement SHOW-LOG-INFORMATION.
This does not hinder the startup of the DBH (without the database affected).
Mono-DB operation
If PP DBNAME and PP MAXDB are not specified, the configuration name specified in the command:
/SET-FILE-LINK LINK-NAME=DATABASE,FILE-NAME=configuration-name
is also the database name of the only database to take part in this session (mono-DB operation).
Please note that the usage mode SHARED-RETRIEVAL is not possible for this database, and that the database then cannot be accessed by several DBHs in parallel (see section “Parallel database operation”).
Mono-DB operation can only be started using the user identification under which the database is cataloged.
Notes on reconfiguration
If the existing configuration is to be altered after a session abort (reconfiguration), the following must be borne in mind:
A RETRIEVAL option cannot be specified to attach an inconsistent database, since the DBH must access the database in the EXCLUSIVE-UPDATE mode in order to perform a warm start.
In this case the database must therefore first be attached without a RETRIEVAL operand and detached again after a successful warm start. If necessary, the ACCESS command may be issued to prevent this database being accessed by transactions of the current session.
It is not possible to attach a number of inconsistent databases to different DBHs simultaneously if all these databases have become inconsistent in one and the same session. The reason for this is that the warm starts must be performed sequentially because the DBH has in each case to access the requisite RLOG file in EXCLUSIVE-UPDATE mode.
If a database has become inconsistent under the configuration name A, it cannot be attached to a configuration with the configuration name B by means of a warm start unless there is currently no session running under the configuration name A.
The reason for this is that there is only one DB status file per configuration, and that is accessed in the EXCLUSIVE-UPDATE mode both in the current session and in the event of a warm start.
Deactivating server tasks due to computer workload (DEACT)
Independent DBH only!
|
Default value: | |
YES | |
YES | Specifies that a server task can be deactivated, i.e. that its resources can be deallocated. Deactivation can occur in the following cases:
|
NO | Specifies that a server task cannot be deactivated. This causes the server tasks to run more efficiently, since they are not affected by other tasks in the system even in situations when there is a high load on the system, when extensive system resources are consumed, and in wait states. Other applications could, however, be adversely affected as a result. |
The load parameter PP DEACT can be used to control how server tasks are to be handled by the operating system in high-load situations. See also section “Load parameters that affect processor utilization”.
For this parameter to take effect, an ADD-USER command with the INHIBIT DEACTIVATION=YES operand for the user ID in which the DBH was started is a prerequisite (see the commands manuals for "BS2000 OSD/BC").
When using the DEACT parameter it is important to have precise knowledge of the system load. Only when the parameter is used correctly can the overall situation be improved.
Resolving interconfiguration deadlocks or deadlocks involving openUTM (DEADTIME)
Independent DBH only!
|
Default value: | |
60 | |
n | Time in seconds. An interconfiguration deadlock or a deadlock involving openUTM will be resolved n to 1,5n seconds after it develops. n = 5..900 |
If PP DEADTIME is made too small, transactions may be rolled back unnecessarily, for example with IQS or openUTM multistep transactions.
Specifying the minimum size for the distribution pool (DIP-SIZE)
For UDS-D
|
Minimum value: | |
1024 Kbytes if PP MPSEG=STD is specified; | |
n | Size of distribution pool in Kbytes n = 1..16384 n is rounded up to the nearest integral multiple of 1024 for PP MPSEG=STD and up to the nearest integral multiple of 64 for PP MPSEG=64K. For PP MPSEG=64K, values above 8192 are not advisable. If n > 16384, the DBH uses 16384 Kbytes. If the storage space requirement calculated by the DBH exceeds the minimum or the specified value, the value computed by the DBH is used when creating the distribution pool. |
If PP MPSEG=STD is specified, the distribution pool is created in the upper address space of the UDS/SQL tasks (> 16 MB). In user tasks the distribution pool is created in the lower or upper address space depending on AMODE (24/31). If PP MPSEG=64K is specified, the distribution pool is located in the lower address space in all tasks. If applications in AMODE 24 are also used in the session, the size of the distribution pool must be set such that it fits into the lower address space of this application.
The size of the actually created distribution pool can be obtained with the load parameter PP PARLIST or from the DIP-SIZE value output by the DAL command DISPLAY PP.
Defining the number of remote databases (DISDB)
For UDS-D
|
Default value: | |
1 | |
n | Defines the maximum number of remote databases which can be accessed per transaction. n = 1..32 |
PP DISDB is only effective if the DBH load parameter is PP DISTRIBUTION != NO.
Defining the input file for the distribution table (DISTABLE)
For UDS-D
|
:catid:
BS2000 catalog identifier (see section “Using pubsets in UDS/SQL”)
$userid
User identification to which file-name is assigned
file-name
Name of the input file for the distribution table.
UDS-D reads the input file and from it generates the distribution table (see section “Structure of the input file for the distribution table”). The application program’s only access to remote databases is via the subschemas listed in the distribution table.
If the DBH load parameter PP DISTABLE is omitted, remote application programs can still access the local configuration, but local application programs cannot access remote configurations.
PP DISTABLE is only effective if the DBH load parameter is PP DISTRIBUTION != NO.
Controlling participation in UDS-D operation (DISTRIBUTION)
For UDS-D
|
Default value: | |
NO | |
NO | In this session, remote application programs cannot access the databases of the local configuration and local applications cannot access the databases of remote configurations. No UDS-D-specific tables are generated. |
STANDBY | |
UDS-D operation is only prepared, i.e. UDS-D-specific tables are generated, but the UDS-D task UDSCT is not started. In this session participation in UDS-D operation is not possible until UDS-D operation has been started with the DAL command &START DISTRIBUTION. | |
START | |
UDS-D operation begins on starting the DBH as a result of initiating the UDS-D task UDSCT. | |
If you set the DBH load parameter PP DISTRIBUTION != NO, you should also set the DBH load parameter PP LOG != NO (see “Maintaining the RLOG File (LOG)”).
If the DBH load parameter PP LOG = NO, remote application programs will have only read access to the local configuration, and local application programs will likewise have only read access to remote configurations.
Determining the scope of a dump (DUMP)
Independent DBH only!
|
Default value: | |
ALL | |
STD | A reduced-scope dump is generated, depending on the error situation and the BS2000 version used. |
ALL | A dump of the entire user address space is generated. |
The load parameter DUMP=ALL should be used in particular when the dump generated using DUMP=STD is insufficient for diagnosing a reproducible error.
Terminating parameter input (END)
|
PP END terminates the input of DBH load parameters. PP END must always be specified.
Executing I/Os asynchronously or synchronously (IO)
Independent DBH only!
|
Default value:
ASYNC
ASYNC
Causes server tasks to execute all I/Os asynchronously. This eliminates I/O-related waiting periods for the server tasks and thus prevents bottlenecks in high-load situations.
This setting can, however, result in CPU overconsumption in situations where the load is too low.
SYNC
Causes server tasks to execute all I/Os synchronously, which leads to I/O-related waiting periods. The number of server tasks may need to be increased as a result (see the load parameter PP SERVERTASK in chapter "DBH load parameters").
This setting is therefore recommended only in low-load situations or if a small number of openUTM transactions is involved.
Defining the locking protocol (LOCK)
|
Default value: | |
STD | |
STD | Once a record has been read (see "Locking granularity"), it continues to be subject to a SHARED lock until the next record is read (see "Lock type"). A record that has been updated is subject to an EXCLUSIVE lock until the end of the transaction. |
SHARED | |
As for STD, with one exception: A lock set using the DML statement KEEP is always of the SHARED type. | |
EXCLUSIVE | |
A record read during UPDATE processing is subject to an EXCLUSIVE lock until the end of the transaction. | |
Locking granularity: | |
The unit to be locked is always the entire page that contains the record involved. | |
Lock type: | |
SHARED EXCLUSIVE | |
Processing type: | |
Provided that updates are permitted in principle for a realm (database is attached with UPDATE, realms or databases have not been deactivated explicitly (DAL) or implicitly (error handling) or locked and no realm locks have been set using BPRIVACY), the processing type is always UPDATE if SQL is used. If SQL is not used, it is UPDATE only if READY-USAGE-MODE=UPDATE is set. | |
The parameter applies to all databases participating in the session.
You should specify PP LOCK=SHARED if you use the DML statement KEEP in order to be able to read data repeatedly, but not for the purpose of serialization with respect to other transactions.
By reducing parallel processing, PP LOCK=EXCLUSIVE can be used to achieve shorter path lengths and less deadlocks. You should specify PP LOCK=EXCLUSIVE only if the following points apply to all UPDATE transactions:
All records that are read are also updated.
There are no searches (FIND-7) running sequentially.
Before each access to the member record of a nonsingular set, the owner record is read and modified.
If one of these conditions is not met, concurrency may be diminished or it may not be possible to decrease the path length as anticipated. In this case, you should carry out a performance comparison to check whether it is worthwhile to use PP LOCK=EXCLUSIVE.
Maintaining the RLOG File (LOG)
|
Default value: | |
There is no default value. | |
NO | The DBH does not maintain an RLOG file.
|
:catid: | BS2000 catalog ID (see section “Using pubsets in UDS/SQL”). |
PUBLIC | |
The RLOG file is created on public disk (PUBLIC VOLUME) under the default catalog ID of the configuration user ID. | |
priv-vsn | |
| The RLOG file is created on private disk. Up to three volume serial numbers can be specified, no two of which may be the same. The volume serial number may comprise up to six alphanumeric characters. |
device | Device type of the private disk. The device type may comprise up to eight alphanumeric characters. |
vsn | The RLOG file is created on disks which are allocated to an SF pubset or a volume set of an SM pubset. Up to three VSNs can be specified, no two of which may be the same. |
The load parameter PP LOG determines whether or not the DBH is to create an RLOG file for the session to be started.
The volumes for the original files are specified. Even when a duplicate RLOG file is to be maintained, the specification made with PP LOG determines only where the original files will be kept.
If a duplicate RLOG file is to be maintained, the volumes for the duplicate files must be specified with the load parameter PP LOG-2.
Whether or not a duplicate RLOG file is to be maintained is specified on starting the DBH. This determination cannot be changed later with the DAL command MODIFY. The DAL command MODIFY can be used to change the volumes for the RLOG files.
The amount of storage for the RLOG files is specified with the load parameter PP LOG-SIZE.
Reserve volumes for single and duplicate RLOG files can be specified with the load parameter PP RESERVE.
While the DBH is being initialized, a check is made to see whether the PP LOG specifications are compatible with a UDS/SQL pubset declaration which has already been checked.
In the event of an error, the load parameter concerned is output and the following message is issued:
UDS0711 UDS PROGRAM PARAMETER REJECTED: CATID NOT WITHIN SCOPE OF UDS PUBSET DECLARATION (...,tsn4)
DBH startup is then aborted after the load parameter check has been completed.
Single RLOG file
The DBH maintains one RLOG file (original) per configuration. This RLOG file always consists of two physical original files.
File names when a single RLOG file is maintained
confname.RLOG.rlog-time-stamp.1
confname.RLOG.rlog-time-stamp.2
confname specifies the configuration name.
rlog-time-stamp
specifies the time at which DBH starts to use the RLOG file.
Both copies of the RLOG file are given the same time stamp.
rlog-time-stamp is formed as follows:
yymmddhhmmss
1,2:
differentiate between the two cyclically used, physical copies of the RLOG file.
Duplicate RLOG files
The DBH maintains two RLOG files (original and duplicate) per configuration.
PP LOG specifies the volumes for the two original files and PP LOG-2 specifies the volumes for the two duplicate files.
PP LOG and PP LOG-2 may be given in any order when specifying the load parameters.
A duplicate RLOG file can be maintained only if the original and duplicate files are maintained on different volumes. At initialization, UDS/SQL checks whether the duplicate file resides on a different volume. If it is evident from the syntax analysis of the DBH load parameter that the volumes are the same, the DBH start is aborted. Otherwise, i.e. if the identical volumes are noted only on accessing the volume, the databases involved in the session are protected by an UPDATE lock.
File names when a duplicate RLOG file is maintained
The DBH maintains two RLOG files, i.e. an original and a duplicate (SAVE).
The following four physical files are created:
confname.RLOG.rlog-time-stamp.1
confname.RLOG.rlog-time-stamp.2
confname.RLOG.rlog-time-stamp.1.SAVE
confname.RLOG.rlog-time-stamp.2.SAVE
In the event of an error in one copy of the RLOG file, a rollback is still possible despite the error, using the duplicate; this enables the databases to be kept consistent.
LOG=NO should therefore only be used to load large masses of data quickly into databases after the data resource has been saved.
CAUTION!
Additional conditions for VSN specifications
The following special rules apply for VSN specifications when the RLOG files are created on disks which are allocated to an SF pubset or a volume set of an SM pubset:
VSN specifications are permissible only when authorization exists for physical allocation of public storage space on the pubset concerned.
In both PUB notation (PUBpxx) and dot notation (pp[pp].[xy]z) it is permissible to omit the sequence number of the disk (xx bzw. [xy]z), in which case only a single VSN specification is possible.
This enables the RLOG file to be created on any volumes of an SM pubset’s volume set.
Examples:
(PUBX01, PUBX02)
RLOG file on volumes PUBX01 and PUBX02 in the singlecharacter SF pubset X or volume set X of an SM pubset
(PUBX)
RLOG file on any volume in the single-character SF pubset X or volume set X of an SM pubset
(ABC.01,ABC.02)
RLOG file on volumes ABC.01 and ABC.02 in the threecharacter SF pubset ABC or volume set ABC of an SM pubset
(ABC.)
RLOG file on any volume in the three-character SF pubset ABC or volume set ABC of an SM pubset
If multiple volumes are specified for an RLOG file, these must belong to the same volume set, i.e. the VSNs must contain the same catalog ID. A file cannot extend over multiple volumes sets.
Twin logging files must be created on different volume sets because when a volume fails the entire volume set is generally no longer available.
In addition, one of the twin logging files may also not be created on a volume set of an SM pubset if the other is created in this SM pubset on account of a :catid: or PUBLIC specification.
The following must be borne in mind when the control volume set of an SM pubset is specified for a copy of RLOG or two volume sets of an SM pubset are specified for the RLOG original and duplicate:
If the control volume set of an SM pubset fails, the entire SM pubset is temporarily no longer accessible. (Reconstruction of the SM pubset is possible.)
Maintaining the duplicate RLOG file (LOG-2)
|
:catid: | |
BS2000 catalog ID (see section “Using pubsets in UDS/SQL”). | |
PUBLIC | |
The duplicate RLOG file is created on public disk (PUBLIC VOLUME) under the default catalog ID of the configuration user ID. | |
priv-vsn | |
The duplicate RLOG file is created on private disk. Up to three volume serial numbers can be specified, no two of which may be the same. The volume serial number may comprise up to six alphanumeric characters. | |
device | Device type of the private disk. The device type may comprise up to eight alphanumeric characters. |
vsn | The RLOG file is created on disks which are allocated to an SF pubset or a volume set of an SM pubset. Up to three VSNs can be specified, no two of which may be the same. The VSN can be specified in PUB notation (PUBpxx) or in dot notation (pp[pp].[xy]z). Please also take into account “Additional conditions for VSN specifications”. |
If you specify the load parameter PP LOG-2 then two copies of the RLOG file are written The load parameter value that you specify determines the data media for the duplicate files.
The volumes for the original files are specified with the load parameter PP LOG. PP LOG and PP LOG-2 may be given in any order.
Whether or not a duplicate RLOG file is to be maintained is specified on starting the DBH. This determination cannot be changed later with the DAL command MODIFY. The DAL command MODIFY can be used to change the volumes for the RLOG files.
A duplicate RLOG file can be maintained only if the original file and duplicate file are kept on different volumes. At initialization, UDS/SQL checks whether the duplicate file resides on a different volume. If the volumes are the same, the DBH start is aborted.
Please also take into account the information on "Duplicate RLOG files" in chapter "DBH load parameters".
The amount of storage for the RLOG files is specified with the load parameter PP LOG-SIZE.
Reserve volumes for single and duplicate RLOG files can be specified with the load parameter PP RESERVE.
While the DBH is being initialized, a check is made to see whether the PP LOG-2 specifications are compatible with a UDS/SQL pubset declaration which has already been checked.
In the event of an error, the load parameter concerned is output and the following message is issued:
UDS0711 UDS PROGRAM PARAMETER REJECTED: CATID NOT WITHIN SCOPE OF UDS PUBSET DECLARATION (...,tsn4)
DBH startup is then aborted after the load parameter check has been completed.
Specifying the amount of storage in RLOG files (LOG-SIZE)
|
Default value: | |
192 PAM pages each (2048 bytes/page) | |
primary | Primary allocation in PAM pages |
secondary | |
Secondary allocation in PAM pages | |
The load parameter PP LOG-SIZE is used to specify the following:
The primary allocation, i.e. the amount of storage space to be initially allocated to each RLOG file.
The secondary allocation, i.e. the amount of storage space to be automatically allocated when additional space is needed during file processing.
If for the secondary allocation you specify a value smaller than the default value of 192, the value specified will be rounded up to 192.
The primary allocation should correspond to the anticipated size of the file to be created.
For large files, the values chosen for the primary and secondary pages should be multiples of the management units of 24 or 192 PAM pages.
Defining the number of databases in the DB configuration (MAXDB)
|
Default value: | |
Number of databases specified in the load parameter PP DBNAME. If DBNAME has not been specified, the DBH automatically goes into the mono-DB mode and assumes a value of 1. | |
n | Maximum number of local databases participating in the session In addition to the 222 local databases, up to 32 remote databases can be accessed. In other words, a total of 254 databases may be involved in a session. |
The load parameter PP MAXDB sets a limit on the number of databases that can be attached at any one time to the session to be started.
If dynamic attachment of databases (ADD DB) causes the limit specified in the MAXDB parameter to be exceeded, the DBH rejects attachment of the database.
The DBH makes the value of n equal to the number of PP DBNAME load parameters if n is smaller than the number of databases specified.
PP MAXDB must be specified for a session in which databases are attached dynamically, i.e. where the total number of attached databases may exceed the number at start of the session.
PP MAXDB need not be specified for a session in which no databases are attached dynamically.
Defining the segment size of memory pools (MPSEG)
Independent DBH only!
|
Default value: | |
STD | |
STD | The memory pools are created in the UDS/SQL tasks in the upper address space (> 16 Mbytes) with a segment size of 1 Mbyte. |
64K | The communication pool, transfer pool, distribution pool and SSITAB pool are created below 16 Mbytes with a segment size of 64 Kbytes. This operand should be specified only if the segment size of 1 Mbyte results in memory bottlenecks, since the segment size of 64 Kbytes can have a negative effect on performance. |
Controlling system behavior during collisions between pending requests and UPDATE transactions (ORDER-DBSTATUS)
Independent DBH only!
|
Default value: | |
STD | |
STD | New UPDATE transactions or processing chains that collide with the execution of existing CHECKPOINT or NEW RLOG requests are rejected with the global status code 12122, and the transaction is rolled back with CANCEL. |
SPECIAL | |
New UPDATE transactions or processing chains that collide with the execution of existing CHECKPOINT or NEW RLOG requests are rejected with the specific status code 12124, and the transaction is rolled back with CANCEL. | |
The load parameter PP ORDER-DBSTATUS can be used to control system behavior in cases where the DBH has been instructed by a PERFORM command or a system-internal PERFORM (e.g. because of an error situation) to execute pending requests (CHECKPOINT, NEW RLOG) and is therefore rejecting new UPDATE transactions or processing chains. As a result, the specification ORDER-DBSTATUS=SPECIAL makes it possible to react specifically to certain wait situations in the application program.
Listing the load parameters used (PARLIST)
|
Default value: | |
NO | |
YES NO | Load parameters are listed Load parameters are not listed |
The load parameter PP PARLIST can be used to list the current load parameters on the database administrator’s display terminal or on SYSOUT when starting the DBH or restarting a session.
Defining passwords for files used by the DBH (PASSWORD)
|
Default value:
STANDARD
NONE
UDS/SQL requires only the password specified in PP CATPASS.
STANDARD
UDS/SQL requires only the password specified in PP CATPASS and the standard password C’UDS'BLANK'’.
password
(password,password,...)
In addition to the password specified in PP CATPASS, UDS/SQL requires further passwords. Via password the database administrator transfers the password(s) required for the session. Up to 100 passwords can be specified, distributed over several PP PASSWORD specifications.
password may be up to four bytes in length and is represented as follows:
C’xxxx’:
where xxxx comprises one through four alphanumeric and special characters
X’nnnnnnnn’:
where nnnnnnnn comprises one through eight hexadecimal digits
d:
where d is a decimal number (comprising up to eight digits and a sign) to be converted to a binary value
The syntax conventions for BS2000 apply (see ADD-PASSWORD in the commands manual for "BS2000 OSD/BC").
The PP PASSWORD parameter is used to specify one or more passwords for files which already exist when they are to be opened by the DBH, such as user realms and DBDIR as well as any ALOG files created beforehand, the DB status file and temporary realms (see the section “Assigning passwords to UDS/SQL files”).
Password protection of the file containing the DBH load parameters is the responsibility of the database administrator. The set of passwords can be changed dynamically with ADD PW (see "Attaching databases, realms and passwords (ADD)") and DROP PW (see "Detaching databases, realms and passwords (DROP)").PP PASSWORD may be specified more than once.
The password C’UDS'BLANK'’ and read passwords specified via PP CATPASS, PP PASSWORD or the DAL command ADD PW should not be used for other files, because UDS/SQL issues these passwords internally, so in special situations files would become accessible which users want to protect.
Responses in error situations
As the DBH load parameters are usually recorded in a cataloged file, incorrect PP PASSWORD specifications cannot be corrected by simple repetition during the UDS/SQL start phase. The response to the following input errors is always to abort following PP END:
syntax error in PP PASSWORD
PP PASSWORD=NONE/STANDARD specified more than once
PP PASSWORD truncated when read in
more than 100 passwords specified with PP PASSWORD
Controlling handling of privacy checks (PRIVACY-CHECK)
|
Default value: | |
STD | |
STD | The privacy check is performed. In order to perform the privacy check, the user group name must be in the format described under the section on BPRIVACY in the "Creation and Restructuring" manual. |
NO-KSET | |
The privacy check is performed. The KSET name in the user group name is not checked in the course of a privacy check for openUTM. | |
OFF | No privacy check is performed. |
Handling transactions in the PTC state in the event of errors (PTCSYNCH)
|
Default value:
(WAIT,WAIT)
For UDS-D/openUTM
The first value of the PTCSYNCH parameter applies to secondary subtransactions or openUTM transactions in the PTC condition at the time of a warm start.
For UDS-D
The second value of the PTCSYNCH parameter applies to secondary subtransactions which are in the PTC condition in the course of the session and for which the condition of the corresponding primary subtransaction cannot be ascertained.
WAIT | The secondary subtransactions/openUTM transactions wait until they are terminated either by a message from the corresponding primary subtransaction from openUTM or explicitly by the database administrator using the DAL command ABORT, OPTION=PTC or COMMIT. |
ABORT | |
UDS/SQL rolls back the secondary subtransactions/openUTM transactions and issues a warning. | |
COMMIT | |
UDS/SQL terminates the secondary subtransactions/openUTM transactions, commits the updates and issues a warning to the database administrator. | |
With the DBH load parameter PP PTCSYNCH you may control whether secondary subtransactions or openUTM transactions in the PTC state should terminate with FINISH or with FINISH WITH CANCEL after a time interval defined by PP CHCKTIME.
The values of the DBH load parameter PP PTCSYNCH can be dynamically changed by the database administrator during the session with the aid of the DAL command MODIFY PTCSYNCH.
Specifying reserve volumes for the RLOG files (RESERVE)
|
Default value: | |
NONE No reserve volumes are specified. | |
:catid: | |
BS2000 catalog ID (see section “Using pubsets in UDS/SQL”). | |
PUBLIC | |
Public disk (PUBLIC VOLUME) under the default catalog ID of the configuration user ID. | |
priv-vsn | |
The RLOG file is created on the private disks specified as reserve volumes. Up to three volume serial numbers can be specified, no two of which may be the same. The volume serial number may comprise up to six alphanumeric characters. | |
device | Device type of the private disk. The device type may comprise up to eight alphanumeric characters. |
vsn | Disks which are allocated to an SF pubset or a volume set of an SM pubset are specified as reserve volumes for the RLOG file. Up to three VSNs can be specified, no two of which may be the same. |
The load parameter PP RESERVE is used to assign the reserve volumes for the volumes specified with the load parameters PP LOG and PP LOG-2, except when no reserve volumes are specified.
If a volume specified with the initial allocation PP LOG or PP LOG-2 is unavailable when an RLOG file is created, the reserve volume from PP RESERVE is used in its place. For reserve volumes you must specify different volumes from those specified in the initial allocation. This is not checked when the DBH load parameters are read in, but instead only when a reserve volume is actually needed.
If the volumes of the reserve allocation PP RESERVE are also unavailable, an update lock is placed on the entire configuration. The update lock remains in effect until the volumes become available or another volume is allocated, and the RLOG file is activated with the DAL commands NEW LOG and PERFORM.
Switching to reserve volumes is limited to cases of error; at the earliest opportunity the DBH will attempt again to set up the files involved as specified in the initial allocation.
There is just one specification of reserve file allocation per configuration.
While the DBH is being initialized, a check is made to see whether the PP RESERVE specifications are compatible with a UDS/SQL pubset declaration which has already been checked.
In the event of an error, the load parameter concerned is output and the following message is issued:
UDS0711 UDS PROGRAM PARAMETER REJECTED: CATID NOT WITHIN SCOPE OF UDS PUBSET DECLARATION (...,tsn4)
DBH startup is then aborted after the load parameter check has been completed.
Grouping together request results for user tasks (RESULT-DELAY)
Independent DBH only!
|
Default value: | |
0 | |
n | Number of grouped request results for user tasks. n = 1..m m = PP TRANSACTION |
The load parameter PP RESULT-DELAY permits a throughput increase in peak load situations by grouping together the request results for the user tasks. See also section “Load parameters that affect processor utilization”.
You should specify this parameter only under the following conditions:
You are using a multiprocessor system with more than three processors.
The number of generated server tasks is the same as the number of processors that can be utilized by the server tasks. This usually means that the server tasks must have a high priority.
If PP SCHEDULING=ASYMMETRIC is set at the same time, the number of request results actually grouped may be restricted.
Controlling scheduling behavior in high-load situations (SCHEDULING)
Independent DBH only!
|
Default value:
SYMMETRIC
SYMMETRIC
All server tasks have equal precedence when processing pending DML requests. This setting is favorable if the server tasks are well-loaded or if no high BS2000 priority can be assigned to them.
ASYMMETRIC
An attempt is made to distribute the DML requests across all server tasks with the objective of achieving a 100% load on n-1 server tasks in a high-load situation if possible. This results in better processor utilization, increased throughput, and a more favorable multiprocessor factor.
This setting is only meaningful for multiprocessor systems and for configurations with more than one server task. In addition, appropriate BS2000 task priorities must be set for the server tasks (see chapter “Optimizing performance”).
Asymmetric processing could result in slower response times for individual transactions in overload situations. This is, however, usually offset by the higher overall throughput and the quicker resolution of the overload situation.
The load parameter PP SCHEDULING can be used to control the internal behavior of multiple server tasks in cases where there are strong fluctuations in relatively high-load situations. See also section “Load parameters that affect processor utilization”.
Defining the number of server tasks (SERVERTASK)
Independent DBH only!
|
Default value: | |
1 | |
n | Number of server tasks to be started n = 1..30 |
On starting the DBH, the DBH master task evaluates the load parameter PP SERVERTASK to determine how many server tasks are to be started (see section “How the independent DBH works”).
If all inputs and outputs are handled asynchronously (see the load parameter PP IO), it is sufficient to start one server task on a monoprocessor and a maximum of one server task per processor on a multiprocessor system. The server tasks must then have a correspondingly high priority (see “RUN-PRIO” on "Starting DBH").
See also chapter “Optimizing performance”.
Specifying the size of the SSITAB pool (SIP-SIZE)
Independent DBH only!
|
Default value: | |
1024 Kbytes if PP MPSEG=STD is specified; | |
n | Size of the SSITAB pool in Kbytes n = 1..16384 n is rounded up to the nearest integral multiple of 1024 for PP MPSEG=STD and up to the nearest integral multiple of 64 for PP MPSEG=64K. For PP MPSEG=64K, values above 8192 are not advisable. If n > 16384, the DBH uses 16384 Kbytes. |
When determining the pool size, you should take the following into account:
the user address space
the sum of the lengths of all SSITAB modules or of those to be processed concurrently.
To avoid frequent loading and unloading of the SSITAB modules in the pool, you should specify a size for the pool that is large enough to accommodate all the SSITAB modules used.
If PP MPSEG=STD is specified, the SSITAB pool is created in the upper address space of the UDS/SQL tasks (> 16 MB). In user tasks the SSITAB pool is created in the lower or upper address space depending on AMODE (24/31). If PP MPSEG=64K is specified, the SSITAB pool is located in the lower address space in all tasks. If applications in AMODE 24 are also used in the session, the size of the SSITAB pool must be set such that it fits into the lower address space of this application.
The size of the SSITAB pool can be obtained with the load parameter PP PARLIST or from the SIP-SIZE value output by the DAL command DISPLAY PP.
Defining the number of simultaneously active SQL conversations (SQL)
Independent DBH only!
|
Default value: | |
4 (default value for PP TRANSACTION) | |
n | Maximum number of simultaneously active SQL conversations n = 0..9999 |
When a new SQL conversation is to be started but doing so would result in the value n being exceeded, the DBH attempts to terminate a conversation that has been inactive for the time period specified with PP SQL-LIMIT. If this cannot be done, the new SQL conversation is rejected with an error message (SQL code: -1710).
When determining the size of PP SQL, you must take into account the fact that SQL conversations occupy internal resources (e.g. memory space) throughout their entire lifetimes. Too many concurrent SQL conversations can thus lead to resource bottlenecks.
PP SQL may also be larger than PP TRANSACTION; this is appropriate in a openUTM environment. PP TRANSACTION determines the maximum number of simultaneously active transactions and the maximum number of user tasks that can be attached. A task that does not execute with openUTM cannot open more than one conversation.
PP SQL=0 can be specified to prevent the use of SQL, even if the DBH was loaded with SQL linkage.
See also chapter “The SQL conversation”.
Setting the time period for inactive SQL conversations (SQL-LIMIT)
Independent DBH only!
|
Default value: | |
10 | |
n | Minimum amount of time, in minutes, for which UDS/SQL will maintain data for inactive conversations n = 5..999 minutes |
When a new SQL conversation is to be started but doing so would result in the value of PP SQL being exceeded, UDS/SQL attempts to terminate conversations that have already been inactive for longer than the time period specified with SQL-LIMIT.
See also chapter “The SQL conversation”.
Writing checkpoints in ALOG files (STDCKPT)
|
Default value: | |
NO | |
YES | By default the DBH writes checkpoints in the ALOG files for the entire configuration on starting and ending the DBH and on restarting a session. |
NO | No checkpoints are written at the above-described events. |
The load parameter PP STDCKPT is used by the DBH to write checkpoints in ALOG files for all databases of the configuration.
Checkpoints are written by the DBH
on starting the DBH
at a normal DBH end (CLOSE CALLS/CLOSE RUN-UNITS)
following a successful session restart.
The results of writing a checkpoint in the ALOG file are that:
the ALOG file as written up to that point is closed
a UDS/SQL message supplies the user with the log interval end (time stamp) of the ALOG file which has just been closed
a new ALOG file is opened.
The writing of checkpoints causes ALOG files to be closed. This releases the files, e.g. for updating shadow databases (with the BMEND utility routine). The ALOG files that have been closed can also be stored on tape and then deleted from the disk.
Checkpoints are written simultaneously for the entire DB configuration.
Dynamic database attachment and detachment with the DAL commands ADD and DROP may cause the configuration to change as compared to the original configuration on starting the DBH.
When the linked-in DBH is used, the PP STDCKPT parameter is the database administrator’s only possible means of requesting the writing of checkpoints in ALOG files.
Switching the ALOG file
If the database is kept under the configuration user ID, the DBH creates a new ALOG file once the current ALOG file is completed.
If the database is kept under a different user ID, an ALOG successor file must be available under the other user ID, and the file must be shareable.
If no ALOG successor file exists, the following is effected:
The old ALOG file is closed in a consistent state.
The ALOG file sequence number in the DBDIR is incremented by one and a marker is set to flag that the ALOG file identified by the ALOG file sequence number is not yet ready for use.
The database is locked against updates until the ALOG file identified by the ALOG file sequence number is ready for use.
A message is issued to indicate that there is no ALOG successor file.
The database administrator can then set up an ALOG file using the CREATE-FILE command. By means of the DAL command CHECKPOINT, the database administrator causes the DBH to initialize the new ALOG file and complete the writing of the checkpoint. The lock against updates is released as soon as the ALOG file is ready for use.
ALOG file overflow
An ALOG file overflow occurs when the ALOG file contains insufficient space to close the ALOG file in a consistent state and switch to a new one. There are two types of overflow:
soft ALOG file overflow (FILE OVERFLOW)
The FILE OVERFLOW message indicates that the ALOG file is in danger of overflowing, although there is still enough space to reach a consistency point.
The database is locked against updating transactions. Active transactions are rolled back or forward (to COMMIT), depending on the amount of space left in the ALOG file.
Once a consistency point has been reached, the ALOG file is switched.
hard ALOG file overflow (ALOG OVERFLOW)
The ALOG OVERFLOW message indicates that the ALOG file is full and there is no space to reach a consistency point. AFIM logging is no longer possible and there would be a gap in logging.
This may occur particularly in the case of long, active transactions.The database is locked against all transactions. The DBH drops the database in an inconsistent state.
You can ascertain the cause of the file overflow from the DMS error code and take the relevant measures.
Once you have created enough space to extend the ALOG file, you can attach the database once again by means of a warm start.
Another ALOG OVERFLOW could occur during a warm start, in which case you can repeat the procedure as many times as needed to reach a consistency point.
Defining the number of subschemas (SUBSCHEMA)
|
Default value: | |
1 | |
n | Number of concurrently usable subschemas per database n = 1..100 Guide to value of n: |
The subschema information area (SSIA) of the addressed subschema must be resident in main memory in order for a processing chain to be executed. The load parameter SUBSCHEMA defines the maximum number of subschemas per database that may be processed simultaneously during the session.
Selecting too low a value for n may degrade performance, since the DBH is then frequently compelled to:
off-load SSIAs that have already been loaded so that new SSIAs can be read
or even to CANCEL transactions (with BIB status code 132) because the required SSIAs are not loaded and cannot be read due to a lack of space.
Defining the number of KDBS file identifications (SUBTRANSACTION)
|
Default value: | |
0 | |
n | Maximum number of KDBS file IDs permitted for all KDBS users at the same time on one database. n = 1..254 |
The load parameter PP SUBTRANSACTION is required only when KDBS is used.
Defining usage modes for transactions (TA-ACCESS)
Independent DBH only!
|
Default value: | |
STD | |
STD | When a processing chain is opened, all usage modes are permitted. Depending on the usage mode set, the realms to be opened are locked against reading or updating for other transactions. |
SHARED | |
When a processing chain is opened, only the usage modes SHARED RETRIEVAL and SHARED UPDATE are permitted. The realms to be opened are not locked. | |
You should specify PP TA-ACCESS=SHARED if all transactions are opened in usage mode SHARED. This reduces the path length for READY.
The load parameter PP TA-ACCESS applies to all databases participating in the session.
Defining the maximum number of transactions (TRANSACTION)
|
Default value: | |
n : 4 / m : 1 | |
n | Maximum number of simultaneously open transactions; at the same time, maximum n = 1..225 |
For UDS-D | |
m | maximum number of secondary subtransactions which the DBH is able to process m = 1..n and m <= n The value for secondary subtransactions is operative in UDS-D mode only. |
PP TRANSACTION determines
the number of transaction channels (mainrefs) in the DBH and thus the maximum number of transactions which the DBH can process concurrently,
the number of task administration entries of the DBH and thus the maximum number of user tasks that can simultaneously be known to the DBH,
with UDS-D, the maximum number of secondary subtransactions that this DBH can process simultaneously for remote application programs.
A timesharing user task is known to the DBH
from the start of the UDS/SQL program (in the case of COBOL DML and SQL) or from the first READYC call (in the case of CALL DML)
until the end of the UDS/SQL program.
In UDS/SQL openUTM mode, each openUTM task is known to the DBH
from the start to the end of the task.
When the linked-in DBH is used, the value of load parameter PP TRANSACTION is permanently set to 1.
It is recommended that you select the value for the maximum number of secondary subtransactions slightly higher than the expected number of secondary subtransactions required. This is because if, for example, the primary subtransaction is rolled back asynchronously (e.g. because of deadlocks or by the administrator), the configurations of the secondary subtransactions are not informed of this immediately, but instead only in the context of the transaction monitoring (see section “Time-controlled monitoring of connections and transactions”). In such cases, the resources of the secondary subtransactions still remain occupied after the primary subtransaction is rolled back, so that they cannot be used by new secondary subtransactions in the time between the rollback of the primary subtransaction and the start of the transaction monitoring. If a secondary subtransaction cannot be opened due to a resource bottleneck, the application program is given the status code 122.
Defining the console for DCAM administration logging and the format of UDS/SQL messages (UCON)
Independent DBH only!
|
Default value:
C’<U’,MSG
Logging is output at the local console. If logging cannot take place at the output location set elsewhere, the default value is once again assumed.
Output location: | |
mn | Two-character mnemonic device name. |
<x | x = one-character routing code. The character ’<’ must be specified. |
nnnn | Four-character name of the authorized user program with operator functions. |
Format: | |
MSG | The messages are logged without a header (default value). This format should be used if messages from different systems are to be evaluated by one console in a uniform way (e.g. via OMNIS-PROP). |
UDS | The messages are logged with the formatted, UDS/SQL-specific header. The header is added to messages administered via DCAM if administration via DCAM does not take place directly from a display terminal. For information on the structure and contents of the header, see the "Messages" manual. |
The load parameter PP UCON defines the console (UCON) at which DCAM administration logging is to take place and the format of UDS/SQL messages (see "PP ADM" in chapter "DBH load parameters", section “Administration of UDS/SQL via DCAM”, and the manual "Introduction to System Administration").
Setting the wait mode of server tasks (WAIT)
Independent DBH only!
|
Default value: | |
EVENT | |
EVENT | |
The last active server task waits for an event message before releasing the processor, which can then be used to perform other functions. | |
BUSY | The server task waits actively for the next request. The processor is not released. |
The load parameter PP WAIT is used in UDS/SQL peak-load applications to control the way in which the last active server task is to wait for new requests in short-term underload situations. See also section “Load parameters that affect processor utilization”.
You should specify PP WAIT=BUSY only under the following conditions:
You are using a multiprocessor system with more than three processors.
The load is consistently so high throughout the entire session that at least one server task always has requests to process.
Underload situations are rare.
Determining the duration of a warm start (WARMSTART)
|
Default value:
STD
During operation of the independent DBH, the load parameter WARMSTART controls when completed transactions finally enter the database.
If the default value is used, the completed transactions are first written to the RLOG file for reasons of fail-safety. They are not written to the database until the appropriately modified pages are off-loaded from the system buffer pools. This cuts down on the number of unnecessary read and write operations during operation. But in the event of a warm start, the rolling forward of these transactions, which are completed but not yet in the database, must be ensured.
With the values FAST and VERY-FAST, the independent DBH rolls forward the completed transactions even if the appropriately modified pages have not yet been off-loaded from the system buffer pools. This increases the number of write operations to the database during operation, but also means that any warm start that becomes necessary will be completed more quickly because there are fewer completed transactions to be updated. The part of the RLOG file that must be read during the warm start is used as the criterion for the premature addition of completed transactions to the database.
During a warm start, however, not only the parts of the RLOG file that contain completed transactions must be read, but also parts containing open transactions. If, as a result of long transactions, the part containing the open transactions grows large, this limits the effect of the load parameter WARMSTART.
STD | Completed transactions are not entered in the database ahead of time. The duration of a future warm start is not reduced. |
FAST | Completed transactions are definitively entered in the database before any offloading from the system buffer pools. The part of the RLOG file that must be read during a warm start is reduced by up to 90% compared with STD. The duration of a future warm start is shortened, possibly at the expense of performance during normal operation. |
VERY-FAST | |
Completed transactions are definitively entered in the database before any offloading from the system buffer pools. The part of the RLOG file that must be read during a warm start is reduced by up to 99% compared with STD. The duration of a future warm start is thus shortened, possibly at the expense of performance during normal operation. | |