skip book previous and next navigation links
go up to top of book: HP OpenVMS Alpha Partitioning and Galaxy Guide HP OpenVMS Alpha Partitioning and Galaxy Guide
go to beginning of chapter: NUMA Implications on OpenVMS Applications NUMA Implications on OpenVMS Applications
go to previous page: Application Resource Considerations Application Resource Considerations
go to next page: RAD Application Programming InterfacesRAD Application Programming Interfaces
end of book navigation links

Batch Job Support for NUMA Resource Affinity Domains  



This section describes updates to the OpenVMS batch processing subsystem in support of resource affinity domains (RADs) in a NUMA environment.

System managers can assign batch queues to specific support of resource affinity domains (RADs) in a NUMA environment, and users can specify a RAD on which to run a batch job.

These new features are restricted for use on batch execution queues and batch jobs.

See the HP OpenVMS DCL Dictionary for DCL command information.

Batch Queue Level RAD Support  

A new qualifier, /RAD, is available to the following DCL commands: INITIALIZE/QUEUE, SET/QUEUE, and START/QUEUE. The system manager specifies the RAD number on which to run batch jobs assigned to the queue.

The RAD value is validated as a positive integer between 0 and SYI$_RAD_MAX_RADS. The SHOW/QUEUE/FULL command now displays the RAD in its output, and the F$GETQUI lexical function now accepts a new RAD item.

Examples  

This section describes a sequence of the commands and their effects on a batch queue. A SHOW command is included in each example to illustrate the batch queue modifications.

Job Level RAD Support  

The new qualifier, /RAD, is added to the following DCL commands: SUBMIT and SET/ENTRY.

The user specifies the RAD number on which the submitted batch job is to execute in the qualifier value. The SHOW ENTRY and SHOW QUEUE/FULL commands are enhanced to list the RAD setting on batch jobs.

Examples  

When a job is submitted to a batch queue that does not have a RAD setting, the job will execute using the RAD specified on the SUBMIT command.

The following command submits TEST.COM to the queue ANYRADQ. There is no RAD setting on the ANYRADQ queue.

$ SUBMIT/HOLD/QUEUE=ANYRADQ /RAD=1  TEST.COM
Job TEST (queue ANYRADQ, entry 23) holding
 
$ SHOW ENTRY/FULL 23
  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
     23  TEST            SYSTEM               Holding
         On idle batch queue ANYRADQ
         Submitted 24-JUL-2001 14:19:37.44 /KEEP /NOPRINT /PRIORITY=100 
         /RAD=0
         File: _$1$DKB200:[SWEENEY.CLIUTL]TEST.COM;1
When a job is submitted to a batch queue that does have a RAD setting, the job will execute using the RAD specified on the queue, regardless of the RAD specified on the SUBMIT command. This behavior is consistent with other batch system features.

The queue, BATCHQ1, is defined with /RAD=0. The following SUBMIT command example creates a job that runs on RAD 0, even though the user specified RAD 1 on the submission:

$ SUBMIT/HOLD/QUEUE=BATCHQ1 /RAD=1  TEST.COM
Job TEST (queue BATCHQ1, entry 24) holding
 
$ SHOW ENTRY 24/FULL
  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
     24  TEST            SYSTEM               Holding
         On idle batch queue BATCHQ1
         Submitted 24-JUL-2001 14:23:10.37 /KEEP /NOPRINT /PRIORITY=100 
         /RAD=0
         File: _$1$DKB200:[SWEENEY.CLIUTL]TEST.COM;2

Run-Time Behavior  

When you specify a RAD on a batch job, the job controller creates the process with the new HOME_RAD argument set to the RAD value on the job.

If the RAD specified on the job is invalid on the target system, the job controller will output a BADRAD message to the operator console. If the bad RAD value matches the RAD setting on the batch queue, the batch queue is stopped. The job remains in the queue.

Error Processing  

The following example shows an error in run-time processing:

SYSTEM@QUEBIT> SUBMIT/NONOTIFY/NOLOG/QUEUE=BATCHQ1 TEST.COM
Job TEST (queue BATCHQ1, entry 30) started on BATCHQ1
 
OPCOM MESSAGES
 
SYSTEM@QUEBIT> START/QUEUE BATCHQ1
%%%%%%%%%%%  OPCOM  25-JUL-2001 16:15:48.52  %%%%%%%%%%%
Message from user SYSTEM on QUEBIT
%JBC-E-FAILCREPRC, job controller could not create a process
 
%%%%%%%%%%%  OPCOM  25-JUL-2001 16:15:48.53  %%%%%%%%%%%
Message from user SYSTEM on QUEBIT
-SYSTEM-E-BADRAD, bad RAD specified
 
%%%%%%%%%%%  OPCOM  25-JUL-2001 16:15:48.54  %%%%%%%%%%%
Message from user SYSTEM on QUEBIT
%QMAN-E-CREPRCSTOP, failed to create a batch process, queue BATCHQ1 will be stopped
 
$ SYSTEM@QUEBIT> WRITE SYS$OUTPUT  -
_$ F$message(%x'F$GETQUI("DISPLAY_ENTRY","CONDITION_VECTOR","30")')
%SYSTEM-E-BADRAD, bad RAD specified

RAD Modifications On Batch Queues  

When you change the RAD value on a batch queue, the jobs currently in the batch queue are not dynamically updated with the new RAD value specified on the queue.

Any executing jobs will complete processing using the original RAD value. Jobs in the pending, holding, or timed execution states will retain the old RAD value on the job; however, when such a job becomes executable, the job is updated with the new RAD value and runs on the RAD specified on the queue.


go to previous page: Application Resource Considerations Application Resource Considerations
go to next page: RAD Application Programming InterfacesRAD Application Programming Interfaces