ADDRESSCHECK

When ADDRESSCHECK is specified, an addresscheck word is appended to all data blocks of every database file. When a block is written, the segment address of the first segment of the block is stored in the addresscheck word. When the block is read, the addresscheck value is verified. If an error is detected, user programs are notified of the error and the database is aborted.

When ADDRESSCHECK is specified, it applies to all database files. ADDRESSCHECK is distinct from the CHECKSUM option, which can be specified independently. The ADDRESSCHECK option is useful in detecting I/O errors, such as shifted records.

ADDRESSCHECK is extremely efficient; however, you should choose the BLOCKSIZE value carefully to conserve disk space. Database files are always allocated in multiples of the segment size. You should select the block size so that the addition of the addresscheck word does not cause the BLOCKSIZE value to increase.

ADDRESSCHECK is reset by default. The recommended value is SET.

Once the ADDRESSCHECK option is set or reset, it cannot be changed for the life of the database.

For new databases using XE features, if ADDRESSCHECK is not specified, the option is SET by default.

For existing databases using XE features, if ADDRESSCHECK is not specified, the option continues to be RESET by default. During a migration from non-XE features to XE features, if ADDRESSCHECK is not specified, the ADDRESSCHECK default value of RESET is retained.

During a migration from XE features back to non-XE features, explicitly set ADDRESSCHECK to its current value. If ADDRESSCHECK is not specified, a syntax error can occur. The reason is that the ADDRESSCHECK default of the XE features is SET, but the default used by non-XE features is still RESET.

Be sure to take into account the explicit or implicit setting of the ADDRESSCHECK option when calculating data set BLOCKSIZE and set-subset TABLESIZE specifications.

AUDIT

The AUDIT option causes the database to be audited. Audit and recovery allow the database to be recovered automatically following a hardware or software failure..

When AUDIT or AUDIT SET is stipulated, the database can contain an audit trail declaration and must contain a restart data set declaration. The audit trail consists of a record of changes made to the database. It is used by the Enterprise Database Server recovery routines during database recovery. The restart data set contains restart information for user programs. Programs that modify the database must utilize the recovery techniques described in the Enterprise Database Server Application Programming Guide.

AUDIT is reset by default. If AUDIT or AUDIT SET is not specified, AUDIT RESET is assumed.

BACKOUTTOSPT

Normally, when database recovery is performed, the system backs out automatically all transactions until it reaches a point in the audit trail at which no program was in transaction state. Occasionally, the backing out includes all transactions since the latest syncpoint. Optionally, by use of the BACKOUTTOSPT option, the database administrator can specify that all transactions since the latest syncpoint be backed out unconditionally. In general, a BACKOUTTOSPT operation results in more transactions being backed out than would be backed out by the automatic process performed by the system.

The system ignores the BACKOUTTOSPT option if the INDEPENDENTTRANS option is set.

This option is included for compatibility with previous releases and is normally reset by default.

BACKUPKEYSET

Immediately after creating the description file, you must create a backup copy of the key sets. This is critical because if you lose these encryption keys, Unisys will be unable to assist you in decrypting your database.

Once you encrypt data, a backup process must be in place for the encryption keys. If the encryption keys are lost or damaged without a backup, the data will be indecipherable and lost. The backing-up of keys is left to your discretion, but multiple backups are essential. Encryption keys stored on smart cards or external devices are also susceptible. If the smartcard or external drive is lost or damaged, the key will be lost and the data unrecoverable. To ensure access to encrypted data, always back-up encryption key sets. The BACKUPKEYSET option requires you to manually back-up the key set before a database can be accessed. For information on how to back up the key set, refer to the Security Center Help.

The default value for the BACKUPKEYSET option is SET. If the BACKUPKEYSET option is SET and you have not manually performed a key set backup, an OPEN ERROR occurs when accessing the database or during a reorganization.

If the BACKUPKEYSET option is RESET, you can open the database without backing up the key set and will not receive an OPEN ERROR. Unisys does not recommend setting the BACKUPKEYSET option to RESET. Setting the option to RESET does not allow you access to the database if you lose the key set.

INDEPENDENTTRANS

INDEPENDENTTRANS ensures that transactions are independent and enables single transaction aborts (SINGLEABORT). To keep transactions independent, avoid using implicit or explicit FREE operations during transaction state. A FREE operation while in transaction state is nonoperable. This option results in the total elimination of ABORT recovery and all occurrences of an ABORT exception.

