| Contents | Index | JAMS Home | Support |
|
||||
|
| Previous | Contents | Index |
1.11 Configuration
The Configuration menu option is used to define and maintain many of
the JAMS system wide options and configuration parameters.
Generally, you will need to review and update these options when you
first install JAMS, but you usually will not want to change
these definitions frequently.
You must specify which days of the week are normally considered workdays. This workday status can be overridden by a specific date definition.
This is a list of OpenVMS Mail addresses, separated by commas. If an unregistered Job terminates with a bad status, a OpenVMS mail message will be sent to this list of addresses. The message will specify the Job which completed abnormally and provide the final status code and message text. If left blank, no mail message is sent.
You can also specify a list of logical names which translate into lists of OpenVMS Mail Addresses and/or logical names.
This is a list of OpenVMS usernames, separated by commas. If an unregistered Job terminates with a bad status, a message will be broadcast to these users (if they are logged on at the time). The message will specify the Job which completed abnormally and provide the final status code and message text. If left blank, no broadcast message is sent.
You can also specify a list of logical names which translate into lists of OpenVMS Usernames and/or logical names.
This is a list of OpenVMS operator classes, separated by commas. If an unregistered Job terminates with a bad status, a message will be sent via OPCOM to these operator classes. The message will specify the Job which completed abnormally and provide the final status code and message text. If left blank, no operator message is sent.
Valid OpenVMS operator classes are:
CARDS
CENTRAL
CLUSTER
DEVICES
DISKS
NETWORK
OPER1 through OPER12
PRINTER
SECURITY
TAPES
You can also specify a list of logical names which translate into lists of Operator Classes and/or logical names.
Directory for Temporary Job Files
JAMS has the ability to parse a command file template and create a temporary command file which is submitted as a batch job. This temporary command file is deleted when the batch job completes. Specify a device and directory, or a logical name which expands to a device and directory, in this field.
This directory should be a secure directory. The UIC of the owner should be a trusted UIC (such as [1,1]) and the protection on the directory should be set to: (S:RWE, O:RE, G:RE, W:RE)
Any logical names referenced here must be defined at the executive level. Make sure that you use the /EXECUTIVE qualifier when you define the logical name. |
Retain History from unregistered Jobs
The JAMS monitoring system monitors all batch jobs which run on an OpenVMS system. An unregistered Job is one which has not been defined in the JAMS database. If you set the Retain History from unregistered Jobs field to Y (Yes), a history record will be maintained for all unregistered Jobs. Set the switch to N (No) to ignore unregistered jobs.
Manage unknown jobs as if they were submitted by JAMS?
This switch defines whether JAMS will attempt to make an unknown job wait for dependencies. An unknown job is a job which is registered in the JAMS database but was not submitted by JAMS. If you set this switch to "Y", JAMS will check a Job's dependencies when it finds an unknown, but registered, Job pending in a batch queue. You must make sure that the job will remain in a pending state until JAMS sees the job in the queue. One way to do this is to include the qualifier /CHAR=JAMS_SCHEDULE on the SUBMIT command.
Treat unknown jobs as if they were submitted with /DEBUG?
This switch defines whether JAMS will treat unknown jobs as if they had been submitted with the JAMS /DEBUG qualifier. An unknown job is a job which is registered in the JAMS database but was not submitted by JAMS. Jobs which are submitted with the /DEBUG qualifier will not satisfy dependencies or cause Triggers to fire.
When JAMS discovers a job which it did not submit, it looks at the queue which the job is in for either the JAMS_PRODUCTION or the JAMS_DEBUG queue characteristics. If it finds one of these characteristics then that characteristic defines if this is a debug or production run. If neither of the characteristics is found on the queue, this field is used to determine if this is a debug or production run.
Submit automatically submitted jobs x before scheduled time
This parameter defines when an automatically submitted job will be submitted to a batch sub-system. At least once a day, the JAMS_AUTOSUBMIT job runs to determine what jobs need to be automatically submitted. These jobs are scheduled by JAMS but they are not submitted to the batch sub-system just yet. The scheduled jobs can be viewed and/or managed with the JAMS Job Monitor.
If this parameter is set to zero, the scheduled jobs are submitted to the batch sub-system at their scheduled time. If the parameter is not zero, the jobs are submitted that many minutes before their scheduled time and they hold until their scheduled time.
Keep Completed Jobs in the Monitor for...
Completed jobs will remain in the JAMS Job Monitor display for this length of time after they have completed.
Scan the OpenVMS queues for unknown Jobs every...
The JAMS Schedule process can periodically scan the OpenVMS batch queues for jobs which are not known to JAMS. A job is known to JAMS if it was submitted by JAMS or if the job has started and has run the JAMS_REGISTRAR.EXE program.
Once a job is known to JAMS, it will be displayed on the Show Current Jobs and Monitor Current Jobs screens.
If you set this field to zero, JAMS will never scan the OpenVMS batch queues. This would be appropriate if all of your jobs are submitted with JAMS or if you do not want to see jobs on the JAMS Monitor screen until they have started execution.
If you have performance problems with the OpenVMS queue sub-system, you may be able to alleviate the problem by setting this field to a fairly small number, such as 5 or 10 minutes, and then encouraging users to use the JAMS functions to display their jobs rather than the OpenVMS SHOW QUEUE command. Since the JAMS functions do not access the OpenVMS queue database, you have one process scanning the OpenVMS queue database every 5 or 10 minutes instead of many processes (people) scanning the queue database every 1 or 2 minutes.
Checking known jobs vs. OpenVMS queues every...
The JAMS Schedule process will periodically check its known jobs against the OpenVMS queues. This is done to resolve any inconsistencies between the JAMS list of known jobs and the OpenVMS queues. Inconsistencies can be introduced for the following reasons:
Only the last item in this list should happen under normal conditions. The last item is not critical because the hold status and after time in the JAMS known jobs list is only used for reference. If you use the JAMS Job Monitor to reschedule the job, the correct attributes are retrieved from the OpenVMS queue database.
This check always occurs when the JAMS_SCHEDULE process starts up. This value determines the interval between checks. You cannot turn this check off. If you set this field to a value which is less than 5 minutes, the check will occur every 5 minutes. We suggest a value of 60 to 120 minutes. A longer value would be appropriate if all of your job rescheduling is performed with the JAMS Job Monitor.
Maximum Size of a .LOG file to include in mail message
Defines the maximum size, in disk blocks, of a .LOG file which should be included in a mail message. If the .LOG file is larger than this, the mail message will include the full name of the .LOG file and an indication that it was too large to include.
| Previous | Next | Contents | Index |
 | Copyright © 2000, MVP Systems, Inc. All rights reserved. |