Subschema Statements › SUBSCHEMA Statement › Usage

Usage

Effect of ADD on Subschema

ADD creates a new subschema source description in the dictionary. Default values established through the SET OPTIONS statement can be used to supplement the user-supplied description.

ADD also sets the subschema's status to IN ERROR. The status must be set to VALID before a subschema load module can be generated; a load module must be generated before programs can use the subschema to access the database.

Effect of MODIFY on Subschema

MODIFY modifies an existing subschema source description in the dictionary. All clauses associated with an ADD operation can be specified for MODIFY operations.

MODIFY also sets the subschema's status to IN ERROR. The status must be set to VALID before a subschema load module can be generated. Note, that if modification involves the following changes, and if the subschema already has a load module, a new load module need not be produced:

• Documentation
• Program registration
• Statistics transfer
• Users included or excluded
• Public access

Effect of DELETE on Subschema

DELETE deletes an existing subschema source description from the dictionary. The subschema load module (if any) remains intact, unless the SET OPTION statement specifies DELETE IS ON, in which case the subschema compiler:

• Logically deletes version 1 of the subschema load module from the load area of the dictionary (load modules qualified by another version number must be explicitly deleted).
• Automatically erases version 1 of any PROG-051 dictionary record occurrence associated with the subschema load module, provided the record was built by the subschema compiler and is not related to any other entity type in the dictionary.

SUBSCHEMA Statement Defines Its Use by Program

The SUBSCHEMA statement defines the following information about its use by programs:

• Program authorization—The SUBSCHEMA statement specifies whether programs using the subschema must be registered with the subschema (by means of the IDD DDDL compiler) in the dictionary in order to be eligible for compilation by the CA IDMS Data Manipulation Language (DML) precompilers.
• DML usage—The SUBSCHEMA statement specifies whether programs using the subschema can issue only DML requests, only logical-record DML requests, or both.

The SUBSCHEMA statement can also be used to transfer the statistics (such as database access statistics) for the named subschema to another subschema.

ADD Interpreted as MODIFY

If, on an ADD operation, a subschema of the same name within the same schema already exists in the dictionary, the action taken by the subschema compiler varies depending on the current session option for DEFAULT:

• If DEFAULT IS ON is specified, the subschema compiler interprets the ADD as a MODIFY for the named subschema.
• If DEFAULT IS OFF is specified, the subschema compiler issues an error message and terminates processing of the ADD SUBSCHEMA statement. Note that, in this case, subschema currency will be null for subsequent statements.

User-Specification Required for Secured Subschemas

If the user-specification clause is not used, user-id and password default to the current session options.

User-specification is used when the subschema compiler checks security. If either the subschema compiler or the specific subschema is secured, the compiler rejects the operation unless it finds the name and password of an authorized user in one of the following places:

• The SUBSCHEMA statement
• The current session value

Note: For a detailed description of security, see the CA IDMS Security Administration Guide.

Transferring Statistics for Some, But Not All, Programs

To transfer statistics for multiple (but not all) programs, repeat the TRANSFER STATISTICS clause for each program. To transfer statistics for all programs registered with the subschema, include a single TRANSFER STATISTICS clause that does not specify a program name.

Existing User Registration Replaced by New One

When modifying a user's registration, the option specified in the REGISTERED FOR clause replaces the previous specification. In the following example, the second REGISTERED FOR clause removes BARBER's ability to delete subschema empss01.

add subschema empss01
    user is barber
    registered for update.

mod subschema empss01
    user is barber
    registered for modify.

Existing User Responsibility Replaced by New One

When modifying a user's responsibility documentation, the option specified in the RESPONSIBLE FOR clause replaces the previous specification. In the following example, the second RESPONSIBLE FOR clause removes CREATE from BAKER's documentation of responsibilities.

add subschema empss02
    user is baker
    responsible for creation and update.

mod subschema empss02
    user is baker
    responsible for update.

Registered Users Can Perform Non-Public Access Operations

To perform any operation not available for public access, the user must be registered for that operation in the current subschema. Registered users can also perform operations available for public access.

At Least One User Must Be Registered for ALL

When a subschema is added to the dictionary, public access defaults to ALL and cannot be changed until at least one user is registered for ALL operations. The first registration of a user for ALL operations changes public access to NONE. Note that the last user with ALL registration cannot be excluded from the subschema description until public access is changed to ALL. Thus the subschema compiler ensures that no inaccessible subschema description exists in the dictionary. The following example illustrates the various stages of public access:

add subschema empss01.

Public access defaults to all.

mod subschema empss01.
    user is mjj
      registered for all
    public access is modify.

Public access changes from NONE to MODIFY with PUBLIC ACCESS is MODIFY.

mod subschema empss01.
    exclude user mjj.

This statement is not possible. Public access must first be changed to all.

Assigning Text to a Comment Key

Before entering comment-text for a comment-key in the COMMENTS clause, the comment key must have been previously defined in the USER DEFINED COMMENTS clause of the IDD DDDL MODIFY ENTITY statement.

Before specifying EXCLUDE in the USER DEFINED COMMENTS clause of an IDD DDDL MODIFY ENTITY statement, you must first specify NULL for the comment key in the SUBSCHEMA COMMENTS clause.