Tivoli Workload Scheduler

Workload management tools automate the scheduling and allocation of hundreds or thousands of interactive and batch jobs among the various computers on the network. This scheduling and allocation may be based on such criteria as time deadlines, the completion of other jobs, the needs of particular applications. Workload management tools must also monitor job completion status and allow systems administrators to establish job or application priorities in order to optimize network performance.

IBM Tivoli Workload Scheduler does not belong to the original Tivoli product line. It is rebranded and modified product called Maestro form Unison Inc. When IBM acquired Tivoli in 1996, the program was renamed IBM Tivoli Workload Scheduler. Founded in 1979, Unison was the established leader in systems management for the Hewlett-Packard marketplace and has moved into the open systems market with support for the leading Unix platforms, including the HP 9000, IBM RS/6000, Sun SPARC, Sequent, and Siemens-Nixdorf MIPS-ABI. Unison Software, Inc. was incorporated in California in 1980 and reincorporated in Delaware in July 1995. The Company's principal executive office were located in Santa Clara. Stock was traded on the Nasdaq under the symbol "UNSN."

Unison Maestro was a full-featured tool for managing background batch processing in a distributed computing environment. Maestro was originally released for the HP3000 in 1985. Maestro was first released for UNIX in 1993 and for Windows NT in 1996. It was selected for HP's OpenView Premier Solutions Partner Program in April 1994, received NetView certification in late 1994. Unison was the leader in providing Workload management tools to large, commercial organizations first on HP3000 systems, and then for UNIX environments (in 1993) and for Microsoft Windows NT (in 1996). At peat Unison used to have approximatly 350 customers of Maestro for Unix. Among them were The Prudential, Home Depot, Northern Telecom, Nike Securities, Signet Bank, and Weyerhaeuser. Pricing for Unix started at $8K for the first system.

Maestro's architecture allowed for central administration, monitoring and control of planned and ad hoc batch processing throughout a network. The administrator identifies planned and ad hoc jobs, and specifies rules by which jobs are scheduled (e.g., every payday), sequenced (some jobs may have to follow certain other jobs) or otherwise constrained (certain jobs cannot run at the same time or only so many jobs can run at one time). Maestro then selects planned jobs that need to be run for all devices in the network, and manages their execution to maximize the number of jobs processed without violating the specified constraints. As additional ad hoc jobs are submitted by users, Maestro manages them together with the planned jobs. Maestro provides a high degree of fault tolerance by supporting peer-to-peer operation, such that each system is capable of continuing full operations regardless of the availability of other resources.

The development of networked systems management tools for UNIX environments has generally not kept pace with advances made in other client/server technologies. As a result, robust, commercial quality systems management tools generally have not been available until 1995. Instead, organizations are relying on a number of alternatives, none of which provides a complete solution. These alternatives include human oversight and intervention, internally-developed tools and earlier generation systems management tools, such as the system utilities provided with UNIX which provide limited scheduling and backup capabilities. Individual hardware manufacturers also provide tools for their systems, but such manufacturers have little incentive to provide effective multi-vendor solutions. Other alternatives include adaptations of mainframe management systems, which were not originally designed for use in distributed, multi-computer environments, and tools developed for technical UNIX environments, which generally lack the necessary user interfaces, robustness and fault tolerance to support business critical applications. As a result, while open systems hardware typically costs less than comparable proprietary hardware, the Company believes that the systems management costs of open systems, including staff costs, can run significantly higher than the costs of proprietary systems. See Unison Maestro

Tivoli Maestro is to provide us with the ability to automate batch job scheduling in a multiplatform environment. The batch job is basically operating system support commands or scripts; however, Tivoli in addition, offers an extended method to control application batch jobs, such as SAP R/3 and BaaN IV. In this section, we describe the basic function and usage of Tivoli Maestro so you will understand how Tivoli Maestro works in an SAP R/3 environment and to evaluate the true benefit which Tivoli Maestro can offer you.

IBM Tivoli Workload Scheduler is composed of three major parts:

IBM Tivoli Workload Scheduler engine. It is nstalled on every non-mainframe workstation in the scheduling network (UNIX, Windows, and OS/400 computers). When the engine is installed on a workstation, it can be configured to play a specific role in the scheduling network. For example, the engine can be configured to be a master domain manager, a domain manager, or a fault-tolerant agent. In an ordinary Tivoli Workload Scheduler network, there is a single master domain manager at the top of the network.

IBM Tivoli Workload Scheduler connector. The connector "connects" the Job Scheduling Console to Tivoli Workload Scheduler, routing commands from JSC to the Tivoli Workload Scheduler engine. In an ordinary IBM Tivoli Workload Scheduler network, the Tivoli Workload Scheduler connector is usually installed on the master domain manager. The connector software is installed on top of the Tivoli Management Framework, which must be configured as a Tivoli Management Region server or managed node. The connector software cannot be installed on a TMR endpoint.

Job Scheduling Console (JSC). JSC is the Java-based graphical user interface for the IBM Tivoli Workload Scheduler suite. The Job Scheduling Console runs on any machine from which you want to manage Tivoli Workload Scheduler plan and database objects. It provides, through the Tivoli Workload Scheduler connector, the functions of the command-line programs conman and composer.

Old News ;-)

This IBM Redbook explains the benefits and technical merits of integrating IBM Tivoli Workload Scheduler Distributed and IBM Tivoli Workload Scheduler for z/OS with other IBM products. Scheduling is a mission critical process for any company. However, when you talk about scheduling, you are really talking about an ecosystem. In this ecosystem, each solution is a building block that adds value to the overall solution. With IBM Tivoli Workload Scheduler, you can collect and add data to and from each component. In addition, expanding the scheduling ecosystem to include monitoring, management, help desk, storage, and business systems management provides greater value.
This book discusses all these integration points and provides detailed scenarios on how to integrate IBM Tivoli Workload Scheduler with these types of applications.
Because workload management is widely considered the nucleus of the data center, there are numerous opportunities for you to integrate IBM Tivoli Workload Scheduler with other products. This book addresses just some of these many opportunities. In terms of integration with IBM Tivoli Workload Scheduler, do not limit yourself to the products that this book discusses. Integration points discussed in this book should give you an idea of the potential value that IBM Tivoli Workload Scheduler integration can provide for your company.

News	Documentation	Recommended Links	Field Guides	Redbooks	TEC	Advanced Monitoring
Redbook Maintaining Your Tivoli Environment	Troubleshooting	Gateway Troubleshooting	Troubleshooting Endpoints	Using log files for troubleshooting	Task libraries	Etc

Tivoli Workload Scheduler

Old News ;-)

Recommended Links

Etc