Methods, systems, and computer programs (high-availability scheduler event tracking)

Abstract

To provide high availability scheduler event tracking for scheduler configuration such as IBM Z workload scheduler configuration.SOLUTION: By a controller, an operational status of a tracker system that is configured to track and record a current status of a job and to report completion of the job to the controller, is monitored. The recording includes storing two copies of the current status. In response to determining, based on the monitoring, that the tracker system is operational, reception of a job completion message from the tracker system is waited for, and a job completion action based on the reception of the job completion message is performed. In response to determining that the tracker system is not operational, the current status of the job is obtained from a shared memory location, and the job completion action based on the current status indicating that the job has completed is performed.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to computer processing, and more specifically, to high availability scheduler event tracking.

Background Art

[0002] IBM (registered trademark) Z (registered trademark) Workload Scheduler is an example of a workload automation solution that enables organizations to automate, schedule, and control the processing of workloads in complex systems. This allows workflows to be managed from a single control point that spans multiple platforms and business applications.

[0003] The controller is the focal point of the IBM Z workload scheduler configuration. This includes control functions, Interactive System Productivity Facility (ISPF) dialogs, databases, and plans. The system on which the controller is started is referred to as the IBM Z workload scheduler control system. The IBM Z workload scheduler system that communicates with the control system is called the controlled or tracker system. The controller provides a single, consistent control point for submitting workloads and tracking them on any operating environment. IBM Z Workload Scheduler provides distributed agents and open interfaces that can be used to integrate the planning, scheduling, and control of work units such as online transactions, file transfers, or batch processing in any operating environment that can communicate with z / OS (registered trademark).

[0004] An execution tracker (or "tracker") is required for all z / OS systems in an IBM Z workload scheduler configuration. The tracker handles job and task submissions on the system and keeps track of workload status. In conjunction with standard interfaces to the Job Entry Subsystem (JES) and System Management Facilities (SMF), the IBM Z workload scheduler records relevant information about workloads by generating event records. These event records are captured and stored by the tracker. The tracker then communicates the event information to the controller for further processing. The log in which events are written by the tracker is called the event dataset. The IBM Z workload scheduler address space is defined as a z / OS subsystem. Routines executed during subsystem initialization establish services that enable event information to be generated and stored in the extended common service area (ECSA).

[0005] In the IBM Z Workload Scheduler, the tracker handles job submissions on the system, keeps track of workload status, and sends event records to the controller system. Events are stored in the ECSA queue, then copied to the event dataset, and finally sent to the controller. If the tracker fails, any events in the ECSA queue that have not yet been copied to the event dataset will be unavailable until the tracker becomes operational again. Processing delays may occur for jobs that have already completed on the target system because the scheduler may prevent subsequent jobs from continuing execution until the controller receives a result indicating that the job has completed. [Overview of the project] [Problems that the invention aims to solve]

[0006] This is intended to provide high-availability scheduler event tracking for scheduler configurations such as IBM® Z® workload scheduler configurations. [Means for solving the problem]

[0007] Embodiments of the present invention relate to a method for tracking high-availability scheduler events. A non-limiting exemplary method includes monitoring the operational status of a tracker system configured by a controller to track and record the current status of jobs being executed and to report the completion of the jobs to the controller. The record includes storing two copies of the current status, including a first copy stored in a shared memory location accessible by the controller. In response to determining, based on the monitoring, that the tracker system is operational, the controller waits to receive a job completion message for the job from the tracker system and performs a job completion action based on receiving the job completion message. In response to determining that the tracker system is not operational, the controller retrieves the current status of the job from the shared memory location and performs the job completion action based on the current status indicating that the job has been completed.

[0008] This can provide an improvement over known tracking methods by mitigating processing delays that may occur in modern systems when the tracker system becomes unavailable. By promptly identifying completed jobs even when the tracker is not operational, one or more embodiments of the present invention enable a controller or scheduler to continue executing other jobs or actions that depend on completed jobs. This can result in improved response times and faster processing.

[0009] In addition to or alternative to one or more of the features described above or below, in further embodiments of the present invention, a second copy of the current status is stored in an Extended Common Service Area (ECSA) that is not accessible by the controller system. One or more embodiments advantageously provide local access to the current status to the tracking module.

[0010] In addition to or alternative to one or more of the features described above or below, in further embodiments of the present invention, the current status record corresponding to a job is removed from the shared memory location when the job is completed. One or more embodiments advantageously provide efficient use of shared memory storage.

[0011] In addition to or alternative to one or more of the features described above or below, in further embodiments of the present invention, the shared memory location is provided by a coupling facility (CF).

[0012] In addition to or alternative to one or more of the features described above or below, in further embodiments of the present invention, the tracker system is determined to be not operational in response to the controller being unable to communicate with the tracker system. One or more embodiments advantageously provide accelerated processing of job streams.

[0013] In addition to or alternative to one or more of the features described above or below, in further embodiments of the present invention, the job completion action includes initiating the execution of a second job. One or more embodiments advantageously provide accelerated processing of a stream of jobs.

[0014] In addition to or alternative to one or more of the features described above or below, in further embodiments of the present invention, the current status of a job is obtained from either or both of the System Management Function (SMF) records and the Job Entry System (JES) records.

