Chapter 26: Working with Resources
Real Resources
Real resources are system conditions that are directly tied to a physical system (for
example, physical memory). Real resources are predefined to CA Workload Automation
AE and are managed by external resource managers such as CA Automation Suite for
Data Centers. You cannot define or update real resources using CA Workload
Automation AE. If the required resources are not available, the job goes into a RESWAIT
state and is not submitted until the resources are available.
You can specify real resources as dependencies to jobs. A job with resource
dependencies is submitted only when the resources required are available. If the
required resources are not available, the job goes into a RESWAIT state and is not
submitted until the resources are available.
You can specify the following supported real resource types as dependencies:
CPU_IDLE_PCT
Defines the percentage of time over the sample period that the system's CPUs were
idle.
Example: (CPU_IDLE_PCT, VALUE=50, VALUEOP=GT) indicates that the system's
CPUs were idle for at least 50% of the sample period.
Corresponding metric in the CA SystemEDGE agent: cpuTotalIdlePercent
Real Resources
CPU_LOAD_AVG_15MIN
Defines the load average in the last 15 minutes.
Example: (CPU_LOAD_AVG_15MIN, VALUE=50, VALUEOP=LT) indicates that the
load average was less than 50 in the last 15 minutes.
Corresponding metric in the CA SystemEDGE agent: loadAverage15Min
CPU_LOAD_AVG_5MIN
Defines the load average in the last 5 minutes.
Example: (CPU_LOAD_AVG_5MIN, VALUE=50, VALUEOP=LT) indicates that the load
average was less than 50 in hte last 5 minutes.
Corresponding metric in the CA SystemEDGE agent: loadAverage5Min
MEM_INUSE_PCT
Defines the percentage of the system’s active memory that is in use.
Example: (MEM_INUSE_PCT, VALUE=30, VALUEOP=LTE) indicates that 30% or less
Corresponding metric in the CA SystemEDGE agent: memCapacity
SWAP_INUSE_PCT
Defines the percentage of the system’s total swap that is in use.
Example: (SWAP_INUSE_PCT, VALUE=60, VALUEOP=LT) indicates that less than 60%
of the system's total swap is in use.
Corresponding metric in the CA SystemEDGE agent: swapCapacity
SWAP_SPACE_TOTAL
Defines the total swap space (in KB).
Example: (SWAP_SPACE_TOTAL, VALUE=10240, VALUEOP=GTE) indicates that the
total swap space is 10240 KB or more.
Corresponding metric in the CA SystemEDGE agent: totalSwapSpace
SYSTEM_CPU_COUNT
Defines the total number of CPUs that the job requires.
Example: (SYSTEM_CPU_COUNT, VALUEOP=EQ, VALUE=2) indicates that the job
requires a machine with 2 CPUs.
Corresponding metric in the CA SystemEDGE agent: Number of CPUs
SYSTEM_CPU_SPEED
Defines the system clock speed (in MHz) the job requires.
Example: (SYSTEM_CPU_SPEED, VALUEOP=EQ, VALUE=100) indicates that the job
requires a machine with clock speed of 100MHz.
Corresponding metric in the CA ACM agent: CPU Speed
Real Resources
SYSTEM_OS_TYPE and VERSION
Specifies the operating system name and version number that the job requires.
Example: (SYSTEM_OS_TYPE, VALUEOP=EQ, VALUE=AIX, VERSION=5.3) indicates
that the job requires a machine with an AIX 5.3 operating system.
Corresponding metrics in the CA SystemEDGE agent: OS Type/OS Version
SYSTEM_PHYSICAL_MEMORY
Defines the total amount of available physical memory (in MB) that the job
requires.
Example: (SYSTEM_PHYSICAL_MEMORY, VALUEOP=GTE, VALUE=200) indicates that
the job requires a machine with at least 200 MB of physical memory.
Corresponding metric in the CA SystemEDGE agent: Physical Memory
SOFTWARE_NAME and VERSION
Specifies the software and version number that the job requires.
Example: (SYSTEM_SOFTWARE_NAME, VALUEOP=EQ, VALUE=Adaptive Enterprise
Server Sybase, VERSION=15.0) indicates that the job requires a machine that has
Adaptive Enterprise Server Sybase 15.0 installed.
Corresponding metrics in the CA ACM agent: SOFTWARE_NAME/VERSION
The previous examples show the syntax for specifying the resource value in a real
resource dependency definition.
Notes:
■ To use real resource dependencies, you must do the following:
■ Install and configure the CA Automation Suite for Data Centers SDK clients on
the CA Workload Automation AE scheduler and application server machines.
■ Install the CA Automation Suite for Data Centers agents (CA SysEdge and CA
ACM agents) on all agent machines that utilize real resources for load
balancing. You must install the CA ACM agent only if you want to utilize
SOFTWARE and SYSTEM_CPU_SPEED metrics.
■ For more information about configuring CA Workload Automation AE to work with
CA Automation Suite for Data Centers, see the UNIX Implementation Guide or
Windows Implementation Guide.
Virtual Resources
Virtual resources can help you control job execution and can improve your
environment's performance. They represent values that can be quantified, but they are
not directly tied to a physical system. CA Workload Automation AE does not check
whether a virtual resource is an actual device that exists or whether it is a device that is
being used by another process.
You can use virtual resources to prevent jobs from running simultaneously and ensure
that a job is submitted only when the minimum number of resources is available. For
example, you can define a virtual resource to represent the maximum number of
floating product licenses available in your enterprise. Each time a qualified job runs, a
unit of that resource is used. When all the units are used, no more jobs can run.
You can define the following types of virtual resources on CA Workload Automation AE:
■ Depletable
■ Renewable
■ Threshold
A virtual resource can be defined for a specific machine, or it can be defined at the
global level. A resource defined for a specific machine is available to jobs submitted to
that machine. A resource may be defined to more than one specific machine. A resource
at the global level is available to all machines controlled by CA Workload Automation
AE. Global resources can help control workload balancing across all machines.
Note: You can define resources for distributed machines only. Before you can define a
resource on a machine, the machine must already be defined on the database.
You can specify virtual resources as dependencies to jobs. A job with resource
dependencies is submitted only when the resources required are available. If the
required resources are not available, the job goes into a RESWAIT state and is not
submitted until the resources are available.
Virtual resources are associated with corresponding resource pools. When jobs with
virtual resource dependencies run, the used resources are temporarily or permanently
removed from the resource pool, depending on the virtual resource type.
CA Workload Automation AE is the resource manager for virtual resources.
Virtual Resources
Notes:
■ When you force start a job in FAILURE or TERMINATED status that has a virtual
resource dependency with free=Y or free=N and has not released the virtual
resources, the FORCE_STARTJOB event verifies if the job's current status is FAILURE
or TERMINATED and schedules the job using the already held virtual resources.
Before force starting the job, the scheduler does not re-evaluate other resource
dependencies. For more information about the FORCE_STARTJOB event, see the
Reference Guide.
■ When you update a job, you cannot update the resources attribute in the existing
job definition if the job has a resource dependency and has held the resource.
■ Virtual resources are secured using CA EEM (external security mode). The native
security in CA Workload Automation AE does not secure virtual resources. For more
information about securing virtual resources using CA EEM, see the Security Guide.
Depletable Resources
A depletable resource is a consumed resource. When a job that uses this resource is
submitted, the used resource units are permanently removed from the resource pool.
When the resource is completely depleted or jobs require more units than what is
currently available, jobs that need it go into a RESWAIT state and are not submitted until
the resource is available. You can manually replenish the resource using the
update_resource JIL subcommand. After the resource is replenished, other jobs can use
it.
Depletable resources are helpful when you want to represent values that have a limit,
such as the maximum times to run a job. Depletable resources are also helpful when
you want to control how many times a job can run in a specified time period.
Example: Run a Job Only Once a Day
Suppose that a bank wants to post daily transactions to its master database only once a
day at midnight to ensure data integrity and system performance. To run this critical job
only once a day, you can do the following:
1. Define a depletable resource with an amount of 1, as follows:
insert_resource: depletable1
res_type: D
machine: hostname
amount: 1 Virtual Resources
2. Define the critical job with the following conditions:
■ The job requires one unit of the depletable resource before it can start.
■ The job is scheduled to start at midnight.
The job is defined as follows:
insert_job: ResDepJob
job_type: CMD
command: /tmp/DBIntensiveApp
machine: hostname
owner: root@hostname
resources: (depletable1,QUANTITY=1)
When the job is submitted, one unit of the resource is permanently removed from the
resource pool. If the job fails, CA Workload Automation AE restarts the job (based on
the n_retrys attribute), but the job goes into RESWAIT state because no units of the
resource are available. The RESWAIT state indicates that a potential problem occurred.
You must run the job must manually.
Note: To add additional resources to a depletable resource, use the update_resource
subcommand. For example, the following command adds 15 units to the depletable1
resource:
update_resource: depletable1
machine: hostname
amount: 15
Renewable Resources
A renewable resource is a borrowed resource. When a job that uses this resource is
submitted, the used resource units are temporarily removed from the resource pool.
When the job completes, the resource units are returned to the pool, or the units are
held until they are manually released back to the pool. Renewable resources are helpful
when you want to control jobs that run concurrently or serially.
When the resource is being used, other jobs that need more units than what is currently
available go into a RESWAIT state and are not submitted until the resource is available.
You can change the amount of resource units available using the update_resource JIL
subcommand. After the amount is changed, a greater number of jobs that need the
resource can run concurrently.
Virtual Resources
Example: Control the Maximum Number of Licenses Used
Suppose that your enterprise has 10 floating licenses for a program. Multiple licenses
can be used on one machine, or they can be used on up to 10 machines. At any time,
you want to ensure that the maximum number of licenses used is 10. To control the
maximum number of licenses being used, you can do the following:
1. Define a renewable resource at the global level with an amount of 10, as follows:
insert_resource: r1
res_type: R
amount: 10
2. Define each job that requires the license with the following conditions:
■ The job requires one unit of the renewable resource before it can start.
■ The job frees the renewable resource whether it completes successfully or not.
The job is defined as follows:
insert_job: jr1
command: sleep 500
machine: hostname
resources: (r1,quantity=1, FREE=A)
When a job is submitted, one unit of the resource is temporarily removed from the
resource pool. Because there are only 10 units, only 10 of these jobs can run
simultaneously on any machine in the enterprise. Other jobs that require a license
cannot be submitted because no resources are available. When a job that is running
completes, one unit of the resource is returned to the resource pool. Another job can be
submitted because a unit is now available.
Threshold Resources
A threshold resource is a sizing resource. For example, if the threshold resource is set to
2, CA Workload Automation AE submits the jobs that require 2 or fewer units. Threshold
resources are helpful when you want to define a boundary that controls which jobs are
submitted to run. The used resource units are not removed from the resource pool.
A job that has a dependency on a threshold resource is only submitted if it requires the
available resource units or fewer. Otherwise, the job goes into a RESWAIT state and is
not submitted until the threshold amount is increased. You can change the threshold
amount using the update_resource JIL subcommand. After the amount is changed, the
jobs that meet the threshold can run.
Example: Prevent Jobs from Running When a Critical Resource is Offline
Suppose that multiple jobs read and write to a disk on a machine named mach1. When
the disk needs to be formatted, you want the jobs to stop running. To prevent the jobs
from running when the disk is offline, you can do the following:
1. Define a threshold resource on the mach1 machine with an amount of 1, as follows:
insert_resource: t1
machine: mach1
res_type: T
amount: 1
2. Define each job that reads and writes to the disk and requires one unit of the
threshold resource before it can start, as follows:
insert_job: jt1
command: readnadwritetodisk
machine: mach1
resources: (t1, quantity=1)
3. Define a job named TRIGGER_JOB that resets the threshold amount to 0 to indicate
that the disk is offline. The trigger job runs the update_resource command as
follows:
update_resource: t1
machine: mach1
amount: 0
When the disk is online, the threshold resource amount is 1, so all jobs that need to
read and write to the disk are submitted (the jobs meet the threshold requirement).
When the disk needs to be formatted, you can run TRIGGER_JOB, which resets the
threshold resource amount to 0. All the jobs that need to read and write to the disk go
into a RESWAIT state and are not submitted until the threshold is set to 1.
Define a Virtual Resource
To use virtual resource dependencies in your jobs, you must first add the virtual
resource definition to the database. You can define virtual resources on distributed
machines only.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.
2. Specify the following subcommand and attributes:
insert_resource: resource_name
Specifies the virtual resource to be defined.
amount
Defines the number of units to assign to the virtual resource.
res_type
Specifies the virtual resource type (D for depletable, R for renewable, or T for
threshold).
3. Specify the following additional attribute if you want to define the resource for a
machine:
machine
Specifies the name of the machine to define the virtual resource for. The
machine must already be defined on the database, and the type of the machine
cannot be v, w, or p.
Note: If you do not specify the machine attribute, the resource will be available to
all machines (global level resource).
4. (Optional) Specify the following additional attribute:
description
Defines a free-form text description of the virtual resource.
5. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The insert_resource subcommand is issued and the specified virtual resource is
defined.
Notes:
■ The virtual resource name must be unique across all resource types.
■ You cannot define the same virtual resource at the machine level and global level.
■ You can define the same virtual resource on multiple machines.
■ For more information about the syntax for the insert_resource subcommand and
related attributes, see the Reference Guide.
Example: Define a Global Depletable Resource
This example defines a virtual depletable resource named glob_res. The machine
attribute is not specified, so the resource is available to all machines.
insert_resource: glob_res
res_type: D
amount: 50
description: "This resource is permanently consumed."
Example: Define a Machine-Level Threshold Resource
This example defines a threshold resource for the unixagent machine. The resource is
assigned 10 units, so only jobs that require 10 or fewer units of this resource are
submitted to the unixagent machine.
insert_resource: threshold_res
res_type: T
machine: unixagent
amount: 10 Update a Virtual Resource
Update a Virtual Resource
You can update the amount and description properties of a virtual resource definition in
the database. Updating the resource amount is helpful when you want to change the
number of jobs that can run concurrently or serially.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.
2. Specify the following subcommand:
update_resource: resource_name
Specifies the virtual resource to be updated. This resource must be defined in
the database.
3. Specify the following additional attribute if the resource is defined for a machine:
machine
Identifies the name of the machine that the virtual resource is defined for.
Note: If you do not specify the machine attribute, CA Workload Automation AE
assumes the resource is a global resource. If the resource is machine-level, but the
machine attribute is not specified, you will get an error.
4. (Optional) Specify the following additional attributes:
amount
Defines the number of units to assign to the virtual resource. The number can
be an absolute value or a relative value.
description
Defines a free-form text description of the virtual resource.
5. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The update_resource subcommand is issued and the specified virtual resource is
updated.
Notes:
■ You cannot update resource types or machine names using the update_resource
subcommand. To update resource types or machine names, you must delete the
resource and add it to database again with the new properties.
■ For more information about the syntax for the update_resource subcommand and
related attributes, see the Reference Guide.
Example: Update a Machine-Level Virtual Resource
This example updates a virtual resource that is associated with the unixagent machine.
The number of units is changed to 35.
update_resource: mach_res
machine: unixagent
amount: 35
Suppose that the amount attribute is defined as follows:
amount: +20
In this situation, the command adds 20 units to the available resource count. For
example, if the resource already has 35 units, the command adds 20 units and the total
would be 55.
Similarly, suppose that the amount attribute is defined as follows:
amount: -20
If the resource has 35 units, the command removes 20 units and the total would be 15.
Delete a Virtual Resource
You can delete a virtual resource that you no longer use.
Note: You cannot delete a virtual resource if it is referenced as a dependency in a job.
To delete the resource, you must delete all the related job dependencies first. If a
resource is deleted while a job that references it as a dependency is active or running,
the job continues to run and is not affected.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.
2. Specify the following subcommand:
delete_resource: resource_name
Specifies the virtual resource that you want to delete.
3. Specify the following additional attribute if the resource is defined for a machine:
machine
Identifies the name of the machine that the virtual resource is defined for.
Note: If you do not specify the machine attribute, CA Workload Automation AE
assumes the resource is a global resource. If the resource is machine-level, but the
machine attribute is not specified, you will get an error.
4. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The delete_resource subcommand is issued and the specified virtual resource is
deleted.
Note: For more information about the syntax for the delete_resource subcommand and
related attributes, see the Reference Guide.
Example: Delete a Global Virtual Resource
This example deletes the global virtual resource named glob_resource.
delete_resource: glob_resource Define Real and Virtual Resource Dependencies in a Job
Define Real and Virtual Resource Dependencies in a Job
You can define a job to have dependencies on real and virtual resources. A job with
resource dependencies is submitted only when the resources required are available.
Using resource dependencies can help you control job execution and improve your
environment's performance.
Note: You cannot define a resource dependency on a box.
Follow these steps:
1. Insert a job and add the following attribute to the job definition:
resources
Defines one or more real and virtual resource dependencies.
Note: To define a virtual resource dependency, the virtual resource must
already be defined on the database.
2. (Optional) Add the following attribute:
priority
Defines the queue priority of the job. The queue priority establishes the
relative priority of all jobs queued for a given machine. A lower number
indicates a higher priority. Jobs with a higher priority get the required
resources first and run before lower priority jobs.
3. Run the job.
The job is defined with the specified resource dependencies. The job is submitted
when the required resources are available.
Note: For detailed information about the syntax for the resources and priority
attributes, see the Reference Guide.
Define Real and Virtual Resource Dependencies in a Job
Example: Define a Virtual Resource Dependency that Does Not Free the Resources
After Job Completion
This example defines a Command job that has a dependency on a virtual renewable
resource. Before the job can start running, it needs all the units of the renew_res
resource.
insert_job: no_free_job
job_type: CMD
machine: unixagent
command: /u1/procrun.sh
resources: (renew_res, QUANTITY=ALL, free=N)
After the job completes, the units of the renew_res resource are not freed from the job.
To return the units back to the available resource pool, you must issue the following
command:
sendevent -E RELEASE_RESOURCE -J no_free_job
Suppose that the job is defined with the following attribute:
resources: (renew_res, QUANTITY=5, free=Y)
If the job completes successfully, the resource is added back to the resource pool. This is
the default behavior.
Suppose that the job is defined with the following attribute:
resources: (renew_res, QUANTITY=5, free=A)
The resource is released back to the pool unconditionally.
Example: Define Real and Virtual Resource Dependencies
This example defines a Command job that has real and virtual resource dependencies.
Before the job can start running, it needs a machine that satisfies all the following
dependencies:
■ 1 unit of the depletable resource named D1
■ 3 units of the threshold resource named T1
■ 4 units of the renewable resource named R1
■ SYSTEM_OS_TYPE is AIX 5.3
■ SYSTEM_PHYSICAL_MEMORY is greater than 2 GB
insert_job: res_dep_job
job_type: CMD
machine: unixagent
command: /u1/procrun.sh
resources: (D1, QUANTITY=1) AND (T1, QUANTITY=3) AND
(R1, QUANTITY=4, FREE=Y) AND
(SYSTEM_OS_TYPE, VALUEOP=EQ, VALUE=AIX, VERSION=5.3) AND
(SYSTEM_PHYSICAL_MEMORY, VALUEOP=GT, VALUE=2048)
Update Real and Virtual Resource Dependencies in a Job
You can update the real and virtual resource dependencies defined in a job.
Follow these steps:
1. Do one of the following:
■ Issue JIL in interactive mode.
■ Open a JIL script in a text editor.
2. Specify the following subcommand and attribute:
update_job: job_name
Specifies the job to update.
resources
Specifies one or more real and virtual resource dependencies to update.
Update Real and Virtual Resource Dependencies in a Job
3. Do one of the following:
■ Enter exit if you are using interactive mode.
■ Redirect the script to the jil command if you are using a script.
The update_job subcommand is issued and the specified real and virtual resource
dependencies are updated.
Note: For detailed information about the syntax for the resources attribute, see the
Reference Guide.
Example: Update Real and Virtual Resource Dependencies
This example updates the real and virtual resources in the proc_daily job. RENEW3
virtual resource dependency does not have the free keyword defined, so the resource
units are freed if the job completes successfully (the default).
update_job: proc_daily
resources: (RENEW3, QUANTITY=3) AND (THRESHOLD2, QUANTITY=3) AND (SYSTEM_CPU_COUNT,
VALUEOP=GT, VALUE=2) Release Renewable Resources
Release Renewable Resources
When you define a job to have a virtual renewable resource dependency, you can
specify whether the units of the resource are freed after the job completes. If the units
are not freed, you can manually release them back to the resource pool so that other
jobs can use them.
To manually release renewable resources, enter the following command at the UNIX
operating system prompt or the Windows instance command prompt:
sendevent -E RELEASE_RESOURCE -J job_name
job_name
Specifies the job that you want to release the renewable resources from.
The sendevent command is issued and the resources are released from the job.
Note: For more information about the sendevent command, see the Reference Guide.
Example: Release Renewable Resources
Suppose that you defined a virtual renewable resource named ren1 that has two units.
JobA and JobB are also defined with a dependency on ren1. Each job requires one unit
of ren1 before it can run. The jobs release the resource units only if they complete
successfully.
When the jobs are submitted, the required units are temporarily removed from the
resource pool. Suppose that JobA completes successfully and JobB fails. JobA returns
one unit of resource to the resource pool. The other unit used by JobB is held, so the
resource pool only has one unit. Other jobs that require more than one unit go into a
RESWAIT state until the required units are available.
The following command manually releases the one unit of resource held by JobB so that
other jobs can use it:
sendevent -E RELEASE_RESOURCE -J JobB Generate a Report on Current Resource Definitions
Generate a Report on Current Resource Definitions
You can generate a report that displays the current resource definitions in a database.
Generating a report is helpful when you want to determine the properties of a resource
and the values that can be specified when defining resource dependencies in jobs.
To generate a report on the current resource definitions, enter the following command
at the UNIX operating system prompt or the Windows instance command prompt:
autorep –V resource_name -q
resource_name
Specifies the virtual resource definition that you want to generate a report on. You
can use wildcard characters.
The autorep command is issued and the report is generated.
Note: For more information about the autorep command, see the Reference Guide.
Generate a Report to Display a Job's Resource Dependencies
You can generate a report that displays a job's current definition, including its resource
dependencies.
To generate a report to display a job's resource dependencies, enter the following
command at the UNIX operating system prompt or the Windows instance command
prompt:
autorep –J job_name -q
job_name
Specifies the job that you want to generate a report for.
The autorep command is issued and the report is generated. The job's resource
dependencies are included in the report.
Note: For more information about the autorep command, see the Reference Guide.
Generate a Report to Monitor Virtual Resource Usage
You can generate a report that monitors virtual resource usage. This report is helpful
when you want to check how many units a virtual resource has defined, how many units
are currently available, and which machines are using the resource during run time.
Note: The detail report (-d option) only displays the jobs that are currently using the
resource.
To generate a report to monitor virtual resource usage, enter one of the following
commands at the UNIX operating system prompt or the Windows instance command
prompt:
■ To generate a summary report:
autorep –V resource_name -s
■ To generate a summary report and detail report:
autorep –V resource_name -d [-M machine_name]
-V resource_name
Specifies the virtual resource definition that you want to generate a report for. You
can use wildcard characters.
Note: You can specify ALL to generate a report on all resource definitions.
-s
Generates a summary report.
-d
Generates a summary report and detail report.
[-M machine_name]
(Optional) Filters the detail report to display only the specified machine. You can
use wildcard characters to match machine names.
Default: ALL (If you do not specify the -M option, the report displays all machines
that are using the resource.)
The autorep command is issued and the report is generated.
Note: For more information about the autorep command, see the Reference Guide.
Generate a Report to Monitor Virtual Resource Usage
Example: Generate a Summary Report for a Global Virtual Resource
This example generates a summary report for the virtual resource named ren1. The
resource is global, so it is available to all machines.
autorep -V ren1 -s
The report displays the following information:
Name Machine Defined Available
---- ------- ------- ---------
ren1 -- 4 1
The resource has a total of 4 units defined. It has 1 unit available, so 3 units are
currently being used by jobs.
Example: Generate Summary and Detail Reports for a Global Virtual Resource
This example generates a summary report and a detail report for the ren1 virtual
resource. The resource is global, so it is available to all machines.
autorep -V ren1 -d
The resulting report might resemble the following:
Resource Name Type Machine Defined Available
___________________________ ___________ _____________________ _______ _________
ren1 V --- 4 1
/**** Current Resource Usage ****/
ResName JobName Run/Ntry Status Machine Amount in Use
__________________ __________________ ___________ ____________ ___________ _____________
ren1 job1 1/1 RUNNING machine1 1
ren1 job2 1/1 RUNNING machine2 2
The -M option is not specified in the command, so the report displays all the jobs that
are currently using the resource.
Example: Generate Summary and Detail Resource Reports for Individual Machines
Suppose that the virtual renewable resource named res_count is defined on three
different machines (amachine1, machine2, and bmachine3). This example generates a
summary report and a detail report for the res_count resource.
autorep -V res_count -d -M amachine*
The report displays the following information:
Name Machine Defined Available
---- ------- ------- ---------
res_count amachine1 4 0
res_count amachine2 3 1
/**** Current Resource Usage ****/
ResName JobName Run/Ntry Status Machine Amount in Use
------- ------- -------- ------ ------- -------------
res_count Job1 1/1 RUNNING amachine1 4
res_count Job2 2/1 RUNNING amachine2 2
The report displays the jobs that are currently running. The -M option is specified with a
wildcard, so the report only displays the jobs on the machines whose names match the
-M value.
You can generate a report that monitors virtual resource dependencies. This report is
helpful when you want to check which resources a job depends on and which of the
resource dependencies are satisfied.
To generate a report to monitor virtual resource dependencies, enter the following
commands at the UNIX operating system prompt or the Windows instance command
prompt:
job_depends -J job_name -r
job_name
Specifies the job that you want to generate a dependency report for.
The job_depends command is issued and the report is generated.
Note: For more information about the job_depends command, see the Reference Guide.
Example: Generate a Report on Virtual Resource Dependencies
Suppose that you define three virtual resources (dep1, ren1, and thr1). The resources
are global, so they are available to all machines.
insert_resource: dep1
res_type: D
amount: 0
insert_resource: ren1
res_type: R
amount: 0
insert_resource: thr1
res_type: T
amount: 1
You also define a job named job1 that belongs to a machine group that includes the M1
and M2 machines. job1 depends on all three virtual resources.
insert_job: job1
job_type: CMD
command: &sleep 500
machine: machineGroup1 /* This machine group includes machines M1 and M2. */
resources: (ren1, QUANTITY=1, FREE=A) AND (dep1, QUANTITY= 1) AND (thr1, QUANTITY=
1)
The following command generates a report on job1's resource dependencies on the M1
and M2 machines:
job_depends -J job1 -r
The report displays the following information:
Job Name Machine
-------- ----------
job1 M1
Virtual Resources
-----------------
Resource Type Amount Satisfied?
-------- ---- ---- ----------
ren1 R 1 NO
dep1 D 1 NO
thr1 T 1 YES
Job Name Machine
-------- -------
job1 M2
Virtual Resources
-----------------
Resource Type Amount Satisfied?
-------- ---- ---- ----------
ren1 R 1 NO
dep1 D 1 NO
thr1 T 1 YES
Example: Generate a Report on Virtual and Real Resource Dependencies
Suppose that you define a job with virtual and real resource dependencies as follows:
insert_job: jobA
job_type: CMD
command: &sleep 500
machine: M1 /* This is an AIX machine */
resources: (ren1, QUANTITY=1, FREE=A) AND (thr1, QUANTITY= 1) AND (SYSTEM_OS_TYPE,
VALUEOP=EQ, VALUE=AIX)
The following command generates a report on job1's resource dependencies on the M1
machine:
job_depends -J job1 -r
The report displays the following information:
Job Name Machine
-------- ----------
jobA M1
Virtual Resources
-----------------
Resource Type Amount Satisfied?
-------- ---- ------ ----------
ren1 R 1 NO
thr1 T 1 YES
Real Resources
---------------------
Resource Satisfied?
----------- -----------
SYSTEM_OS_TYPE, VALUEOP=EQ, VALUE=AIX YES
Note: If the SysEdge agent is not available (that is, it is not installed or not running) on
the machine M1, all the real resources dependencies are disqualified although they
satisfy the resource dependency criterion. In this example, if the SysEdge agent is not
running, the Satisfied field displays "NO”.
No comments:
Post a Comment