To define a scheduling environment, you need to specify the following
information:
- Scheduling Environment Name
- (Required) One to 16 character name of the scheduling environment.
- You can have up to 999 unique scheduling environments defined
in a service definition.
- Alphanumerics and the special characters @, $, # and _ are allowed.
- Underscores (_) must be imbedded (for example, PLEX_D01 is valid,
but PLEX_ is not).
- Names beginning with SYS_ are reserved for system use.
- Description
- (Optional)Up to 32 characters describing the scheduling
environment.
Once you have defined a scheduling environment, you can start selecting
its resource names and required states, as follows:
- Resource Name
- (Required) One to 16 character name of the resource. There
can be more than one resource name listed in a scheduling environment.
- You can have up to 999 unique resource names defined in a service
definition.
- Alphanumerics and the special characters @, $, # and _ are allowed.
- Underscores (_) must be imbedded (for example, PLEX_D01 is valid,
but PLEX_ is not).
- Names beginning with SYS_ are reserved for system use.
- Resource Description
- (Optional)Up to 32 characters describing each resource.
When you select a resource name to become part of the scheduling
environment, you also need to specify a required state:
- Required State
- (Required) For each resource name in a scheduling environment,
you must specify a required state of either ON or OFF:
- ON specifies that the resource name
must be set to ON on a given system for the work associated with this
scheduling environment to be assigned to that system.
- OFF specifies that the resource name
must be set to OFF on a given system for the work associated with
this scheduling environment to be assigned to that system.
Scheduling environment example
To define
a scheduling environment called DB2LATE that contains the following
requirements:
- The “DB2A” resource must be set to ON. (In this example, we'll
say that DB2A has been defined to represent the existence of the DB2® subsystem.)
- The “PRIMETIME” resource must be set to OFF. (In this example,
we'll say that PRIMETIME has been defined to be ON during the normal
weekday business hours, and OFF for all other times.)
You would define the following scheduling environment:
- Scheduling Environment
- DB2LATE
- Description
- Offshift DB2 Processing
| Resource Name |
Required State |
Resource Description |
|---|
| DB2A |
ON |
DB2 Subsystem |
| PRIMETIME |
OFF |
Peak Business Hours |
Null scheduling environments
If you no longer
need to restrict where work executes in a sysplex, you can remove
all the resource state requirements from a scheduling environment.
A null or empty scheduling environment always allows work to be scheduled;
that is, any system in the sysplex is satisfactory for work associated
with a null scheduling environment. This is a migration aid when you
initially have resources that exist on only some of the systems in
a sysplex, but later make the resources available to every system.
It saves the effort of having to remove the scheduling environment
specification from all the incoming work.
Refer to Working with scheduling environments to see how to use the WLM ISPF application
to create and modify scheduling environments.