Locked records are kept in memory; therefore, setting INDEPENDENTTRANS can affect memory usage. This would be noticed only if explicit FREE operations or multiple LOCK operations on the same structure were done previously in transaction state. Otherwise, FREE operations would not occur until ENDTRANSACTION time.

When INDEPENDENTTRANS is set, either primary or secondary audit must be set to disk. If audits have been switched to alternates and neither is set to disk, a switch is made to the normal audit path. When INDEPENDENTTRANS is set, LOCK TO MODIFY DETAILS must be set for disjoint data sets that have embedded structures.

INDEPENDENTTRANS allows a program to use the DMSAVEPOINT and ABORTTRANSACTION host language statements.

If you set INDEPENDENTTRANS in DASDL and a DEADLOCK exception is returned in the transaction state, all the updates made during the transaction are backed out. The paths for all the structures updated during the transaction are returned to their pretransaction state.

When INDEPENDENTTRANS is set, any database update that results in changes to a table of an index sequential set causes modified index tables to remain locked until the application completes its transaction. The index sequential table locks are held for the duration of the transaction and implicitly freed at ENDTRANSACTION time. The following actions lock the modified index sequential tables:

INDEPENDENTTRANS (cont.)

An application attempting an update that requires modification to an index sequential table locked by another application must wait until the application holding the locked table completes its transaction and frees the locked index sequential table.

An application that attempts a LOCK or a SECURE operation on a record using an index sequential set waits if the key entry for the record being locked is in an index table that is locked by another application. The application must wait for when the key entry for the record being locked might be in the process of being deleted from that table. Because the application that deleted the key entry might not yet have committed the transaction, the application attempting to do the LOCK or the SECURE operation must wait. Waiting until the transaction is committed prevents the application from seeing the results of uncommitted transactions.

Waiting for locked index sequential tables can result in a DEADLOCK exception under certain circumstances. For example, if an application performs a BEGIN TRANSACTION operation and a DELETE WHERE X=10 operation, the Enterprise Database Server must remove the key entry from the fine table for X=10. This changes the fine table and causes the fine table to be automatically locked by the application that performed the DELETE operation.

Once that application performs an END TRANSACTION operation, the fine table is automatically freed. Until then, if another application attempts any update operation that requires a key entry to be deleted from the locked table, the second application waits until the first application performs an END TRANSACTION operation. If, while the second application is waiting, the first application attempts to lock a record or table locked by the second application, a DEADLOCK is detected. One of the applications receives a DEADLOCK exception.

INTERNAL LOBS

INTERNAL LOBS enables you to store large object (LOB) data items internally. The two types of large objects are binary large object (BLOB) and character large object (CLOB). Examples of binary large objects include image data, audio, and multimedia. Examples of character large objects include Extensible Markup Language (XML) files and other documents.

The size of these objects makes it impossible to hold the data within the record. New data sets, called LOB tank data sets, are added implicitly to contain LOB data. You can alter the physical options of LOB tank data sets, sets, and subsets. Depending on the object size, the item is dynamically stored inside a small, medium, or large tank. Refer to Data Set Declaration for additional information.

If the dump list does not include all structures, then you must ensure that these structures are included in the dump list.

A DASDL UPDATE operation that sets only the INTERNAL LOBS option causes the following implicit structures to be added to the database description. In order to create physical files for these structures, a DMUTILITY INITIALIZE run needs to be performed on LOB-STR-DIR, SMALL LOBS, MED-LOBS, and LARGE-LOBS data sets.

For example,

RUN $SYSTEM/DMUTILITY (”(UC)MYDB ON MYPACK INITIALIZE LOB-STR-DIR”)

A DASDL UPDATE operation that sets the INTERNAL LOBS option and adds items in existing data sets causes the following implicit structures to be added to the database description. Since items are added to existing data sets, reorganization is required. Running a reorganization creates the physical files for these structures.

LOB-STR-DIR (standard data set)  MED-LOBS-
SET (access)
LOB-STR-DIR-SET (set)            MED-LOCATOR-
SET (subset)
SMALL-LOBS (direct data set)     MED-SPACE-
SET (subset)
SMALL-LOBS-SET (access)          LARGE-
LOBS (direct data set)
SMALL-LOCATOR-SET (subset)       LARGE-LOBS-
SET (access)
SMALL-SPACE-SET (subset)         LARGE-
LOCATOR-SET (subset)
MED-LOBS (direct data set)       LARGE-SPACE-
SET (subset)

