IBM iSeries
Systems Operations &
Administration
Why this course
The author and some course development background
My name is Doug Stevens and I am the author of this instructional material. Technically I have been authoring (not sure that is a word) this course since the early 90’s. I had been engaged by a large grocery retailer to train some of their lead operational ‘mainframe’ personnel in the operational characteristics of an IBM AS/400.
Initially, it wasn’t anything special and not much different than meeting up with a study group 3 times a week to go over some topics of interest to everyone. After the first few weeks of this ‘study group’ approach it became apparent that something was definitely missing.
We had covered all of the basic ‘food groups’ for any AS/400 technical discussion such as security, subsystems, jobs, user profiles and spooling. Each of these topics was discussed from a architectural perspective, from outside looking in. After having worked in the AS/400 environment since 1979, that was the easiest approach for someone like myself. In spite of the multiple hour long discussions and dry-erase board diagram sessions none of the material had made any real connection with the audience. I knew this from the
response I received when starting each group session with a summary of what had been discussed previously. There were some obvious gaps and a surprising loss of content.
Why this course
Audience ability to absorb information - rate of retention
I was disappointed in my inability to convey the information in an interesting and useful manner such that it would be retained and ultimately applied by the audience.
The learning audience was not exactly junior apprentice types. They were experienced mainframe operational personnel, some with more than 20 years of experience in their area of expertise.
I tried to change things around a bit and after some structural modifications in how the material was presented some improvement in retention was observed. We had turned our sessions into practical demonstrations using one of their test AS/400 servers. This ‘demo’ approach had the immediate effect of getting everyone’s attention. At least for the first few minutes anyway.
It turns out that most people learn by visualizing something within context of something familiar. In this case each person was familiar with a command line interface (CLI). They were also comfortable with issuing commands and waiting for responses to those
commands.
Finally, after narrowing the focus of the subject material to specific operational tasks I was able to bring the training course to a logical conclusion after several more ‘demo’ sessions with a practical exam as the final session.
Why this course
Search for a better way to communicate knowledge
Most members of the learning group did come away with a better understanding of the AS/400 and some were able to begin applying what they had learned to their new
assignments in the AS/400 operations area. While their learning experience had not exactly worked out to a completely satisfactory result, I on the other hand had learned quite a bit.
First, a clever speaking style and an engaging personality does not make up for a lack of meaningful content in any course.
Secondly, the lack of meaningful content, in context, makes no demands on the learning audience to become engaged in the learning process.
Thirdly, a disengaged learning audience does not acquire knowledge, in fact they are no longer an audience.
Armed with these observations I began a search for a more effective way to present and instruct operational/technical information. This research led to the then emerging science of instructional theory and the design of ‘e-learning’ courses. There are some serious
heavyweights in this area such as Ruth Colvin Clark or Richard E. Mayer both of whom have authored many books and papers in this area.
Why this course
Theory versus applied science
It wasn’t exactly a full time effort and did require some searching around. I eventually pulled together some guiding principles and fundamental theories about how people learn stuff, not just technical things but anything.
Concepts such as cognitive outcomes, psychomotor outcomes and affective outcomes became part of my working vocabulary. I know this must sound overly inflated but when you look at the matrix¹ these concepts describe you will hopefully understand how
important each is to the learning process.
More importantly you will understand how difficult the learning process actually is for a learner. Understanding this process of ‘learning’ gives anyone writing a course of
instruction some boundaries and guidelines. Anything outside of those markers, no matter how well defined and documented, fails to move the learning process forward.
This is all about the learner and in this case for this course, the operator.
What does an operator need to know and when do they need to know it? The simple answer is that an operator must be well informed on the basic operational flow and work patterns of the iSeries server environment and must know how to respond to any event or issue arising from that flow or work patterns.
Why this course
Accidental knowledge from experience
An operator must have acquired this understanding of the basic operational flow and work patterns of the iSeries environment well in advance of being assigned the task of observing and managing the processing environment.
How exactly does an operator acquire this knowledge about the basic operational flow of the iSeries environment? When does an operator get exposed to and learn the work patterns of the business processing environment of the iSeries?
For all those who shouted ‘on-the-job-training’ please go back and sit down, we happen to agree with you, from today’s perspective anyway.
When first introducing an operator to a shop, it is still common practice today, in most shops, to equip them with a run book, a desktop PC running some type of emulation software and a copy of some routine business processing steps and procedures.
We expect that they understand how to sign on to the iSeries server and we have equipped them with an operator profile belonging to the operations group. We might have one of the senior shift operators hang around and ‘show them the ropes’ for a few hours, in fact we almost always do this just to make sure the place doesn’t go up in smoke entirely.
Why this course
Who is the operator
As someone with over 30 years of experience in the systems and programming area of the iSeries it seems almost intuitive that this approach would be the most logical direction for operator training.
After all most of our knowledge was gained from direct contact with the operating system, the hardware and various parts of the processing environment. Why wouldn’t this
approach work with an operator’s training?
Basically the situations are not equivalent and the context is entirely wrong for today’s operator.
Based on my experience and observation there are several different operator ‘types’. The entry level operator with technical skills, is at the beginning of his or her career in data processing. They want to ‘experience’ first hand what is happening in the world of business processing systems. Some have just graduated from high school and have
acquired a solid understanding pc-based processing, usually with an extensive knowledge of Linux and other 3rd or 4thorder languages and tools. They understand technical material,
can dance circles around most of the social networks and dissect a Shell script for Linux in under 30 seconds.
Why this course
A mixture of talent and experience
The entry level operator with light or no technical skills, can be anyone from any area possibly from within the company in another department. This could be someone wanting to change career paths or it could be someone from outside who expresses an aptitude for technical knowledge and just needs a step up on the ladder.
The practicing operator with several years of operational experience, is someone who has been in several different processing environments, survived one or more ‘disasters and has managed to keep a fairly complete set of notes about what not to do in certain situations. They may have been with your company over the stretch of their entire operational career or maybe they are a recent hire. This might be the stair climber on their way up the
technical ladder from operations to systems or programming. That is ok, you take advantage of that skill and knowledge while you have access to it.
The experienced operator with multiple years of heavy operational experience, is someone either on their way up to management, genuinely satisfied with their current situation or slightly confused on the merits of making any changes to their current employment picture given today’s unsettled economic picture. Whatever the reason, such a person is a valuable asset. They have developed a good understanding of the business processing environment and know the business groups that control the day-to-day processing schedule of the
Why this course
A goal setting process and what is not there
These days, with the mixture of processing environments it is important to know that our operational personnel can arrive in their current capacity from many different
backgrounds fitting in any one of these ‘types’.
One of my goals in designing this instructional material is to reach this diverse audience with as much useful information as possible.
Possibly one of your goals, if you are the manager of operations, is to retain your best
people. Many surveys are conducted each year in companies across the business spectrum, training comes in a strong 2nd or 3rd for job satisfaction.
Perhaps (we hope) one of your goals, if you are a potential learner, is to understand your knowledge and skill gaps. You must evaluate whether a course like this will improve those areas. Regardless of your experience level, it is my opinion that you will derive some
benefit from all of the chapters in this course.
One thing you should notice, we have not mentioned systems programmers, applications programmers, database designers, security administrators nor any of the other half dozen specialization areas within the iSeries environment. That is by design.
Why this course
A chapter by chapter review & new stuff
We follow with a summary or thumbnail sketch of each chapter in the course.
First a note
As a practical matter we do not intend that the last chapter be the last chapter. There are other chapters under development such as security, CL programming and BRMS.
Once you have subscribed to this course, as currently constructed, you are automatically given access to the new courses when they get introduced. We advise all enrolled learners when a new course arrives by email and automatically enroll them in the new course. I welcome you responses and comments. Please send them along to me at the following email address:
Unit – 01 - Heritage
Like anyone else of my generation, I grew up surrounded by the emerging world of desktop technology and midrange computers.
For many of us, a big part of that world was the IBM Rochester, Minnesota facility, the creators of the System/38, the AS/400 and the entire iSeries family of processors and systems.
What made that so special? Why is there something akin to an iSeries cult in some circles? Is it really 64 bits or just PR? What are some of the factors that weighed in to making and creating the IBM iSeries platform and why is the iSeries still considered an advancing technology and fresh today?
These are some of the questions anyone new to the iSeries will have. Maybe they won’t know very much at all about the platform and have no clue as to its origins. Perhaps it is a bit presumptuous of us to think they might really care.
However knowing what we know about the heritage of this amazing processing platform really does need to be shared with those of our community that have not had the same experience we have had.
That is what this chapter is intended to do.
Unit – 02 – Architecture – 5 elements
Anyone ever asks you what makes the iSeries a unique platform you can whip out this list of 5 elements and stun them.
Technology independence Object-based design
Hardware integration Software integration Single level store
So what is so unique about these elements? What are they and how do they work together in a system environment like the iSeries? Why are they important? What is the
significance of them versus some other attribute?
We all have questions about any environment that we are involved with. Windows, the latest iPad or the iPhone or the office Black Berry.
In the iSeries world we really do need to understand the architecture before we can begin to understand some of the rules and processes that we see used and implemented in this environment. This is what this chapter is intended for.
Unit – 03 – Architecture - the file systems
Everyone knows there are multiple file systems supported by the iSeries, correct?
Nope, not everyone really understands that fact. Possibly because it is so well integrated in the overall iSeries environment that no one really notices the differences or takes any
notice of the distinction made between one file system or another in the same operation system environment.
However, we know that there are currently 11 different file systems supported by the iSeries operating system.
Some are more frequently used than others such as the ‘root’ (/) file system, the library files system (QSYS.LIB), the document library services file system (QDLS).
Others, not so much such as the network file system (NFS) or the Netware file system (QNetWare).
Explaining to someone who has a single dimensional view of the iSeries environment that there are really several different file systems underneath becomes a very interesting task. It is important that an operator understand this structural reality. That is the intent of this chapter.
Unit – 04 –Architecture – the job
It seems that any discussion on work management starts out ok with some simple concepts and dialogue. Most of the time this reasonable pace quickly swirls around into a mashup effort describing everything about jobs, subsystems, job queues, priorities and routing steps, all in one breathless blur of pages.
We determined that it was best to separate out the job as a component of the system architecture. This allowed us to deal with the structural content of a job in more detail without getting lost in the larger stadium of work management.
The job is the most significant, self-contained, entity in the work management area. All things tend to come into focus with a job. More importantly it is how work is actually ‘defined’ on the iSeries.
As a managed entity a job becomes a focus of an operator when managing work in the iSeries environment. The various tools and commands they need to use revolve around the job and its attributes.
Understanding the job, the various types of jobs and where these jobs usually reside is a major piece of the puzzle for anyone trying to figure out the iSeries work environment. That understanding of a job is what this chapter is intended to provide to an operator.
Unit – 05 – Operations Interfaces – Menus & CL Commands
Understanding the structure of the operator interface is sometimes considered obvious or overlooked as a critical piece of the familiar routine.
Would it surprise you to know that most people with no exposure to the iSeries can quickly become acclimated to the basic operational interface by pressing one or two function keys? What are the command name structures, work with ‘WRK’, display ‘DSP’, start ‘STR’ and end ‘END’?
How does a menu environment work and how is it accessed? What are the most common commands used by an operator?
Orienting an operator to the command and menu environment that they work in is very important to long term survival. These would be the questions we ask and attempt to answer in this chapter.
This chapter also drives through a number of practical screens and displays demonstrating the use of various commands and menus. The practice effort builds some familiarity with each command and menu.
Unit – 06 – Operation Interfaces – Help facilities & keyboard
Knowing when, where and how to request help from the system is important. Using the extensive help and command prompted facilities of the iSeries can fill in a lot of
information about any condition, error, event, process or command that an operator encounters.
These help and command prompt facilities are often overlooked and underutilized. They provide an operator with extended textual explanations of each topic with further
references to external sources for more information as appropriate.
If looking through a job log for an active job they spot an error or event by pressing the F1 key they are provided with a detailed description of the condition or error.
When entering any command by pressing F4 with the command and thereafter for each parameter of the command they are given a step by step description of the command and each aspect of the parameters used by the command.
Unit – 06 – Operation Interfaces – Help facilities & keyboard (continued)
How many times have you seen an instruction advising the use of function key F14 and then turned to your keyboard only to see function keys F1 through F12?
Go ahead and admit it, when you first encountered this function key you wondered aloud on exactly how you would enter that key sequence. Of course by now most of us are
familiar with this ‘shifted’ keyboard operation (shift F2).
But the fact is that many operators new to the iSeries environment and keyboard interface will not immediately know to use a shifted function key.
We break down a few of the more important functional key strokes used in operations such as system request.
This is a general awareness chapter.
Unit – 07 – Operation Interfaces – the consoles & Client Access
Quick, how many consoles can an iSeries have? Ok, trick question, there can be only one console on any iSeries server.
The fact that there can be multiple different ‘types’ of console devices for an iSeries can be a bit confusing. These console types will have been sorted through and one selected by the team that installs the iSeries server initially.
That is just how it is these days. So what is an operator supposed to know and understand about a console device?
How is this display device any different than any other display device? What is an HMC and how is that defined and accessed?
What is IBM’s Client Access desktop suite of products?
What is the Client Access Navigator desktop application? How is it used by an operator? When might it be used?
We put some attention on these important interfaces and use some practical demonstrations for emphasis.
Unit – 08 – Messages & Message Management
Messages are the vocabulary used by all processes in an iSeries environment to talk with one another and the system.
As an operator observes and manages processing on the iSeries environment they will encounter messages in one form or another that arrive from every process in the
environment.
Some messages can be informational, job ending normally, processing started and so on. Other messages can be alerts indicating errors were encountered in a process or job. Some require intervention while others declare the process failed and has been ended.
Where do messages come from? How are they defined? Where are they defined? What happens when a message is sent by a job or process?
What is 1stand 2nd level text and how can that information help understand the condition
or meaning of the message?
These questions and more are asked and partially answered in this chapter. Some of the additional information needed to fully answer a question is derived from external research using the provided IBM manuals and notes.
Unit – 09 – Logs & Log Management
There are two main types of logs within the iSeries, the system log and the job log. We discuss both types and how they are maintained and managed.
QHST is the system log and is closely followed by operations since it represents the
activities or major activities taking place within the iSeries environment. More or less any message sent to the system operator message queue (QSYSOPR) will also be written to the QHST system log.
What are the various logging levels of a job and what is the importance of each logging level?
We walk through a number of scenarios that adjust the logging level of a job and then inspect the results of the job’s log.
We also discuss where most job logs reside in the system environment and why.
We walk through the operational view of the system history file QHST and discuss what we are going to see in this log file that pertains to the operational health of the iSeries server.
We also include a brief discussion of how some operational data can be derived from the history file using simple scan techniques to derive the jobs that have started or ended within a specific period of time.
Unit – 10 – Jobs & Job Management
This is part one of our work management discussion. This chapter describes and discusses jobs.
Jobs, what are their characteristics? What are you looking at when you perform a WRKJOB operation on a job from the WRKACTJOB display?
Each of those menu items is discussed.
What are the various job types? There are 8 job types within an iSeries environment. What are their unique attributes and functional roles in the overall scheme of things?
If you were ever asked what that particular job is, why it is running in the subsystem it is currently running in, how long does it normally run, who owns it?
This chapter will provide you with some of the answers to those questions.
Unit – 11 – Subsystems & Managing Work
This is the second part of our work management discussion. This chapter covers managing work from the point where it enters the iSeries environment.
The focus of this chapter is on how work takes place within an iSeries environment.
We break down the major processing environments in the iSeries known as subsystems. It is within the definition and use of a subsystem that work is allowed to materialize and be processed.
Understanding how subsystems perform this basic function is an important element of the operational role. We cover all of the major design points of any subsystem description and do close up review of some of the more important environments.
We discuss and review the major pieces of any IPL and how this process is controlled by a controlling subsystem and a startup program.
We review memory and CPU resources to see how they are directly affected and utilized by the resource statements included in a subsystem definition.
We discuss the normal alignment of memory and memory pools within any iSeries environment and how this alignment effects processing within the iSeries.
Unit – 11 – Subsystems & Managing Work (continued)
We develop the operational ‘walk around’ process and discuss the steps in the procedure to be used by the operator. Highlights include specific guidelines for thresholds of memory or CPU usage, server jobs that must be active and subsystems that must be started and running.
We take a close up review of all normally ‘required’ servers within an iSeries environment. We expand on the discussion of what should be considered ‘normally’ active server
including the TCP server environment.
We discuss the changing ‘nature’ of remote users, how they have evolved from the ‘green screen world’ to using server-attached processes with SQL-based inquiries and other extended database processes.
We discuss the concepts of stopping, starting and changing a process. We extend this to moving, holding, releasing or changing a job (process) and review the impact to ongoing system processes, as well as dependencies for other related jobs to the job being changed, started or ended.
Unit – 11 – Subsystems & Managing Work (continued)
We also note in this material, readers and writers with a discussion on ‘holding’ a queue or a spooled file and subsequently releasing it.
Ending something: What happens when you want to end a job? And the job does not want to end? What do you do? What type of job is it? Who owns the job? What user profile is attached to the job? Are they any dependencies or other locks being held by the job?
These are the questions that run through anyone’s mind when first thinking about ending any job on an iSeries or at least they should be. We discuss this task along with other ‘ending’ tasks and their specific requirements and impacts.
Starting something: What happens when you start a subsystem, a TCP server, a series of prestart jobs or some other process? What is the impact to the iSeries environment?
Again, this is something you should be thinking of when you first think about starting something within an iSeries environment.
Unit – 12 – Printers & Managing Printers
An often overlooked technology, printers and printer management is something we wanted to focus on from an operational perspective.
Visual data, as represented by printed output, is represented in the iSeries as a spooled file. Data written to a spooled file is considered ‘final form’ data, in that it is not capable of being changed from its current form.
We chase down of the writer terminology and discuss the various printer processes that exist within the iSeries environment.
Included is a discussion of the various print data streams supported by the iSeries. We also discuss the file-based design behind spooling, the printer file and the spooled file.
We spend some amount of time with the nuances of a PDF writer environment and blend this in with the new ‘paperless’ office environment that is taking shape in many business environments.
We discuss the manner in which printer writer jobs are started, managed and ended. The process of moving data from a file to printer file and then to a spool file is discussed in some detail. We present the various ‘types’ of writers that can be used within the iSeries, including local, remote and virtual writers.
Unit – 13 – Save & Restore :: Backup & Recovery
This might actually be one of the more important chapters of the course since it discusses the important operational task of saving (backing up) the iSeries server on a regular and consistent basis.
It also presents a somewhat detailed review of restore operations with a suggested guideline for accomplishing this important task in an ‘active’ iSeries environment.
The aspects of any backup are discussed in some detail with emphasis given to processing the critical libraries in any environment as broken down by IBM with their special names such as *ALLUSR or *IBM when the SAVLIB command is discussed.
We provide access to various templates and diagrams from IBM that align the various save and restore commands depicting them in command order (option order) along with their save or restore equivalent command.
What is your save strategy? When do you normally perform a save operation? What is the scope of the save? What type of media do you use? What happens to the media once it is used in a save operation?
Unit – 13 – Save & Restore :: Backup & Recovery (continued)
What methods of performing a save are available?
We present and discuss, in detail, the three most common methods used today, the GO SAVE menu options, BRMS or another 3rd party package and user written CL programs.
We review the most common recovery situations or disaster events from which a recovery is required. We discuss the structure and design of some widely used ‘protection’
mechanisms, including UPS, RAID and replication (mirroring).
We also review two of the more important game-changing technologies to the recovery environment, external disk and virtual tape.