[0015] Another embodiment of the present invention implements the features of the above method in a system and a computer program product.

[0016] Further technical features and benefits are realized by the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered to be part of the subject matter claimed. For a better understanding, refer to the detailed description and drawings. [Brief explanation of the drawing]

[0017] Details of the exclusive rights described herein are specifically set forth and expressly claimed in the claims at the end of the specification. The aforementioned and other features and advantages of embodiments of the present invention will become apparent from the following detailed description when read in conjunction with the accompanying drawings.

[0018] [Figure 1] This is a block diagram of an operating environment providing high-availability event scheduler tracking according to one or more embodiments of the present invention.

[0019] [Figure 2] This is a block diagram of a tracker according to one or more embodiments of the present invention.

[0020] [Figure 3] This is a block diagram of a workflow executed by a tracker and controller according to one or more embodiments of the present invention.

[0021] [Figure 4] This is a block diagram of a workflow executed by multiple trackers and controllers according to one or more embodiments of the present invention.

[0022] [Figure 5] A flowchart of a method for providing high availability scheduler event tracking according to one or more embodiments of the present invention.

[0023] [Figure 6] A diagram showing a cloud computing environment according to one or more embodiments of the present invention.

[0024] [Figure 7] A diagram showing an abstraction model layer according to one or more embodiments of the present invention.

[0025] [Figure 8] A diagram showing a system for providing high availability scheduler event tracking according to one or more embodiments of the present invention.

[0026] The figures shown herein are illustrative. Without departing from the spirit of the present invention, many modifications may be made to the figures or the operations described in the figures. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Also, the term "coupled" and its variations describe having a communication path between two elements and do not imply a direct connection between elements without intervening elements / connections therebetween. All of these modifications are considered to be a part of this specification.

Embodiments for Carrying Out the Invention

[0027] One or more embodiments of the present invention relate to providing highly available scheduler event tracking for scheduler configurations such as the IBM® Z® workload scheduler configuration in the event of execution tracker failures. One or more embodiments of the present invention use a coupling facility (CF) component that provides data sharing across system complexes (sysplexes) to store job event records, which are duplicates of job event records stored in an Extended Common Service Area (ECSA) queue of a tracker system (also referred to herein as the “tracker” or “execution tracker”). The operational status of the tracker is monitored by a tracker monitor module, which is run by a controller that notifies an event cross reader module to handle the process when the tracker becomes unavailable, for example, due to a failure that causes the tracker to terminate abnormally. According to one or more embodiments of the present invention, the event cross reader module reads job event records in the CF to determine the status of jobs previously tracked by the tracker, collects job execution results from job output, and writes the job event records to the tracker’s event dataset. When the controller is notified that a job has completed (for example, via the content of the event dataset), the scheduler can continue executing jobs that depend on the completed job. Job completion can be that the job completed successfully, was canceled, or terminated with an error. When the execution tracker becomes available to the sysplex again, it synchronizes the records in the event dataset, ECSA, and CF structure and continues execution.

[0028] By providing a method for monitoring tracker status and switching to an alternative method for obtaining job completion status when the tracker is not operational, one or more embodiments of the present invention can mitigate processing delays that may occur in modern systems. By promptly identifying completed jobs even when the tracker is not operational, one or more embodiments of the present invention enable a controller or scheduler to continue executing other jobs or actions that depend on completed jobs.

[0029] Referring here to Figure 1, a block diagram of an operating environment 100 providing high-availability scheduler tracking is generally shown according to one or more embodiments of the present invention. All or part of the operating environment 100 shown in Figure 1 can be implemented, for example, by the computer system 800 of Figure 8 and / or by one or more of the cloud computing nodes 10 and / or cloud computing devices 54A to 54N of Figure 6. The operating environment 100 shown in Figure 1 comprises a coupling facility (CF) 102, a controller system 104, and two tracker systems 106a, 106b (collectively referred to herein as “tracker system 106”).

[0030] The IBM Z Workload Scheduler can be used to implement a portion of the operating environment 100 shown in Figure 1. As previously stated, the controller system 104 is the focus of the IBM Z Workload Scheduler configuration, and the controller system 104 provides a single, consistent control point for submitting and tracking the workloads being run. The controller system 104 shown in Figure 1 includes a processor 110 that includes computer instructions for performing the operations described herein, for implementing controllers such as a tracker monitor and an event cross reader, etc., but is not limited to these.

[0031] According to one or more embodiments of the present invention, each system in an IBM Z workload scheduler configuration, such as the operating environment 100 in Figure 1, includes a tracker module implemented by a tracker system 106, which handles job and task submissions on the system and keeps track of workload status. As shown in the operating environment 100 in Figure 1, each of the tracker systems 106 communicates with the CF 102 and the controller system 104. Each tracker system 106 includes event datasets 122a, 122b (collectively referred to herein as “event datasets 122”), intermediate data storage locations 126a, 126b (collectively referred to herein as “storage locations 126”), and processors 150a, 150b (collectively referred to herein as “processors 150”) to run all or part of the tracker module. Each of the intermediate data storage locations 126 includes (ECSA) queues 124a, 124b (collectively referred to herein as “ECSA queue 124”). Each of the intermediate data storage locations 160 also includes Job Entry System (JES) and / or System Management Function (SMF) records 140a, 140b (collectively referred to herein as “JES and SMF records 140”) obtained from systems running workloads tracked by the tracker system 106.

