A web-based or server-based application using Advantage CA-IDMS Database Server Option to access an Advantage CA-IDMS database is failing. How do I identify where the problem is occurring and debug it?

Document ID : KB000055804
Last Modified Date : 14/02/2018
Show Technical Document Details

Here are two ways to identify where the problem occurs. The first is by testing each of the SQL statements in the code. If this is a program written at your site, you can test the SQL statements in that program under the Advantage CA-IDMS CV using the online (OCF) or batch command (IDMSBCF) facility. This may require changing the format of the command slightly, for example, to reference literals instead of any host variables that are specified.

A second alternative is to turn on ODBC traces within the Advantage CA-IDMS Database Server Option, as follows:

  1. Enter the ODBC Administrator.
  2. Select the IDMS Data Source, and click CONFIGURE.
  3. Select OPTIONS Set Log Options, and click SETUP; or select LOG OPTIONS (depending on your release).
  4. Enter a log file name, typically, CAIDDSI.LOG.
  5. Click only these CLIENT TRACE options:
    ODBC (or JDBC), SQL, and DTS
  6. Click OK, OK, Exit; and then run the abending application or statement.
  7. Turn the trace off by repeating Steps 1-4, deselecting the trace options and executing Step 6.
  8. Read the trace dataset for a statement that returns an unexpected error. This will not be the last statement in the trace.

If you have run the traces, at this point, you may have enough information to understand the error. If the error message does not clarify the nature of the problem, then we recommend you begin testing and debugging it is using OCF or IDMSBCF. If the task fails, you have determined that the statement is flawed and you must correct it. You can get detailed information on the error by running the query in a local mode IDMSBCF job with these SYSIDMS parameters:

PROCTRACE=ON (if using table procedures)

If the statement executes successfully under OCF or IDMSBCF, the problem is in the original statement (before any substitution of literals for variables) or with the software handling the statement. Again, if you have the ODBC trace message, you may have the information you need to debug this. If you do not, then you will need to code a small program with the original statement embedded in it, and execute it. If this program, containing the exact original code, also abends, then you have identified that the original statement is flawed and must be debugged.

If the program runs successfully, then you have shown that the error is one of the several software layers separating the mainframe server from the platform on which your application is running. The only alternative at this point is to use the detailed error messages in the trace to pinpoint where the error occurred. You may need assistance from Technical Support to interpret the trace.