Refer to “Internal Large Object (LOB) Data Items” in Data Set Declaration for additional information.

KEYCOMPARE

KEYCOMPARE causes the Accessroutines to verify that the key in the data set matches the key entry in the set or the automatic subset through which it is accessed. If an error is detected, the database access is automatically terminated.

LOCKEDFILE

When LOCKEDFILE is specified, the following occurs:

By default, the LOCKEDFILE option is reset.

When performing a DASDL update to change the LOCKEDFILE option, the Accessroutines sets or resets the LOCKEDFILE file attribute for the database files when the database is opened for the first time following the update.

LOCKPROGRAM

Initiates the database stack and RDBSUPPORT as locked processes by making use of the LP (Lock Program) MCP system command. This prevents these two processes from being discontinued. For additional information, refer to LP (Lock Program) in the System Commands Reference Manual.

By default, the LOCKPROGRAM option is reset.

The LOCKPROGRAM option can be changed either by a DASDL update or by performing a DMCONTROL operation. The value of the option is listed in the control file content.

OPENOLTP

OPENOLTP enables a database to participate in Open Distributed Transaction Processing operations. When this option is set, the database automatically links to the RMSUPPORT library, which then links to the Transaction Manager (TM). This linkage enables an application program to participate in global transactions that synchronize updates to multiple databases that support Open Distributed Transaction Processing capabilities.

When an OLTP application is doing work for a global transaction, it does not wait for syncpoints in either BTR or ETR. Additionally, global transaction records are not freed on DMSII ETR. The OLTP programs do not wait for syncpoints to avoid the situation where a deadlock condition could develop: the OLTP application waits for a syncpoint while another application waits in transaction state for records locked by the global transaction. Records belonging to a global transaction can only be freed at the end of the global transaction, which will be either an OLTP Commit or Rollback.

The effect is that the syncpoint interval can extend beyond the DASDL value for SYNCPOINT. This is most noticeable when the mix is primarily OLTP applications. Even though the SYNCPOINT interval might be extended, the audit buffers are written to disk at each OLTP ETR.

When you use this option, you must also specify the INDEPENDENTTRANS option.

The first DASDL UPDATE operation that sets the OPENOLTP option causes the following implicit structures to be added to the database description:

All updates to these structures are done implicitly during the Open Distributed Transaction Processing. Otherwise, maintenance of these structures is the responsibility of the database administrator.

The first DASDL UPDATE operation that sets the OPENOLTP option also causes the listing to indicate that new structures were added and that those structures should be initialized with the DMUTILITY program.

If there is an I/O error on these implicit structures, then the database fails with a fatal error. In this case, you must perform a reconstruction to recover the database.

RDSSTORE

RDSSTORE tells the Accessroutines that a STORE operation is to be done on the restart data set at BEGINTRANSACTION/ENDTRANSACTION time when the AUDIT option is specified. Restart records are not created at recovery time.

The option can be added and deleted at DASDL update time. This action increases the update level. Therefore, all database software must be recompiled.

When the RDSSTORE option is set, the restart record is not freed at ENDTRANSACTION time. However, if a DEADLOCK exception occurs at any time during processing, the restart record is freed, regardless of the RDSSTORE option setting.

Prior to the first BEGINTRANSACTION or ENDTRANSACTION with AUDIT operation, a CREATE or RECREATE operation on the restart data set must be performed if there is no locked current record for the restart data set. If the restart data set record is locked and a DEADLOCK exception occurs during processing, the restart data set record is freed. A CREATE, RECREATE, or LOCK operation must be performed on the restart data set. If one of these operations is not done, a NOTLOCKED exception occurs.

REAPPLY-COMPLETED

The REAPPLYCOMPLETED option causes the system to write every transaction to the audit trail instead of waiting until the syncpoint. Halt/load recoveries in the audit trail reapply all the completed transactions. Each restart area reflects the last completed transaction for each program. The REAPPLYCOMPLETED option requires that the INDEPENDENTTRANS option be set. Specifying the REAPPLYCOMPLETED option affects how the Accessroutines calculates audit file tape capacity. Refer to Using the Audit Trail and Control File Specifications for more information.

RESTART TRANSACTIONS ONLY