[0032] Combined with standard interfaces to JES and SMF, the tracker system 106 records relevant information about the tracked workload by generating event records that are captured by the tracker and stored in the event dataset 122. The IBM Z workload scheduler address space can be defined as a z / OS® subsystem, and routines executed during subsystem initialization establish a service that enables event information to be generated and stored in the ECSA queue 124 even when the address space is inactive.

[0033] The tracker system 106 handles job submissions on the system, keeps track of workload status, and sends event records to the controller system 104. Events generated by completion (e.g., indicated by JES and SMF records 140) are stored in the ECSA queue 124, then copied to the event dataset 122, and finally sent to the controller system 104. According to one or more embodiments of the present invention, the coupling facility (CF) 102 is implemented in hardware, and the CF 102 allows multiple processors to access the same data.

[0034] As shown in Figure 1, CF102 is coupled to the controller system 104 and the tracker system 106. One or more embodiments of the present invention may utilize one or more CF102, which can store shared data using a CF list structure. Using CF enables data sharing between and within clusters while maintaining the integrity, consistency, and availability of shared data.

[0035] As shown in the operating environment 100 of Figure 1, according to one or more embodiments of the present invention, each of the tracker systems 106 writes job status records or event record data contained in the ECSA queue 124 to CF102. This connection, or writing of job status records to CF102, is shown in Figure 1 by arrows 120a and 120b. Also, as shown by arrows 112a and 112b in Figure 1, the processor 110 in the controller system 104 (for example, running a tracker monitor module) monitors the status of the processor 150 in the tracker system 106. In addition, as shown by arrow 118, if the tracker system 106 is not operational, a cross-reader module run by the processor 110 in the controller system 104 can access CF102 to read job information. The controller system 104 can then monitor the job to determine job completion, as shown by arrows 114a and 114b in Figure 1. When a job is completed, the controller system 104 writes a record to the event dataset 122 of the tracker system 106, as indicated by arrows 116a and 116b, to mark the job as completed. Job completion can indicate that the job was completed successfully, canceled, or terminated with an error (for example, via a job completion code or status).

[0036] Referring here to Figure 2, a block diagram 200 of the tracker is shown in general terms according to one or more embodiments of the present invention. All or part of the processes described with reference to the block diagram of Figure 2 can be performed, for example, by the computer system 800 of Figure 8 and / or by one or more of the cloud computing nodes 10 and / or cloud computing devices 54A to 54N of Figure 6. All or part of blocks 206, 208, 210, and 216 can be performed by computer instructions executed on the processor 150 of the tracker system 106 of Figure 1.

[0037] In block 202, a job is started, and calls are made to the SMF and JES interfaces to collect an end record associated with the started job. In block 204, information about events related to the job is collected. As is known in the art, the event information includes, but is not limited to, the job start date and time, the job name, the job identifier (ID), the job end date and time, and the job completion code. In one or more embodiments where the IBM Z Workload Scheduler is used, the IBM Z Workload Scheduler collects the information and passes it to the tracker. As shown in Figure 2, in block 206, the tracker receives the event information, constructs a job status record containing the event information, and stores it in ECSA queues 212 and CF214. The processing in blocks 204 and 206 can be repeated while the job is running.

[0038] Still referring to Figure 2, processing continues in block 208 and the job is completed. According to one or more embodiments of the present invention, the tracker receives notification that the job is completed when the tracker receives information including the job completion date and time. In block 210, the event writer portion of the tracker writes the job record to the event dataset 216 and removes any previously written event records associated with the job from CF214. According to one or more embodiments of the present invention, the job record includes: job start date and time, job name, job ID, job end date and time, and job completion code.

[0039] According to one or more embodiments of the present invention, when an execution tracker becomes available after being inactive for a period of time, the execution tracker resynchronizes events between the ECSA queue 212, CF 214, and event dataset 216.

[0040] As described above, according to one or more embodiments of the present invention, the tracker monitor or tracker monitor module is executed by the controller. Monitoring may include, for example, monitoring controller-tracker connections via TCP / IP, XCF, NCF, or a combination thereof. If the connection between the controller and the running tracker or tracker system is lost, the tracker monitor module initiates the execution of the event cross reader module. According to one or more embodiments of the present invention, the event cross reader module is executed by the controller (for example, as a subtask). If communication with the running tracker is lost, the event cross reader module reads information from the CF to obtain job information, and the event cross reader module invokes a program to monitor the job status. When the event cross reader module receives a job status indicating that the job has been completed, the event cross reader module writes a record to the event dataset of the running tracker. According to one or more embodiments of the present invention, if the tracker monitor module detects a connection between the running tracker and the controller, the subtask executing the event reader module is terminated, and the tracker takes over the process of tracking events. According to one or more embodiments of the present invention, a separate event reader on the controller processes the event, and the IBM Z workload scheduler takes the relevant action defined in the running application. The action may include, but is not limited to, continuing execution and suspending execution.

[0041] According to one or more embodiments of the present invention, job status or event data is not lost when the tracker is not operational, as long as the CF structure is large enough to hold all event records for jobs running in the sysplex during the same period, and the event dataset is large enough to hold all event records for jobs completed in a logical partition (LPAR) during the same period.

