02
Sat, Nov
2 New Articles

AS/400 Basics

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.

TOM HUNTINGTON

Tom Huntington is Executive Vice President of Technical Solutions at HelpSystems, and has been with the company for nearly 30 years. He works with business alliances, acquisitions and large customer relationships and ensures that the HelpSystems software works with other major software and hardware vendors worldwide.

Tom often speaks on enterprise scheduling, security, automation topics, IBM i technology, and the HelpSystems products, and hosts technical presentations on a variety of automation topics. He is the author of the HelpSystems IBM i Marketplace Survey and has written articles on automated operations, security, cloud computing, and business intelligence for leading trade journals and newsletters. He was named an IBM Champion in 2016, 2017, 2018, 2019, and 2020 for over three decades of advocation and thought leadership on the IBM i platform.

Contact Tom at This email address is being protected from spambots. You need JavaScript enabled to view it..


 

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: