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.
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.
* 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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
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.
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:
LATEST COMMENTS
MC Press Online