A controller for a single device or group of devices that is connected to a single selector channel defines its idled and cycled loads in exactly the same way as the channel. The application and operating system loads to be associated with a controller are, of course, defined during the periods of their respective activities. Thus, a controller is idled when all devices with which the controller is associated are either unmounted or contain no active files. It is, of course, idled when there are no jobs in the system. The controller is active, but unused, when there are active but currently quiescent files on its devices. In this case the controller is creating cycled load.

It should be noted that the controller and the channels to which it connects might not have identical load distributions. That is, the controller may connect several channels to a group of devices and therefore the sum of the

The Devices

The distribution of loads for a peripheral device follows the same pattern as that for the other equipments in the data transfer chain between file and core memory. As before, we will say that the device is idled if no media is mounted on it, or if no jobs are currently present in the system. The device is also idled if it holds no active files.

When the device holds active files the load on the device is distributed into application, operating system and cycled categories, according to the same criteria applied to the channels and controllers.

REFERENCE

Leo J. Cohen, System Performance Measurement and Analysis, Performance Development Corp., Trenton, N.J., May, 1973.

INTRODUCTION

Modern day business data processing systems have changed dramatically over the past ten years. With the advent of third-generation machine power, sophisticated data management and operating systems, and with more extensive use being made of teleprocessing, the modern systems are impressive, indeed. But, along with these advances, a problem has appeared that is significantly different from the early days of data processing. That problem is efficient and effective machine scheduling. The difficulty lies in the fact that it is not a simple matter to translate human requirements and human thought processes into complex machine requirements in such a way so as to realize the maximum utilization of expensive machine resources. The problem is most often solved by simply allowing the computer to accept jobs on a first-come, first-serve basis or by utilizing an unsophisticated software job selection procedure. An example of the former is the practice of loading the job queue with the jobs that are to be executed over a given period of time and executing these jobs in a first-in, first-out manner. An example of the latter is utilization of a feature of the IBM 360/Operating System (OS) termed HASP (Houston Automatic Spooling & Priority). This feature is primarily used in those installations that process large quantities of relatively independent jobs; it is unsuitable for long running mutually dependent processes that access integrated files. The intent of the following discussion is not to pursue the pros and cons of the various scheduling methodologies; rather, it is to describe a program which helps greatly to eliminate many of the problems associated with scheduling of the AMC Commodity Command Standard System (CCSS).

AUTOMATED PRODUCTION SCHEDULER DESCRIPTION

The Automated Production Scheduler (APS) is a COBOL program incorporating many of the basic principles of PERT (Program Evaluation and Review Technique). The scheduler applies these principles to descriptions of computer jobs to evaluate the relationship between a variety of activities that compete for resources and time. A computer job in IBM terminology is defined as "a total processing application comprising one or more related processing programs, such as a weekly payroll, a day's business transactions or the reduction of a collection of test date." The refore, in order to apply the principles of PERT, it is necessary to describe the workload for the computer in terms of computer jobs, i.e., job profiles must be constructed.

requirement, run time (calculated, estimated or observed), the earliest time the job can be started and the latest allowable time for job completion, percentage of CPU time, devices required to support the job, predecessor jobs that must be completed prior to the beginning of each job, number of disk tracks that will be required to support transactions into and out of each job, number of disk tracks that will be free at the successful completion of the job and any special conditions that must be considered, such as: restrictions on updating the same file by two programs simultaneously or the physical mounting of a given file before job initiation. The job profile can be established at any level preferred. For jobs that will be processed on computer systems running under an MFT (Multiprogramming with a Fixed number of Tasks) operating system, it is sufficient to define the profile at the job level as opposed to the step level (jobs are comprised of one or more job steps which are defined as that unit of work associated with one processing program). For those jobs that are to be processed on machines which operate under an MVT (Multiprogramming with a variable number of Tasks) operating system, it may be convenient to In either define the profile at the step level. case, the job profiles can be collected in such a manner that one or more jobs may be scheduled by using an indexing technique. For example, suppose a given application, Weekly Billing, comprises five separate jobs. In building the APS data base the five jobs would be individually described, each with a separate name. In addition, the five job profiles could be "collected" under a separate name to facilitate their manipulation in a remote environment.

Jobs may be scheduled for completion in any period up to 24 hours in length by entering the job names (or collection names) into the computer via a terminal (see Appendix B). The APS program will mix and match the job profiles in such a way so as to produce the optimum sequence of execution. Those jobs that cannot be scheduled within the time frame established are indicated on a separate APS report.

APS REPORTS

Several reports are provided by the scheduler. Each report is optional in the sense that, when operating the terminal in interactive mode, the opportunity is provided to print or suppress printing of each report. The basic reports are:

-Status Report (Appendix C). This report is essentially an extract from the APS data base and reflects major parameters assigned to describe each job selected for scheduling. The option is provided to change any parameter for any job on either a temporary (one time usage) or permanent (physical data base change) basis.

-Unscheduled Runs (Appendix D). As previously indicated, all jobs that cannot be scheduled within the time frame or hardware configuration provided will be shown on a separate report.

