* The company names and the contents of the case studies are given as of the time of the interview.

A Japanese manufacturer has been using IBM mainframe and A-AUTO for mainframe for more than twenty years. The company has two main data centers in Japan. In 2000 it started downsizing, application by application. Currently they have more than 150 UNIX/Windows servers. For these servers, they were using cron to schedule batch jobs in each server by date and time only. This meant that they had to set up some allowance between dependent jobs to absorb some delay of the prior jobs. But even this did not guarantee that jobs would run in the correct sequence. Also they had to manually synchronize the mainframe processes and the open server processes.

In 2003, with more and more servers, the company decided to implement a more functional job-scheduling system on all open servers. The scheduling system had to be able to control dependencies between mainframe and open servers and among open servers. Also the company wanted to manage all jobs in all the servers in one scheduling database. AIX, Solaris, and Windows platforms had to be supported. They analyzed the pros and cons of using A-AUTO for UNIX and A-REMOTE for UNIX rather than other scheduling software, such as Tivoli and Hitachi's JP1. They decided to use A-REMOTE because they are familiar with A-AUTO and they wanted to centrally manage schedules in all the servers. By installing A-REMOTE in each server, they can integrate the scheduling of batch jobs in all servers, and control the dependencies between servers.

In the three-level system structure, A-AUTO for mainframe schedules all the jobs run in mainframe, and A-AUTO for UNIX schedules all the jobs run on the open servers. Jobs that run on open servers are queued into A-AUTO for UNIX's Network Queue once a day, usually at the start of the day. A-AUTO for UNIX monitors the jobs in the Network Queue and directs them to the appropriate servers when they are ready to be executed. Then A-REMOTE for UNIX/Windows actually executes the jobs at the server.

By 2005, the company had installed 80 A-REMOTEs connected to one A-AUTO for UNIX for the production environment. For the development and test environment, they installed 50 A-REMOTEs connected to one A-AUTO for UNIX. Here they had one problem. A-AUTO for UNIX can manage only 255 concurrent jobs. If A-REMOTE for UNIX/Windows submits resident jobs, this limit is reached easily. The company therefore made A-REMOTE submit jobs that initiate resident jobs. The execution status of each of these resident jobs is monitored by Tivoli. Then A-REMOTE submits jobs that terminate resident jobs when they are ready to be terminated. Thus they avoid the limitation of 255 concurrent jobs.

Also they encountered a limitation of A-SUPERVISION/Server. They have over 100 people who monitor and manage the scheduling of application jobs, but one A-SUPERVISION/Server supports only 45 A-SUPERVISION clients. The company therefore installed four A-SUPERVISION/Servers. An A-SUPERVISION/Client is used to display only the progress of the jobs that one person schedules and monitors and to report any delay or abnormal termination. Please refer to the diagram below.

To avoid a company-wide shut down, the A-AUTO master server is duplicated. Its hardware, along with the network equipment, is monitored by Tivoli. The A-AUTO files are stored into IBM ESS (Enterprise Storage Server). Also IBM HACMP (High Availability Cluster Multiprocessing) is implemented to switch operation automatically to the backup system when the current system encounters trouble. Thus A-AUTO can continue its processing with no interruption.