Method and system for optimizing a job scheduler in an operating system

A workload scheduler determines how to submit jobs to several scheduler agents across multiple systems. The scheduler engine determines the systems to which it is able to submit jobs. A job is received and analyzed to determine systems to which the job can be submitted. The scheduler engine determines which system will receive the job by evaluating the next system in line and determining if the job can be sent to that system and if that system is currently in a healthy state. The scheduler engine sends the job to the selected system. The scheduler agents inform the scheduler engine when the job is submitted and when it is executed. Once a time period has expired, the engine evaluates the health of each of the systems based on the number of jobs submitted and executed by each system.

FIELD OF THE INVENTION

The present invention relates to the field of job scheduling in an enterprise-wide environment. In particular, the present invention supports an optimization routine for job schedulers having access to multiple systems.

BACKGROUND OF THE INVENTION

A job scheduler is a program that enables an enterprise to schedule and, in some cases, monitor computer “batch” jobs. A job is the unit of work that a job scheduler gives to the operating system. Typically, the job scheduler gives the operating system a batch of jobs to do and these are performed in the background when time-sensitive interactive work is not being done. The job is typically described with job control language (“JCL”) and is broken down into job steps.

The job scheduler can initiate and manage jobs automatically by processing prepared JCL statements or through equivalent interaction with a human user. Conventional job schedulers provide a graphical user interface and a single point of control for all the jobs in a distributed network of systems and computers.

Conventional job schedulers do not efficiently distribute jobs amongst the multiple systems to which they have access. For instance, job schedulers typically submit jobs to the first system which is permitted to receive that job. This may result in one particular system receiving an inordinate number of jobs when compared to the other systems. In addition, if the system is currently having a problem executing the jobs submitted to it, submission of the current job will only cause a further backlog on that system. Accordingly, there is a need in the art for a system and method for optimizing the scheduling of jobs in a network environment.

SUMMARY OF THE INVENTION

The invention provides a method and system for efficient scheduling of jobs across a network environment. In support of one aspect of the present invention, a scheduler engine determines which systems to which it can submit jobs. The analysis time period can be determined either based on a default time period or a user supplied time period. The current time period begins and the scheduler engine accepts the next job in a queue of jobs waiting to be submitted and processed.

The scheduler engine can determine a group of systems to which the job can be submitted based on an evaluation of the job or the group of systems can be provided by a user of the system. One of the systems can be selected in a round-robin format from the systems to which the scheduler engine can submit jobs. The selected system can be compared to the group of systems on which the job can be submitted to determine if the selected system is within the group. If the selected system is not within the group, another system can be selected and the first selected system can be placed in the back of the line to continue the round-robin selection format. If the selected system is within the group, the health of the selected system can be determined based on health information stored in the scheduler engine for each of the systems. If the selected system was healthy at the end of the prior analysis time period, the scheduler engine can submit the job to the selected system. If the selected system was not healthy, another system can be selected in the round-robin format and the newly selected system can be evaluated to see if it is in the group of systems on which the job can be completed.

A first counter variable can be incremented by one each time a job is submitted to a particular system and the scheduler agent for that system sends a status update to the scheduler engine that the job has been submitted. A second counter variable can be incremented by one each time the scheduler engine receives a status updated from the scheduler agent that a job on the particular system has been processed. A determination can be made as to whether the current analysis time period has expired. If the period has not expired, the scheduler engine can select the next job in the queue. Once the time period expires, the system can evaluate the health of each of the systems to which the scheduler engine can submit jobs.

The health of each system can be evaluated by accepting the first counter variable and the second counter variable for each system. The health quotient for each system can be calculated by dividing the second counter variable by the first counter variable. The health quotient can then be compared to a health value, in which, a system is designated as healthy if its health quotient is greater than the health value and unhealthy if its health quotient is less than the health value. The counter variables for each system and the analysis time period can be reset, and the scheduler engine can access the next job in the queue for evaluation and submission to one of the systems.

These and other aspects, features, and embodiments of the invention will become apparent to a person of ordinary skill in the art upon consideration of the following detailed description of the illustrated embodiments exemplifying the best mode for carrying out the invention as presently perceived.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

Referring now to the drawings in which like numerals represent like elements throughout the several figures, aspects of the present invention and an exemplary operating environment will be described in the context ofFIGS. 1-6. The present invention supports a computer-implemented method for job management and health evaluation of systems and can be more readily understood by reference to the workload scheduler system100ofFIG. 1. FIG.1is a block diagram illustrating a workload scheduler system100constructed in accordance with an exemplary embodiment of the present invention. In one exemplary embodiment, the workload scheduler system100is a software component that submits work, such as jobs on MVS systems, for execution according to a pre-defined schedule.

