We have nearly finished the internal testing phase of our Job Tracking product JT4i and are now looking for some external clients that would be willing to test in their real life environments.
Job Tracking is something that is never mentioned when High Availability or Disaster Recovery on the IBMi is sold into the client base, but we feel it’s something that should warrant a discussion. Many of the applications that run on the IBMi today have been built around batch processes which are responsible for generating a large amount of data and object changes. These batch processes can either be managed by a Job Scheduling software or submission by programs and individual operators. If a system loss occurs during the batch processing it could leave a lot of data which has been generated by the batch program in the application database that may need to be removed or recovered before the application can be restarted. If you are running a High Availability Product that data is most likely already applied on the target, so before allowing the application to be restarted you may need to remove some or all of that data.
In the situation where you are running a Job Scheduler and have that scheduler content replicated to the remote system you might be able to see the jobs which were submitted and which were still waiting to be run. However, if those jobs had already been submitted you may not know how far they were into the processing cycle or what data and objects those jobs have affected. In addition you may not even know all of the jobs that were loaded to the job queue as they could have been loaded outside of the Job Scheduler. It is no longer uncommon to see the IBMi process requests from outside platforms or processes, many of these are loaded via job queues for processing not via a job scheduler so tracking them and being able to resubmit them on the target system is more than likely impossible.
JT4i is a product which tracks all of the jobs submitted via the job queue, it will capture all of the information required to resubmit those jobs and store it in a set of database files which can be replicated to the recovery system. It does not touch or interfere with the job queues on either system to carry out the data capture and store, the jobs will run in exactly the same manner with no additional delays. When you need to recover you use a single command to load all of the job queues with the required jobs, each job will be loaded with the same attributes they were loaded on the source right down to the scheduled date and time and priorities. If a job has already started on the source system and it did not complete we have provided tools that will allow you to identify the data and objects affected by that job, this will allow decisions to be made on how the recovery needs to be completed to ensure your applications can start with data integrity maintained.
We have many discussion with clients about the need for JT4i, one of one the main reasons for needing it is where you run any kind of batch that generates data and object changes which could affect your ability to recovery on your target system. If you do not run any batch processes JT4i is definitely not required, but just because you run a Job Scheduler does not mean you are safe and do not need it. A number of our largest clients do run the best Job Schedulers on the market, but they still need Job Tracking to fill in the gaps those job schedulers do not fill. This recent rewrite has greatly improved the responsiveness and manageability of the product with many new features. It has also allowed us to ensure the code is as clean and efficient as possible so we are not bolting on new features, they are built into the core.
If you would be interested in having a no obligation trial of the product please let us know, we will help you install and configure the product at no cost to you. That alone will save you money if you decide to keep the product.
Chris…