Registering startup days
Sometimes there is a specific pattern for the days when a batch file or shell script that performs a job is started. Examples include jobs that are performed every Monday or on a fixed date each year. When registering this kind of job (or a job net), first register the startup day pattern (schedule pattern) and then specify this pattern as the startup days for the job net. Alternatively, register startup day patterns for job nets on a "yearly" basis or a "monthly" basis.
To set up startup days using patterns such as "the nth day of the month" or "n business days before end of the month", register the startup day pattern using a "business day" basis.
For jobs with no fixed pattern for the days when they start, startup days can be registered for each job net using the Startup Days window. Alternatively, jobs can be started as desired using the Select Job window, without registering startup days.
To set up the same startup days as for another job net, the other job net can be specified as the base job net.
How to make job nets finish by a certain time
Sometimes it is desirable to have a job net finish executing by a certain time. In this kind of situation, scheduled end time of the job net can be worked out by starting the job net and then using the Gantt Chart window. Then, the startup time can be set up by calculating back from this scheduled end time. Note, however, the time displayed is an estimate based on the previous execution time, so allow sufficient time when setting up the startup time.
The startup time for a job net only becomes relevant when startup days have been registered.
How to delete job output files
It is possible to delete job output files that are created when jobs registered in a job net with the "Job Execution Control" attribute are executed. It is also possible to save these output files without deleting them.
The files to be deleted are as follows:
Jobname."o"Jobnumber (Standard output files)
Jobname."e"Jobnumber (Standard error output files)
Jobname."l"Jobnumber (Job list files)
The startup parameters for the Jobscheduler service or daemon can be used to define whether to delete job output files. For notes on startup parameters, including information about how to define them, refer to the Systemwalker Operation Manager Installation Guide.
Registering large numbers of job nets
For the Enterprise Edition, there is no limit to the number of job nets that can be registered, but if a large number of job nets are registered in a single project, job nets may no longer be able to start on schedule due to performance problems.
When registering a large number of job nets, perform thorough testing to ensure that job nets start on schedule without any problems before commencing production operations. Refer to "Tuning of Performance" in the Systemwalker Operation Manager User's Guide for information about performance testing. If there are any performance problems, divide the project into several smaller projects.
If the system environment allows for multiple CPUs or multiple I/O controllers, system performance can be improved by using multiple subsystems.
Environment variables
Before starting jobs, the Jobscheduler assigns values to the environment variables listed below. Use these environment variables in situations such as when the processing for subsequent jobs needs to be changed depending on the type or completion code of the preceding job.
With network jobs, however, the environment variables listed below are not inherited.
Information
For network jobs, if the schedule server and execution server are both running Systemwalker OperationMGR V10.0L20/10.1 or later, the environment variables that have been set in the "Environment variables" section of the Detail information sheet in the Add/Change/Monitor - Job window are inherited by network Jobs. (If both the schedule and execution servers are not running Systemwalker OperationMGR V10.0L20/10.1 or later, these environment variables are not inherited).
These variables store the owner of the project.
This variable stores the directory name of the job. If the directory name is omitted, this variable stores the name of the home directory for the project owner.
This variable stores the name of the home directory for the project owner.
This variable stores the name of the project owner.
This variable stores "/usr/mail/project-owner-name". In AIX, this variable stores "/usr/spool/mail/project-owner-name". In the Linux versions, this variable stores "/var/spool/mail/project-owner-name".
This variable stores the domain name for the project owner if the connection destination server is a Windows server. If no domain name is specified, the value of this environment variable is omitted. If the connection destination server is a UNIX server, the value of this environment variable is omitted.
JOBSCH_SUB_SYSTEM environment variableThis variable stores the subsystem number.
This variable stores the name of the project where the job net has been registered.
This variable stores the name of the job net.
If the job name that is passed to Job Execution Control has been registered in the job registration information, this variable stores that job name. If a job name has not been registered, this variable stores information about the execution file that has been registered in the "Command" field of the Add/Change - Job window (including the qsub command option and execution file parameters).
This variable stores a value indicating the date of the configuration with which the job net has been started. The value is stored using the "yyyymmdd" date format.
This variable stores the "BATCH" character string.
This variable stores "C". Set this environment variable if it is required by a startup shell (".login", ".cshrc" or ".profile") for the job execution user.
In addition, values are set for the following environment variables when preceding jobs exist. However, if there is more than one preceding job, the data for the job that triggered the startup of the current job (the preceding job that was executed most recently) is set.
If the job name that is passed to Job Execution Control has been registered in the registration information for the preceding job, this variable stores that job name. If a job name has not been registered, this variable stores information about the execution file that was registered in the "Command" field of the Add/Change - Job window (including the qsub command option and execution file parameters).
This variable stores the completion code for the preceding Job.
If the job net is nested, this variable stores the name of the job net in the first layer. If the job net is not nested, this variable stores the job net name (the value will be the same as the JOBSCH_JOBNET environment variable).
