DB2 Server for VSE & VM: Application Programming

Doing Your Own Testing

Checking Warnings and Errors at Preprocessor Time

If errors or warnings are detected during preprocessing, the preprocessor inserts messages into the modified source code and preprocessor listing files to indicate that a problem was encountered. A return code is also issued indicating the severity of the problem.

Messages associated with warning conditions are inserted into the files in comment form so that the compilation of the modified source code is not inhibited. A return code of 4 is issued and, if no problems of greater severity are found, package processing occurs. All warnings should be investigated, because they may indicate a situation that must be corrected before the program is executed. For example, if you use the NOEXIST preprocessor option and a table is not found at preprocessing time, the database manager issues a warning because it assumes that the table will be created before the program is executed. If the program is executed and the table is not found, the successful execution of the program is inhibited and an error results.

DB2 Server for VM

Messages associated with error conditions are treated differently if the preprocessor option ERROR is specified. When you are preprocessing without the ERROR option, messages are inserted in the files in uncommented form so that the compilation process is inhibited. A return code of 8 or greater is issued, and no package processing occurs. When preprocessing with the ERROR option, most statement-parsing errors are tolerated. Messages associated with these errors are inserted into the files in commented form, and the return code is downgraded to a warning: detection of these errors does not inhibit package processing. However, some statement-parsing errors, such as errors with host identifiers and all errors that could jeopardize the integrity of the package, are too severe to be ignored. Such errors are treated as outlined for preprocessing without the ERROR option. Because the ERROR option allows preprocessing to complete successfully even though errors have been detected, ensure that each statement is preprocessed successfully on the application server on which the statement will be executed. Check the preprocessor listing associated with the binding application server.

DB2 Server for VSE
When you are preprocessing, messages associated with error conditions are inserted in the files in uncommented form so that the compilation process is inhibited. A return code of 8 or greater is issued, and no package processing occurs.

To check for error and warning conditions:

1. Scan the modified source code or preprocessor listing file for error and warning message. Error message numbers are formatted as ARInnnnE, and warning message numbers as ARInnnnW or ARInnnnI.

   Messages generated during preprocessor initialization and termination are stored in the listing file, not in the modified source code. A listing file containing these messages is produced regardless of whether the NOPRint preprocessor parameter is specified.

2. Look up the message numbers, SQLCODES and SQLSTATES issued by the system in the DB2 Server for VM Messages and Codes or the DB2 Server for VSE Messages and Codes manual.
3. If the error was detected by a non-DB2 Server for VM application server or non-DB2 Server for VSE application server, look up the SQLCODE and SQLSTATE explanations in the Messages and Codes manual associated with the database management system that detected the problem.
4. Use ISQL HELP for online information about messages and SQLCODEs issued by the database manager. To obtain limited online help information for SQLSTATEs, type HELP SQLSTATE from ISQL.

Testing SQL Statements

Several facilities are available to help you test SQL statements:

• Interactive facilities such as ISQL or QMF can be used for testing statements; however, the range of statements that can be tested with these facilities is limited. For example, you cannot test the following:
  • Statements that use host language delimiters, host variables, cursors, or statement names.
  • Dynamic or extended dynamic SQL statements.

  For other static SQL statements, however, these facilities are fast and easy to use, and you can do data definitions, authorizations, and data control tasks. For information on ISQL, see the DB2 Server for VSE & VM Interactive SQL Guide and Reference manual.

• The DBS Utility can be used for testing the same range of SQL statements that can be tested using ISQL or QMF. In addition, it lets you use file input and output, which makes submitting and reviewing test conditions easier, and lets you set up and restore test databases with DBS Utility data load and unload commands. For information on the DBS Utility, see the DB2 Server for VSE & VM Database Services Utility manual.
• DB2 Server RXSQL can be used for testing statements with host variables, statement names, and cursors. You can test dynamic and extended dynamic SQL statements. DB2 Server RXSQL can be used to prototype application programs. For information on DB2 Server RXSQL, see the DB2 REXX SQL for VM/ESA Installation and Reference manual.