Idaho State University

• Academics
• Prospective Students
• Current Students
• Faculty & Staff
• Alumni & Visitors

• Information
  • Access Security
    • Department Information
    • HP3000 Server Account Information
    • Network Services Account Information
    • Responsible Account Holder Information
    • Application System Responsibility
    • Department/Group Info
  • User Guide
    • Table of Contents
  • Networked Printers
  • Miscellaneous System Info
    • HP1 (HPe3000) Server Scheduled Down Time
    • Powerhouse Web Queue Management Values
    • Portal Web Services Availability Schedule
• Our Staff
  • Support by System
  • Primary Support
  • Backup Support
• Project Management
  • Staff Responsibilities
    • Support by System
    • Primary Support
    • Backup Support
• Information Technology Services
• DEACON Project

Enterprise Applications
Development Guidelines and Procedures

Job Processing #2

Computer Operations Instructions

To help reduce the likelihood of errors due to conflicting access requirements, no two jobs run from the same USER.ACCOUNT will be allowed to run concurrently. Also, no two jobs with the same system code prefix (first two characters of the job name) will be allowed to run at the same time. Exceptions to this rule will be coordinated by Administrative Systems analysts via a written workorder or phone conversation with the operator. Jobs from MGR.ADMIN, MGR.AD2 and MGR.FINAID are an exception to this rule. Jobs accessing multiple database systems require work requests so Computer Operations will know which jobs can run concurrently.

Any job requiring over 5000 CPU seconds to process is a potential problem to Computer Operations. On such occasions a job may have to be aborted for backup or emergencies. Any job requiring this much CPU time must have instructions to Computer Operations indicating the expected time. Recovery procedures should be included when appropriate.

1. System Throughput

Computer Operations has the responsibility for changing the priority of a running job to enhance throughput or to resolve problems caused by jobs running in an improper queue.

2. Communications with Computer Operations
1. Altering Job Input Priority (INPRI)


• Altering Input Priorities should be avoided except when recovering from production job errors, i.e., to get a job back into its proper sequence.
• Some clients have the ability to alter Job Input Priorities for their own jobs.
• In all cases, if altering Input Priorities was necessary Computer Operations should be notified.
2. Altering Job Limit

• If you have the capability to alter the Job Limit you should only do so if the computer operator is not available.
• If raising the Job Limit was necessary it must be lowered again immediately thereafter. A TELLOP message should be sent to the computer operator to let them know what occurred in their absence.
3. Aborting jobs by Non-Computer Operations staff

• A production job on a work request may be aborted by the analyst responsible for the job only if the computer operator is not available.
• Some clients have the ability to abort their own jobs.
• If a production job is aborted, written notice should be given to Computer Operations explaining the action.
• Non-production jobs may be aborted but must be followed by a telephone call to inform Computer Operations. This applies both to jobs running and jobs waiting with an input priority of 2 or 7. This avoids confusion in filling out error action sheets (speed letters).
• It is the responsibility of Computer Operations to change the queue in which a given program is running when necessary. Analysts should request this service of Computer Operations whenever a violation of the queue policy exists, or a given process is taking more than its fair share of system resources.
3. Job Sequence
   
   Jobs will be run in the order they are submitted except as indicated to the contrary on a work request or priority 7 tracking sheet. Unless stated otherwise, Computer Operations is to assume that any sequence of jobs on a single work request are interdependent. Subsequent jobs on the same work request should not be processed following any abnormal condition for which no instructions are provided with the work request or in an attached job stream listing. JobRescue's error scanning is used to determine whether or not a job aborts. If JobRescue does not report an error, the job is assumed to have completed successfully.
4. Special Forms and Labels
   
   Work requests for jobs requiring special handling or special forms must be received by Computer Operations before 11:00am to be printed by 1:00pm the same day. Exceptions are work requests for Labels and Payroll Time Cards.

   Labels and Payroll Time Card work requests must be sent to Computer Operations by 12:45pm to be printed by 3:00pm the same day. Otherwise they will be completed during regular evening processing.

5. Scantron Form Processing
   
   Scantron forms will be processed according to times indicated for Special Forms and Labels with one exception. During finals week instructors will be allowed to submit scantron exams based on the following schedule:
   
   

   Drop Off Forms	??	Pick Up Forms and Reports
   Before 3:00pm	??	Before 5:00pm the same day,
   Before 4:00pm	??	After 7:00pm the same day,
   After 4:00pm	??	After 9:30am the next business day.

6. Abnomal End of Processing for a Production Job

1. Job Failures
   
   When a production job stream fails to execute properly the computer operator on duty must determine the need for rerunning the job. This can be ascertained by evaluation of the work request. Special instructions, if any, will be found on the job stream listing which will be attached to the work request. JobRescue's error scanning is used to determine whether a job aborts. If JobRescue does not report an error, the job is assumed to have completed successfully.
2. Job Conflicts with Backup
   
   Jobs requiring extensive CPU processing time may conflict with backup processing. Unless stated on the work request the respective analyst should be contacted regardless of the hour to obtain instructions as to whether backup is to run with the job or whether the process is to be aborted. Whenever possible Computer Operations will be forewarned of a long batch process via instructions placed on a work request for the job stream. Whenever a process can be reasonably aborted it should be stated as such on the work request. Reasonable attempts should be made to contact the responsible analyst before a job is aborted for backup or other reasons.
3. Notification of Failures for Non-Critical Jobs
   
   Those jobs for which processing is not critical will be set aside, along with all relevant information as to the cause of the failure, for Production and Reporting to distribute to the following business day.
4. Pending Jobs After Work Request Job Failures
   
   Any pending jobs on the same work request with a job that ends abnormally must have their input priority changed to 0 and left on the system until the analyst has an opportunity to review the problem. The analyst is responsible to arrange to either have the job(s) rescheduled or purged.
5. Output of Failed Jobs
   
   Output of an aborted job may also deferred to a '0' if possible and left on the system until the analyst has had an opportunity to respond. The computer operator should no longer have to purge any spoolfiles. The job stream SPCLEAN will automatically run based on the following chart to purge old spoolfiles left on the system:

   Files created on or before:	Mon	Tue	Wed	Thu	Fri	Sat	Sun
   Purged after 5pm the following:	Wed	Thu	Fri	Mon	Tue	Tue	Tue

   Should the computer operator need to copy deferred spoolfiles to tape and purge them to free spooler disc space the tape should be entered into the Tape Library system with a 7-day retention.

   The computer operator will note on an error action sheet (speed letter) any spool files and/or jobs that you had to defer. All error action sheets (speed letters) from aborted production jobs will be taken to Production and Reporting for distribution.

6. Computer Operator Not to Reprogram Jobs
   
   Computer Operations or Production and Reporting are not to attempt to make programming or job modifications to resolve processing problems.
7. Error Action Sheet
   
   JobRescue will produce an error action sheet for any job with an error, except jobs which are in development as indicated by the user MGR. Only errors which are predetermined and configured into JobRescue will be reported. A manual form (speed letter) should be prepared for any event that appears abnormal for which no automated report is generated. This will aid in quick discovery and communication of problems.
8. Analyst to Review Job Failures
   
   Although routine job setup is the responsibility of the customer, in the event modification is required to a production job, it is the responsibility of the analyst to make the required changes. Analysts are expected to review all stream jobs which have failed and assist users in correcting errors.