Monitoring multiple servers
Job nets in projects under multiple servers can be monitored and operated according to the privileges of the login user. Job nets in mixed environments that contain both Windows and UNIX servers can also be monitored according to the privileges of the login user.
This type of operation is suitable for small-scale systems where only Systemwalker Centric Manager has been installed. For information about monitoring job nets on medium- to large-scale systems where Systemwalker Centric Manager has also been installed, refer to "2.11 Linking to Systemwalker Centric Manager".
Nesting job nets
A job net can be registered as a job in another job net. This kind of registration is referred to as "job net nesting." A job net where another job net has been registered is called a "parent job net," and a job net that is registered inside another job net is called a "child job net." For nested job nets, the depth of a particular level is represented as "the nth level". Job nets can be nested up to five levels deep.
The following configuration diagram shows an example of a job net with three levels.
In this example, job net A is in the first level, job net B is in the second level, and job net C and job net D are in the third level. Job net A is the parent of job net B. Job net B is the parent of job nets C and D. Job net B is a child of job net A, and job nets C and D are children of job net B.
Nesting using linked job nets
Each job net can be used as a job by other job nets, a job net used as a job in multiple job nets is called a "linked job net". Linked job nets use another job net as definition information; job nets used to define linked job nets are called "master linked job nets". Multiple linked job nets can be used as a job in a parent job net. An example configuration is shown below.
In the above diagram, Job net A uses two linked job nets, which are defined by the master linked job net. Job net B uses one linked job net that is defined by the same master linked job net.
Setting up startup days for nested job nets
Startup days can be set up for child job nets in nested job nets. Additionally, by setting a startup day for the master linked job net, the startup day is also set for the linked job nets. By registering the child and linked job nets as jobs where the startup day has been set, the job net configurations are changed for each operation date automatically.
Refer to the Systemwalker Operation Manager User's Guide for information on the procedure for setting up startup days for child job nets and linked job nets.
The following configuration diagram shows an example of a job net with four levels.
In this example, the 1st day is set as the startup day for job net C and the 2nd day is set as the startup day for job net D.
Executing a job net concurrently
You can execute the same job net concurrently by copying and starting multiple job nets from a single definition.
The number of job net definitions can be reduced because you no longer need to define multiple job nets containing similar processing. In addition, concurrent execution using copy and startup allows you to check past execution results because the execution results are not overwritten even when the same job net is executed multiple times.
Group management of job nets
By registering several job nets as a single group, all of the job nets can be started, monitored and operated as a group.
For information about the procedures for registering, monitoring and operating groups, refer to the Systemwalker Operation Manager User's Guide.
The following figure shows an example of a group configuration
Using event occurrence as an execution trigger
As well as using execution schedules based on startup days, job nets can also be started when events occur. For the Jobscheduler, events are referred to as "message events."
Message events can be generated using the Jobschmsgevent command.
The following examples show how to start job nets by generating message events using the Jobschmsgevent command.
If there is a job net B that waits for the message event "Jobneta", this job net will be started if the following command is entered at the command prompt.
Jobschmsgevent Jobneta
If "Jobschmsgevent.exe Jobneta" is defined as the last job in job net A, then job net B must wait until job net A has completed before it can commence.
Executing the Jobschmsgevent command within a user application makes it possible to start any job net from the user application.
Information
Job net linkage using message events also has disadvantages, such as it being difficult to check the operating status of job nets, and the complexity of operations where message events need to be cleared. In many cases, equivalent operations can be achieved using the hierarchical job net operation function, so Fujitsu recommends using this function where possible.
It is also possible to specify execution conditions for job nets using AND/OR combinations of execution schedules based on startup days and execution triggers based on event occurrence.
For more information about the Jobschmsgevent command, refer to the Systemwalker Operation Manager Reference Guide.
Linking job nets between servers
Message events can be generated on other servers using the Jobschmsgevent command described above. In this way, job nets on other servers can be started as desired.
The following items are specified with the Jobschmsgevent command.
The name of the message event to be generated
The host name of the server on which the message event is to be generated, or the name of a file containing a list of hosts
Information
To generate message events on servers running different operating systems, use network jobs.
Starting job nets by specifying variable parameters
Job nets can be started by specifying variable parameters. "Variable parameters" are parameters that are passed to the job net in order to replace variables (@.VPARAM) that have been entered in the job definitions beforehand. For the jobs in the job net that receives these variable parameters, these variables are replaced with the variable parameters before the jobs start.
Defining a base job net in advance using pre-determined variables and then starting this base job net by specifying variable parameters eliminates the need to define a large number of different job nets, particularly in situations where there are multiple job nets that differ only by a parameter.
There are several methods for starting job nets by specifying variable parameters, as follows:
The jobschmsgevent command starts job nets by passing variable parameters at the same time as the notification that a message event has occurred.
Jobs are started by replacing variables that have been entered beforehand with the variable parameters that are received together with the message event notification.
When a job net is started by passing variable parameters when a message event is notified, it is possible to duplicate the job net to be started, and then start the duplicate job net. This allows multiple job nets (with different parameters) to be executed in parallel by attaching different suffixes, and makes it possible to execute a job net with different parameters without overwriting the previous execution results.
It is possible to perform startup operations where variable parameters are specified dynamically, in situations such as when a job net is started from an operator instruction by specifying variable parameters, or when a job net is started manually by specifying variable parameters (as a recovery task when an error occurs, for example).
Refer to the Systemwalker Operation Manager User's Guide for information about the procedure for starting job nets by specifying variable parameters.
Simultaneously replacing job registration information using job definition variables
Jobs can be defined in advance using job definition variables (@variable name@), and the values of these job definition variables can be replaced as a batch when the job is executed. Information such as the environment definitions for the paths to job definitions can be easily replaced as a batch, making it easy to migrate assets between systems with different operation environments.
Refer to the Systemwalker Operation Manager User's Guide for more information.
Using a job net variable to pass information between jobs
Individually set information and information such as the file name or message event that triggered startup can be passed as a job net variable between jobs within the same job net. You can branch a subsequent process depending on the information received as the job net variable.
Refer to the Systemwalker Operation Manager User's Guide for details.
Importing and exporting definition information from the GUI
Definition information for jobs, job nets and groups can be imported and exported as CSV files from the Systemwalker Operation Manager client window.
The following CSV files can be imported and exported:
Job net definition CSV files
Group definition CSV files
Refer to "Jobscheduler Commands" in the Systemwalker Operation Manager Reference Guide for details on job net definition CSV files and group definition CSV files.
When importing definition information, it is possible to specify multiple CSV files or a directory containing CSV files. The import destination is a project. The CSV file determines how job/job net definition information and group definition information is imported into a project.
The target range of export includes job nets, parent job nets, child job nets, master linked job nets, groups, projects and subsystems. The definition information of jobs/job nets or groups within the target range is used to create a CSV file for each job net or group within the specified directory.
The definition information of the following Systemwalker Operation Manager server platforms and V/L can be imported or exported to/from Systemwalker Operation Manager clients running V13.3.0 or later:
Windows: V11.0L10 or later
Solaris: 11.0 or later
Linux: V11.0L10 or later
HP-UX: 11.0 or later
AIX: 11.0 or later
Refer to "Importing and Exporting Definition Information from the GUI" in the Systemwalker Operation Manager User's Guide for more information.
Systemwalker Operation Manager users [UNIX version]
Using Systemwalker Operation Manager functions normally requires user authority for the operating system, such as logging in as a user that has been registered with the operating system. With the UNIX version, users of Systemwalker Operation Manager functions can be registered and managed on Systemwalker Operation Manager (using the Extended User Management function).
Using the Extended User Management function has the following advantages.
The number of users on the operating system does not need to be increased unnecessarily in order to perform operations from clients.
Administrator or non-administrator authority can be assigned to users registered with Systemwalker Operation Manager, so multiple administrators can be set up for Systemwalker Operation Manager, separate to the system administrators for the operating system. Also, detailed access authority for Systemwalker Operation Manager operations can be set up for administrators and non-administrators.
Operating system users need to be registered for each server, but users registered using the Extended User Management function can be distributed to other servers using the Policy Extraction and Distribution function. The tedious task of registering users does not have to be performed separately for each server.
Users that are managed on Systemwalker Operation Manager using the Extended User Management function can use Systemwalker Operation Manager functions from clients.
Starting job nets when the server is turned off
It is possible to specify what to do when a job net cannot start at the scheduled starting time (because, for example, the power to the server is turned off at the time). Select the "Startup on power-on if power is off during scheduled execution" option when the job net information is registered.
For an overview of registering job net information, refer to the Systemwalker Operation Manager User's Guide.
Continuing jobs when the schedule server fails
Even if the system fails on the schedule server, network jobs that are executing on servers other than the schedule server can continue operating without having to be cancelled. When the schedule server is restarted, the status of all jobs that were executing on execution servers is checked, and the results are automatically reflected in the schedule information file. If there are any subsequent jobs that need to be executed, the relevant job net is restarted automatically and job execution continues.
Whether to continue network job operations when the schedule server fails is defined using a command that switches continuous execution mode on and off. For more information about how to make these definitions, refer to the Systemwalker Operation Manager User's Guide.
Note
The settings for enabling or disabling continuous execution mode must be the same on all linked servers, or else the following symptoms may occur:
When the schedule server terminates due to a system failure, "Executing" is displayed even when the job is terminated.
A job outputs an error message and terminates abnormally.
A network job is executed while it is already running.
Even if continuous execution mode has been enabled, currently executing network jobs will terminate abnormally and will not continue executing if the execution server (a server other than the schedule server) fails. Continuous execution mode cannot be used to specify job continuation when the system fails on an execution server. Setting up continuous execution mode only enables jobs to continue when the system fails on the schedule server.
Duplicating execution servers for network jobs
If the execution server specified for a network job has failed or if the communication path has been interrupted, it is possible to request a secondary execution server to execute the network job.
When duplicating network job execution servers, define the primary and secondary execution servers when jobs are registered. For information about how to make these definitions, refer to the Systemwalker Operation Manager User's Guide.
Note
Jobs will terminate abnormally if both the primary and secondary execution servers are down.
Do not specify the local host name for the primary and secondary execution servers.
Operating in test mode
For multi-subsystem operations, the execution of future schedules can be checked in advance in Test mode using a subsystem other than the one where operations are currently taking place. Virtual times can be set up for particular subsystems without changing the time for the operating system, which makes it possible to check job execution on the subsystem where the virtual time has been set up. For information about how to define virtual times, refer to the Systemwalker Operation Manager User's Guide.
Although multi-subsystem operations are not supported in the Standard Edition, a virtual time can still be set up. Operations can be tested by setting up virtual times beforehand.
Temporarily changing job net startup settings
It is possible to temporarily change information (such as start times and estimated end times) that is set up as startup conditions when a job net is registered. During the period specified for this temporary change, the job net will be executed according to the new operation environment. When this specified period elapses, the settings return to that of the original operation environment.
For information about how to change startup settings temporarily, refer to the Systemwalker Operation Manager User's Guide.
Changing startup parameters
All startup parameters for the Jobscheduler are set to default values during installation, and can be changed when necessary.
For information about startup parameters and how to specify them, refer to the Systemwalker Operation Manager Installation Guide.
Using APIs and exits
The following APIs and exits can be used to customize the application environment to match user environments. For information about APIs and exits, refer to the Systemwalker Operation Manager Reference Guide.
Job Net Manipulation API
Job Net Manipulation API/EE
Job Net Manipulation (Startup Parameter Setup) API
Job Net Manipulation (Startup Parameter Setup) API/EE
Group Manipulation API
Group Manipulation API/EE
Job Net Startup API [Windows version]
Job Net Startup API/EE [Windows version]
Job Net Startup Time Modification API
Job Net Startup Time Modification API/EE
Job Net Normal Termination/Abnormal Termination Exit
Job Net Abnormal Termination Extended Exit
Job Termination Exit
Log File Switchover Exit
Day Change Time Arrival Exit
Normal/Abnormal Termination Shutdown Exit [Windows version]
Job Net Activation Delay Exit
Job Net Termination Delay Exit
Outputting various data
The following information managed by the Jobscheduler can be output to the standard output using the Jobschprint command. For more information about the Jobschprint command, refer to the Systemwalker Operation Manager Reference Guide.
Current status of groups, job nets, and jobs
Registration information for groups, job nets, and jobs
Startup days data for job nets
Job net operation schedules
Job net history information
Schedule pattern information
Calendar information
User information
Preventing operational mistakes for groups, job nets, and jobs
When operations are performed on groups, job nets or jobs, operational mistakes can be prevented by displaying a dialog box to confirm the operation. Operations are confirmed using the Operation Confirmation dialog box.
For information about how to set up the Operation Confirmation dialog box, refer to the Systemwalker Operation Manager User's Guide.
Switching between subsequent jobs according to completion codes
It is possible to select which subsequent job is executed according to the completion code of the preceding job.
The following figure shows an example where the execution conditions have been set up so that Job B starts if the completion code for Job A is 10 or less, but Job C starts if the completion code is greater than 10.
Refer to the Systemwalker Operation Manager User's Guide for more information.
