Techniques for working your way out of the System/36 Environment

by Ernie Malaga

Library Management

This month we will discuss the library management procedures available in SSP and how they translate into native commands. Because there is so much to cover on the general topic of library management, we won't mention those SSP procedures that combine library management with magnetic media, such as SAVELIBR.

Because S/36 libraries and AS/400 libraries are different entities, let's begin by pointing out the differences between the two systems.

On the S/36, a library is an area on disk that has a name, a directory, and is comprised of library members. The space reserved for the library has a fixed size and must be all in one piece; when this size is exceeded, SSP automatically creates a library extent somewhere else on disk, which again has a fixed size. Only one such extent can exist for each library.

There are four types of S/36 library members: source, procedure, object and subroutine. Of these, the first two can be edited directly by the user, while the last two must go through a compiler.

AS/400 libraries are somewhat different. They, too, have a name and a directory, but do not have a fixed size, and their components do not have to be in contiguous disk space. The size of the library object does not include the size of the objects contained therein. This last difference is of primary importance, and you should remember it when you read the size of a library: all you are reading is the size of the directory -- not the sum of the sizes of all the library objects.

On the AS/400, all objects, including files, are contained in libraries. This is an entirely new concept for S/36 users, who are accustomed to thinking of files as separate entries in the disk catalog, entirely unrelated to libraries.

Among the objects contained in an AS/400 library, is a type of file known as a source physical file. These files are made up of members which contain the source code for your programs, display formats, menus, procedures and so on. Remember this in the rest of the article: libraries have source physical files, which in turn have source members. It is a three-step hierarchy. In the S/36 environment, you have two source physical files: QS36SRC for "source members" and QS36PRC for "procedure members." In the native environment, it is customary, but not required, to have different source physical files for DDS (QDDSSRC), commands (QCMDSRC), CL programs (QCLSRC), RPG programs (QRPGSRC), and so on.

Condensing Libraries and Allocating Space

It may seem like an odd starting point, but let's talk about the CONDENSE procedure and the ALOCLIBR procedure. CONDENSE is used in the S/36 to reorganize all the space that has been allocated to a library, so that all the members occupy consecutive locations on disk, leaving all unused space at the "end" of the library. If a library extent exists on disk, it is merged with the library itself if there is room.

Because the AS/400 library is only a named directory of objects, the system does not really care where the components are on disk. For this reason, then, the CONDENSE procedure performs no action at all on the AS/400 S/36E; if encountered in a procedure or executed from the keyboard, the system will do nothing at all. By the same token, ALOCLIBR is equally meaningless on the AS/400 and is treated as a do-nothing procedure.

Creating, Renaming and Deleting

SSP uses the BLDLIBR procedure to create a library on disk. When you run BLDLIBR you must specify the name and the size of the library, but all other parameters are optional: directory size, preferred disk spindle, and all the diskette/tape paraphernalia that will be covered in a future installment of "Going Native".

OS/400 uses the Create Library command (CRTLIB) for the same purpose. When you create a library you are required to indicate the name of the library and nothing else. Optionally you can specify type (*PROD or *TEST -- the default is *PROD), text (a brief description of the library), public authority (which defaults to *CHANGE), and the auxiliary storage pool (ASP) number.

The distinction between *PROD (production) and *TEST (test) libraries is small, but important. Database files contained in *PROD libraries cannot be opened for update if the user is in debug mode with protection of database files. *TEST libraries, on the other hand, pay no attention to this detail.

The 50-character text is an optional parameter, but I urge you to treat it as mandatory. Try to get into the habit of entering a descriptive text for all objects you create. This text appears every time you list objects of any kind, and it will help others (and you, too) understand the purpose of the objects. Libraries are no exception.

The public authority parameter defaults to *CHANGE, which means that unless otherwise indicated, all users are allowed to add, update or delete directory entries. Unless you are in security level 30 this parameter means very little to you.

Finally, the ASP number parameter similar to the BLDFILE parameter that accepts the name of the disk spindle (A1, A2, A3, A4, or block number). The default value is 1, and unless you are creating a very specialized library and you have defined other ASPs, you should leave it that way.

RENAME changes the name of a library, and its exact equivalent is RNMOBJ (Rename Object) for object type *LIB (library). For example, RENAME MYLIB,YOURLIB can be translated into native as RNMOBJ OBJ(MYLIB) OBJTYPE(*LIB) NEWOBJ(YOURLIB).

DELETE is used to delete a library on the S/36, and it translates exactly as DLTLIB (Delete Library). However, you should know that although the S/36 DELETE procedure takes a second to run, the AS/400 DLTLIB command can take considerably longer, since it not only deletes the library directory, but all the objects contained within it. Contrast this with the S/36 DELETE, which only erases the VTOC entry for the library.

Listing a Library

The LISTLIBR procedure has three separate uses. It can be used to print the status of a library (space allocated and remaining, number of members, and so on), to print a list of members, or to list the member. Let's review each one in detail.

The closest equivalent I can think of for the library status function is the DSPOBJD command. This command gives you the size of the object (in this case, the size of the directory) among other things.

If you are interested in printing the directory of a library, you should use the DSPLIB command, which can send the output to the display or printer. If you send it to the printer, OS/400 will give you the total size of all objects in the library. Either way, you should remember that because AS/400 libraries are different, you will not see the list of source members when you run DSPLIB; it will give you the names of all the objects contained in the library, some of which are source physical files such as QS36SRC (source members) and QS36PRC (procedure members). In order to list the members, you must use the DSPFD command with TYPE(*MBRLIST).

