Price: $85.95 - $73.27
(as of Apr 13,2023 03:57:26 UTC – Details)
Communicating with the System
Overview
The IBM i operating system (OS) is one of the most sophisticated on the market today. To a new user, the apparent complexity may seem like a huge jigsaw puzzle waiting to be solved. What we hope to provide with this first chapter is simply a place to start collecting critical pieces of the puzzle.
This chapter provides initial exposure to several topics necessary for a basic understanding of how to communicate with the IBM i OS using the different types of screens and menus. The chapter also introduces concepts related to system organization and a few basic work management ideas (e.g., how jobs enter, run in, and leave the system).
As in any other technical field, you will need to master a number of terms and concepts to be successful using the OS. Although the IBM i OS will provide comprehensive help as you learn, you are strongly encouraged to ask questions of your instructor or mentor.
Objectives
Students will be able to
• Sign on to the IBM i OS system, properly entering a user profile and password
• Explain the difference between system and subsystem
• Describe the two most common types of jobs
• List several attributes of a user profile
• List several features of the IBM i OS
• Explain the function of IBM i Control Language (CL) and enter a CL command on a command line using proper syntax
• Explain the purpose of system values and how to check them
• Describe four types of displays, their use, and their components
• Explain the relationship between CL commands and IBM i OS menu paths
The System
The IBM i OS is a complex and rich set of programs that not only controls traditional functions such as data access, storage, and task management but also incorporates features that normally would require separate software components on other systems — features such as communications support, database management, security, and interactive support.
A new system running IBM i OS comes with a standard basic configuration, which includes predefined system settings for work management functions that allow interactive and batch jobs to run without need for a customized installation. Later, subsystems can be created and system resources allocated to optimize workload distribution and throughput according to the special needs of a particular business.
IBM i is a multiuser, multitasking OS (a system on which two or more people can perform two or more tasks concurrently) optimized for the efficient execution of business applications. The basic unit of work is a job. The term job refers generally to a unit of work that includes all programs, files, and instructions necessary to perform that work. Examples of a job would be an interactive user session for updating a customer master file, or a program compilation running unobtrusively in the background.
The older IBM AS/400 systems used terminals and hardwired (twinaxial, or “twinax”) connections to access the system. Today, most users connect to the system using 5250 emulators or Web interfaces. In this book, we present a number of ways to connect to the system, including 5250 emulators, Remote System Explorer (RSE)/Rational Developer for Power (RDP)-based, and IBM i Access for Web and Access for Windows. The IBM i OS has evolved to become one of the most advanced OSs available today.
IBM I Objects
The IBM i OS is an object-based OS. An object is anything on the system that has a name and takes up space in storage. IBM supplies a large number of objects through the IBM i OS and licensed program products. These objects typically have names beginning with Q. Programmers and operators create other objects and name them according to their organizations’ naming conventions.
The system can locate an object by its name; once located, the object can further identify itself to the system by functional attributes that are a part of the object. Objects are grouped into types. An object type determines how the object is used on the system (i.e., the actions that one can take when using the object). Common object types include programs, files, and commands. Object types also include user-profile objects, which contain information about users, and subsystem-description objects, which contain the characteristics of subsystems. Object type is always assigned by the system and is determined by the command used to create the object. We continue to explore this concept of objects throughout this book.
Subsystems
All jobs in the IBM i OS are run in subsystems. A subsystem is a predefined operating environment the system uses to coordinate workflow and system resources. The system uses a subsystem description to define the required resources to process work. The components of a subsystem description determine how the system uses resources to process jobs within the subsystem. When the base IBM i OS is installed, several different subsystems are already defined and active, and each one has a separate subsystem description.
Attributes of subsystems are defined in the subsystem description; these include the subsystem name (e.g., QCTL for the controlling subsystem, QINTER for the interactive subsystem, QBATCH for the batch subsystem), how many jobs can run in the subsystem at one time, which storage pools the subsystem will use (IBM i main storage is divided into a number of different storage pools), and which job queues the subsystem will use.
Different subsystems are necessary because there are many different types of jobs with different characteristics and often-conflicting needs. If we treated all of these various jobs equally, the overall performance of the system would suffer. As system administrators, we can change the existing subsystem descriptions and create new subsystems when necessary. In this way, we can tailor subsystems to efficiently handle the needs of different jobs — for example, to ensure that long-running jobs that require no user interaction but significant CPU time do not interfere with high-priority interactive jobs that need fast response time. Within subsystems, we can prioritize individual jobs to begin execution sooner or later; and, after they begin execution, we can give them a higher or lower runtime priority.
Types of Jobs
IBM i OS jobs can originate from several sources and are classified by how they originate on the system. In this course, and in general, you will deal mostly with two types of jobs: interactive and batch.
An interactive job begins when a user signs on to the system, and it terminates when the user signs off the system or the job is ended. Interactive jobs run in conversational mode, which means there is a dialogue of sorts between the user and the program, utility, or OS function. Because of this conversational, back-and-forth nature of interactive jobs, any CPU- or I/O-intensive request a user makes could lock up the workstation keyboard until the request is completed. Therefore, it is often advisable to direct such requests to a subsystem designed to handle them — that is, to submit them as batch jobs.
Batch jobs can execute without user intervention; they do not require data or controlling values to be input through the workstation once they have started. Batch jobs are sent to a job queue until they can begin execution. A job queue is a staging area, managed by the subsystem in which the job will run, where batch jobs wait in line for their turn at processing. Each batch subsystem can execute only a limited number of batch jobs concurrently. If no other higher-priority jobs are waiting, a batch job can start right away; otherwise, it must wait its turn.
Typically, you would submit as a batch job a report program that reads many records from a database file and performs standard calculations written into the logic of the program. Once the program is submitted, it requires no input from the operator or requester of the report. If the program were run interactively, the direct-access storage device (DASD, or hard disk), access time required for the large file would be substantial and could cause the program to run for an extended period, tying up the workstation until program execution was completed.
In addition, to minimize disruption of workflow, programmers can pack up and send off as batch jobs certain tasks they encounter during a normal interactive session. Consider a programmer in the midst of an interactive session who needs to compile a large program for testing. If she runs the compile as part of an interactive job, she will be locked out of the system during the several minutes it may take to complete the compilation. If other tasks on the computer need attention, she could submit the compilation as a batch job from within the interactive job. Then, while the compilation runs in a batch subsystem, she could go on to other tasks.
Control Language (CL)
For all its complexity, one of the more remarkable things about the IBM i OS is that it provides a single, consistent user interface to its various functions through Control Language (CL) commands.
IBM i OS CL is flexible and powerful and allows direct access to IBM i OS functions. More than 2,000 individual CL commands are available. Each individual command is an OS object. Most CL commands consist of a command name and one or more command parameters. A command parameter is a value, specified along with a command, that controls and limits the operation of the command and names the files, programs, or other objects the command will work on. Individual commands can be entered on a command line (a line beginning with the symbol ===> that appears near the bottom of certain types of display screens), or they can be grouped together into a CL program to perform a specific task. Such a program can then be compiled and run from a command line or from within a high-level language (HLL) program (e.g., RPG, COBOL, C, or C++).
If you are a new user, you don’t need to memorize a large number of CL commands because most IBM i OS functions are available to interactive jobs through the menu interface of IBM i. As you choose a series of menu selections, the system determines the CL commands to be run to satisfy your request.
System Values
System values are control and configuration attributes that let you customize certain OS functions. System values define critical aspects of the environment and the general rules that all jobs on the system must follow. System values are not objects, but they describe characteristics of the system that can be displayed, or in many cases changed, with CL commands. Many system values come preset with the OS; others need to be set when the system is installed. The categories of system values include the following:
• Allocation values (Type=*ALC) — These values let you control the number of active jobs and how much main storage will be used for different functions necessary to run jobs.
• Date and time values (Type=*DATTIM) — These values let you set and change the date and time the system keeps and makes available to application programs and utilities.
• Editing values (Type=*EDT) — These values control how dates, decimal values, and numbers involving currency symbols are formatted.
• Library-list values (Type=*LIBL) — These values define the system library list and initial user library list. A library list is an ordered group of libraries a job uses to search for objects it needs for processing. A library is a directory of related objects.
• Message and logging values (Type=*MSG) — These values control how the system handles and records certain types of messages.
• Security values (Type=*SEC) — These values control certain aspects of security, such as the maximum number of invalid sign-on attempts allowed.
• Storage system values (Type=*STG) — These values define the minimum size and activity level (number of active jobs) of the base storage pool.
• System control values (Type=*SYSCTL) — These values let you define or obtain certain controlling values of the OS, such as operator console name, user assistance level, and date and time to automatically IPL the system. (An IPL, or initial program load, is the IBM i version of a “boot” process, which loads the OS when the power is turned on.)
Most users can display current system values, and, when necessary, authorized users can change these values. This capability to customize system values for a particular job environment can lead to a more efficiently running system. In the lab for this chapter, you learn how to examine system values.
Licensed Programs
Besides the IBM i OS, several software components available from IBM extend the functions and capabilities of the system and let installations tailor the system to the type of work and the communications environment they need. These software components are licensed program products. A few licensed program products are shipped with all IBM i systems at no additional cost. But for the most part, licensed program products are chargeable; the actual cost usually is determined by the size of the system and the number of users who have access to the product. Most of the licensed program products fall into one of several categories:
• Application development tools — This group of programmer utilities greatly expedites the application development process. Recently, IBM has brought its software tools under the Rational brand. Rational Developer for Power (RDP) is a set of GUI-based tools designed to replace traditional 5250 tools such as Source Entry Utility (SEU), Screen Design Aid (SDA), an interactive file-update utility called Data File Utility (DFU), and a programmer’s workbench suite called Programming Development Manager (PDM). The Rational Business Developer product includes support for Web development. These two toolsets can be used together to give the developer a rich set of tools. In Chapter 11, we will cover Rational Developer tools for IBM i.
• Communications support — This category consists of the many System i Access for Windows (formerly known as Client Access or PC Support) programs that let IBM i connect programmable workstations (PCs) through various PC OSs, including Microsoft Windows. In Chapter 10, we cover System i Access for Windows in depth and in Chapter 13, IBM i Access for Web.
• Programming languages — Traditionally, IBM i systems have supported a number of programming languages by making compilers available as licensed programs. In the past, Basic, FORTRAN, Pascal, and PL/I were supported, but current and future compiler support will be targeted at ILE RPG (RPG IV), C, C++, COBOL, and Java. In addition, Structured Query Language (SQL) is available through the DB2 Query Manager and SQL Development Kit.
• Web products — These include IBM i Access for Web, IBM HTTP Server for IBM i OS, and WebSphere Application Server products; and as of V6R1, IBM is shipping Zend PHP and MySQL with the IBM i OS.
Some other licensed program products that do not fall clearly into any of the above categories provide services such as automatic routing, IBM Backup Recovery and Media Services for IBM i OS (BRMS), Performance Tools, and double-byte character support for ideographic languages such as Chinese, Japanese, and Korean. In fact, there are many more such products designed to extend the versatility and usefulness of the IBM i OS.
You can see which licensed programs are installed on your system by going through the Work with Licensed Programs (GO LICPGM) menu.
User Profile
When we refer to a user, we mean any person who is signed on to the system. This may include students, programmers, data-entry personnel, operators, and administrators. To perform work, a user needs to be defined on the system. A user is defined to the system when a security officer or administrator creates a user profile object for that user. A user profile not only identifies a user but also describes the user’s authority and is the source of several operational characteristics of that user’s job.
Later, we examine user profiles in more detail and see that they contain defining information; for example, a user’s profile contains the following:
• User class, such as casual user, programmer, operator, or security officer.
• Special authorities, such as job control, the capability to save system software, or the capability to create or change user profiles.
• Initial program, or the program to be run when sign-on is completed.
• Initial menu, the first menu the user sees after sign-on.
• Current library, the first user library searched for objects the user has requested.
(Continues…)Excerpted from Mastering IBM i by Jim Buck, Jerry Fottral. Copyright © 2011 Jim Buck and Jerry Fottral. Excerpted by permission of MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Understand traditional methods of working with the system as well as newer methods such as SQL
Update your skill set by learning how to use IBM’s latest graphical tools and methods
Gain a solid foundation for more advanced programming studies such as CL and RPG
