As discussed in my previous tip, controlling library lists and the list environment on your system is important...
to running a secure application. Abusing the library list environment could easily cause a wrong (and possibly malicious) program to run or to access an incorrect data file.
In fact, in my work doing software support, I am often presented with an inexplicable scenario only to find that wrong programs or data have been processed because and wrong object was referenced.
In the previous tip, I talked about the system library list component. The library list environment also includes a user library list and two specific libraries: the current library and the production library.
The user library list is maintained as system value QUSRLIBL. This is a list of libraries that will always be present for all users of your system at sign-on time. The user library list can also be modified by the Job Description in effect at processing time. This list should be kept to a minimum. Most shops that I've seen have the QGPL and QTEMP libraries in this list, which may be helpful.
The QTEMP library is often used by applications for work files and objects and the QGPL library is often used by system applications. Shops that are concerned about security issues will often even leave those libraries off the list. Just as with the system library list, you should take steps necessary to restrict users from making changes to the system values and job descriptions that can update how the user library list environment is set.
The only other candidates for inclusion in the user library list should be libraries that all users will need access to. Those might include a general use utility library or some other such library that all users need access to.
Unfortunately, because of ignorance of how library lists work, many shops load these up with lots of application library names just to get their applications to run and then they just leave the lists cluttered up leaving lots of room for problems down the road. If you have specific application requirements, it would be best to include them in the Job Description and not in the system value.
Once you have settled on your system library list and user library list, there are still two more ways to add library control to your jobs: the product library and the current library. When OS/400 searches for objects, it searches the system library list first, then the product library, current library, and finally the user library list.
The product library and current library are controlled by the OS/400 command object or by the menu from which they are run. When you create your applications, you should take care to make sure that the users who have access to create command objects and menu objects are limited to trusted users. There are a small number of OS/400 commands that can be used to create and modify *CMD objects; make certain that access to these OS/400 commands is limited. The same is true for creating and maintaining menus on your system.
When you create commands and/or menus, you should take some time to consider how you want the product library and current library set up. It is an easy way to make sure that your application library is available for processing without cluttering up your user library list with unnecessary entries that apply to everyone.
If you have any specific questions about this topic, you can reach me at (firstname.lastname@example.org), I'll try to answer your questions. All e-mail messages will be answered.
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.