[0042] Referring here to Figure 3, a block diagram 300 of the workflow performed by the tracker 302, such as the tracker system 106a in Figure 1, and the controller 304, such as the controller system 104 in Figure 1, is generally shown according to one or more embodiments of the present invention. All or part of the processing described with reference to the block diagram in Figure 3 can be performed, for example, by the computer system 800 in Figure 8, and / or by one or more of the cloud computing nodes 10 and / or cloud computing devices 54A to 54N in Figure 6. As shown in the embodiment of Figure 3, the tracker 302 runs on "SYSA" and the controller 304 runs on "SYSB". A "tracker monitor" run by the controller 304 is also shown in Figure 3. According to one or more embodiments of the present invention, the tracker monitor continuously monitors the operational status of the tracker 302 via XCF, NCF, TCP / IP, or a combination thereof.

[0043] In block 306, the tracker 302 starts the job, and in block 310, the job is initiated. In response to the job being initiated in block 310, processing continues in blocks 314 and 326. In block 314, the tracker 302 constructs a job status record or event record containing job information that the tracker 302 stores in the ECSA queue 312 and CF 324 (e.g., from JES and / or SMF record 308). In block 326, the job status is changed from ready to started in controller 304. In block 316, it is determined whether an execution tracker failure has occurred. This can be determined, for example, by a tracker that is not able to communicate with controller 304, or by a tracker 302 that reports a failure to controller 304, or by any other method.

[0044] If block 316 determines that no tracker failure occurred while the job was running, processing continues in block 318, and the event writer of tracker 302 writes a job record to event dataset 322 upon job completion. The job record may, but is not limited to, the job start date and time, job name, job ID, job end date and time, and job completion code (e.g., successful completion, canceled, or termination with an error). In addition, any previously written event records associated with the job are removed from CF324. According to one or more embodiments of the present invention, only jobs that are currently in progress have event records in CF324.

[0045] If a tracker failure is determined in block 316 of Figure 3, the tracker monitor notifies the controller 304 in block 328 that a tracker failure has been detected. In block 330, the tracker monitor module notifies or starts an event cross-reader subtask or module to take over the process. In block 332, the event cross-reader module reads an event record about the job from CF324, and in block 334, the event cross-reader module starts code on tracker 302 to read the job status. The job is then monitored for job completion. According to one or more embodiments of the present invention, the event record includes the job name and job ID used in block 320 to obtain the job status from the JES record of the execution system (e.g., LPAR). The job completion status may include that the job was completed successfully, that the job was canceled, or that the job terminated with an error.

[0046] When it is determined that a job is complete, the event cross reader module writes a record to CF324 to mark the job as complete, and the record includes a job completion code indicating whether the job was completed successfully, canceled, or terminated with an error. Processing continues in block 336, where a job record indicating that the job is complete is written to event dataset 322. In block 338, the event reader on controller 304 receives notification that the job is complete, and controller 304 performs a job action in block 340. According to one or more embodiments of the present invention, the job action may include, but is not limited to, continuing execution and suspending execution.

[0047] The process flow diagram in Figure 3 is not intended to show that operations are performed in any particular order, or that all operations shown in Figure 3 are included in all cases. In addition, the process shown in Figure 3 may include any number of additional operations as appropriate.

[0048] According to one or more embodiments of the present invention, one tracker exists on each logical partition (LPAR). A job can be submitted from a tracker located on a first LPAR, but the job can be executed on a second LPAR (not the submitting LPAR). The job status can be tracked by the first LPAR, and an event writer on the second LPAR can write event records to an ECSA queue. An example of this configuration is shown in Figure 4.

[0049] Referring here to Figure 4, a block diagram 400 of the workflow performed by tracker 406, tracker 408, and controller 304 is generally shown according to one or more embodiments of the present invention. All or part of the processing described with reference to the block diagram in Figure 4 can be performed, for example, by the computer system 800 in Figure 8, and / or by one or more of the cloud computing nodes 10 and / or cloud computing devices 54A to 54N in Figure 6. As shown in the embodiment of Figure 4, tracker 408 runs on "SYS A", tracker 406 runs on "SYS C", and controller 304 runs on "SYS B". In Figure 4, a "tracker monitor" or tracker monitor module is also shown, which is performed by controller 304 and, according to one or more embodiments of the present invention, continuously monitors the operational status of tracker 406 and tracker 408, for example, via XCF, NCF, TCP / IP, or a combination thereof.

[0050] As shown in Figure 4, the execution tracker module 402 is executed by tracker 406, and the tracing tracker 404 is executed by tracker 408. In block 306, tracker 408 starts a job for execution on "SYS C", where tracker 406 is running. In block 310, the job is started, at least partially, based on the JES and / or SMF record 308. In response to the job being started in block 310, processing continues in blocks 314 and 326. In block 314, the execution tracker module 402, which is being executed by tracker 406, constructs a job status record or event record containing job information that tracker 406 stores in ECSA queue 312 and CF324. In block 326, the job status is changed from ready to started by controller 416. In block 316, it is determined whether an execution tracker failure has occurred.

