STARTING JOBS

As an operator, you will be expected to run utility programs and batch jobs. The start up procedures are similar for both; refer to the operator's manuals and run folders for the specifics for each job you run. The most common application utility programs that you will run will be tape and disk copies, to make backup copies of application files.

While batch jobs are more detailed when it comes to starting them, as long as the run folder is followed there will be no problems. They will have different inputs and outputs required than utility programs. All of the file names and media types will be supplied by the user in the form of an AIS service request. Remember, before starting either an application utility or a batch job, look at and follow the operator's manual and run folder for the job.

DISPLAYING JOB STATUS

Using the system console, you can display, by their assigned name, the status of all jobs that are currently being executed. The job status also indicates whether the job is active, stopped, terminated, or canceled but still residing in the CPU; waiting for space in the work area or on disk; waiting for a printer or a communications line; or waiting for you to respond to a message. You can also display the status of the system's I/O devices to see whether or not they have been varied offline to the system.

One of your primary responsibilities is to maintain an awareness of the jobs currently undergoing processing within the system. Having the above information is extremely important to you, as it enables you to provide services to the various jobs being processed. The jobs with the highest priorities usually receive immediate attention. Jobs with lower but equal priorities are processed in the order they were entered (loaded) into the system (first-come first-served).

Considering these operating constraints, it is easy to understand why the system is in a continuous state of change. Through the use of the display command, you are able to get an immediate picture of the system's activities. Using this information as a frame of reference, you can determine what actions are necessary to maintain a continuous work flow.

RESTARTING A JOB

Unfortunately for us, not all jobs processed come to a normal end of job (EOJ). Things like program or machine interrupts, operator errors, bad input data, and incorrect responses to messages can cause a job to prematurely or abnormally terminate (ABORT). When this occurs, it is imperative that normal operations be resumed as quickly as possible. Error recovery must be accomplished to maintain production schedules and minimize cost and lost computer time.

By monitoring the console (CRT or console printer), you can determine whether a job aborted because of invalid data or during processing. On some systems, the operating system software will display on the console the reason for the job's cancellation or the point at which the abort of the program took place. If the job aborted during the input phase, you may conclude that bad input data was at fault. If the input data was accepted and processing begun, you may conclude that a program malfunction was encountered (barring any hardware problems) and caused the job to be automatically flushed (canceled) from the system.

Regardless of why the job aborted, ultimately, you are responsible for initiating recovery from the job cancellation, using one of a number of methods. In many cases, the operator's manual or run manual will provide you with the proper procedures necessary to recover or restart a job. One method is to rerun the entire job. However, this could be very costly and time consuming, especially if the master file(s) had to be returned to its/their original state. You might have to recreate files from backup files and rerun programs that added, changed, and deleted records. This problem is especially true when working with disk files. 

When the operating system supports checkpoint restart routines, a job can be restarted near the point where the problem occurred without having to rerun the ^{entire job (or system).} The logical point to take a checkpoint is at the end of reading or writing a tape file or after a predetermined number of records (say, 15,000) have been processed, or after so many minutes of processing (say, 30 minutes) have occurred. The programmer determines the points in the program at which the checkpoints are to occur. This way, if the program cancels (aborts), it can be started again at the last checkpoint.

Even if the system provides for an automatic restart at the last good checkpoint, you still must authorize the restart. Usually, a message will appear on the console indicating the job (or task) to be executed and the checkpoint for restarting the job. It is then up to you to either restart the job, postpone the restart until the cause of the problem can be determined, or indicate that the job is not to be restarted. Under no circumstances should the termination or cancellation of a job interfere with the continuous flow of processing within the system. CANCELING A JOB

Among the tasks you may be asked to initiate via the console is cancellation of a job currently running within the system. The purpose of the cancel operation is to allow you to halt (stop) the processing of an application program and remove it from the system. A program can be canceled by either the supervisor control program or by you. Should the supervisor control program determine that an application program is not executable, it automatically directs the computer to cancel the program and, thereby, halt its processing. There are times when you must intervene with normal processing and flush a job from the system even though the program being executed may not have an error in it. For example, you could be instructed to process a higher priority job immediately. Unable to wait for the completion of the current program (job), you are, therefore, required to abort it. Don't become confused over the terms cancel, flush, or abort; they all have the same meaning. You may also be required to cancel a job because it has entered a continuous loop, been running way beyond the allotted time, or because it is trying to access a restricted file. You will find that there are many such reasons for having to cancel a program. There are times when you will cancel a program or a program will abnormally terminate (ABEND). This will require you to dump (print out) the contents of storage. This is known as a post-mortem dump. The system prints the contents of all the storage areas used by the program in the processing. This post-mortem dump is used as a debugging aid to help the programmer analyze the program.

Whenever a job is canceled or abnormally terminates, it is your responsibility to make an entry in the error/trouble log, giving the cause of the problem and as much detail as possible.

DOCUMENTATION

Documentation, who needs it? In data processing, we all do: for without it, we would quickly find ourselves in serious trouble. As a computer operator, if you want to know how to run a particular procedure, job, or system or learn more about a particular procedure, job, or system, the operator's manual or run manual is a good place to start. It can provide you with a wealth of information. Examples are a written overview of the system and systems flowchart, in-depth coverage pertaining to I/O requirements, file specifications (layouts), processing methods, job setup, error messages that might be generated, recovery/restart procedures, and sample reports. As the console operator, you are responsible for running hundreds, possibly even thousands, of jobs on a regular basis. Without using the available documentation, even an experienced operator cannot understand or be expected to remember exactly how each job is to be set up and run.

The actual format of the operator's documentation differs, depending on your installation's requirements and SOPS. In some installations, you will find that each procedure or job has its own folder or notebook. Other installations may include an entire system (several jobs), such as personnel or payroll, in one large notebook. Regardless of how the documentation is formatted, its basic objectives are to provide you with complete instructions and to serve as a ready reference. So take the time to read the documentation. You will find that from knowledge comes the wisdom to make the right choice or the right decision every time.