For example, if you wanted to list all your procedure members in library MYLIB, execute the following command:

 DSPFD FILE(MYLIB/QS36PRC) + TYPE(*MBRLIST) + OUTPUT(*PRINT) 

If you change the OUTPUT parameter to OUTPUT(*), as it is by default, the list of members will be displayed instead of printed.

To list a source or procedure member, use the CPYSRCF command with TOFILE(*PRINT); that will send the listing to the printer and, unfortunately, there is no way to send it to the display instead. On the S/36 at least you could do a SYSLIST CRT before running LISTLIBR. For example, to list procedure PROCA in MYLIB, execute the following command:

 CPYSRCF FROMFILE(MYLIB/QS36PRC) + TOFILE(*PRINT) + FROMMBR(PROCA) 

To list a compiled object (such as a program), use the DMPOBJ command. For example, if you ever executed LISTLIBR to print the hexadecimal gibberish that is an actual compiled program, you can still do so (and still get hexadecimal gibberish) like this:

 DMPOBJ OBJ(MYLIB/PROGA) + OBJTYPE(*PGM) 

Creating Duplicates of Members

One of the procedures most widely used by S/36 programmers is LIBRLIBR, which creates a duplicate of a library member and optionally gives it a different name. When followed by REMOVE, the LIBRLIBR is often used to move a member from one library to another.

On the AS/400, you use the CPYSRCF command to copy source or procedure members. For example, suppose you want to write program PROG2 which is an almost exact replica of PROG1. The AS/400 can do this as follows:

 CPYSRCF FROMFILE(MYLIB/QS36SRC) + TOFILE(MYLIB/QS36SRC) + FROMMBR(PROG1) + TOMBR(PROG2) 

If the member you are copying is a compiled object, you must use the CRTDUPOBJ command instead. If PROG1 were a compiled program and you wanted to create a copy in another library, you would proceed as follows:

 CRTDUPOBJ OBJ(PROG1) + FROMLIB(MYLIB) + OBJTYPE(*PGM) + TOLIB(YOURLIB) 

Optionally you can give it a different name by adding the NEWOBJ parameter, as in:

 CRTDUPOBJ OBJ(PROG1) + FROMLIB(MYLIB) + OBJTYPE(*PGM) + TOLIB(YOURLIB) + NEWOBJ(PROG2) 

Changing the Name of a Member

SSP did not always have the CHNGEMEM procedure. I remember the days when one had to use LIBRLIBR, followed by REMOVE, in order to rename a member. When CHNGEMEM was made available (I forget with which release), I discovered that it let you change not only the name but the subtype and reference number.

Changing the name of a library member is pretty straightforward on the AS/400. For source or procedure members, you use the RNMM command; for compiled objects, the RNMOBJ command. Examples to replace a procedure and a compiled program:

 RNMM FILE(MYLIB/QS36PRC) + MBR(PROC1) + NEWMBR(PROC2) RNMOBJ OBJ(MYLIB/PROG1) + OBJTYPE(*PGM) + NEWOBJ(PROG2) 

On the AS/400 you can only change the subtype of source members. This is called "type" on the AS/400. There is no command to do it directly, but you can use SEU instead. Simply enter SEU for the source member in question and press F13 to change session defaults. Midway down the panel you will see the "source type," which you can change at will. When you exit SEU be sure to answer with a "Y" the prompt to change/create the member.

Moving a Member to Another Library

SSP does not have a means to move a member from one library to another; you must copy it first with LIBRLIBR, then use REMOVE to delete the original. OS/400 offers the MOVOBJ command to move compiled objects from one library to another. Source or procedure members still have to be copied first, then removed.

MOVOBJ is easy to use. To move PROG1 from MYLIB to YOURLIB, enter the following command:

 MOVOBJ OBJ(MYLIB/PROG1) + OBJTYPE(*PGM) + TOLIB(YOURLIB) 

Deleting Members from Libraries

Instead of using REMOVE to delete library members, you have to use the RMVM command to remove source or procedure members from the source physical file where they are located. To delete compiled objects you must use the various DLTxxx commands.

Examples: remove procedure PROC1, program PROG1, and display format member DSPFMT1 from library MYLIB:

 RMVM FILE(MYLIB/QS36PRC) + MBR(PROC1) DLTPGM PGM(MYLIB/PROG1) DLTF FILE(MYLIB/DSPFMT1) 

The last example may have given you a jolt unless you were prepared for it, right? On the AS/400, display formats are actually display files, and they are treated as such.

Stay Tuned to This Station...

Just for the fun of it, I will give you homework this time. I have explained how to manage libraries in native mode, but I have intentionally left out one item because there is no S/36 equivalent. Picture the following scenario: Your Accounts Receivable library (ARLIB) must be duplicated, ARLIB1 and ARLIB2, which will have almost identical members (the few exceptions are insignificant). How do you go about creating a duplicate of a library?

On the S/36, you run BLDLIBR to build the library followed by LIBRLIBR to copy all members from one to the other, right? The AS/400 needs only one command. If you know the command-naming scheme adopted by IBM, the answer will be obvious. If you do not know the naming scheme, pick up the CL Reference Guide (all five volumes) and dig it out!

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails