Full Preprocessing Mode

• Unless you have specified the NOINSTALL option without specifying a DBEnvironment name, when the program being preprocessed already has a stored module, be sure to use the DROP option, or else an error will result. Also, be sure that no one is currently executing the module when you invoke the preprocessor. To avoid conflicts, do your preprocessing in single-user mode during off-hours.

• Unless the NOINSTALL option is specified without specifying a DBEnvironment name, the preprocessor starts a DBE session in the DBEnvironment named in the preprocessor command by issuing a CONNECT TO 'DBEnvironmentName' statement. If the autostart flag is OFF, the DBE session can be initiated only after a START DBE statement has been processed (by means of ISQL or an embedded SQL program). Remember that if multiple, simultaneous users run a program, you should issue the START DBE statement only once.

• If the DBEnvironment to be accessed is operating in single-user mode, preprocessing can occur only when another DBE session for the DBEnvironment does not exist.

• When the preprocessor's DBE session begins, ALLBASE/SQL processes a BEGIN WORK statement. When preprocessing is completed, the preprocessor submits a COMMIT WORK statement, and any sections created are committed to the system catalog. If the preprocessor detects an error in SQLIN, it processes a ROLLBACK WORK statement before terminating, and no sections are stored in the DBEnvironment. Preprocessor warnings do not prevent sections from being stored.

• Since any preprocessor DBE session initiates only one transaction, any log file space used by the session is not available for re-use until after the session terminates. You can issue a CHECKPOINT statement in ISQL before preprocessing to review the amount of available log space. Refer to the ALLBASE/SQL Database Administration Guide for additional information on log space management, such as using the START DBE NEWLOG statement to increase the size of the log file.

• During preprocessing, system catalog pages accessed for embedded statements are locked. In multiuser mode, other DBE sessions accessing the same objects may have to wait, so there is potential for a deadlock. You have several options to use to attempt to avoid a deadlock situation.

  • Minimize competing transactions when preprocessing an application.

  • Ask your DBA to specify the system tables that utilize row level locking. Refer to the ALLBASE/SQL Database Administration Guide appendix, "Locks Held on the System Catalog," and to the section "Changing System Table Lock Types" for further information.

  • Use the INSTALL (DEBFileSetName) preprocessor parameter option to maximize transaction concurrency. This option specifies the DBEFileSet in which a module's static sections are to be stored.

• For improved runtime performance, use the UPDATE STATISTICS statement in ISQL before preprocessing for each table accessed in a data manipulation statement when an index on that table has been added or dropped and when data in the table is often changed.

• If you specify an OwnerName or ModuleName in a language other than NATIVE-3000 (ASCII), be sure that the language you are using is also the language of the DBEnvironment in which the module will be stored.

• When you invoke the preprocessor with the FLAGGER option, your application must contain an ANSI mode compiler directive in order for the compiler to detect non-standard statements. The following table lists the appropriate directive for each language:

  Language	Directive
  C	ccxl ... ;info='-Aa'
  COBOL	$CONTROL STDWARN
  FORTRAN	$OPTION ANSI ON$
  Pascal	$standard_level 'ANSI'$

• If implicit updatability is specified (using the ANSI option), any column in a select list can be updated or deleted, so long as the FOR UPDATE clause has not been used in the SELECT statement definition. Refer to the later section, "Understanding Implicit Updatability."

• If a DBEFileSet is specified and the module owner does not have authority to store sections in that DBEFileSet, a warning is given and any sections are stored in the default DBEFileSet instead.

In some cases an ALLBASE/SQL program is used with one or more DBEnvironments in addition to the DBEnvironment accessed at preprocessing time. In these cases, you can use ISQL to install the installable module created by the preprocessor into each additional DBEnvironment accessed by your program.

An alternative method of accessing more than one DBEnvironment from the same program would be to divide the program into separate compilable files. Each source file would access a DBEnvironment. In each file, start and terminate a DBE session for the DBEnvironment accessed. Then preprocess and compile each file separately. When you invoke the preprocessor, identify the DBEnvironment accessed by the source file being preprocessed. After a file is preprocessed, it must be compiled so that no linking is performed before the next source file is preprocessed. When all source files have been preprocessed and compiled, link them together to create an executable program.

For example, to preprocess several ALLBASE/SQL application programs in the same group and account and compile and link the programs later, you should do the following for each program:

To preprocess a program, or to use an already preprocessed ALLBASE/SQL application program, you must satisfy the authorization requirements for each DBEnvironment accessed.