TechTip: Handling SQL Return Codes, Part II

SQL
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

 

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.

exec sql open  DemoCursor;             
if SQLSTT <> SQLSuccess;               
    SQLProblem('open DemoCursor');     
endif;

 

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 ======================================
  * For those "Never should happen" SQL errors.
  * Issues DUMP(A) to dump memory, then ends program by
  * sending an *ESCAPE message of the supplied debugging text.
 p SQLProblem      B
 d SQLProblem      PI
 d piSQLDebug                  1024    varying value

 d wkSQLDebug      s           1024    varying

  /free
   wkSQLDebug = piSQLDebug;
   dump(a);
   SndEscMsg(piSqlDebug);
   return;
  /end-free
 p SQLProblem      E

 

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

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.

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: