How to Identify Work to Perform for JMO?

Products

• Unicenter Job Management Option

Issue/Introduction

A job is a unit of work performed. A job can be as follows:

• An executable file used to process an application.
  
  
• A manual task to be performed before or after processing an application.

Before reading about how to define jobs, review the following sections that describe how the Unicenter NSM JM Option evaluates the policies you define to determine when jobs are eligible to run.

 

Environment

UUJMA

Resolution

Jobset Membership
Every job must belong to a jobset, and only after a jobset is marked as started will Job Management evaluate the jobs in the jobset.
Note: DYNAMIC jobs are a special exception to this rule and are discussed separately in Demand a DYNAMIC Job.

Early Start Time
Early start time indicates the earliest time a job may start. For CPU jobs, this is the earliest time they would be submitted to the operating system. Once the job's jobset has started, the Unicenter NSM JM Option checks the job's early start time. If you specify an early start time for the job, the job remains in WSTART status (waiting for the job's early start time) until that time arrives. When the time arrives, or if the job does not have an early start time specified, the job advances from WSTART to WPRED status (waiting for predecessor requirements to be satisfied).

External Predecessors
The EXTERNAL job type setting in a job profile lets you define a job to the Unicenter NSM JM Option that will be submitted by an external job manager. The job is actually submitted by another job management system such as Unicenter CA-7 Job Management (Unicenter CA-7), Unicenter CA-Scheduler Job Management (Unicenter CA-Scheduler), Unicenter CA-Jobtrac Job Management (Unicenter CA-Jobtrac), and so forth. The Unicenter NSM JM Option treats this job as a non-CPU job with a class of EXTERNAL (similar to PRECPU and POSTCPU).

The job's presence on the tracking file causes JOBINIT and JOBTERM triggers to be generated internally and the job is automatically tracked by the client where the job actually runs. The job server tracks the job, but does not submit it. Since this is a JOB base entry, predecessor definitions and calendar selection can reference it.
You specify the job type at the Main - Info notebook page of the Job - Detail window.

Job Resources
Job resource requirements do not override jobset resource requirements. Rather, resource requirements defined at the job level are added to any resource requirements that may already be defined at the jobset level. Jobset and job resource requirements are therefore cumulative.

Job Submission
The Unicenter NSM JM Option submits CPU jobs based on user-defined processing requirements. You define what to submit and any special considerations through a submission profile that assigns these submission characteristics:

• User ID (the user for whom the job is submitted).
  
  
• Name of the file or program to submit.
  
  
• Optional parameter values to pass to the submitted file or program.
  
  
• Password of the user for whom the job is submitted.
  
  
• Domain of the user for whom the job is submitted (Windows only).

Job Predecessors
Jobs, jobsets, and triggers can all be defined as predecessors for a job. All predecessors defined for the job must be satisfied before a job can become a candidate for submission.
Important! The jobset starts only after all of the jobset's predecessor requirements have been met, and only after the jobset starts will the Unicenter NSM JM Option evaluate the predecessor requirements for the individual jobs that are members of that jobset.

On UNIX/Linux, you can also specify advanced system conditions that must be met before a job can run on a specific node.
For example, if a job must not run when a particular user is logged on, you can define a system condition criterion that specifies this. The Unicenter NSM JM Option holds the job until that user is no longer on the system and then releases it.

SYSCON objects for administering system condition requirements are available using cautil command syntax and are described in JOBSYSCON, JOBSETSYSCON, and TJOBSYSCON in the online CA Reference.

Password Validation for Job Submission (UNIX/Linux)
By default, job submission requires a password and a valid user ID for a job to be executed.
You can change this rule at any time after installation by executing the cawrksec utility located in the $CAIGLBL0000\sche\bin directory. The utility allows only the uid 0 user to maintain the file and preserve the file permissions. The file can also be maintained using a UNIX/Linux text editor. For more information about using the cawrksec utility, see the online CA Reference.

The ExtNodeL.sch configuration file is located in the $CAIGLBL0000\sche\config directory. You can use this file to maintain policies that specify how password validation is to be performed based on the submitting node and user ID. The file must be owned by root, and only a uid of 0 may have write access to it. An individual entry in the file has the following format:

-n=nodename,user-id,flag

where:
nodename
Specifies the node from which the job is initiated; it can contain a trailing generic mask character.
user-id
Specifies a user ID to whom the rule applies; it can contain a trailing generic mask character.
flag
Specifies D for disable (perform no password authorizations), E for enable (unless the proper password is supplied, the job will not run), or W for warn (check the password; if invalid, run the job but issue a warning message).

Examples
The following rule is the default rule in effect if you elected to enable password checking during installation. The rule states that for all nodes and all users password validation is to occur.

-n=*,*,E

The following rule is the default rule in effect if you elected to disable password checking during installation. The rule states that for all nodes and all users password validation is bypassed.

-n=*,*,D

The following combination of rules only enforces a password validation on user root and allows all other users to bypass password validation.

-n=*,*,D
-n=*,root,E

The following combination of rules allows all users to bypass password validation unless the request comes from the node mars. In that case, password validation is enforced for all users. The last entry sets a warning type password validation for user root if it comes from a node other than mars.

-n=*,*,D
-n=mars,*,E
-n=*,root,W

Job Management scans the entire configuration file for a best match and uses that rule. It uses the node field as a high level qualifier when searching for a best match. For example, if the following entries are the only two entries in the file, any request coming from the node mars uses the enforce rule. The user root only uses the warning rule if the request comes from a node other than mars.

-n=mars,*,E
-n=*,root,W

Cyclic Job Submission
The Unicenter NSM JM Option supports cyclic job submission, which allows a job to be submitted multiple times during a particular time period. For example, if you have a job that needs to run every hour between 8:00 a.m. and midnight, you can define the job as cyclic and specify the frequency (how often it should run) and the number of iterations (how many times it should run). Cyclic job submission is much easier than defining 17 jobs, one for every hour between 8:00 a.m. and midnight. It also simplifies maintenance because you need only change a value once to alter the cycles, frequency, or number of iterations.
Note: You should define cyclic jobs as ineligible for backlogging to ensure that the job is purged from the tracking file at the next new-day autoscan.

Cyclic Job Special Considerations
Processing cyclic jobs has special considerations of which you should be aware if you plan to take advantage of this powerful facility. The following discussion provides detailed explanations of these special considerations.
When a cyclic job is demanded into the tracking file after its early start time has passed, the Unicenter NSM JM Option adjusts for this situation by doing the following:

• Adding one instance of the job using the normal early start time job, so that the job starts immediately.
  
  
• Submitting x instances of the job to start at the first eligible time interval after the current time.

For example, if the job has an early start time of 1:00 p.m. and a frequency of 60 minutes, and the job is demanded at 3:15 p.m., the Unicenter NSM JM Option generates entry one to start at 1:00 p.m. When the job enters the current workload (by entering the tracking file), the Unicenter NSM JM Option recognizes that it is late (it should have started at 1:00 p.m.) and starts it immediately. The next submitted instance of this job has a start time of 4:00 p.m. with subsequent entries to start at 5:00 p.m., 6:00 p.m., and so forth.

By default, when a cyclic job is brought in late (demanded), the Unicenter NSM JM Option skips the jobs that are too late to run and only runs the number of iterations left, based on the calculation of when the jobs should have run. If you set the Windows configuration setting "cycle count precedence" or the CAISCHD0540 environment variable on UNIX/Linux to Y, the cycle count takes precedence over the remaining count based on current time. Thus, the defined number of cyclic jobs is scheduled up to the time of the new-day autoscan.

Using the default, consider, for example, a cyclic job that has a frequency of 30, a cycle count of 16, and an early start time that defaults to the new-day autoscan time of 1:00 a.m. The job is typically brought in at 1:00 a.m. and runs 16 times: at 1:00 a.m., 1:30 a.m., 2:00 a.m., and so forth until the last (sixteenth) run at 8:30 a.m. However, if the job is demanded in at 4:05 a.m., the occurrences up to that time are skipped and the job is run at 4:05 a.m., 4:30 a.m., 5:00 a.m., 5:30 a.m., and so forth. At 8:30 a.m., the job runs for the last time, for a total of 10 runs. The occurrences that would have run (at 1:00 a.m., 1:30 a.m., 2:00 a.m., 2:30 a.m., 3:00 a.m., 3:30 a.m.), are skipped. The Unicenter NSM JM Option does not attempt to "catch up" if it means running the jobs after the last calculated start time of 8:30 a.m.

If you enable cycle count precedence using the above example, the jobs would run at 4:05 a.m., 5:00 a.m., 5:30 a.m., and so forth, until the last (16th) ran at 12:30 p.m. All counts up to the time of the new-day autoscan are scheduled.

If you elect to run with the autoscan process disabled, cyclic jobs are submitted only when you execute a manual autoscan. The jobs are not automatically submitted each day. For an explanation of the autoscan process, see Autoscan.

You cannot define a cyclic job as a predecessor to itself. In other words, when a cyclic job is submitted, the job begins execution when its early start time is reached. It does not wait for any preceding instances of itself to complete.

You can define a cyclic job as a predecessor to another job or jobset. All occurrences of the cyclic job are treated as predecessors and must complete before the successor job or jobset is eligible to run.

The predecessor criteria for cyclic jobs include a qualifier option that allows cyclic jobs to run in one of two ways. For example, assume you have two cyclic jobs, CycJobA and CycJobB, where both have an iteration number of 3, frequency is set to 60, and CycJobA is the predecessor of CycJobB. When both jobs are demanded into the tracking file, the file appears as follows:

CycJobA QUAL=xx01
CycJobA QUAL=xx02
CycJobA QUAL=xx03
CycJobB QUAL=xx01
CycJobB QUAL=xx02
CycJobB QUAL=xx03

If you set the qualifier Use Qualifier Predecessor Criteria for cyclic job? to N, CycJobB runs after all CycJobA iterations have run.
If you set the qualifier to Y, CycJobB QUAL=xx01 runs after CycJobA QUAL=xx01 completes, CycJobB QUAL=xx02 runs after CycJobA QUAL=xx02 completes, and so forth.
If you plan to use cyclic job submission for Windows platforms, review the environment settings for the Unicenter NSM JM Option in the Configuration Settings window (Options tab) for Max active jobs, Max resources, Max predecessors, and Use Qualifier Predecessor Criteria for cyclic job? and set the appropriate values to accommodate the additional jobs in the daily workload.

If you plan to use cyclic job submission for UNIX/Linux platforms, review the values set for the environment variables CAISCHD0025, CAISCHD0026, CAISCHD0027, and CAISCHD0040 and set appropriate values to accommodate the additional jobs in the daily workload.
For procedures to identify work to perform, refer to Defining Jobs in the online Procedures.