Camellia Batch Job Server Recommended for "cron-type" Functions on NT/2000
CTDATA has tested Batch Job Server from Camellia Software as a solution for controlling unattended server-based tasks on Windows NT and Windows 2000 servers. We consider it a reliable tool that provides more functionality than the UNIX cron system. In fact, we believe that BJS is a sophisticated job control system that mimics many of the mini-computer and mainframe batch control environments.
Read on if you want to know why we think so highly of it. We will also attempt to outline use strategy for this product.
CTDATA considers Windows NT and Windows 2000 useful as a client operating system, primarily because of the vast number of applications available for it and the guaranteed compatibility with Microsoft's consumer operating systems.
However, for historical reasons that go beyond the scope of this discussion CTDATA has several Windows NT 4.0 servers in production at this time. Our intermediate strategy is to replace Windows NT Server with Linux or Solaris wherever possible. But, this takes time for companies of our size and in our position in the market.
Last month, we found ourselves attempting to install a Web application designed for UNIX on an NT server. This application had a couple of very important cron jobs that kept much of the data presented to the user current. So, we started looking for ways to implement cron jobs on a Windows NT Server.
Our typical toolkit for making Windows NT run UNIX applications is ActivePerl from ActiveState Tool Corp, and MKS Toolkit from Mortice Kern Systems. However, neither of these products really addresses the issue of scheduling and executing batch jobs.
Most people who need to run unattended batch jobs on NT resort to using the at command in Windows NT. The problem with this strategy is that Windows NT is known to be fairly unreliable for real-time tasks because the scheduler within the operating system is rather flaky. We were looking for a more reliable plug and play solution that would allow us to monitor execution of our batches without having to write platform-specific code.
The O'Reilly book called Essential Windows NT System Administration by AEleen Frisch recommended the Batch Job Server product for this purpose. We had never heard of the developer of the product, Camellia Software, but we were willing to give it a try for 30 days as they recommend.
We found that the product performed as advertised. It is implemented as an NT service, and this makes it just about as reliable as the core operating system. It does an excellent job logging the result of batch jobs as they are executed. It has a lot of batch scheduling, execution, chaining, and termination options. Several of these options go well beyond our requirements in terms of the flexibility that they provide.
There are a couple of features on our wish list that are currently not implemented. The most important of these are:
- Scheduling of events to occur at regular intervals and at a specific time within that interval. A real world analogy: a news radio stations in the NYC markets runs traffic reports every 10 minutes, "on the eights". This means the report is at :08, :18, :28, :38, :48, and :58 past the hour. It is possible to use BJS to execute a task every 10 minutes, but the other dimension is not supported.
- Ability to replace Windows batch language with other scripting languages. The initial script triggered by the scheduler must be a Windows batch language (BAT) file. Of course, you can write a stub batch file to call your favorite scripting language -- that is what we have chosen to do. However, we would like to be able to choose any scripting language that runs under Windows from the outset.
Other than those features that we would like to see implemented, we have not encountered any issues with the product.
Some users may object to the license cost of approximately $500 per server. However, we believe the cost is justifiable, if you have a "mission-critical" application that depends upon unattended batch jobs to maintain itself. We certainly have applications like that. Therefore, the cost of this product was justifyable to us.