In a previous TechTip, I encouraged you to do stringent error-checking on SQL return codes. In this TechTip, I suggest a standard error-handling routine for those SQL return codes you don't expect. I also provide template program SQL_SKELR, which you can clone as a beginning for many of your embedded SQL programs. The code snippets provided previously came from SQL_SKELR.

As stated before, my rule of thumb is this: Check for and have logic to handle the SQLSTT return codes you expect. If you get a return code you don't expect, don't ignore it. Instead, take some diagnostic or corrective action with a common SQL error-handler.

An SQL Error Handler for Batch Programs

My development philosophy is that if my batch program gets to a situation that I have not anticipated, it should provide as much debugging information as possible and then end abnormally before it does any damage.

The code below shows an example of coding such logic, using the SQLProblem procedure to handle any unexpected SQL return code.

The SQLProblem procedure is the last-ditch effort that my skeleton program uses to end abnormally when it gets an SQL return code that it doesn't know what to do with. Shown below is the code for the procedure.

SQLProblem takes a single parameter: debugging text to help identify where the program was when the error occurred. Each call to SQLProblem must have unique debugging text so that you can quickly and unambiguously determine where the error occurred. You will find this useful if you have a complicated program with many SQL statements, especially if you are not the original author of the program.

SQLProblem first issues a DUMP(A) opcode to give a formatted memory dump to aid debugging. If you are building dynamic SQL statements, you will be able to see the statement you built.

SQLProblem then sends the provided debugging text as an escape message using the QMHSNDPM API coded in the SndEscMsg procedure. The escape message stops the program dead in its tracks and makes it break to the operator console. Someone on support then receives a (usually late-night) phone call.

This is not a technique that can be accused of being over-engineered. Remember, however, that this is for unexpected return codes, and SQLProblem should never be executed. Your shop may not like breaking to the operator console and may have other standard ways to handle and report unexpected program logic errors. If so, incorporate them into the SQLProblem routine, but still use the debugging text and the DUMP(A) opcode.

An SQL Error-Handler for Interactive Programs

Breaking to the operator console is not a good idea for interactive programs, and you need another approach. Since users are notoriously inaccurate in telling you what happened, I suggest that you use a variation on SQLProblem. Lose the escape message, but continue to identify the location of the error with unique debugging text and execute a DUMP(A) opcode. You will find the debugging text in the dump in field wkSQLDebug. If you want something in the job log, send the debugging text as an info or diagnostic message. Finally, tell the user that an unexpected SQL error occurred and that he should contact the Help Desk for assistance. Then, end the program gracefully.

Proof of the Pudding

I have been checking SQL return codes this way for several years now. SQLProblem has been exercised numerous times during development but only twice in production batch. One problem was a date range situation similar to the SQL_DEMOR program in my original article. The other resulted from an internal SQL problem after applying a PTF. I'm not sure what that program would have sent to the POS system if I had ignored the problem, but there might have been some very happy shoppers and some very unhappy bean counters.

Let me stress again that this approach is to handle unexpected SQL return codes and that you hope the error-handling code will never be executed. The technique I suggest here is easy to code and doesn't have any significant overhead, and your programs will be closer to bulletproof and less likely to do something stupid.

Download Code

The code of SQL_SKELRis available to download. It is a complete program that runs but produces no output. Not having a SQL_DEMOP file will cause the open cursor to fail and is the easiest way to check out how SQLProblem works and see the results. If you want SQL_SKELR to run to completion, create the SQL_DEMOP file using the script that I provided with my original TechTip.

Sam Lennon is an analyst, developer, consultant and IBM i geek. He started his programming career in 360 assembly language on IBM mainframes, but moved to the AS400 platform in 1991 and has been an AS400/iSeries/i5/IBM i advocate ever since.