System Generation Statements › PROGRAM Statement—Defines and Associates a Program › PROGRAM Statement Usage

PROGRAM Statement Usage

Manual Program Definition

The system generation compiler populates the data dictionary with a program source record for each PROGRAM statement input to the compiler. At generate time, these source records are copied to object records. At system startup, the system uses the information in the object record to build a program definition element (PDE) for each program. The PDE contains information used by the system at runtime.

Automatic Program Definition

For each program load module output by a CA IDMS compiler (that is, map, edit or code table, access module, subschema, or dialog), a program source record is added to the dictionary. The first time a task or program issues a request to load a map, edit/code table, access module, subschema, or dialog for which no PDE exists, the system allocates a PDE for that program from the null PDE pool. The system stores information contained in the program's source record in the allocated null PDE.

The system then attempts to load the program:

• If the program is found, the null PDE is used to load the program. The null PDE then remains allocated to service subsequent load requests that specify the same program.
• If the program cannot be found, the null PDE is returned to the null PDE pool.

You enable automatic program definition during system generation with the SYSTEM statement UNDEFINED PROGRAM COUNT parameter, which directs the system to allocate a null PDE pool and specifies the size of the pool. For more information about automatic program definition, see the description of the UNDEFINED PROGRAM COUNT parameter in SYSTEM Statement.

Dynamic Program Definition

The system uses information supplied in the DCMT VARY DYNAMIC PROGRAM command to build a PDE for the program. Programs defined dynamically exist only for the duration of system execution and have no effect on the system; no definitions are stored in the data dictionary. Typically, dynamic program definition is used in a test environment to accommodate new programs without shutting down the entire system. All programs are eligible for dynamic definition, provided they are not already defined to the system.

For more information about dynamic program definition, see the CA IDMS System Operations Guide.

Describing the Location of Program Load Modules

Program load modules are stored either in the DDLDCLOD area of a data dictionary or in system load libraries:

• DDLDCLOD contains load modules created by CA IDMS compilers (for example, access modules, subschemas, maps, edit and code tables, and dialogs).
• Load (core-image) libraries contain load modules for database procedures, system programs, and user programs. Additionally, these libraries can contain any DDLDCLOD-eligible modules that have been punched from DDLDCLOD by using the IDD DDDL compiler and link edited into the appropriate library.

Selecting Dialogs to Appear on the CA ADS Menu Screen

The MENU/NOMENU option of the MAINLINE/NOMAINLINE parameter allows you to specify which mainline dialogs will appear on the CA ADS menu screen. CA ADS APPC dialogs, which are defined as mainline dialogs, do not have to automatically appear on the CA ADS menu screen. CA ADS APPC users can specify, on a dialog-by-dialog basis, which mainline dialogs are to appear on the CA ADS menu screen.

Multithreaded Programs

Reentrant and quasireentrant programs can be multithreaded; that is, they can execute multiple requests concurrently through a single copy of code. Nonreentrant programs are always single-threaded; that is, they can execute only one request for each copy of the code.

Multiple Enclave

The performance of certain online applications which use COBOL programs under the IBM Language Environment can be improved significantly by specifying MULTIPLE ENCLAVE ON. These are the restrictions on what COBOL programs can participate in a multiple-program enclave:

1. No enabled program can do a DC RETURN DML call and then be reentered via a subsequent TRANSFER. Note that this restriction does not apply to a program which contains a DC RETURN with no subparameters. That is because the DML compiler generates a GOBACK for such a statement. The restriction does apply if the DC RETURN statement does have subparameters. For example, it is not valid to execute a "DC RETURN NEXT TASKCODE ..." statement and then reenter the same program in the same task.
2. No enabled program can issue a TRANSFER CONTROL NORETURN or a TRANSFER CONTROL XCTL.
3. Optional bit 196 is ignored for programs which are participating in a MULTIPLE USE enclave. Therefore, any program which depends on the use of optional bit 196 must have MULTIPLE ENCLAVE OFF.