[0051] If it is determined in block 316 that no tracker failure occurred while the job was running, processing continues in block 318, and the event writer writes a job record to the event dataset 322 when the job is completed. The job record may, but is not limited to, the job start date and time, job name, job ID, job end date and time, and job completion code. In addition, any previously written event records associated with the job are removed from CF324. According to one or more embodiments of the present invention, only jobs that are in progress have event records in CF324.

[0052] If a tracker failure is determined in block 316 of Figure 4, the tracker monitor notifies the controller 304 in block 328 that a tracker failure has been detected. In block 330, the tracker monitor module notifies the event cross reader subtask or module to take over the process or starts it. In block 332, the event cross module reads the event record for the job from CF324, and in block 334, the event cross module starts code on tracker 406, which reads the job status. The job is then monitored for job completion.

[0053] When the event cross reader module determines that the job is complete, it writes a record to CF324 to mark the job as complete. The record includes a job completion code indicating whether the job was completed successfully, canceled, or terminated with an error. Processing continues in block 336, where a job record indicating that the job is complete is written to event dataset 322. In block 338, the event reader on controller 304 receives notification that the job is complete, and controller 304 executes the job action in block 340.

[0054] The embodiment shown in Figure 4 enables continued tracking of job status when the execution tracker module 402 drops out of the sysplex (for example, becomes inoperable or unreachable via the communication link). This continued tracking can be performed without interfering with or losing execution schedules and event records or job status records.

[0055] The process flow diagram in Figure 4 is not intended to show that operations are performed in any particular order, or that all operations shown in Figure 4 are included in all cases. In addition, the process shown in Figure 4 may include any number of additional operations as appropriate.

[0056] Referring here to Figure 5, a flowchart of method 500 for providing high-availability scheduler tracking is generally shown according to one or more embodiments of the present invention. All or part of the processes described with reference to the block diagram of Figure 5 can be performed, for example, by the controller system 104 of Figure 1, or by the controller 304 of Figures 3 and 4.

[0057] In block 502, the controller monitors the operational status of a tracker system configured to track and record the current status of jobs being executed. The current status can be obtained, for example, based on data from either or both of the System Administration Function (SMF) records and the Job Entry System (JES) records.

[0058] The tracker system is also configured to report job completion to the controller. The record includes storing two copies of the current status, the first copy of which is stored in a shared memory location accessible by the controller, such as a CF. According to one or more embodiments of the present invention, the second copy of the current status is stored in an Extended Common Service Area (ECSA) queue that is not accessible by the controller.

[0059] In block 504, it is determined, at least in part, based on monitoring, whether the tracker is operational. This can be determined, for example, based on whether the controller can communicate with the tracker system. In response to the determination in block 504 that the tracker is operational, processing continues in block 506, where the controller waits for a job completion message from the tracker about the job. In response to receiving a job completion message or indication, the controller takes a job completion action in block 512. According to one or more embodiments of the present invention, the job completion message is a record in the event dataset. The job completion action is based on how the job was completed (e.g., error, cancellation, no error) and may include, for example, starting the execution of one or more additional jobs that depend on the job being completed, or restarting the job if the job ended with an error or was canceled.

[0060] In response to determining in block 504 that the tracker is not operational, processing continues in block 508 to retrieve the current status of the job from a shared memory location. In block 510, it is determined whether the current status of the job indicates that the job is complete. If the job is not complete, processing continues in block 508 to retrieve the current status of the job. If the job is complete, as determined in block 510, processing continues in block 512. According to one or more embodiments of the present invention, the current status record corresponding to the job is removed from the shared memory location when the job is complete.

[0061] The process flow diagram in Figure 5 is not intended to show that operations are performed in any particular order, or that all operations shown in Figure 5 are included in all cases. In addition, the process shown in Figure 5 may include any number of additional operations as appropriate.

[0062] While this disclosure includes a detailed description of cloud computing, it should be understood that the implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in combination with any other type of computing environment that is currently known or may be developed in the future.

[0063] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and deployed with minimal administrative effort or interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0064] The characteristics are as follows:

[0065] On-demand self-service: Cloud consumers can unilaterally provision computing power, such as server time and network storage, automatically as needed, without requiring human interaction with service providers.

[0066] Broad network access: This capability is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0067] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. While consumers generally have no control or knowledge of the exact location of the resources provided, there is location independence in that they may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0068] Rapid resilience: This capability allows for rapid and elastic provisioning, sometimes automatically, enabling quick scaling out and rapid release and rapid scaling in. To consumers, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0069] Services measured: Cloud systems automatically control and optimize resource usage by leveraging metric capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0070] The service model is as follows:

[0071] Software as a Service (SaaS): The ability provided to consumers is the use of a provider's applications running on cloud infrastructure. These applications are accessible from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0072] Platform as a Service (PaaS): The ability provided to consumers is to deploy applications they have created or acquired, written using programming languages ​​and tools supported by the provider, on a cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they do control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0073] Infrastructure as a Service (IaaS): The ability provided to consumers is to provision processing, storage, networking, and other basic computing resources, where consumers can deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating system, storage, and deployed applications, and in some cases have limited control over selected networking components (e.g., host firewalls).

[0074] The deployment model is as follows:

[0075] Private Cloud: This cloud infrastructure operates solely for a specific organization. It may be managed by that organization or a third party, and may reside on-premises or off-premises.