The workload scheduler system100includes a scheduler engine125running on a first system, such as system A105. In one exemplary embodiment, the scheduler engine125operates on an MVS system105. The scheduler engine125decides where to submit a job and sends orders to one of the scheduler agents130-145to execute the submission. The scheduler engine125can also be informed about what is happening on each system105-120by the scheduler agents130-145.

The system100also includes one or more scheduler agents130-145that can be positioned on the same or different systems105-120from the scheduler engine125. The scheduler agents130-145are typically posited on systems where the workload scheduler system100wants to submit and track jobs. In one exemplary embodiment, the scheduler agents130-145are configured to submit and track jobs on their respective systems105-120.

FIG. 2is a block diagram illustrating a general component architecture for system A105, in accordance with certain exemplary embodiments. System A105includes a general-purpose computing device in the form of a conventional computer220. Generally, the computer220includes a processing unit221, a system memory222, and a system bus223that couples various system components, including the system memory222, to the processing unit221. The system bus223can include any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, or a local bus, using any of a variety of bus architectures. The system memory222includes a read-only memory (“ROM”)224and a random access memory (“RAM”)225. A basic input/output system (BIOS)226containing the basic routines that help to transfer information between elements within the computer220, such as during start-up, is stored in the ROM224.

The computer220also includes a hard disk drive227for reading from and writing to a hard disk (not shown), a magnetic disk drive228for reading from or writing to a removable magnetic disk229, such as a floppy disk, and an optical disk drive230for reading from or writing to a removable optical disk231, such as a CD-ROM, compact disk-read/write (CD/RW), DVD, or other optical media. The hard disk drive227, magnetic disk drive228, and optical disk drive230are connected to the system bus223by a hard disk drive interface232, a magnetic disk drive interface233, and an optical disk drive interface234, respectively. Although the exemplary system A105employs a ROM224, a RAM225, a hard disk drive227, a removable magnetic disk229, and a removable optical disk231, it should be appreciated by a person of ordinary skill in the art having the benefit of the present disclosure that other types of computer readable media also can be used in the exemplary system A105. For example, the computer readable media can include any apparatus that can contain, store, communicate, propagate, or transport data for use by or in connection with one or more components of the computer220, including any electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or propagation medium, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like. The drives and their associated computer readable media can provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data for the computer220.

A number of modules can be stored on the ROM224, RAM225, hard disk drive227, magnetic disk229, or optical disk231, including an operating system235and various application modules125,237-238. Application modules125,237-238can include routines, sub-routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. Application module125, referred to herein as a “scheduler engine”125, is discussed in more detail above, with reference toFIG. 1.

A user can enter commands and information to the computer220through input devices, such as a keyboard240and a pointing device242. The pointing device242can include a mouse, a trackball, an electronic pen that can be used in conjunction with an electronic tablet, or any other input device known to a person of ordinary skill in the art, such as a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit222through a serial port interface246that is coupled to the system bus223, but can be connected by other interfaces, such as a parallel port, game port, a universal serial bus (USB), or the like. A display device247, such as a monitor, also can be connected to system bus223via an interface, such as a video adapter248. In addition to the display device247, the computer220can include other peripheral output devices, such as speakers (not shown) and a printer241.

The computer220is configured to operate in a networked environment using logical connections to one or more remote computers249, such as systems105-120. The remote computer249can be any network device, such as a personal computer, a server, a client, a router, a network PC, a peer device, or other device. While the remote computer249typically includes many or all of the elements described above relative to the computer220, only a memory storage device250has been illustrated inFIG. 2for simplicity. The logical connections depicted inFIG. 2include a LAN204A and a WAN204B. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, the computer220is often connected to the LAN204A through a network interface or adapter253. When used in a WAN networking environment, the computer220typically includes a modem254or other means for establishing communications over the WAN204B, such as the Internet. The modem254, which can be internal or external, is connected to system bus223via a serial port interface246. In a networked environment, program modules depicted relative to computer220, or portions thereof, can be stored in the remote memory storage device250.

It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used. Moreover, those skilled in the art will appreciate that the system105illustrated inFIG. 1can have any of several other suitable computer system configurations. For example, the system105may not include certain components, in alternative exemplary embodiments. In certain exemplary embodiments, each of the systems105-120can include a structure similar to that described previously in connection with the system105.

FIGS. 3-6are logical flow chart diagrams illustrating the computer-implemented processes completed by an exemplary method for job management in a z/OS operating system environment.FIG. 3is a logical flow chart diagram300presented to illustrate the general steps of an exemplary process for job scheduling and management across multiple systems within the operating environment of the exemplary workload scheduler system100ofFIG. 1.

