Note: The code accompanying this article is available for download here.

In my previous tip, I detailed the prototyping technique required to enable program calls in free-format RPG to use a variable to control the target program. These days, most modern RPGers make extensive use of subprocedures, so can the same techniques be applied to procedure calls?

The simple answer is “yes,” but the technique is slightly more complex than that used for program calls. The reason for this is unlike program calls, procedure calls normally have to be resolved at program creation time, i.e., during the binding

Global temporary tables are a marvelous, powerful feature of SQL, allowing SQL programmers to create temporary tables as needed in order to build complex queries. One problem you will encounter occurs when you want to use a host variable within a program to limit the amount of data loaded into the table. You may not use a host variable in a Declare Global Temporary Table command. Fortunately, this is an easy limitation to circumvent.

First, let’s look at an example of the problem. In the following code fragment, I attempt to create a global temporary table using data for one

To satisfy regulatory requirements, we must change our i/OS password strategy so that the system accepts up to 128-character passphrases using any keyboard character, including spaces. We currently use 10-character passwords. How do I make this change?

–Len

It’s easy to activate passphrases on iSeries, System i, and Power i systems. For readers not familiar with the concept, a passphrase refers to a password scheme that allows for very long passwords with few restrictions on character content.

Setting up passphrase support on an i/OS or OS/400 partition requires you to change the following three system values.

1. Password level (QPWDLVL)