-Release Sequence (Appendix E). This report lists the optimum sequence of job release along with estimated start time (SETUP) estimated time of completion (REMOVE) and jobs that must complete prior to release of a given job (PRED). A message is printed at the end of this report which indicates the degree of multiprogramming that can be expected.

-Resource Map (Appendix F). A listing of resources remaining for each time increment is provided by this report, along with a theoretical multiprogramming map. Column headings refer to resources remaining available after assignment of those required to support the scheduled jobs.

TERMINAL CONSIDERATIONS

There are a number of commercial scheduling systems available in the market-place that will perform in a manner similar to APS; however, APS is believed to be the only scheduling system that operates from a terminal. The primary advantage in having capability to operate the scheduler from a terminal is the ability to dynamically reschedule on an as-required basis without interruption of the host computer.

Before discussing the scheduling/rescheduling aspect of APS, it would be beneficial to discuss general advantages and disadvantages of automatic scheduling. First, it is perhaps unfortunate that the term "scheduler" is used to describe the subject system. A more accurate term would be "pre-scheduler" because, basically, that is precisely what happens. By utilizing automated scheduling (pre-scheduling) we can determine the best job start sequence to most effectively utilize equipment resources. Automated scheduling will also allow determination of the best time to start "one-time job" after a normal production day has been scheduled. This is readily accomplished by examining the resource map to choose the time frame wherein resources are available for "one-time jobs." If described in the APS data base, it can automatically be fitted into the current schedule by simply entering its name through the terminal, thereby providing the dynamic rescheduling capability.

A secondary benefit of automatically prescheduling a periodic computer workload is the forced attention to detail necessary to properly utilize APS. All too frequently a given work period is scheduled in a most cursory manner. By identifying the requirement to the scheduler, more assurance is given that the proper homework is done before a job is entered into the computer for execution. For example, one of the uses made of the APS system is to simulate a given scheduling period to determine whether more work has been planned than can actually be performed.

Of course, as with all planning, the real world frequently will not allow exact execution. Unexpected job failures, equipment failures or

changes in processing priority tend to disrupt the best of schedules. Operational environments that are basically unstable may find that prescheduling has limited value in defining optimum job sequence. This is because of the bias thrown in by unpredictable run times. Although this is a disadvantage, it can be compensated for in part by the workload simulation aspect and in part by the ease in which rescheduling can be accomplished. APS retains the last schedule produced so that it is possible at any time to enter, through the terminal, the specific conditions at a point in time and obtain a new schedule in a few minutes (3-5).

CURRENT APS USAGE

The USAMC Automated Logistics Management Systems Agency presently utilizes the APS system in two ways. The first way was addressed briefly above; i.e., used as a pre-scheduling planning tool to insure preproduction considerations are honored. A second and growing use of the scheduler is in the area of "simulation" (Appendix G). In this latter role the scheduler plays an increasingly important role in the area of equipment configuration predictions. These predictions are made in the following manner:

-The workload requirements of a given program are described in terms of transaction type and volume, disk storage requirements and master file activity estimates. These basic statistics are utilized to produce program run time estimates.

-The run time estimates are entered into an APS data base along with other job profile parameters described earlier. Model schedules are then produced which attempt to show a theoretical sequence of work that can occur on a given equipment configuration.

A

-The reports produced by the scheduler are analyzed to determine whether additional hardware is required or too much hardware is provided for an estimated workload at a given location. For example, if the estimated workload cannot be accommodated on a given configuration, the scheduler reports will show all jobs that can be run and will further list the jobs that cannot be scheduled under the constraints provided. quick analysis of the output reports will reveal that, perhaps the reasons scheduling cannot occur are a limitation or inavailability of some system resource (i.e., core, tape drive, disk drives, etc.). The overall effect of the "simulation" is a quick look at the impact of additional workload on a given equipment configuration. This methodology has proven to be extremely accurate and effective to date with the qualification that, as with a "normal simulator", the results are only as accurate as the input provided.

APS DATA BASE CONSIDERATIONS

As may be noted in Appendix G, a powerful feature of the automated scheduler is the capability to update the scheduling data base with actual history data. Update is accomplished by using data generated by the System Management Facilities (SMF) feature of the IBM OS. This

feature automatically records operational parameters for each job and job step executed. It provides all of the basic information included in the APS data base except the predecessor considerations. Not only is the capability to update the data base to reflect actual history on a recurring basis important, but in addition, those installations that must build the job profile from scratch will find the SMF data a valuable source of information. Since SMF is the source of the machine utilization accounting and billing reports, a secondary benefit is obtained. The APS data base can be used to serve not only the scheduler, but also as the repository of utilization statistics.

APS AVAILABILITY

The APS program described in this paper is a proprietary package of Value Computing, Inc. of Cherry Hill, New Jersey. In October 1972, the USAMC ALMSA acquired a license for this package. Provisions in the license include the use of the package throughout the Department of the Army without additional charge.

The program as it stands under the licensing arrangement was designed around the requirements of the CCSS. In this respect, it is built to operate under the IBM MVT operating system Release 20.6 and higher. The access method specified is TCAM (telecommunications access

method).