At run time for a single program, there are always at least three independent VLS object members (or load modules): one reentrant, one non‑reentrant, and one for the symbol table. There can be more, depending on the size of the program.
The executable object is loaded from the VLS object library or load library and executed. The reentrant portion (the program procedure and report) can be shared among users. The non‑reentrant portion (program parameter data, working data, and dataview buffers) is not shared, and each user gets a copy.
When a panel is accessed, the panel definition (as opposed to the panel object) is retrieved from the panel library or load library.
The panel member and module is also grouped into reentrant and non‑reentrant parts. The reentrant part (the panel definition) can be loaded into global storage and shared among users. The non‑reentrant part (the panel data) is not shared and each user gets a copy.
The distinction between reentrant and non‑reentrant is significant because the execution of CA Ideal applications online takes place in pseudo‑conversational mode. At the end of each CICS transaction, some or all of the in‑core resources are written to CICS auxiliary temporary storage and CICS ESDSA.
If programs and panels were converted to load modules, they are controlled by CICS, and the CA Ideal run status has no effect.
The program symbol table is loaded only when a run‑time error occurs.
In a DB2 environment, execution of programs containing SQL in static mode requires an application plan. The Administration Guide describes how application plans are generated and used at run time.
In CA Datacom/DB, SQL access plans are built at compile time.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|