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!