[0076] Community Cloud: This cloud infrastructure is shared by several organizations and supports a specific community that shares common interests (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by these organizations or third parties and may reside on-premises or off-premises.

[0077] Public Cloud: This cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0078] Hybrid Cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain separate entities but are joined together by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0079] Cloud computing environments are service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing lies an infrastructure that includes a network of interconnected nodes.

[0080] Referring now to Figure 6, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 comprises one or more cloud computing nodes 10 that can communicate with local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or a combination thereof. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped within one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or a combination thereof, as described above in this specification (not shown). This enables the cloud computing environment 50 to provide infrastructure, platforms, or software, or a combination thereof, as a service that does not require cloud consumers to maintain resources on their local computing devices. The types of computing devices 54A to 54N shown in Figure 6 are for illustrative purposes only, and it should be understood that the computing node 10 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network, or a network addressable connection, or both (for example, using a web browser).

[0081] Referring now to Figure 7, a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 6) is shown. It should be understood in advance that the components, layers, and functionalities shown in Figure 7 are for illustrative purposes only and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functionalities are provided:

[0082] The hardware and software layer 60 comprises hardware components and software components. Examples of hardware components include: a mainframe 61; a RISC (Reduced Instruction Set Computer) architecture-based server 62; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0083] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73 including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0084] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Measurement and pricing 82 provides cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) planning and execution 85 provides pre-arrangements and procurement of cloud computing resources where future requirements are expected to conform to the SLA.

[0085] The workload layer 90 provides examples of functions that can be utilized in a cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and data encryption / decryption 96.

[0086] It is understood that one or more embodiments of the present invention can be implemented in combination with any other type of computing environment that is currently known or may be developed in the future.

[0087] Referring here to Figure 8, the computer system 800 is shown in general terms according to one embodiment. All or part of the computer system 800 shown in Figure 8 can be implemented by one or more cloud computing nodes 10 and / or cloud computing devices 54A-54N of Figure 6. The computer system 800 can be an electronic computer framework that includes, utilizes, or both, any number and combination of computing devices and networks that utilize various communication technologies, as described herein. The computer system 800 can be easily scaled, extensible, and modular, with the ability to change to different services or to reconfigure some features independently of others. The computer system 800 may be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smartphone. In some examples, the computer system 800 may be a cloud computing node. The computer system 800 may be described in the general context of computer system executable instructions, such as program modules, that are executed by the computer system. In general, a program module may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system 800 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may reside in both local computer system storage media, including memory storage devices, and remote computer system storage media.

[0088] As shown in Figure 8, the computer system 800 has one or more central processing units (CPUs) 801a, 801b, 801c, etc. (collectively or commonly referred to as processors 801). Processors 801 can be single-core processors, multi-core processors, computing clusters, or any number of other configurations. Also referred to as processing circuits, processors 801 are coupled to system memory 803 and various other components via system bus 802. System memory 803 may include read-only memory (ROM) 804 and random-access memory (RAM) 805. ROM 804 is coupled to system bus 802 and may include a basic input / output system (BIOS), which controls certain basic functions of computer system 800. RAM is read-write memory coupled to system bus 802 for use by processors 801. System memory 803 provides temporary memory space for the operation of the above instructions in motion. The system memory 803 may include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0089] The computer system 800 includes an input / output (I / O) adapter 806 and a communication adapter 807 coupled to a system bus 802. The I / O adapter 806 may be a serial advanced technology attachment (SATA) adapter that communicates with a hard disk 808 or any other similar component, or a combination thereof. The I / O adapter 806 and the hard disk 808 are collectively referred to as mass storage 810 in this specification.

[0090] Software 811 for execution on computer system 800 may be stored in mass storage 810. Mass storage 810 is an example of a tangible storage medium readable by processor 801, and software 811 is stored as instructions to be executed by processor 801 to make computer system 800 work, as described herein with respect to various figures. Examples of computer program products and the execution of such instructions are discussed in more detail herein. A communication adapter 807 interconnects system bus 802 with network 812, which may be an external network that enables computer system 800 to communicate with other such systems. In one embodiment, portions of system memory 803 and mass storage 810 collectively store an operating system, which may be any suitable operating system, such as z / OS® or AIX®, for coordinating the functions of the various components shown in Figure 8.

[0091] Additional input / output devices are shown connected to the system bus 802 via display adapter 815 and interface adapter 816. In one embodiment, adapters 806, 807, 815, and 816 may be connected to one or more I / O buses connected to the system bus 802 via an intermediate bus bridge (not shown). A display 819 (e.g., a screen on a display monitor) is connected to the system bus 802 by display adapter 815, which may include a graphics controller and a video controller to improve the performance of graphics-intensive applications. A keyboard 821, mouse 822, speaker 823, etc., can be interconnected to the system bus 802 via interface adapter 816, which may include, for example, a super I / O chip that integrates multiple device adapters into a single integrated circuit. Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI). Therefore, as configured in Figure 8, the computer system 800 includes processing functions in the form of a processor 801, storage functions including system memory 803 and mass storage 810, input means such as a keyboard 821 and a mouse 822, and output functions including a speaker 823 and a display 819.