Normally, programs that terminate abnormally outside transaction state are provided with a restart record. Optionally, by the use of the RESTART TRANSACTIONS ONLY option, the database administrator can specify that restart information be provided only to tasks which terminate abnormally while in transaction state.

When INDEPENDENTTRANS is set and a program is terminated during a transaction, the following actions occur:

This option is provided for compatibility with previous releases and is normally reset by default.

SECURITYADMIN

Specifying SECURITYADMIN sets the SECURITYADMIN file attribute for the database files including the control file, audit files, and dump files. By default, this option is reset. This option is only effective if security administrator status is enabled on the system which is done using the ??SECAD command.

Setting SECURITYADMIN on a system that has the security administrator status enabled, requires the following:

For additional information about security configuration, refer to the Security Overview and Implementation Guide, and refer to the File Attributes Programming Reference Manual for additional information about the SECURITYADMIN file attribute.

Note that when SECURITYADMIN is set for a database, it places restrictions on how a database is maintained. For example, only a security administrator (who has a usercode designated as PU and SECADMIN privileges) can copy files with the SECURITYADMIN file attribute set. In addition, only a security administrator can perform a backup procedure such as DMUTILITY DUMP.

You can set or reset SECURITYADMIN with the DMCONTROL statement. Once it has been modified with DMCONTROL, it is protected and cannot be overwritten by a DASDL update. You can use the DMCONTROL statement OVERRIDE SECURITYADMIN to reset the changed bit in the control file. Refer to the Enterprise Database Server Utilities Operations Guide for additional information.

SENSITIVEDATA

Specifying this option sets the SENSITIVEDATA file attribute for the database files including the control file, audit files, and dump files. The default is reset. Refer to the File Attributes Programming Reference Manual for additional information about the SENSITIVEDATA file attribute.

You can also set or reset the SENSITIVEDATA option with a DMCONTROL statement. If this occurs, it is protected and cannot be overwritten by a DASDL update. You can use the DMCONTROL statement OVERRIDE SENSITIVEDATA to reset the changed bit in the control file. Refer to the Enterprise Database Server Utilities Operations Guide for additional information about DMCONTROL.

STATISTICS

The Accessroutines maintain statistical information concerning the run-time performance of the database. The statistics include the number of physical reads and writes, the number of finds, deletions, transactions, and syncpoints, as well as other information. When the STATISTICS option is specified, the Accessroutines automatically print the statistics when the database shuts down.

The statistics are automatically printed to a file called (<user name>)<database name>/ACRLIBRARY/ADDED when all database users have closed the database. The statistics can be printed or the STATISTICS option reset to 0 (zero) while the database is active by directing a message to the database stack. For instructions on how to change this parameter by using Visible DBS commands, refer to the Enterprise Database Server Utilities Operations Guide.

By default, the STATISTICS option is reset.

TPSDUALUPDATE

TPSDUALUPDATE enables a database to be used by both the Transaction Processing System (TPS) and other (non‑TPS) data management programs simultaneously.

When TPSDUALUPDATE is specified, a database can be opened by both a non-TPS program (OPEN UPDATE) and a TPS program (OPEN TRUPDATE).

If this option is not specified, the database can be opened by either TPS programs or non-TPS programs, but not both. A mixture of the two types of OPEN operations results in an open error (OPENERROR).

If the TPSDUALUPDATE option is reset, the TPS update programs can be run during an online reorganization without setting the TPSDUALUPDATE option. The following restrictions apply:

By default, the TPSDUALUPDATE option is reset.

XL

XL enables a database to contain a maximum of 16000 structures and 4000 data sets. By default, the option is reset. If the database is compiled with the UPDATE card and XL is set for the first time, the database must contain more than 4000 structures. If the database was initialized with the XL option set, there is no structure count minimum. Once the XL option is set, it cannot be reset.

If an existing database contains an internal LOB data item, setting the XL option for the first time requires a database reorganization.

DASDL gives a warning message to notify if the number of structures defined is greater than or equal to 80 percent of the maximum structure limit.

If the WFL job DATABASE/WFL/COMPILEDB is initiated manually and the database contains more than 8000 structures, then a value of TRUE is required for the ninth parameter. For example:

START DATABASE/WFL/COMPILEDB
("DB=TESTDB OB=DEBELPK C=DMSUPPORT,RECON 
INIT=SET","","","","","", , ,TRUE);