A new column provides a technical overview of the AS/400.
This month: Libraries.
by Craig Pelkie
Many Midrange Computing subscribers have written to say that some of the AS/400 discussions are over their head. Many are still on the System/36, but plan to be on the AS/400 sooner or later, and need some basic conceptual understanding now.And sone just want to know more about the machine and how it is programmed.
In response to this need, we're starting a new column designed explicitly to teach fundamentals to novice AS/400 programmers and even non-AS/400 programmers. Most of the articles will be written with the S/36 programmer in mind.
So with that introduction, let's examine one of the most fundamental concepts of the AS/400. This is the concept of libraries, which are used for every interaction you have withy the machine.
They Hold Everything
According to the book (CL Programmer's Guide, SC21-8077), a library is "...an object that serves as a directory to other objects. A library is used to group related objects and to find objects by names when they are used." Now right away, you have to understand another concept: that of an "object." Put simply, everything that you can create, use, and destroy on the AS/400 is an object. You will immediately think of programs and files as objects; these are the most common things that we use as programmers. But there are other things that we use that are also objects: job queues, output queues, user profiles, folders, and so on. Every object is contained within a library. A library, as defined above, is another type of object.
This definition and organization differs from the S/36. On the S/36, a library contains procedures, subroutines, object code, and source code. Files and folders are considered as separate entities; if we were to think of them being "contained" anywhere, we would think of them as contained within the VTOC.
Many new AS/400 programmers might well wonder why a new organization scheme is used. After all, if the program library and file/folder mechanism worked so well on the S/36 (and earlier machines), why is it necessary or desirable to complicate things? It turns out that putting everything into libraries actually simplifies the organization, with the additional benefit of promoting consistency. I will explain.
The S/36 was never intended to store thousands of files and libraries. Of course, it could be extended to store great numbers of files, but I imagine that most installations have fewer than 500 files to deal with. The AS/400 (and its predecessor, the S/38), in contrast, were designed from the beginning to store multiple thousands of files and programs. The amount of storage planned into the machine is fantastically large, on the order of trillions of bytes. So a simple VTOC-type organization really wouldn't accommodate a machine with this capacity. Can you imagine dealing with a VTOC with 10,000 entries?
One solution to this organization problem was the idea of the "library." The machine can contain any number of libraries, and a library can contain any number of objects. Each library, then, can be thought of as a "virtual VTOC." That is, you can list the contents of a library, just as with a VTOC. The difference is that a library can contain more types of things than will listed on a VTOC.
Simple Rule
The primary rule for what can be in a library is so simple that it should never be a problem: each object of the same type must have a unique name. That is, every file must have a unique name; every program, and so on. Some programmers confuse the object type with the object subtype. For example, "program" is a type of object, and RPG, COBOL, and CL are subtypes defining the type program. Because the rule applies to the object type, you must have different program names, even though one may be an RPG program and the other a CL program.
On the other hand, the same name can be used for different object types. You might have a file named OEMSTR, for Order Entry Master, and an RPG program named OEMSTR. This will not cause any problems. The machine determines which object to use based on the context in which you use it. For example, if you CALL OEMSTR, then the system knows it should "call" the program, since it wouldn't make sense to call the file.
I suppose this rule causes problems for some S/36 programmers, since it is possible to have several library members of the same name in a S/36 library. For example, the source and load modules of an RPG program would usually be given the same name, and it is possible that a procedure would have the same name as a program. So although this may cause confusion at first, don't let yourself dwell in S/36 mode too long.
WHERE'S THE SOURCE/?
At this point you might be wondering whyere source code is kept. Programs are a type of object that is kept in a library, this similarto a S/36 load member. CL programs take the place of procedures, and because a CL program is complied, it is also a type of program object. So where is actual source code kept?
It turns out that source code for any type of program (RPG, CL, COBOL, and so on) is kept in a physical file known as a source file. A source file, like all physical files on the AS/400, can contain more than one member. Each source program becomes a separate member in the source file. The source file, of course, is kept in a library. The source file can be in the same or a different library than the complied program object.The decision on where the source file is located is up to you. Some installations create a library that contains only source files, compiling all of the program objects into production libraries. Others keep the source files in the production libraries, and set up libraries by application; for example, all Order Entry programs and files are placed in their own library.
This topic will be covered in more detail in the future. But you should know that there is no requirement to have more that one source file, although the convention is to have a separate source file for different types of objects. For example, most installations will have a file for RPG source, another for CL and COBOL source, and still another for DDS siource (usually containing source forphysical, logical, and display files). The conventional names for these source files are QRPGSRC, QCLSRC, QCBLSRC and QDDSSRC. Other languages have similarly conventional source file names.
When you create an object that requires source specifications (a program or file), you specify the names of the source member, the source file, and the name of the "target" library on the create command. That is how you can have the source in one library and the created objectin another.
Multiple Libraries
Because the AS/400 can contain so many libraries, you are allowed to access objects in any number of libraries when you run a program or command. You can tell the system the libraries to which you want access with a library list, which can include up to 25 libraries. Your "job" also has access to up to 15 libraries in what is called the system library list. (For our purposes now, think of a job as the time between signing on and signing off a workstation.)
When your job requires the use of an object, you have two ways that you can tell it where to find the object: explicitly, or by default. The explicit method is to specify the name of the library containing the object with the name of the object. For example, to use the file OEMSTR, specify OELIB/OEMSTR.
That indicates that the file OEMSTR is contained within library OELIB. The default method is to let the system find the object for you, using the library list that is current for your job. If a program needs to use file OEMSTR, and you have not told it which library to use, the system starts with the system library list and examines each library in that list, looking for OEMSTR. If the file is not found in that list, it then examines each library, in order, in your user library list. The search stops at the first instance of the required object, or when there are no more libraries to search. If the system can't find the object, it sends a message telling you that the object was not found in the library list.
The rationale for letting the system search for the object is so that you can have objects of the same type and name in different libraries, and get different results just by changing the library list. Why would you want to do that? One reason is so that during testing, you can have test files in a test library, and production files in another. As long as your test library appears in your library list before the production library, the system will use the test files. Naturally, you must be careful about specifying the library list when you do this; even so, you can set up libraries as test or production libraries, and give the system commands to ensure that you don't update anything in a production library. Another reason to use the "find it yourself" technique is to run the same program against different sets of data, if you group the data in different libraries.
Setting a Library List
There are two parts of the library list that you can set: the system part and the user part. The system part contains up to 15 library names, and is in effect for every job on the system. The user part can contain up to 25 library names, and can be unique for each job.
The system part of the list can be permanently altered for all users with the CHGSYSVAL (Change System Value) command. The change is in effect when new jobs start; it does not change for currently active jobs. The security officer and authorized users can also use the CHGSYSLIBL (Change System Library List) command to temporarily change their system library list.
The user part of the library list can be set to a default, also with the CHGSYSVAL command. However, a user can also use the CHGLIBL (Change Library List), ADDLIBLE (Add Library List Entry) and RMVLIBLE (Remove Library List Entry) commands to alter their library list. It would not be uncommon to create an initial program for a user, and have one of the first commands be the CHGLIBL command. That would set them up with the libraries that are needed for the job.
Other Parts of the List
There are two other parts of a library list that I will mention. These are the product libraries and the current library.
Product libraries are a curious artifact in that they are managed by the system. For example, when you compile an RPG program, the QRPG library is placed in the product library list. I can only surmise that IBM thought this would be a nice touch, so that we wouldn't have to remember to include product libraries in our library lists. There is apparently no reason to ever think, wonder or worry about the product library part of the list.
However, you may want to consider the current library concept. The current library is typically used on the various CRT (Create) commands, to specify where the created object is to reside. For example, the CRTRPGPGM (Create RPG Program) command specifies *CURLIB (Current Library) as the default for where the program object is to be placed. Of course, you can specify another library instead of *CURLIB. You select one library to be the current library on the CHGLIBL (Change Library List) or CHGCURLIB (Change Current Library) commands. If you don't specify a current library, the library QGPL (General Purpose Library) is used instead. So you should be careful when using CRT (Create) commands if you don't have a current library, since you will end up with lots of things in QGPL if you don't specify otherwise.
Creating and Using Libraries
If an AS/400 is in your future, you should give some thought now to how you might set up your libraries. The S/36 paradigm probably won't help much, since AS/400 libraries are so different from those on the S/36. Some of the issues you should consider are setting up libraries by application (e.g., Order Entry, Accounts Payable, Personnel); setting up libraries with programs in one, files in another; setting up a separate library for source files; and so on. On most systems that I've seen, there tends to be a mix of techniques in use. As people learn about the system, they change the way they do things. There is really no one "best" way to configure your libraries, although as with all issues connected with computers, this can be the subject of heated controversy.
For any library configuration that you think you want to set up, you should probably write up a list of pluses and minuses, and then pick the technique that you believe would be best.
As far as using libraries, your needs as a programmer are quite different from your user's needs. Generally, there is no need for a user to have any awareness of libraries. You should create initial programs for them that set their library list, and include commands in your CL programs that alter the library list as required.
For programming, you will need access to different libraries as you move from project to project. I generally use the CHGLIBL (Change Library List) or EDTLIBL (Edit Library List) commands to change the library list. As a programmer, you will want access to these commands, but I don't think it is a good idea to let non-programmers use these commands.
If you have objects of the same type and name in different libraries, you will have to be careful when you use those objects. Accessing an object in the wrong library can be a very subtle and potentially disastrous error, especially in batch jobs.
For the Future
To really understand the AS/400, you need to become very familiar with the concepts of libraries and the library list. In future articles, you will see other places where you can specify library lists, such as when submitting batch jobs.
If you are currently programming a S/36, you will find it useful to completely separate the S/36 concept of a library from the concept underlying the AS/400 library. As you have learned in this article, the AS/400 library is much more comprehensive.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online