Nobody likes Open Query File operations. However, we’re all more or less forced to live with them and, more importantly, maintain them. Here’s how to replace them with SQL cursors.

The prospect of “killing” those error-prone, problem-magnet Open Query File operations sounds nice, doesn’t it? Well, SQL cursors are the way to go. However, before I get to that part, there are a few things about cursors that you need to take note of.

Before you learn how to use a cursor to replace an Open Query File, here are a few notes to keep in mind regarding cursors:

• The list of variables used by FETCH can be a data structure. This is particularly useful with cursors that have a long SELECT clause. You define a data structure with the appropriate variables and use it instead of the list after the INTO, like this:

Exec Sql FETCH mainCursor INTO :W_My_Data_Structure;

When I’m reading data from a single table, I sometimes define the record format of that table as an external data structure and use it in my FETCH operations.

• You can’t open a cursor that’s already opened or close a cursor that’s already closed. The system will return an error and stop execution.
• You can’t use FETCH on a closed cursor.
• The DECLARE statement must be specified before any other statements that mention the cursor in the source code. This is rather peculiar; it means that if you want to fetch data in source code line 200, the cursor must be defined before that line. I’ve always found this to be the source of many compilation errors, with very unfriendly error messages.

Never forget these tips! Some of them are basically common sense, but others are the product of countless hours looking for errors that weren’t actually there. It took quite a few programmers quite some time to distill this four-bullet-point list. Having said that, it’s finally time to tackle the real topic of this article!

Replacing the Dreaded OPNQRYF with an SQL Cursor

The Open Query File command or OPNQRYF, along with the GOTO and TAG operations codes, sits at the top of the RPG programmer’s worst nightmare list because what (eventually) started as a good, simple idea becomes a huge mess in no time. Then someone has to maintain that mess…and it’s never easy. However, it can get easier: just modernize the code when an opportunity presents itself. It’s going to take some time, but it’s time you’ll save in the future. With this in mind, I decided that it would be a good idea to show you how to get rid of OPNQRYF.

I’ve shown earlier in this series how to create a cursor using a basic SELECT statement. This statement is hardcoded in the DECLARE SQL statement and not changed by the other cursor-related operations. This might work in theory, but in real life, you probably want to refine the record selection at run time. This is usually achieved by an OPNQRYF command executed prior to the program call. Big QRYSLT values are common, leading to nightmarish commands that don’t always perform as you’d wish. A static, hardcoded cursor doesn’t solve the problem; you need a dynamically definable data access (or cursor), like you had (or still have) with OPNQRYF.

The solution is defining a flexible cursor using host variables in the DECLARE statement. Let’s say I want to refine mainCursor from the previous TechTip’s example; I want to be able to indicate the warehouse ID dynamically. The new DECLARE statement looks like this:

/Free

   Exec SQL

     DECLARE mainCursor CURSOR

     FOR

     SELECT InvMst.ItemID, ItemDesc, ExpDate

     FROM   InvMst InvMst

     INNER JOIN ItmMst ItmMst ON InvMst.ItemID = ItmMst.ItemID

     WHERE WHID = :K_WHID;

Notice the line in bold? I’ve added a WHERE clause with a host variable. This variable’s value is not known when the cursor is declared, but that’s not a problem, because the DECLARE statement is more concerned with the SELECT clause—it needs to know which columns are going to be part of the temporary result table it creates. K_WHID matters when the FETCH statement is executed; that’s when K_WHID’s value will be used to replace the host variable name in the statement.

Creating a replacement for an OPQRYF is feasible, assuming that you understand what’s in the QRYSLT part of OPQRYF. It can be as easy as “translating” the QRYSLT code to the appropriate SQL comparisons and putting them in the WHERE clause of the DECLARE statement.

SQL’s power allows one additional step toward flexible data access: you can create a dynamic SELECT statement for your cursor declaration! In other words, you can build the DECLARE’s SELECT statement conditions (columns to return, selection, aggregation, order, and everything else) at run time. Sounds even better, doesn’t it? Well, you’ll have to wait for the next TechTip to learn how to do it!

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 2

TechTip: Automate Complex Tasks Using SQL and User-Defined Table Functions

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 1