SCHENV Parameter

Purpose

The SCHENV parameter specifies the name of a Workload Management (WLM) scheduling environment that a job requires for execution. A scheduling environment is a list of resources and their required states. The job can only run on systems where the scheduling environment is available and in the correct state.

Syntax

JOB Statement Format

jcl
1
//jobname JOB parameters,SCHENV=environment-name

Parameter Value

environment-name

  • 1-16 character name of a scheduling environment defined to WLM
  • Must be alphanumeric or national characters ($, #, @)
  • First character must be alphabetic or national
  • Example: SCHENV=PAYROLL or SCHENV=DB2PROD

Scheduling Environment Overview

A scheduling environment is a set of resource requirements that a job needs to execute properly. Each scheduling environment consists of one or more resources in specific states (ON or OFF). WLM ensures that a job with a SCHENV parameter only runs on systems where all resources in the specified scheduling environment are in the required state.

Key Components

ComponentDescription
ResourceA named entity representing a system feature, application, or condition
Resource StateEach resource has a state (ON or OFF) on each system
Scheduling EnvironmentA named set of resources and their required states

Use Cases

Common Usage Scenarios

  • Application Subsystem Requirements: Ensuring a job runs only on systems where specific application subsystems (like DB2, CICS, IMS) are available
  • Test vs. Production Separation: Preventing test jobs from running on production systems and vice versa
  • Hardware Dependencies: Directing jobs to systems with specific hardware features or peripherals
  • Software Version Control: Ensuring jobs run on systems with the correct software versions
  • System Maintenance Control: Preventing critical jobs from running on systems scheduled for maintenance

Examples

Basic SCHENV Specification

jcl
1
2
//PAYROLL JOB (ACCT),'JOHN DOE',CLASS=A,
//         MSGCLASS=X,SCHENV=PAYPROD

This job will only run on systems where the PAYPROD scheduling environment is satisfied.

With Other Parameters

jcl
1
2
3
//DB2JOB  JOB (ACCT),'JANE SMITH',CLASS=A,
//         MSGCLASS=X,SCHENV=DB2PROD,REGION=0M,
//         TIME=NOLIMIT

This job requires the DB2PROD scheduling environment and also specifies other execution parameters.

Job Selection Process

  1. Job Submission: When a job with SCHENV is submitted, it's placed in the JES queue
  2. System Evaluation: JES and WLM evaluate which systems have the specified scheduling environment available
  3. Resource Checking: For each potential system, WLM checks if all resources in the scheduling environment are in the required state
  4. System Selection: The job can only be selected for execution on systems where all resources match the required state
  5. Resource Unavailability: If no system has the required scheduling environment available, the job remains in the queue until resources become available

WLM Administration

Scheduling environments are defined and managed through the WLM ISPF application. System administrators can:

  • Define new scheduling environments
  • Associate resources with scheduling environments
  • Specify required resource states
  • Manage resource states on different systems
  • Display scheduling environment status across the sysplex

Note:

Scheduling environment definitions and resource states are maintained by system administrators. JCL programmers should consult with their WLM administrators to determine which scheduling environments are available and appropriate for their jobs.

JES2 vs. JES3 Considerations

JES2JES3
  • SCHENV checking done at execution time
  • Jobs remain in queue until scheduling environment is available
  • Supports dynamic changes to resource states
  • SCHENV checking integrated with JES3 job selection
  • Can consider scheduling environment during initial job routing
  • Supports main processor selection based on scheduling environment

Note: With IBM's direction to consolidate on JES2, JES3-specific functionality is being migrated to JES2 or provided through alternative means.

Restrictions and Considerations

  • JCL Validation: The syntax of the SCHENV parameter is validated when the job is submitted, but the existence of the named environment is not checked until execution
  • Invalid Environments: If a job specifies a scheduling environment that doesn't exist, the job will remain in the queue indefinitely
  • Resource State Changes: System operators can change resource states dynamically, which can affect which jobs are eligible to run
  • Emergency Override: In emergency situations, operators can override scheduling environment requirements to allow a job to run
  • JCLLIB Compatibility: The SCHENV parameter is ignored in JCL that is included via a JCLLIB statement

Best Practices

  1. Coordinate with WLM administrators to understand available scheduling environments
  2. Document scheduling environment requirements for each application
  3. Define meaningful environment names that clearly indicate their purpose
  4. Implement standards for which types of jobs require scheduling environments
  5. Consider job dependencies when designing scheduling environments
  6. Test scheduling environment configurations before implementing in production

Related Concepts