This chapter introduces the concept of a database and describes DB2/400, which is the database management system that's part of the AS/400. You'll get a general idea of how the AS/400 and its operating system, OS/400, are architected. You'll also get an overview of DB2/400 physical and logical files.
Databases and Database Management Systems
A database is a set of computer files for storing information that's used by a business or other organization. A typical business might keep information about customers and their orders, suppliers of raw materials, employees who work for the company, and so on. Storing this type of information in computer files provides for easy retrieval and updating, as well as flexible analysis of the raw data to produce management reports, such as sales trends or average employee benefit costs. Of course, how "easy" and "flexible" it is to work with the data is largely determined by how well the database has been setup and the capabilities of the database management system (DBMS), which provides the software to create files and retrieve and update file contents. In this chapter, we'll look at the building blocks of the DB2/400 database management system that runs on IBM AS/400 computer systems.
DB2/400 is an integrated part of OS/400, the AS/400's operating system. That means you don't have to buy it as a separate software product, and any AS/400 application you write can take advantage of DB2/400 features. Figure 1.1 shows a simplified view of how DB2/400 fits into the AS/400 architecture. As you can see, DB2/400 provides a layer that all high-levellanguage (HLL) programs — i.e., RPG IV, COBOL, C, and C++ — use to access application data. You can also see that all utilities and remote applications must go through DB2/400 to access data on the AS/400. This integrated, uniform interface provides a high degree of consistency and control for AS/400 application developers.
If you're familiar with other operating systems and DBMS products, you'll find that DB2/400 has features of both conventional operating systems' file management facilities, as well as features of relational DBMS. For example, like a conventional file management facility, DB2/400 lets you use built-in HLL I/O operations, such as COBOL's Read and Write verbs, to access data. You can also access the same data using Structured Query Language (SQL) the way you'd do with other relational DBMS products. The "dual" nature of DB2/400 is even expressed in the nomenclature — files and fields are also referred to as "tables" and "columns" when you work with SQL/400, the DB2/400 version of SQL.
OS/400 Objects, Libraries, and User Profiles
Since DB2/400 is an integral part of OS/400, it helps to have a general understanding of how OS/400 is organized and where DB2/400 fits in. Everything in the OS/400 operating system, including the database, is organized as objects. Examples of OS/400 objects are programs, database files, user profiles, message queues, and about eighty other types of objects. Like other operating systems (e.g., UNIX), OS/400 stores program instructions, application data, and other system components on disk, loading them into main memory as needed. But, unlike most other operating systems, OS/400 doesn't let you get at the bytes on disk or memory directly. Instead you must always use specific commands or other system interfaces that are valid for each type of object. For example, you can't execute a database file or perform a file update operation on a program object. As we progress through DB2/400's capabilities, you'll learn about various types of OS/400 objects and the way to use them.
OS/400 controls how you use an object by storing some descriptive information along with the actual content of the object. Figure 1.2 depicts the storage (disk or memory) for an OS/400 object. As you can see all objects have a header, the object-specific contents (e.g., program instructions or file data), and an area known as the associated space where system or user programs can store miscellaneous data related to the object.
All objects have at least the following information in the standard part of their header:
An AS/400 library is an object that contains other objects. You can think of an AS/400 library as a UNIX or MS-DOS directory or a Windows 95 folder, except you can't nest AS/400 libraries as you can directories or folders — that is, a library can't contain another library object.
AS/400 object names are generally up to ten alphanumeric characters, beginning with a letter or national character ($, #, @ in the US), e.g., CUSTOMER might be the name of the customer master file. Libraries also have names; for example, you might use APPDTA as the name of the library that contains your production application data files. An object's qualified name is the combination of the name of the library that contains it and the object's (unqualified) name, separated with a forward slash. For example, APPDTA/CUSTOMER could be used as the qualified name of the customer master file.
We've already discussed the notion of object type, and on the AS/400, each object type is designated by a special value, such as *PGM for program and *FILE for file. Some object types are further broken down into subtypes. The *FILE object type, for instance, includes physical files, logical files, printer files, display files, and communication files — which are all kinds of record-oriented sources or targets for external program data. In this book, we'll use the term "file" to mean a database file (i.e., either a physical or logical file). When it's necessary to refer to another kind of file, we'll use an unambiguous term, such as "printer file."
An OS/400 object is uniquely defined by the combination of its qualified name (library and object names) and its object type, which means OS/400 allows only one object on an AS/400 that has a given combination of library, name, and object type. As a result, you can have a CUSTOMER *FILE object in the APPDTA library, and another CUSTOMER *FILE object in the TSTDTA library, but you can't have two files with the same name in the same library. Although you can have two objects with the same name in the same library, as long as they aren't the same type, it's not good practice because of the potential for confusion. Generally you should give unique names to all the objects in the same library, regardless of their types.
Each OS/400 object is owned by a user profile — another type of OS/400 object. Each user profile stores information about a system user, including the user's name, password, and authority to access data or use system functions. Whenever you sign on, you supply a user profile name and password, and this lets OS/400 control your use of the system, including access to the database. Chapter 18 covers database security in more detail, the main thing to know as you learn about creating and accessing files is that each file object has a user profile designated as its owner and all access to the database is controlled based on the authority granted to one or more user profiles.
Files, Record Formats, and Members
In studying DB2/400, we'll spend a lot of time talking about database files. In simple terms, a database file is a named collection of records. In a typical example (see Figure 1.3), the CUSTOMER file would contain a record for each of the company's customers. A record is a collection of fields, which are named items of data, such as CUSTID (customer ID) and NAME (customer name) that represent attributes of some item (e.g., a customer) of interest to the organization.
An OS/400 file object contains the object header information discussed previously. For files, this header is often referred to as the file description, and contains (among other things) a description of the file's record format. A record format is the byte-by-byte layout of all the fields in the file's records. Figure 1.4 depicts a simple record format for the CUSTOMER file. (Some kinds of logical files, which we discuss in the next section have multiple record formats.)
You can organize the data in a particular file into one or more file members, each with its own member name. Single-member files are the most common organization you'll encounter in AS/400 applications, and typically the one member has the same name as the file (and, of course, holds all the file's data). In some cases, however, a file might have multiple members. For example, a SALE96 file, which holds sales records for 1996, could have twelve members: JAN, FEB, ..., DEC, with each member containing the sales records for a single month. Members can be added to or removed from a file at any time; you don't have to specify a fixed number of members when you create a file. If a file has multiple members, they all have the same record format(s), as specified in the file description.
Physical and Logical Files
There are two types of DB2/400 files: physical and logical files.
Physical files are where you store application data. DB2/400 takes care of low-level details such as reading and writing disk sectors. Application programs and database utility programs see the data in a physical file member as a sequence of records, as in Figure 1.5. Each record occupies a unique location in a member, and the records are not necessarily in any order based on their content. A record's location is identified by its relative record number (RRN), which starts at 1 for the first record in the member and increases by 1 for each location. When you delete a record, DB2/400 sets on an internal "deleted record" flag in the record's location. When you insert a new record, DB2/400 puts it either in the first available location with a "deleted record" flag set, or after the last record in the file.
A physical file always has just one record format, and all records in the same physical file (regardless of how many members the file has) have the same record layout. For most business applications, the record layout is a fixed length, although DB2/400 does support variable length records, as well.
Logical files provide an alternative way to access data in one or more physical files. Here are some of the things you can use a logical file for:
File and Field Descriptions
One of the things that distinguishes DB2/400 from a traditional operating system file management facility is that every DB2/400 file contains a description of itself. The file description contains the following items (as well as other information):
AS/400 HLL compilers (which are all written by IBM) read the file descriptions for any files you declare in your programs. AS/400 HLLs have extended I/O-related statements that take advantage of the fact that the compiler has this file information. For example, you don't have to declare a record layout in your RPG input specs or your COBOL Data Division — with the appropriate file declaration in your program, you can have the compilers do that automatically. As another example, the compiler can automatically use the correct fields for keyed record access (e.g., by customer number) based on the key field(s) you define for a file. In addition, utility programs such as report generators can use file descriptions to determine a file's layout and keyed sequence (if any) without requiring the end-user to enter anything other than the file's name...
Alexey22
Posted Sat Jun 04 00:00:00 EDT 2011
The condition of the book is good but not very good as it was written in a description. The cover page contains a signature at the center, brushed with a marker.
My mark is four of five. Just good, but not very good.
Overview