Now referring toFIGS. 1 and 3, the exemplary method300begins at the START step and proceeds to step302, in which the scheduler engine125accepts a default time variable. In one exemplary embodiment, the time variable is used to designate the amount of time between system status or health checks for those systems accessible by the scheduler engine125. In one exemplary embodiment, the default time variable is five minutes. In step304, a user or system manager is prompted with an option to provide a user selected time variable. The prompt may be by way of a pop-up screen or other methods known to those or ordinary skill in the art. In an alternative embodiment, the user may be required to take active steps to change the time variable, such as selecting an option from a drop-down box on the user interface, instead of the request being automatically provided to the user. The option provides the user with the ability to select a time variable that is different than the default time variable.

In step306, an inquiry is conducted to determine if a user selected time variable was received. If not, the “NO” branch is followed to step312. Otherwise, the “YES” branch is followed to step308, where the default time is replaced with the user selected time variable. The time is reset in step310. Those of ordinary skill in the art will recognize that the time may be set to zero and the time may count up until it reaches the time variable or the time may be set at the time variable and count down to zero. In step312, the scheduler engine125determines which systems it has access to and can send jobs. In the exemplary embodiment ofFIG. 1, the scheduler engine125can submit jobs to scheduler agents130,135,140, and145in systems A through D105,110,115, and120. In this exemplary embodiment, the scheduler engine125maintains information about each system, such as how many jobs it has submitted to each system.

The scheduler engine125accepts the next job in the queue in step314. In step316, the scheduler engine125determines the pool of equivalent systems to which the job can be submitted. For example, while the scheduler engine125is able to submit jobs to systems A-D, the job may contain information that shows it can only be submitted to system B110and system C115. In one exemplary embodiment, the pool of equivalent systems is determined by a user providing this information. In an alternative embodiment, the pool of equivalent systems for each job is provided with the job. The scheduler engine125determines which system and scheduler agent the job will be sent to in step318. The scheduler engine125sends the job to the selected scheduler agent in the selected system in step320and records information regarding the job, job status and the system the job was sent to in step322. For ease of reference, in this example, it will be assumed that the scheduler engine125selected and sent the job to the scheduler agent135in system B110.

In step324, the scheduler engine125accepts a status update from the scheduler agent135that the job has been submitted. In one exemplary embodiment, in the MVS system, the scheduler agent sends the information back when the scheduler agent puts the job on the job entry subsystem (“JES”) internal reader queue. In step326, counter variable X represents the number of jobs submitted to one of the systems and is initially set at zero at the beginning of the time period. In this embodiment, each system will have its own counter variable X. In one exemplary embodiment, the counter variable for system B110is incremented by one upon receipt by the scheduler engine125that the job has been submitted. The scheduler engine125accepts a status update from the scheduler agent135, that the job has been processed in step328. In one exemplary embodiment, in the exemplary MVS system, the scheduler agents can use the JES exits, like exit51, to monitor the job life and inform the scheduler engine125of what is happening with the job. In step330, counter variable Y is incremented by one. Counter variable Y represents the number of jobs processed by a system during the time period and is initially set at zero at the beginning of the time period. In one exemplary embodiment, each system will have its own counter variable Y.

In step332, an inquiry is conducted to determine if the time period has expired. If the time period has not expired, the “NO” branch is followed back to step314, where the scheduler engine125accepts the next job in the queue. On the other hand, if the time period has expired, the “YES” branch is followed to step334, where the scheduler engine125conducts a health check for each of the systems with which it is able to schedule jobs. In step336, the counter variables X and Y are reset to zero for each of the systems. The scheduler engine125determines the backlog of jobs not yet processed for each scheduler agent in step338. The process then returns to step310, where the time period is reset and a new analysis period begins.

FIG. 4is a logical flow chart diagram318presented to illustrate the steps of an exemplary process for selecting a system and agent to which a job is sent as completed by step318ofFIG. 3. Now referring toFIGS. 1 and 4, the exemplary method318begins with a counter variable Z representing the systems available to the scheduler engine125for job submission. In one exemplary embodiment, the counter variable is initially set at one and selects the first system available to the scheduler engine125. However, as the exemplary workload scheduler system100continues to process jobs, the counter variable continues to increment up to the total number of systems available to the scheduler engine125. At that point the counter variable is reset to one and the scheduler engine125goes back through the list of available systems. In this manner, the scheduler engine125determines which system to evaluate for receiving the next job in a “round-robin” format.

The scheduler engine125selects the first system to determine if it should receive the next job in step410. In step415, an inquiry is conducted to determine if system Z is one to which the next job can be submitted. In one exemplary embodiment, this determination is made by the scheduler engine125determining if system Z is included in the pool of equivalent systems to which the job can be submitted. If the job cannot be submitted to system Z, the “NO” branch is followed to step425, where counter variable Z is incremented by one to select the next system for evaluation. If the job can be submitted to system Z, the “YES” branch is followed to step420.