[0092] In some embodiments, the communication adapter 807 can transmit data using any suitable interface or protocol, such as, in particular, an Internet Small Computer System interface. The network 812 may be, in particular, a cellular network, a wireless network, a wide area network (WAN), a local area network (LAN), or the Internet. An external computing device may be connected to the computer system 800 via the network 812. In some examples, the external computing device may be an external web server or a cloud computing node.

[0093] It should be understood that the block diagram in Figure 8 is not intended to show that the computer system 800 includes all the components shown in Figure 8. Rather, the computer system 800 may include any suitable fewer or additional components not shown in Figure 8 (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, embodiments of the computer system 800 described herein may be implemented using any suitable logic, which, as referred herein, in various embodiments may include any suitable hardware (e.g., processors, embedded controllers, application-specific integrated circuits), software (e.g., applications), firmware, or any suitable combination of hardware, software, and firmware.

[0094] Various embodiments of the present invention are described herein with reference to the relevant drawings. Alternative embodiments of the present invention may be conceived without departing from the scope of the invention. Various connections and positional relationships (e.g., above, below, adjacent, etc.) are described between elements in the following description and drawings. These connections or positional relationships, or both, may be direct or indirect unless otherwise specified, and the present invention is not intended to be limited in this respect. Thus, connections between entities may refer to direct or indirect connections, and positional relationships between entities may be direct or indirect positional relationships. Furthermore, the various tasks and process steps described herein may be incorporated into broader procedures or processes having additional steps or functions not described in detail herein.

[0095] One or more of the methods described herein can be implemented using any or a combination of the following technologies, each well known in the art: discrete logic circuits having logic gates for implementing logic functions for data signals, application-specific integrated circuits (ASICs) having appropriate combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0096] For the sake of brevity, prior art relating to the manufacture and use of aspects of the present invention may or may not be described in detail herein. In particular, various forms of computing systems and specific computer programs for implementing the various technical features described herein are well known. Therefore, for the sake of brevity, many prior art implementation details are mentioned only briefly herein, or are omitted entirely without providing details of well known systems or processes or both.

[0097] In some embodiments, various functions or operations can be performed at a given location, in connection with the operation of one or more devices or systems, or both. In some embodiments, a portion of a given function or operation can be performed at a first device or location, and the remainder of the function or operation can be performed at one or more additional devices or locations.

[0098] The terminology used herein is for the purpose of describing specific embodiments only and is not intended to limit them. Where used herein, the singular forms "a," "an," and "the" are intended to include the plural form unless otherwise explicitly indicated by the context. Where used herein, the terms "comprises" or "comprising" or both specify the presence of the described feature, integer, stage, operation, element, or component or combination thereof, but do not exclude the presence or addition of one or more other features, integers, stages, operations, element components or groups or combinations thereof.

[0099] All corresponding structures, materials, actions, and equivalents of all means-plus-function elements or step-plus-function elements in the following claims are intended to include any structures, materials, or actions for performing a function in combination with other claimed elements, as specifically claimed. While this disclosure is presented for illustrative and explanatory purposes, it is not intended to be exhaustive or to limit the disclosed forms. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of this disclosure. The embodiments have been selected and described to best illustrate the principles and practical applications of this disclosure and to enable others skilled in the art to understand the disclosure in terms of various embodiments with various modifications to suit specific intended uses.

[0100] The drawings shown herein are illustrative. Many variations are possible to the drawings or the steps (or actions) described therein without departing from the spirit of this disclosure. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term “combined” describes the presence of a signal path between two elements and does not imply a direct connection between elements without an intervening element / connection. All of these variations are considered part of this disclosure.

[0101] The following definitions and abbreviations are used for interpretation of the claims and specification. Where used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” or “containing,” or other variations thereof, are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus comprising a list of elements is not necessarily limited to those elements alone and may include other elements not expressly enumerated or specific to such composition, mixture, process, method, article, or apparatus.

[0102] In addition, the term “exemplary” is used herein to mean “to serve as an example, case, or illustration.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as being preferable or advantageous to other embodiments or designs. The terms “at least one” and “one or more” are understood to include any integer greater than or equal to 1, i.e., 1, 2, 3, 4, etc. The term “a plurality” is understood to include any integer greater than or equal to 2, i.e., 2, 3, 4, 5, etc. The term “connection” may include both indirect and direct “connections.”

[0103] The terms “about,” “substantially,” and “approximately,” and their variations, are intended to include the degree of error associated with a measurement of a particular quantity based on equipment available at the time of filing this application. For example, “about” may include a range of ±8%, 5%, or 2% of a given value.

[0104] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or a set of mediums) having computer-readable program instructions that cause a processor to execute an aspect of the present invention.

[0105] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of those described above. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disk drives (HDDs), solid-state drives (SDDs), random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures recording instructions, and any suitable combination of those described above. When used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0106] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers such computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0107] The computer-readable program instructions that perform the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, the one or more programming languages ​​including object-oriented programming languages ​​such as Smalltalk®, C++, etc., and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or fully on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), and the connection may be to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can be personalized by executing computer-readable program instructions using state information of computer-readable program instructions in order to perform an aspect of the present invention.

