The library list is powerful, but it presents some difficulties in the new world of SOA; this article shows you how to get around those issues.

Whenever we open files or call programs in i5/OS (or simply "i" as it is known as of the 6.1 release), we rely on a concept called the library list. With this unique feature of the system, each job is associated with a list of libraries, and these libraries are searched in order when you look for an object, provided that object's name wasn't qualified with a library in the first place.

RPG Support for Library Lists

RPG in particular has inherent support for library lists. In fact, in earlier releases, you could only use the library list; files opened via the file specification or programs invoked via the CALL opcode were always resolved from the library list. You could use an Override with Database File (OVRDBF) command in CL to force a file to be opened from a specific library, but it was nearly impossible to invoke a program in a specific library.

But from an application architecture standpoint, that really wasn't much of a problem, because in most instances the library list was set either for the user (in the case of an interactive session) or for the job (via the job description when it was submitted). Either that, or a special program was invoked at the beginning of the job to set the library list, but that had a little bit of a catch-22 involved; for you to invoke the library program, it had to be on your library list or else you had to hard-code the library name.

The Problem Is Magnified with SOA

This was less of an issue in bygone days, because in most cases users would sign on to a session and set their library list and use that for the duration of their job (often the whole day). Batch jobs would inherit their library lists from the submitting job or would have the library list defined in the job description used to submit the job. In either case, it was relatively easy to control the library list on a case-by-case basis.

With SOA, however, that became a little more difficult. In general, the idea of a server job's library list is a tricky one, especially if the job services multiple users. In this article, we'll concentrate on the situation where a job services a single user, what we call a "persistent" service. I won't go into a long description of the benefits and disadvantages of persistent jobs, but it's definitely easier to illustrate the library list issues this way

It's important to understand that in the world of SOA, it's as likely as not that the library list your job runs under has little to do with the program that you are invoking; in fact, it's likely to be the default library list, which on the IBM i consists of the system libraries and often little else.

RPG to the Rescue!

As I noted, early releases of RPG had no concept of libraries. The file specification only had a file name, and the CALL opcode only allowed you to specify the program name. In both cases, the library was assumed to be the special value *LIBL, which meant to search the library list. This made it very easy to run the same program on data for, say, different companies by simply changing the library list. However, it made it difficult for the program itself to control the library where data was located.

However, that limitation is gone today. Now it is quite easy to open files or call programs from predefined libraries, regardless of the library list.

Let's take a look at an example.

Opening a Fully Qualified File

   FSESSIONS  IF   E           K DISK    EXTFILE(filename) USROPN

   D filename        s             21

The code above shows a file specification with a variable name. You see two specifications: the F-specification that defines a file named SESSIONS and a D-specification that identifies a field named filename. The filename field allows you to specify the fully qualified name of the SESSIONS file at runtime, before the file is opened. Since RPG will normally try to open the file for you during its internal initialization process, you need to specify the USROPN keyword so that the file open is under your control.

Now all you need to do is fill in the filename field prior to opening the file. You can use the program status data structure to get the library name. I usually do this in the initialization subroutine, *INZSR. Here's an example of that code:

   D                SDS

   D xsLib                  81     90

This specific application applies the fully qualified name technique in two steps. The first step shown in the code above is to determine the library name the program was called from. We'll then use this to qualify the file. This may or may not work for your application. In this specific application, the programs and files are all in the same library, so it works quite well. In other situations, you may need some additional logic to determine the name of the file library, or you may even have to call a program (a technique I'll demonstrate shortly).

Start by using the library name from the PSDS to qualify the SESSIONS file name:

   begsr *inzsr;

     filename = %trim(xsLib) + '/SESSIONS';

     OPEN SESSIONS;

   endsr;

Once you have a way to determine the library, the next part is simple. Take the library name, trim any trailing blanks, and then append a slash followed by the name of the file. This LIBRARY/FILE syntax is the standard for fully qualified i5/OS file names, and it's entirely supported by the EXTFILE keyword in the file specification. This also explains why the filename field is 21 characters: The maximum length of a fully qualified file name--including library, file name, and slash--is a total of 21 characters.

Calling a Fully Qualified Program

There are other ways to open a fully qualified file. The most common is to use an OVRDBF command. If you call the program QCMDEXC and tell it to execute an OVRDBF command prior to opening a user-controlled file, the OVRDBF will be applied to that file name. But I much prefer the EXTFILE variable technique I've shown here because the same basic concept can also be used to fully qualify programs.

For example, I can use the same library name from the program status data structure to qualify the library for every program I call. This requires the use of a prototype, but you should probably be considering prototypes for all new calls anyway, since there are really no downsides.

Let me show you how it works. In this case, I use a variable for the program name:

   DnLOGOUTR         s             21

   D LOGOUTR         PR                  EXTPGM(nLOGOUTR)

   D  iEventMajor                   2a   const

   (...)

Here, I initialize the variable in the *INZSR subroutine:

   begsr *inzsr;

     nLogoutr = %trim(xsLib) + '/LOGOUTR';

   endsr;

In this example, I am calling a program named LOGOUTR. I use the standard external call prototype, which is a D-specification with the EXTPGM keyword. And, as with the EXTFILE keyword for the file, I specify a variable in the EXTPGM keyword for the prototype. This will cause the CALL opcode to use the contents of that variable when executing the call. So the last step is to then initialize the variable in the initialization subroutine, again trimming the library name and appending a slash and then the program name.

An interesting application of this technique is to use the library of the called program to call a program that determines the libraries of database files and other programs. The libraries returned will be different, depending on the library that the initial program is invoked from. It's an interesting alternative to the library list.

Back to the Future

We spent a lot of time in years past removing all the hard-coding of library names. Great productivity ensued from the ability to have an application use an entirely different set of database files and even different business logic by simply changing the library list. It was very easy to have multiple environments on a single machine, be it different environments for testing and production or different databases for different companies. But with the advent of SOA, we're coming full circle to where it is sometimes necessary to hard-code those libraries once again--or at least to derive them at runtime from something other than a library list.

This article shows you how to do that.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale