Contents Index JAMS Home Support

This chapter explains management of JAMS.

11.1 JAMS Processes

When the JAMS start-up procedure is executed on OpenVMS one, two or three detached processes will be started. The JAMS_MONITOR process is started on all OpenVMS nodes and the JAMS_SCHEDULE and JAMS_NETWORK processes are started on one OpenVMS node in the VMScluster.

On Windows NT/2000 systems, the JAMS Agent service must be running.

11.1.1 The JAMS_MONITOR process

The JAMS_MONITOR process must be running on all OpenVMS nodes which will process batch jobs. The JAMS_MONITOR process monitors the creation and termination of batch processes. It also will redirect connection requests from remote nodes to the node in the VMScluster which is running the JAMS_NETWORK process. Do not confuse the JAMS_MONITOR process with the JAMS Job Monitor function. The JAMS_MONITOR is notified of the creation of a batch process by the JAMS_REGISTRAR program.

The JAMS_REGISTRAR program should be executed by the OpenVMS system wide login command file (it will have no effect on non batch processes). The JAMS_REGISTRAR program sends a message to the JAMS_MONITOR to alert the monitor that a batch job has started. It also sets the batch job's termination mailbox to point to the JAMS_MONITOR's mailbox. The OpenVMS job controller will place a message in the job's termination mailbox when the job terminates, no matter how the Job terminates. The JAMS_MONITOR process will verify the mailbox messages which it receives and forward them to the JAMS_SCHEDULE process.

The JAMS_MONITOR process will also keep track of the JAMS_SCHEDULE and JAMS_NETWORK processes to make sure that there is one of each running in the VMScluster.

11.1.2 The JAMS_SCHEDULE process

There should always be one JAMS_SCHEDULE process running in a VMScluster. The JAMS_MONITOR processes in the cluster (one on each node) will keep track of the JAMS_SCHEDULE process and if the process dies or the node which the JAMS_SCHEDULE process is executing on leaves the cluster, one of the remaining JAMS_MONITOR processes will fire up another JAMS_SCHEDULE process on a remaining node.

The JAMS_SCHEDULE process receives messages from the JAMS_MONITOR processes and performs the following basic tasks:

• Updates Job History.
• Examines Jobs submitted by the JAMS Submit sub-system to determine if all of the Jobs dependencies have been satisfied.
• Fires Triggers when their events occur.
• Releases Jobs when their dependencies are satisfied.
• Verifies that resources are available for a Job.
• Releases Jobs when their resources become available.
• Sends notification of failed Jobs via OpenVMS Mail, operator requests and broadcasts.
• Sends messages to JAMS Job Monitors when the status of a job changes.

The JAMS_SCHEDULE process must be running on one node in a VMScluster. If a JAMS_MONITOR process detects that the JAMS_SCHEDULE process is not running, it will start one.

In a large VMScluster, you may have many different types of systems, these may range from fast Alpha class systems to small VAXstation 2000's. Generally, you want the JAMS_SCHEDULE process to run on one of your more powerful nodes, or one with available capacity.

You can control which node the JAMS_SCHEDULE process will start on by defining the logical name JAMS_SCHED_WEIGHT. This logical must be defined in the system logical name table, have the executive attribute and translate into a numeric value. If JAMS_SCHED_WEIGHT is not defined, or is defined incorrectly, then the value 1 will be used.

Nodes which have JAMS_SCHED_WEIGHT defined as 0 (zero) will never start a JAMS_SCHEDULE process. In fact, they won't even check to see if a schedule process is running.

When a monitor detects that the schedule process is not running, it will compare the value of it's JAMS_SCHED_WEIGHT logical with the values of the other nodes in the VMScluster. The node with the highest value will then start a schedule process.

If you want to move the JAMS_SCHEDULE process off of the node which it is currently running on, you can use the STOP SCHEDULE and START SCHEDULE commands. You may need to do this if your primary node goes down and the Schedule process starts on one of the secondary nodes. Note however that when the Schedule process is restarted, it will start on the node with the highest JAMS_SCHED_WEIGHT value.

11.1.2.2 Customizing JAMS_SCHEDULE startup

You can customize the start up of the JAMS_SCHEDULE process by creating the JAMS_COM:JAMS_SCHEDULE_STARTUP.COM command procedure. If this command procedure exists, it is executed by the JAMS_SCHEDULE process when it starts. You can use this command procedure to define process level logical names, set RMS buffers or perform almost any other type of initialization.

11.1.3 The JAMS_NETWORK process

The JAMS_NETWORK process provides wide area network communications support. When JAMS needs to communicate with a remote node, a message is sent to the local JAMS_NETWORK process which will establish a link with the remote node and send the message. If a link cannot be established, the JAMS_NETWORK process will save the message and periodically retry.

11.1.3.1 Controlling the JAMS_NETWORK node selection

The JAMS_NETWORK process is similar to the JAMS_SCHEDULE process in that there is only one JAMS_NETWORK process per VMScluster. If you will be using the wide area network features of JAMS, the JAMS_NETWORK process must be running on one node in the local VMScluster and one node on the remote VMScluster. If a JAMS_MONITOR process detects that the JAMS_NETWORK process is not running, it will start one.

Generally, you want the JAMS_NETWORK process to run on one of your more powerful nodes, or one with good network connections.

You can control which node the JAMS_NETWORK process will start on by defining the logical name JAMS_NETWORK_WEIGHT. This logical must be defined in the system logical name table, have the executive attribute and translate into a numeric value.

Nodes which have JAMS_NETWORK_WEIGHT defined as 0 (zero) will never start a JAMS_NETWORK process. In fact, they won't even check to see if a network process is running. Also, if this logical name is zero, a remote node will not be able to establish a connection because the JAMS_MONITOR process will not redirect remote network connection requests to the node which is running the JAMS_NETWORK process.

When a monitor detects that the network process is not running, it will compare the value of it's JAMS_NETWORK_WEIGHT logical with the values of the other nodes in the VMScluster. The node with the highest value will then start a network process.

If the JAMS_NETWORK_WEIGHT is not defined, or is defined incorrectly, then the value 1 will be used.

If you want to move the JAMS_NETWORK process off of the node which it is currently running on, you can use the STOP NETWORK and START NETWORK commands. You may need to do this if your primary node goes down and the network process starts on one of the secondary nodes. Note however that when the network process is restarted, it will start on the node with the highest JAMS_NETWORK_WEIGHT value.

11.1.4 The JAMS Agent Windows NT/2000 Service

The JAMS Agent Windows NT/2000 Service receives requests and sends responses to the JAMS_SCHEDULE which is running in the VMScluster. The JAMS Agent's purpose is to initiate the batch job which is received from the JAMS_SCHEDULE and to provide status back to the JAMS_SCHEDULE when the job completes.

Communication between the JAMS_SCHEDULE process and the JAMS Agent is secured. Only JAMS_SCHEDULE processes can access the JAMS Agent service running on Windows NT/2000.

The communication between JAMS_SCHEDULE and the JAMS Agent can be further secured through the use of a password. The password is only necessary in those situations where you have multiple systems (VMSclusters and stand-alone systems) running the JAMS_SCHEDULE process, and you wish to specify the JAMS_SCHEDULE processes which should be able to schedule batch jobs on any specific Windows NT/2000 system. The password must be set in the JAMS Database on the OpenVMS system as well as in the control applet on the Windows NT/2000 system.

If you have only one OpenVMS system (VMScluster or stand-alone) or all of your OpenVMS systems are trusted to submit batch jobs to the Windows NT/2000 system, then the password is not needed.

For JAMS to successfully submit jobs to Windows NT/2000 systems the following conditions must be established:

• The JAMS Agent Service must be installed on the Windows NT/2000 Server or Workstation system. The installation must occur using a Windows NT/2000 Administrator account (local or Domain).
• Verify that the JAMS Agent NT Service is running.
• The Agent Node Name, found under the Submit Options of the Job, must specify the Windows NT/2000 computer name where the job will run.
• The Execution Method, found under the Source Options of the Job must specify a Windows NT/2000 Execution Method. JAMS ships with three NT Execution Methods already established. They are:
  • NT. Non-parsed batch file.
  • NTCMD. Non-parsed one line NT command.
  • NTPARSE. Parsed batch file.