[0108] Aspects of the present invention are described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in a flowchart or block diagram, or both, and any combination of blocks in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0109] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or another programmable data processing device to generate a machine, thereby creating means for implementing functions / operations specified in one or more blocks of a flowchart or block diagram, or both, through the instructions executed via the processor of the computer or other programmable data processing device. Furthermore, these computer-readable program instructions may be stored in a computer-readable storage medium, which can instruct a computer, a programmable data processing device, or another device, or a combination thereof, to function in a specific manner, thereby resulting in a computer-readable storage medium containing instructions that include instructions for implementing modes of functions / operations specified in one or more blocks of a flowchart or block diagram, or both.

[0110] Furthermore, computer-readable program instructions can be loaded into a computer, other programmable data processing device, or other device to execute a series of operational steps on the computer, other programmable device, or other device, thereby generating a computer implementation process in which the instructions executed on the computer, other programmable device, or other device implement the functions / operations specified in one or more blocks of a flowchart or block diagram, or both.

[0111] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions that implement a specified logical function. In some alternative implementations, the functions described in the blocks may be performed in an order different from the order shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, and blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, or both, and any combination of blocks in the block diagram or flowchart, or both, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0112] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or limit to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technologies available on the market of the embodiments, or to enable other persons skilled in the art to understand the embodiments described herein.

Claims

1. The step of monitoring the operational status of a tracker system configured by a controller to track and record the current status of a job being executed and to report the completion of the job to the controller, wherein the record includes storing two copies of the current status, including storing a first copy in a shared memory location accessible by the controller; A step in which, in response to determining that the tracker system is operational based on the monitoring, the system waits for a job completion message for the job to be received from the tracker system, and performs a job completion action based on the receipt of the job completion message; and In response to determining, based on the aforementioned monitoring, that the tracker system is not operational: The step of obtaining the current status of the job from the shared memory location; and A step in which the job completion action is performed based on the current status indicating that the job has been completed. A method that includes [a certain feature].

2. The method according to claim 1, wherein a second copy of the current status is stored in an Extended Common Service Area (ECSA) queue that is not accessible by the controller.

3. The method according to claim 1, wherein one or more current status records corresponding to the job are removed from the shared memory location when the job is completed.

4. The method according to claim 1, wherein the shared memory location is provided by a coupling facility (CF).

5. The method according to claim 1, wherein the tracker system is determined to be not operational in response to the controller being unable to communicate with the tracker system.

6. The method according to claim 1, wherein the job completion action includes initiating the execution of a second job.

7. The method according to any one of claims 1 to 6, wherein the current status of the job is obtained from either or both of the System Management Function (SMF) record and the Job Input System (JES) record.

8. The system comprises one or more processors that execute computer-readable instructions, wherein the computer-readable instructions are: An operation to monitor the operational status of a tracker system configured by a controller to track and record the current status of a job being executed and to report the completion of the job to the controller, wherein the record includes storing two copies of the current status, including storing a first copy in a shared memory location accessible by the controller; Based on the monitoring, the tracker system determines that it is operational, and in response, waits to receive a job completion message for the job from the tracker system, and performs a job completion action upon receiving the job completion message; and In response to determining, based on the aforementioned monitoring, that the tracker system is not operational: The operation of obtaining the current status of the job from the shared memory location; and A system that controls one or more processors to perform an action that performs the job completion action based on the current status indicating that the job has been completed.

9. The system according to claim 8, wherein a second copy of the current status is stored in an Extended Common Service Area (ECSA) queue that is not accessible by the controller.

10. The system according to claim 8, wherein one or more current status records corresponding to the job are removed from the shared memory location when the job is completed.

11. The system according to claim 8, wherein the shared memory location is provided by a coupling facility (CF).

12. The system according to claim 8, wherein the tracker system is determined to be not operational in response to the controller being unable to communicate with the tracker system.

13. The system according to claim 8, wherein the job completion action includes initiating the execution of a second job.

14. The system according to any one of claims 8 to 13, wherein the current status of the job is obtained from either or both of the System Management Function (SMF) records and the Job Input System (JES) records.

15. For one or more processors: A procedure for monitoring the operational status of a tracker system configured by a controller to track and record the current status of a job being executed and to report the completion of the job to the controller, wherein the record includes storing two copies of the current status, including storing a first copy in a shared memory location accessible by the controller; A procedure to wait for a job completion message for the job to be received from the tracker system in response to determining that the tracker system is operational based on the monitoring, and to perform a job completion action based on receiving the job completion message; and In response to determining, based on the aforementioned monitoring, that the tracker system is not operational: A procedure for obtaining the current status of the job from the shared memory location; and A procedure for performing the job completion action based on the current status indicating that the job has been completed. A computer program designed to execute something.

16. The computer program according to claim 15, wherein a second copy of the current status is stored in an Extended Common Service Area (ECSA) queue that is not accessible by the controller.

17. The computer program according to claim 15, wherein one or more current status records corresponding to the job are removed from the shared memory location when the job is completed.

18. The computer program according to claim 15, wherein the shared memory location is provided by a coupling facility (CF).

19. The computer program according to claim 15, wherein the controller determines that the tracker system is not operational in response to the controller being unable to communicate with the tracker system.

20. The computer program according to any one of claims 15 to 19, wherein the job completion action includes initiating the execution of a second job.

Images