Precompiler Guidelines

Follow these guidelines when precompiling DB2 programs.

Use the Appropriate DBRM Library

Most shops allocate DBRM libraries. These libraries must be set up as partitioned data sets with 80-byte records.

Retain DBRMs Only When Absolutely Necessary

Although the DBRM produced by the precompiler must be placed in a partitioned data set, DBRMs sometimes do not need to be retained. If the DBRM will be temporary due to the replication of program preparation during the testing process, it can be written to a temporary PDS. When the program is out of the testing phase, the DBRM can be written to a permanent PDS before it is migrated to production status.

Name the DBRM the Same As the Program

Ensure that the DBRM is named the same as the program from which it was created. This eases the administration of objects created and modified by the program preparation process.

Precompile Only When Required

Precompilation is not required by BASIC and APL2 programs that contain SQL statements. Refer to the appropriate BASIC and APL2 programming guides for additional information about these environments.

Use DEC31 to Impact Decimal Precision

DB2 supports decimal precision of either 15 or 31, depending upon the precompiler option. If decimal numbers with a precision greater than 15 are to be utilized, you must specify the DEC31 precompiler option.

When you're using this option, examine the application program to verify that the host variables can accommodate 31-digit decimal precision.

Using LEVEL to Avoid Binding

LEVEL is a precompiler option that can be used when a program is modified but the SQL in the program has not changed. LEVEL is specified as a character string to be used by DB2 for consistency checking in place of the timestamp token. By precompiling a DBRM with the same level as before, a BIND can be avoided. You do not need to bind because SQL has not changed allowing DB2 to use the same access paths and the program to use the same package or plan as before.

Using LEVEL , a programmer can change his program without modifying the embedded SQL, and avoid worrying about having to bind. But care must be taken to ensure that the SQL is not changed. If the SQL is changed but a bind does not occur, unpredictable results can occur.

If LEVEL is used, DB2 will use the level as the consistency token and the default for version (if no version is specified).

CAUTION

Avoid using LEVEL as much as possible. Unpredictable and undesirable results can occur when using the LEVEL option improperly.

Specify the Version with Care

Remember, you basically have two options for specifying the version name. Versions can be automatically defined by DB2 specifying VERSION(AUTO) or explicitly named using the VERSION( name ) precompile parameter. When versions are automatically assigned by DB2, a timestamp will be used.

If you explicitly name your versions, they will be more difficult to implement but easier to administer. The difficult part is providing a mechanism to ensure that programmers always specify an appropriate version when precompiling a program.

On the other hand, if you use automatic versioning, packages are easier to implement because DB2 is automatically naming the version for you, but much more difficult to administer. The administration difficulty occurs because the auto timestamp version is unwieldy to manually enter when package administration is necessary. Consider this when deciding how to name versions at your shop.

If your shop does not have an automated means of administering versions, consider explicitly specifying the version when precompiling a program.