In step420, an inquiry is conducted to determine if system Z is healthy. One exemplary method for determining the health of a system will be described hereinafter with regards toFIG. 5. If system Z is not healthy, the “NO” branch is followed to step425. In step425, counter variable Z is incremented by one to select the next system for evaluation. If counter variable Z already equals the number of systems accessible for job submission by the scheduler engine125, then counter variable Z is reset to one and the first system is selected again. Retuning to step420, if system Z is healthy, the “YES” branch is followed to step430, where system Z is designated to receive the job from the scheduler engine125. In step435, counter variable Z is incremented by one to select the next system for evaluation for the next job to be distributed by the scheduler engine125. If counter variable Z already equals the number of systems accessible for job submission by the scheduler engine125, then counter variable Z is reset to one and the first system is selected again.

FIG. 5is a logical flow chart diagram presented to illustrate the steps of an exemplary process for conducting a health check for each of the system as completed by step334ofFIG. 3. Now referring toFIGS. 1 and 5, the exemplary method334begins by accepting a list of systems to which the scheduler engine125can send jobs in step505. In step510, the scheduler engine125selects the first system. The scheduler engine125retrieves the variable X, representing the number of jobs submitted to the system, for the just concluded time period in step515. In step520, the scheduler engine125retrieves the variable Y, representing the number of jobs processed by the system, for the time period that has just concluded.

The percentage of jobs that have been processed, as compared to those that have been submitted to the system, is determined by dividing variable Y by variable X to derive a health quotient in step525. In step530, the scheduler engine125compares the health quotient for the system to a predetermined health value. The predetermined health value can be one that is pre-set in the system or received from a user of the workload scheduler system100. In one exemplary embodiment, the predetermined health value is ninety percent. In one exemplary embodiment, if the health quotient is less than the predetermined health value, then that particular system is deemed unhealthy. Conversely, if the health quotient for the selected system is greater than the predetermined health value, then the selected system is deemed healthy. Thus, the health of a particular system can be generally based on the percentage of submitted jobs that have been processed by the scheduler agent of the system.

In step535, an inquiry is conducted to determine if the system and/or scheduler agent for the system are healthy. If the system and/or scheduler agent are not healthy, the “NO” branch is followed to step540, where the scheduler engine125generates a message that the system and/or scheduler agent are not healthy. In one exemplary embodiment, the message can be sent by the scheduler engine125to an MVS console or a web user interface. If the system is healthy, the “YES” branch is followed to step545. For both healthy and unhealthy systems, the current health status for the system is stored by the scheduler engine125in step545. In step550, an inquiry is conducted to determine if there is another system to evaluate. If so, the “YES” branch is followed to step515. Otherwise, the “NO” branch is followed to step336ofFIG. 3.

FIG. 6is a logical flow chart diagram presented to illustrate the steps of an exemplary process for determining a backlog of jobs not yet processed on each scheduler agent in each system as completed by step338ofFIG. 3. Now referring toFIGS. 1 and 6, the exemplary method338begins by selecting a scheduler agent on one of the systems to which the scheduler engine125can submit jobs for evaluation in step605. In step610, the scheduler engine125accepts information on a job that was submitted to a scheduler agent in a system. In one exemplary embodiment, the scheduler engine125is able to compare the information it receives from the scheduler agent to information the engine125has stored about the particular job. For exemplary purposes, the process ofFIG. 6will be described with reference to a job sent to scheduler agent145in system D120.

In step615, an inquiry is conducted to determine if the scheduler engine125received an execution notification for that job from the scheduler agent145. If the scheduler engine125did not receive an execution notification from the scheduler agent145, the “NO” branch is followed to step620, where the scheduler engine125designates the job as being backlogged. The job is added to a backlog list for system D120by the scheduler agent125in step625.

In step630, an inquiry is conducted to determine if there is another job to evaluate in system D120. If so, the “YES” branch is followed back to step610to receive information about the next job. Otherwise, the “NO” branch is followed to step635. In step635, an inquiry is conducted to determine if the scheduler engine125has another system to evaluate. If so, the “YES” branch is followed to step640, where the next system is selected and the process returns to step610to begin retrieving job information for the next system. Returning to step635, if there are no additional systems to evaluate, the “NO” branch is followed to step310ofFIG. 3.

It is considered that the operations, steps, and procedures described above and illustrated in the accompanying drawings are sufficiently disclosed to enable one of ordinary skill in the art to practice the present invention. However, there are many computers, operating systems, and application programs which may be used in practicing an exemplary embodiment of the present invention. Each user of a particular computer will be aware of the language and tools which are most useful for that user's needs and purposes. In addition, although the invention was described in the context of a workload management system, those skilled in the art will appreciate that the invention can be extended to a wide variety of business management applications. It should be understood that the foregoing related only to specific embodiments of the present invention, and that numerous changes may be made therein without departing from the spirit and scope of the invention as defined by the following claims.