• A username/password combination must be previously established which is passed to the JAMS Agent by the JAMS_SCHEDULE process. See the JAMS Reference Manual for detailed instructions on how to establish this information in the JAMS database. The JAMS Agent first authenticates this username/password combination against the local Windows NT/2000 security system. If this fails, authentication will be attempted against the Windows NT/2000 Domain that this computer is in.
• The username above, must have the "Logon as Batch Job" Windows NT/2000 privilege.

The JAMS Monitor, Schedule and Network processes share a common log file which they use to log events when they occur. This log file is named JAMS.LOG and is located in JAMS_DATA:. You can type this file at any time.

11.2 Recurring Jobs

JAMS has the capability to automatically submit recurring Jobs. This is done by the JAMS_AUTOSUBMIT batch Job. This Job is scheduled to run every day at 1:00 am, including non-workdays.

You must submit this Job after the initial installation of JAMS. After the initial submission, you should make sure that the JAMS_AUTOSUBMIT Job is scheduled. If your recurring Jobs are not submitted, it may be caused by a failure of the JAMS_AUTOSUBMIT Job.

The Jobs supplied with JAMS are in the System named JAMS. You should update this System Definition to add the appropriate names to the list of people who should be notified when a Job is this System fails. This is especially important since the failure of the JAMS_AUTOSUBMIT Job will prevent other Jobs from running.

11.3 Relative CPU Power Ratings

The JAMS job history information includes the amount of CPU processing time consumed by a job. If you have a VMScluster which consists of nodes with varying CPU speeds, you may want to define relative CPU ratings for each CPU in your cluster.

The CPU rating is used when JAMS reports CPU utilization history and when making projections. The CPU rating is expressed as a percentage. If the CPU rating is undefined, it is assumed to be 100 percent.

