Using a combination of SQL and new services, DB2 continues to be an RPG programmer’s best friend.

In a previous article, I introduced you to a powerful SQL statement, VALUES. This statement allows you to write a single line of code in an SQLRPGLE program to execute an SQL statement or function and return the result to your program.

VALUES is a very powerful technique that allows you to take advantage of all of the standard SQL functions such as MIN/MAX, UCASE/LCASE, mathematical functions and so on—things that in RPG require either more work or access to the C libraries. VALUES can also quickly execute an aggregate statement to get, for example, a count or the greatest value in a set. These features are all very useful and can be used in any SQL environment; one of the great features of SQL is that what you learn anywhere tends help you everywhere.

But What About the IBM i?

The downside to that ubiquity is that SQL typically isn't quite as well suited for handling features, which are specific to a given platform, and in particular for those things that make the IBM i such a powerful business machine. When IBM first introduced pure SQL access to DB2 on the midrange, it didn't always mesh perfectly. As just one example, members were never handled very well. To this day, we still don't have syntax to do something like this to access the A2013 member in the file ORDHDR in library ARCHIVE:

SELECT ORDNUM FROM ARCHIVE.ORDHDR.A2013

That would be a nice addition! IBM has made it a little easier; back in the day, you had to actually do an OVRDBF outside of SQL to override your file to the appropriate member. The fact that SQL for the IBM i recognizes overrides is rather nifty albeit potentially a bit confusing to midrange neophytes; imagine the consternation when a select gives them data from a different file than the one they expected. The possibilities on an UPDATE are even more frightening. The newer alternative is to create an ALIAS:

CREATE ALIAS ARCHIVE.ORDHDR_A2013 FOR ARCHIVE.ORDHDR(A2013)

This is a bit more SQL-friendly; it's done inside the SQL. An SQL person may recognize what the ALIAS does even if they're not familiar with the concept of a file member, although in the SQL world the concept of an ALIAS is usually more temporary and scoped to the individual SQL statement. And of course, ALIAS could still lead to the same sort of confusion, but at least the confusion would arise from an SQL statement and not an external OVRDBF command.

Speaking of nice additions, you may have noticed that I used dots instead of slashes to separate the parts of the file name. That's a relatively new bit of syntactical sugar that is actually much more useful than you might think. That simple enhancement allows me to use the exact same SQL statement inside of the green-screen STRSQL as in any of my PC-based SQL clients, from IBM i Navigator to SQuirreL SQL. It's really a big deal if you find yourself moving between the two a lot.

Does Using SQL Mean Losing IBM i Functionality?

That's the scary thought: the idea that moving entirely to SQL will cut us RPG programmers off from some of the functionality that makes the IBM i great. And for now you may still have some issues with that: no way exists to completely emulate the simplicity of a CHAIN operation, and single record UPDATES are still easier through native I/O. But does that mean that SQL necessarily means losing the capabilities of the platform? Some of the more recent additions to SQL for DB2 on the IBM i refute that premise. We've seen already that judicious use of the VALUES provides functionality otherwise not available in RPG, but in this case the new DB2 services provide access to things that only an IBM i programmer could appreciate.

Let's take a quick look at one of the new DB2 services:

SELECT TEXT_DESCRIPTION FROM USER_INFO WHERE USER_NAME = 'JOEPLUTA'

If you run that instruction, you will see the text description from user profile JOEPLUTA. USER_INFO is a new SQL view that resides in library QSYS2. It provides an SQL interface directly to the user profiles on the system. You can see it and many other services here. It looks kind of nifty: an SQL way to look at what you might see from file output of the DSPUSRPRF command. But combine it with the VALUES statement and now you can do this in your RPG program:

exec sql VALUES
(SELECT TEXT_DESCRIPTION FROM USER_INFO WHERE USER_NAME = :USERID)
   INTO :USERDESC;                                                  

In one line of code, you can get the description (or just about any other attribute you might want to access) for any user profile you desire. In this specific line of code, the program will get the description from the user profile named in USERID and return it into the field named USERDESC. This can be done in RPG, but it would involve quite a bit of work: at the very least executing the DSPUSRPRF command into a file and then scanning the file to get the information for the correct user. This new service is definitely a huge timesaver.

Refer to the link above and you'll see that there are many other useful services available. How important they are depends on your environment, but I can see a situation where it would be nice to get my current library list easily: the LIBRARY_LIST_INFO view will do just that. Another option is to get a quick view of the active jobs, which is available via the ACTIVE_JOB_INFO service. Note, though, that ACTIVE_JOB_INFO is provided via a user-defined table function (UDTF), not a view. To access it as a table, you need to use the TABLE statement in SQL. It looks like this:

SELECT * FROM TABLE (ACTIVE_JOB_INFO()) ACTJOB

I don't understand why some features are provided as views and some as UDTFs. But that does bring up an important point: these new services are not silver bullets. In particular, some of these features come with real overhead. The user profile service, for example, can take a significant amount of time the first time you call it. The information seems to be cached at that point so that subsequent calls are faster, but even so, you might not want to put that call into a job that processes millions of records. In that case, you might be better off using a more traditional approach of executing DSPUSRPRF OUTPUT(*OUTFILE) to build a work file.

But that doesn't take away from the inherent utility of these functions. Look through the list. You'll see functions providing access to things ranging from joblogs to object locks to journal entries. I'm sure that at least one of these functions will provide an opportunity for you to either add some new functionality to your applications or make something that already exists a little easier to do. So have fun and keep an eye out as IBM continues to expand this list.