Did you know you can use host variables nearly everywhere in an embedded SQL statement? Keep reading to find out more!

Last time around, I showed you how to embed SQL code in both fixed- and free-format RPG code. I also demonstrated the functionality provided by host variables, which allow SQL and RPG to exchange information in a simple and easy-to-implement way. Let’s continue that discussion.

You can also use host variables in the WHERE clause to define conditions for any DML instruction. Imagine that you want to reduce the expiration date of all the items in Warehouse 24’s inventory by one day. Using only RPG, this would mean reading the InvMst table in a loop, making sure that you affect only items where the WHID column contained 24, calculating the new expiration date, and updating each record. It’s not difficult to do (after all, we’ve been doing stuff like this for years), but it takes a while to build. Now let’s do it in six lines of code:

      K_WHID = 24; // key to the warehouse Id

      W_Exp_Reduction = 1; // nbr of days to cut in the exp. dates

      EXEC SQL

      Update InvMst

      Set   ExpDate = ExpDate – :W_Exp_Reduction DAYS

      Where WHID = :K_WHID;

There are a few new things in this code, so let’s dissect it line by line:

• The first two lines assume that variables K_WHID and W_Exp_Reduction have been defined somewhere else and simply serve to assign values to them.
• The SQL statement begins with the EXEC SQL line, just like in the previous examples.
• The UPDATE INVMST line shouldn’t be a surprise—you saw shown the UPDATE statement a few TechTips ago, and this is part of the typical syntax of the SQL instruction.
• The fun begins with the next line. When I discussed the date-related functions in the RPG Academy TechTip series, I didn’t mention (quite intentionally) this way of performing calculations involving dates. It’s nothing special, but it has to follow some rules: the variables involved (the ExpDate in this case) have to be of the date, time, or timestamp data type. However, you need to be reasonable because it doesn’t make sense to subtract a day from a time field. Speaking of reasonability, it doesn’t make sense to multiply dates or times, only to add or subtract them, so the only operators that you can use are the plus and minus signs. Finally, you need to use one of the date-related reserved words (YEARS, MONTHS, DAYS, HOURS, MINUTES, SECONDS, and MICROSECONDS) to define the unit of the quantity that you’re adding or subtracting. I mention all of this to explain that the SET line will simply subtract one day from ExpDate and assign the result of the operation back to ExpDate. If W_Exp_Reduction had the value 2, then this would reduce the expiration date in two days, and so on. Note that W_Exp_Reduction is not an SQL column or variable; it comes from the RPG code. That’s the reason for the semicolon character that precedes it. If, instead of reducing the expiration date by one day, I wanted to increase it by three months, I’d just change W_Exp_Reduction’s value appropriately and adjust the SET line to the following:

                 Set ExpDate = ExpDate + :W_Exp_Reduction MONTHS

• In the last line, K_WHID is being used to restrict the UPDATE’s scope to the lines that contain WHID = 24, because K_WHID contains 24.

While the SELECT example from the previous TechTip showed how to use a host variable to receive data from the embedded SQL statement, this UPDATE example showed how to use host variables to send data to the embedded SQL statement. Naturally, if you have a SELECT statement that uses host variables in the INTO and WHERE clauses, you’ll be receiving data (in the INTO clause) and sending data (in the WHERE clause) simultaneously.

This is a great way to extend what RPG can do with the awesome power of SQL, but (as always) there are a few restrictions:

• The host variable names can’t start with the characters DSN, RDI, SQ, or SQL. These names are reserved for the database manager.
• The length of the host variable names can’t exceed 64 characters.
• Some data types can’t be used as host variables. The list below includes the most common:
  • Unsigned integers
  • Pointers
  • Tables
  • UDATE
  • UDAY
  • UMONTH
  • UYEAR
  • Look-ahead fields
  • Named constants
  • Multiple-dimension arrays
  • Definitions requiring the resolution of %SIZE or %ELEM
  • Definitions requiring the resolution of constants, unless the constant is used in OCCURS, DIM, OVERLAY, or POS and is declared before it is used in the OCCURS, DIM, OVERLAY, or POS

As you might imagine, the RPG compiler doesn’t know how to handle SQL. Additionally, your editor of choice (SEU, RDi, or some other editor) might not recognize the SQL in the source, so you also need to change the source member type from RPGLE to SQLRPGLE. As you might have gathered, all of this means that you can’t simply compile an RPG source that has embedded SQL statement with the CRTRPGMOD or CRTBNDRPG commands. You need to use something that transforms the SQL statements into a language the RPG compiler understands—you need new compilation commands.

How to Compile SQL-Infused RPG Code

I explained (way) back in the beginning of the RPG Academy TechTip series how to compile modules, programs, and service programs. The only source that is compiled is the module’s, so I only need one new command, which will allow me to call the SQL precompiler (a nice little thing that turns the embedded SQL statements into something the RPG compiler understands) before calling the familiar CRTRPGMOD. After the module is created, binding it to a program or service program follows the usual process.

The command is CRTSQLRPGI (Create SQL ILE RPG object), and it’s similar to CRTRPGMOD. However, CRTSQLRPGI can be used to create modules, service programs, or programs.

Let’s say I want to compile a module named SQLOPS. All I need to do is issue the following command:

CRTSQLRPGI OBJ(MYLIB/SQLOPS) SRCFILE(MYLIB/QRPGLESRC) SRCMBR(*OBJ) COMMIT(*NONE) OBJTYPE(*MODULE) DBGVIEW(*SOURCE) USRPRF(*OWNER) DYNUSRPRF(*OWNER)

It’s important to remember the parameter OBJTYPE(*MODULE) because that’s what indicates you’ll be creating a module, instead of a program or service program. Note that you can also create a program by specifying *PGM or a service program (*SRVPGM) in this parameter. I usually create a module and then bind it to a program or service program, along with other modules, as needed. This command has several other parameters, but a deep knowledge of them is not required for most situations. (If you really want to know, check out the CRTSQLRPGI full description here.

If you still use SEU, I suggest that you create a user-defined PDM option for this command. Something like BQ for Build SQL module, for instance:

CRTSQLRPGI OBJ(&L/&N) SRCFILE(&L/&F) OBJTYPE(*MODULE)

This will save you some time and a lot of typing.

Coming Up

Now that you know how to compile SQL ILE RPG modules, let’s revisit some of the functions created in earlier installments of RPG Academy, and rewrite them using embedded SQL. Sound interesting? Then read the next SQL 101 TechTip!

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