The Jobscheduler can automatically start shell scripts and commands for a certain job net. Also, the Jobscheduler can monitor status of the job net and each job in the job net or browse their histories.
The following describes shell scripts which registered in the Jobscheduler as jobs making up a job net and the Jobscheduler to work with smoothly.
When a certain operation is carried out, a series of processes are incorporated in sequence into one shell script. However, when using the Jobscheduler, shell scripts can be divided by the processes so that respective status may be easily monitored. This enables browsing of execution statuses and logs for each process (shell script). Also, debugging will be much easier compared to the cases where one job is created as one large shell script.
The following would be helpful when creating shell scripts to be registered in the Jobscheduler.
One shell script consists of a group of processes.
One shell script consists of processes to be monitored.
When allocating the succeeding processes by the command return code, one shell script should consist of the command and the succeeding process.
If parallel processing is possible, create individual shell scripts for commands and subsequent processes, respectively.
Include a number of processes which can be easily browsed on the display in one shell script.
When starting a child shell script from a shell script registered in the Jobscheduler, make the parent process control the completion codes, etc. for the child process.
For the execution shells of the jobs under the Jobscheduler, use sh, ksh or csh. If a free shell such as "bash" is used, the Japanese text may not output correctly as the free shell does not support the Japanese language display.
Considering the shell script completion code
For the system where the exit routine is started when the job net is abnormally terminated, the completion code must be determined taking the exit routine processes into account.
Make sure that the completion codes for shell scripts and commands to be registered in the Jobscheduler are 200 or less. This is because the Jobscheduler uses the completion codes from 201 to 256. For details on the completion codes to be used by the Jobscheduler, see "Jobscheduler Completion Code" in the Systemwalker Operation Manager Reference Guide.
Considering the child and grandchild shell scripts
When starting a child shell script among the shell scripts registered in the Jobscheduler, the child process output can also be browsed. However, the job status display shows the status of the shell scripts registered in the Jobscheduler, not the child process status. When the registered shell script itself recognizes the completion code of the child process and set this as the completion code of the parent process (registered shell script), the completion code of the child process can be obtained.
Note that operation when the parent process is completed during the child shell script execution is not guaranteed.
Considering the shell strategy
In the shell script which starts the Jobscheduler server, the SHELL environment variable and the server startup command are set. When the Jobscheduler is installed, the SHELL environment variable is set as follows.
SHELL=/bin/ksh ; export SHELL |
It is possible to specify the shell at job execution by changing the SHELL environment variable value. When not specifying the SHELL environment variable like the following, the login shell of the user who has registered the job net will be the job execution shell.
unset SHELL |
When sh or ksh is specified as the startup shell, the .profile file will be read and executed. When csh is specified, the .cshrc file and the .login file will be read and executed. For details on the dot files (files with ".") executed at startup, see the descriptions of each shell.
When the JOBSCH_JOBNET environment variable is specified, the job will be executed under the Jobscheduler.
For the jobs with the Job Execution Control attribute, it will depend on the shell strategies of the Job Execution Control.
When the job is started, the dot file (file with ".") of the project owner of the project in which the job net is registered will be read and executed. Whether to execute the dot file of the shell specified in the SHELL environment variable at the Jobscheduler server startup or to execute the dot file of the login shell of the project owner of the project in which the job net is registered depends on the shell strategies of the system administrator. When the Jobscheduler is installed, the SHELL environment variable is set to ksh.
When operations such as terminal setting are carried out in the dot file, make sure these parts will not be executed. For the jobs with the Job Execution Control attribute, make sure operations such as terminal setting in the dot file are not carried out. The following provides an example of how to change the .profile file. In this example, stty and eucset are specified in the .profile file as the terminal setting commands.
When using a job with the "Compatible with the earlier versions (old and standard)" attribute
From
stty erase '^h' intr '^c' echo cs8 -istrip imaxbel eucset
To
if [ "$JOBSCH_JOBNET" = "" ]
then
stty erase '^h' intr '^c' echo cs8 -istrip imaxbel
eucset
fiWhen using a job with the Job Execution Control attribute
From
stty erase '^h' intr '^c' echo cs8 -istrip imaxbel eucset
To
if [ "$JOBSCH_JOBNET" = "" -a "$ENVIRONMENT" = "" ]
then
stty erase '^h' intr '^c' echo cs8 -istrip imaxbel
eucset
fiInformation
Output of "Warning: no access to tty; thus no job control in this shell..." message to the job output result (previous history)
If the C shell cannot obtain the terminal (tty) attributes, it outputs the "Warning: No access to tty; thus no job control in this shell..." message to the job output result (previous history). For details, see "A.5.10 Cautions when the Job Submitter's Login Shell is the C Shell [UNIX version]" section.
Consider using the remote shell
Note the following when using the rsh command in the shell script of the job to be registered in the scheduler for execution on a remote machine.
When executing a command or a shell script specified the rsh command argument, it will be executed in the job net administrator's home directory even if the execution directory is specified in the Jobscheduler. For jobs to be registered in a certain directory, change the directory using the cd command in the shell script.
Output when the command or shell script specified with the rsh command argument is executed will be displayed in the Jobscheduler. However, the completion code (exit code) of the command or the shell script will not be displayed, and the completion code of the rsh command will be the completion code displayed in the Jobscheduler.
As one of the methods to display the completion code of the shell script, the following is available. At the end of the shell script executed on a remote machine, write the completion code to a file. Pass the contents of the file in which the remote machine completion code has been written to the exit function at the end of the shell script (shell script including the rsh command) registered in the Jobscheduler.
For example, when a shell script existing on machine B is executed from machine A, create the following shell script a.sh on machine A, and b.sh in the home directory of machine B. In the following example, the shell script "calculation" on machine B is executed.
Command to be registered in the Jobscheduler:
a.sh keisan /work/keisan_result |
a.sh on machine A
rsh B b.sh $1 $2; exit `rsh B "cat $2;rm $2" ` |
b.sh on machine B:
$1 ; echo $? > $2 |