Objects

The i5/OS architecture supports a great variety of objects. Each object has a type identifier. The type identifier always begins with an asterisk and is followed by an abbreviated name, such as PGM for program. Therefore, the object type for a program is *PGM.

The use of strongly typed objects is one of the strengths of i5/OS. On many systems, no mechanism is available to prevent a program from opening a file of binary object code and altering it because, to these operating systems, a file is a file is a file. Under i5/OS, a program cannot open a *PGM object as if it were a file. Needless to say, an i5/OS system does not have the high susceptibility to viruses that most other operating systems have.

The rest of this section only describes some of the most important object types, because far too many exist to describe them all.

Authorization List (*AUTL)

Authorization lists are objects you can create to simplify the maintenance of object authorities. You can learn more about them in Chapter 13. All authorization lists must exist in QSYS.

Command (*CMD)

Commands are objects used to give an order to the system. When the system receives the command, it starts a particular task. All commands have an associated program object (*PGM), called the command processing program, which is the object that actually performs all the work. The command object acts as an interface between the user and the program.

Controller Description (*CTLD)

Controller descriptions must reside in QSYS. These are objects (such as a local workstation controller) that describe a controller device to the system.

Device Description (*DEVD)

Device descriptions must reside in QSYS. These are objects that describe a physical (although sometimes logical) device to the system. For example, when you configure a new printer, you create a device description for that printer. A user must have *CHANGE authority to a device description to be able to sign on to an interactive session at that device.

Data Area (*DTAARA)

Data areas are objects you can create to store small bits of information that are not repetitive in nature (a file would be overkill). Think of a data area as a file that has only one record. They are ideal for storing constants, such as report titles and headings, or company names that could change someday.

Data Queue (*DTAQ)

Data queues are similar to data areas, except that they can contain multiple entries, which are known as messages. Data queues are the most efficient way to pass information between two programs. Data queues can be accessed by many programs at once. Some programs may be writing data and others may be reading it. The main difference between a data queue and a file is that a file may have an internal record structure known to the system (via DDS or SQL), while a data queue has no structure at all. Also, records in a file can be read any number of times, but data queue messages are deleted by default when they are read.

File (*FILE)

Files come in several subtypes, but all have something in common: They can contain many entries ("records"). The records remain until intentionally deleted, and the records have a template that defines data items ("fields"). Database files are ideal for the permanent (or at least longterm) storage of information. The file subtypes are:

• Physical database files. These are normally thought of as "files." They are permanent, and they contain data.

• Physical source files. Source files contain the source code for programs, file definitions, and commands.

• Logical files. Logical files are alternative views of physical files (either database or source). By view, the system means a different sequencing of the records or a different selection of records (with some records omitted).

• Device files. Device files describe the data passed for input and output between the system and a physical device, such as a display station or a printer. If the device file describes a display station, it is often called a display file. If the device file describes a printer, it is usually called a printer file. Diskette files and tape files also exist.

Job Description (*JOBD)

Job descriptions are objects used to provide a set of attributes to a job that is about to begin. When you submit a job to batch, for example, you can attach a job description that provides the submitted job with settings such as a library list and a default output queue. Job descriptions are described in detail in Chapter 13.

Job Queue (*JOBQ)

Job queues contain requests for jobs that are waiting to run. When you submit a job to batch, the job must enter a subsystem (where the job's work is eventually performed) by passing through a job queue. The job may have to wait in the job queue for its turn to start. The system can have any number of job queues, and job queues may bring jobs to the subsystem in a single thread (one job at a time), or in groups of any size.

Journal and Journal Receiver (*JRN & *JRNRCV)

Journaling is a task that records events in journal receivers. Any event can be journaled but, in most cases, it is a database file operation such as adding or changing a record. These events must go through a journal object. The journal channels the recording of the event into one or more journal receivers. Journaling is described in detail in Chapter 15.

Library (*LIB)

Libraries are containers of objects; they are just another type of object to the system.

Line Description (*LIND)

Line descriptions are objects used to describe a telecommunications line to the system. All line descriptions reside in QSYS.

Menu (*MENU)

Menus are objects used to start activities by selecting one of the options presented on the screen.

Message File (*MSGF)

Message files are not *FILE objects, but objects of type *MSGF. You cannot store data in them or use them to pass data between a program and a device. Message files can only contain message descriptions, which are predefined messages with a fixed text and characteristics. The most important message file is QSYS/QCPFMSG which contains all the operating system's messages.

Message Queue (*MSGQ)

Message queues are repositories of messages that are waiting to be received by the user to whom they are destined. The system automatically creates message queues for user profiles, but you can create your own.

Module (*MODULE)

A module is a unit of machine language that cannot be directly executed by the operating system. ILE (Integrated Language Environment) imposes the creation of modules from language-specific source code, which must be bound together into a program before they can be executed.

Output Queue (*OUTQ)

Output queues are repositories for reports that are waiting to be printed. They are described in detail in Chapter 14.

Program (*PGM)

Programs perform work. Programs are created by a compiler when you run the compiler on a source member that contains no syntax errors. Programs are all in machine language. The source code (contained in source files) is written in languages like RPG, CL, COBOL, C, or Java.

Panel Group (*PNLGRP)

Panel groups are objects used to present information on the screen. They are similar to display files, but have a different structure and somewhat different uses. All IBM-supplied displays (except for a few) are panel groups.

Subsystem Description (*SBSD)

Subsystem descriptions are objects used to describe a subsystem. A subsystem is the place where work is performed. The subsystem (as controlled by the subsystem description) allocates resources and manipulates system objects to carry out the work intended for the jobs.

Service Program (*SRVPGM)

A service program is a collection of "utility"-type modules, each of which can be statically called from any program or module.

User Profile (*USRPRF)

User profiles describe computer users. These were described in detail in Chapter 13. They must reside in QSYS.