The Stored Section

A section consists of ALLBASE/SQL instructions for executing an SQL command. The commands that do not generate sections are listed in the "Stored Sections" paragraph of the chapter, "Using the ALLBASE/SQL COBOL Preprocessor." Not every command requires a section. For each SQL command that does require a section, the preprocessor creates a section and assigns a unique section number for all embedded ALLBASE/SQL commands except:



   BEGIN DECLARE SECTION             INCLUDE

   BEGIN WORK                        OPEN

   CLOSE                             PREPARE

   COMMIT WORK                       RELEASE

   CONNECT                           ROLLBACK WORK

   DECLARE CURSOR                    SAVEPOINT

   DELETE WHERE CURRENT              START DBE

   DESCRIBE                          STOP DBE

   END DECLARE SECTION               SQLEXPLAIN

   EXECUTE                           TERMINATE USER

   EXECUTE IMMEDIATE                 UPDATE WHERE CURRENT

                                     WHENEVER

Note that if the DELETE WHERE CURRENT or UPDATE WHERE CURRENT command is dynamically preprocessed, a section does exist in the module. The preprocessor assigns a number to each section and references the appropriate stored section in the generated code:



   MOVE 1 TO SQLSECNUM

   .

   .

   .

   CALL SQLXCBL USING SQLXFET, SQLCA, SQLOWNER, SQLMODNAME,

     SQLSECNUM, SQLTEMPV, SQLINLEN, SQLOUTLEN, SQLTRUE

Purpose of Sections

A section serves two purposes:

Access validation: Before executing a stored section at run time, ALLBASE/SQL ensures that any objects referenced exist and that runtime authorization criteria are satisfied.
Access optimization: If ALLBASE/SQL has more than one way to access data, it determines the most efficient method and creates the section based on that method. Indexes, for example, can expedite the performance of some queries.

Runtime performance is improved by creating and storing sections at preprocessing time rather than at run time.

Section Validity

A section is assigned one of two states at preprocessing time: valid or invalid. A section is valid when access validation criteria are satisfied. If the SQL command references objects that exist at preprocessing time and the individual doing the preprocessing is authorized to issue the command, the stored section is marked as valid. A section is invalid when access validation criteria are not satisfied. If the SQL command references an object that does not exist at preprocessing time or if the individual doing the preprocessing is not authorized to issue the command, the stored section is marked as invalid. After being stored by the preprocessor, a valid section is marked as invalid when such activities as the following occur:

Change in authorities of the module's owner.
Alteration to tables accessed by the program.
Deletion or creation of indexes.
Update of a table's statistics.

At run time, ALLBASE/SQL executes valid sections and attempts to validate any section marked as invalid. If an invalid section can be validated, as when an altered table does not affect the results of a query, ALLBASE/SQL marks the section as valid and executes it. If an invalid section cannot be validated, as when a table reference is invalid because the table owner name has changed, ALLBASE/SQL returns an error indication to the application program.

When a section is validated at run time, it remains in the valid state until an event that invalidates it occurs. The program execution during which validation occurs is slightly slower than program executions following validation.

The Stored Section

Technical documentation

» Table of Contents

» Index

Purpose of Sections

Section Validity