If, for example, you have a VMScluster which consists of 5 VAX 64X0's (7.0 VUP's per CPU) and one VAX 65X0 (13 VUP's per CPU), you could leave the CPU rating undefined on the 64X0's (which would default to 100 percent) and define the CPU rating for the 65X0 as 185 percent (13/7).

You define a nodes CPU rating by defining the logical name JAMS_CPU_RATING. This logical name must be defined in the system logical name table and it must be defined with the executive qualifier. The following command would define a CPU rating of 185 percent:

$ DEFINE/SYSTEM/EXECUTIVE JAMS_CPU_RATING 185

This CPU rating is an arbitrary rating of the CPU processing speed relative to the other nodes in your VMScluster.

For SMP machines which may have multiple CPU's, the CPU rating should be based on the relative power of a single CPU.

11.4 Security

JAMS includes a feature which allows an unprivileged (but authorized) user to submit a batch job which will run under a different, possibly privileged, username. This feature must be carefully managed in order to prevent abuse.

This concept may be alarming at first but, if properly managed this feature can enhance your overall security. With JAMS, instead of granting a person the privileges they need to perform a simple task, privileges which could be misused, you grant them submit access to a specific Job or System which contains Jobs to perform the privileged tasks. Since the user cannot modify the Job definitions, they cannot misuse the privileges. You can essentially grant a person privileges for a limited set of functions.

In order to insure the security of your OpenVMS and JAMS environment, you must follow these guidelines:

• Use the SET USERNAME command to define Access Control Lists which grant submit access to OpenVMS usernames. This can eliminate the need to give people the CMKRNL privilege.
• If a JAMS System runs under a privileged username, make sure that the directory where the Systems command files are located is secure. Also make sure that access to the System definition is secure.
• If a JAMS System runs under a privileged username, make sure that the JAMS template library used by the system is secure.

When JAMS is first installed, you must have the OpenVMS BYPASS privilege to perform any activity in the JAMS database. You can ease this restriction using the Access Control menu option in JAMS_MASTER. As long as you protect any System or Job definitions which execute under a privileged username, JAMS will not pose a security risk and in fact, will enhance your overall security.

11.5 Backing Up the JAMS Database

Currently, the JAMS database consists of a number of RMS files. These files are created by the installation procedure. The JAMS database files are located in the directory which is pointed to by the JAMS_DATA logical name. This logical name is defined by the JAMS_STARTUP.COM command procedure. These files are protected from normal user access by standard OpenVMS file protections.

Normally, the JAMS_SCHEDULE process has many of these files open for write access. Because of this, you cannot make a valid backup copy of the JAMS database without stopping the JAMS_SCHEDULE process.

The JAMS_MASTER program has a STOP SCHEDULE command. This command is intended to be used during the backup of the JAMS database. JAMS will not lose any information while the Schedule process is down but, jobs which are submitted by the JAMS Submit sub-system will remain in a pending state until the Schedule process is restarted. The general procedure is:

1. Issue the JAMS STOP SCHEDULE command.
2. Backup the JAMS database.
3. Issue the JAMS START SCHEDULE command.

The JAMS_MONITOR and JAMS_NETWORK processes also have files open for write access. The JAMS_MONITOR opens the JXQ.DAT and JCQ.DAT files for write access and the JAMS_NETWORK has the NWIP.DAT file open for write access. These files are used to pass data between the Monitor, Schedule and Network processes. This data is transient and there is no need to backup these files. If these files ever become corrupt or lost, they can be recreated by performing the following steps:

1. Stop the Monitor, Schedule and Network processes on all nodes in the cluster.
2. Delete the JCQ.DAT, JXQ.DAT or NWIP.DAT files in the JAMS_DATA directory.
3. Start the Monitor processes (which will create new JCQ.DAT and JXQ.DAT files and start the Schedule and Network processes).

JAMS uses OpenVMS queue characteristics to prevent batch jobs from executing (assuming the Job in question utilizes queues). The JAMS_WAITING and JAMS_SCHEDULE queue characteristics should never be assigned to a batch queue because this would defeat the purpose of assigning the characteristic to a job (namely preventing the job from starting).

The following table lists the queue characteristics which may be assigned to a Job and the reason they are assigned to a job. These characteristics are defined the first time that the JAMS_SCHEDULE process starts.

Characteristic	Reason
JAMS_SCHEDULE	This Job needs to be examined by the JAMS_SCHEDULE process to determine if it can be released.
JAMS_WAITING	This Job is waiting for a Precheck Job, Dependency or time slot.

If you notice that a Job remains in a pending state longer than you think it should, you can use the SHOW ENTRY/FULL entry OpenVMS command to display all information about the Job. If the Job has characteristics associated with it, the characteristic numbers are displayed. You can translate these numbers into the text characteristics with the OpenVMS command SHOW QUE/CHAR.

If you see Jobs with the JAMS_SCHEDULE characteristic for more than a few seconds, it indicates that the JAMS Schedule process is not running. If the JAMS Schedule process is in fact running, it either has a very heavy work load or it is not working correctly. If you feel that the JAMS Schedule process is not working correctly, you should try stopping and starting the JAMS Schedule by using the STOP SCHEDULE and START SCHEDULE commands.

11.6.1 Production & Debug Characteristics

You can also define queue characteristics to identify production and debug batch queues. When a Job is submitted by JAMS the /DEBUG qualifier is used to define whether this is a debug or normal (production) run of the job. For jobs which are not submitted by JAMS, JAMS will look at the queue which the job is in, if the queue has the JAMS_PRODUCTION characteristic then the job is considered a production run. If the queue has the JAMS_DEBUG characteristic then the job is considered a debug job. If the queue has neither of these characteristics then a JAMS configuration field determines whether this is a production or debug run.

If you plan to use the JAMS_PRODUCTION and/or JAMS_DEBUG characteristics, you must define the characteristics manually.

Copyright © 2000, MVP Systems, Inc. All rights reserved.