If you are or have been a programmer on an iSeries 400 or any of its predecessors, you've run into the issue of where to put QTEMP in the library list. Because the operating system hunts for any unqualified objects by searching the library list from top to bottom, it's important to get the order of the library list correct.

The QTEMP library is usually located in the user portion of the library list (QUSRLIBL), and applications tend to move it around to suit their own needs with the CHGLIBL (Change Library List) and EDTLIBL (Edit Library List) commands. Application programmers typically maintain the QTEMP library in their library list as needed, and they keep QTEMP in a standard location in their library list so that their programs always work the same way. As new programmers enter the shop, they either learn the unwritten standard by which other programmers work, or they write a CL program that manipulates the location of QTEMP for the duration of their program and returns it when they're done.

The Wrinkle

OS/400 includes two additional libraries in the library list - *PRDLIB and *CURLIB. These libraries exist between the QSYSLIBL and the QUSRLIBL. Application vendors and IBM use *PRDLIB, or product library, to help free up a slot in the library list when an application isn't using a given object that resides in the product library. *CURLIB, or current library, defaults to QGPL, but you can use it for nearly anything. As a standard practice in my shop, we create a library for each programmer and assign it to *CURLIB in the user profile. Although we like having each programmer's library above the user portion of the library list, doing so places QTEMP below an application library.

After much consideration, we added QTEMP as the last entry of QSYSLIBL, the system portion of the library list. From a development standpoint, this is a godsend. It frees up a slot in the QUSRLIBL and eliminates the raft of CL programs that do nothing but alter the location of QTEMP, call a program, and return QTEMP to the original location. Using this approach lets everybody know exactly where QTEMP is located and lets our programmers all code to the same standard. Nobody moves QTEMP around anymore. Nobody but the vendors.

Beware the Vendors

Most programmers tend to run into the same problem. As they write their applications, they make assumptions about what the library list contains. Programmers who've worked on the System/38, AS/400, or iSeries expect that QTEMP belongs to their job and that they can move the library to suit their needs. If you're fortunate, they remember to put QTEMP back where they found it.

Few application vendors prepare for a shop that keeps QTEMP in QSYSLIBL. The regular commands to manipulate the library list, CHGLIBL and EDTLIBL, work only on the QUSRLIBL portion of the library list. Because a library can exist only once in the entire library list, vendors are prevented from using these commands for the QTEMP library. This restriction has caused more than a few problems over the years.

Now What?

Many of our vendors complain about the way we manage QTEMP, and most are unwilling to change their code to meet our standard. When we try to explain to potential vendors the reasons we keep our home-grown application code set up to work with QTEMP in the system portion of the library list, they usually ask why we want it that way. Most iSeries shops have never considered freezing the QTEMP location, preferring to let the programmers fight over the location of QTEMP within their programs. Because of management requests to use more purchased software, the conflict over where to place QTEMP is arising more often. So this begs the question, "How would you manage QTEMP?" You can send your suggestions to the AS400 Network's RPG forum at http://www.as400network.com/communities/rpgprogrammer.

Scott Cole is a senior technical analyst at Excel Corporation in Wichita, Kansas. You can e-mail him at .