Best practices for compressing and optimizing the job database in Job Management for OpenVMS

Products

• System Watchdog for OpenVMS

Issue/Introduction

This article describes the best-practices for optimizing the job database used by Job Management for OpenVMS.

Periodic maintenance of the job management database files is recommended for best product performance. That is especially true when your job database is dynamic with jobs being regularly created and deleted. Since this activity requires shutting down Job Management, it is best scheduled for a time when production jobs are not running.

Furthermore, it is not acceptable to make a copy of the job management database and then compressing the copy while production jobs are allowed to execute or other users are allowed to  update the job management database. If either of those activities are allowed during the compression operation, information will be lost.

Environment

OpenVMS VAX  running Job Management for OpenVMS r3.0 SP01

OpenVMS Alpha and I64 running Job Management for OpenVMS r3.1

Resolution

1. Ensure that there are no jobs currently running. Furthermore, in order to prevent jobs from starting, we recommend set the maximum job limit to 0. If you are running in a clustered environment, you must set the limit to 0 on all nodes in the cluster. The most efficient way to set the job limit to 0 is to execute the following command:

$ SCHEDULE SET MAX 0/ALL

2. Shutdown Job Management for OpenVMS. If you are running in a clustered environment, you must shutdown the product on all nodes in the cluster. The most efficient way to shutdown the product is to execute the following command:

$ SCHEDULE STOP/ALL

It is also very important to notify users to exit any Schedule Shell interface or Job Management GUI sessions; the job management database should not be accessed by anyone other than the person that is executing these steps.

3. If your job database is dynamic with jobs being regularly created and deleted, you should run the DB_UTILITY application. If your job database is static such that jobs are rarely deleted, then you may proceed to step 3; however, you may run db_utility if you wish to do so. In order to run db_utility, execute the following command:

$ RUN NSCHED$EXE:DB_UTILITY

The DB_UTILITY application will recover deleted space and clear the pending delete counter.

4. Optimize the database by running the SCHEDULE OPTIMIZE command as shown below:

$ SCHEDULE OPTIMIZE DATABASE/FULL

5. Restart Job Management for OpenVMS by executing the following command:

$@SYS$STARTUP:UJM$MANAGER$STARTUP

Tip: Use the SYSMAN utility to execute the startup procedure on multiple cluster members, or the entire cluster, without having to log in to each node to execute the startup procedure.

Additional Information

If your environment utilizes remote dependencies between standalone nodes, between clusters, or a combination of the two, you should notify your users to cease executing SCHEDULE commands on those remote nodes/clusters that use the /SERVER qualifier to target the node or cluster where the database is to be compressed.

Tip: You may temporarily rename the file SYS$SYSTEM:SCHED_DECNET.COM to SYS$SYSTEM:SCHED_DECNET.NOCOM in order to prevent remote users from accessing the node or cluster where the database is going to be compressed.