Previous Topic: #PUTSCR ExampleNext Topic: @READY Syntax


@READY—prepares a database area for access by DML functions

The @READY statement prepares a database area for access by DML functions and specifies the usage mode of the area. @READY also defines and logs the initial checkpoint for a recovery unit to facilitate recovery operations.

The DBA can specify default usage modes in the subschema. A run-unit using a subschema with specified default usage modes need not issue any @READY statements; the areas are readied automatically in the predefined usage modes. However, if a run-unit issues an @READY statement for one area, it must issue @READY statements for all areas that it accesses unless the FORCE option was specified for the default usage mode. Areas using the default usage mode combined with the FORCE option are automatically readied even if the run-unit already issued @READY for other areas.

The usage mode specified in the @READY statement (or in the subschema) indicates the runtime operations that the readying run unit can or cannot perform against the database area. The following usage modes can be specified:

The specified usage mode can be qualified with a PROTECTED or EXCLUSIVE option to prevent update or use, respectively, of areas by other run units executing concurrently under the CA IDMS/DB central version. Each area can be readied in its own usage mode. Usage modes can be changed during a recovery unit by executing an @FINISH statement and readying the areas in a different usage mode. Note, however, that the appropriate BIND statements must also be issued.

When the run unit (rather than the subschema) readies database areas, all areas can be readied with a single @READY statement or each area to be accessed can be readied individually. You must ready all areas explicitly or implicitly affected by the DML statements issued by the run unit. Areas are affected implicitly, for example, when a set's owner and member records belong to different areas. Some areas included in the subschema may not need to be specified in an @READY statement, as only those areas that are explicitly or implicitly affected need to be readied.

The @READY statement can appear anywhere in an application program; however, to avoid runtime deadlock, the best practice is to ready all areas before issuing any other DML statements.