Figure 5-1 Queue Routing
This chapter explains the NQS configuration management.
This section describes the queue configuration alterations (add, delete, edit, etc.).
You may occasionally need to create new batch queues in NQS applications because the operation mode was altered. When this need arises, be sure to take note of the relationship between existing batch queues and the new batch queues as you create them. See Chapter 4, Batch Operations, for information on creating batch queues.
As explained in Chapter 4, Batch Operations, the resource limit is one of the attributes of batch queues. This attribute restricts the use of resources by requests registered in the batch queues. If the resource limit defined in the request to be queued is larger than that defined in the queue, the entry of that queue request is rejected. This attribute is used efficiently by such classification (as into queues that allow huge consumption of resources and queues that allow little consumption of resources). The resource limit attribute can be defined with the set subcommand of the qmgr(1M) command. This implementation supports the following resource limits.
In the following, the per-process CPU time limit is changed. The queue batch1 per-process CPU time limit becomes 59.1 seconds.
Example:
# qmgr Mgr: set per_process cpu_limit=(59.1) batch1
| Home |
|---|
The resource limit is a batch queue attribute (see Section 4.2.6.1). This attribute is used as the requests' resource limit when the default standard mode is ON (see Section 5.4) and requests are submitted without specified resource limits using the qsub(1) options.
The resource standard value can be defined using the qmgr(1M) subcommand set standard. SUPER-UX supports the resource standards for all resource limits mentioned previously. See qmgr(1M) for information on the subcommands for setting the various resource standards.
The following example changes the per-process standard CPU time value.
# qmgr Mgr: set standard ppcputime = (59.1) batch1
The per-process standard CPU time value for queue batch1 becomes 59.1 seconds. The method of specifying the value is the same as that used for specifying the resource limit value.
| Home |
|---|
In addition to the resource limit attribute, the following batch queue attributes can be defined.
This attribute must be defined when creating the queue, but it can be changed later. Use the set priority subcommand of qmgr(1M) to change the queue priority. In the following, the queue priority of batch1 is changed to 10.
Example:
# qmgr Mgr: set priority =10 batch1
This attribute can be defined or changed after the creation of the queue. The set run_limit subcommand of qmgr(1M) is used to change the attribute.
In the following, the maximum number of requests for simultaneous execution of the batch queue called batch1 is changed to 5.
Example:
# qmgr Mgr: set run_limit=5 batch1
Example:
# qmgr Mgr: set nice_limit=5 batch1
The nice execution value of the batch queue called batch1 is changed to 5 by the preceding procedure.
| Home |
|---|
# qmgr Mgr:set timeslice=5 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the timeslice value of the batch queue batch1 to 5.
Example:
# qmgr Mgr:set basepriority=80 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
Example:
# qmgr Mgr:set memoryprioriy=5 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the memory priority value of batch1 in the batch queue to 5.
Example:
# qmgr Mgr:set modcpu=50 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
This procedure changes the modifier priority value of batch1 in the batch queue to 5.
Example:
# qmgr Mgr:set tickcnt=5 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
This procedure changes the tick count of batch1 in the batch queue to 5.
| Home |
|---|
Example:
# qmgr
Mgr: set dcyfctr=5 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the decay factor of batch1 in the batch queue to 5.
Example:
# qmgr Mgr: set dcyintvl=5 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
This procedure changes the decay interval of batch1 in the batch queue to 5.
Example:
# qmgr Mgr: set mrt_pri_effct=200 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
Example:
# qmgr Mgr: set mrt_size_effct=200 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
Example:
# qmgr Mgr: set aging_range=200 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
| Home |
|---|
Example:
# qmgr Mgr: set mrt_minimum=5 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
The preceding procedure changes the MRT minimum value of batch1 in the batch queue to 5.
Example:
# qmgr Mgr:set slavepriority=40 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
The preceding procedure changes the slave priority of batch1 in the batch queue to 40.
Example:
# qmgr Mgr: set cpu count = 4 batch1 NQS manager[TCML_COMPLETE]:Transaction complete at local host.
The preceding procedure changes the CPU count value of batch1 in the batch queue to 4.
Example:
# qmgr Mgr: set intra_queue_scheduling_type=type1 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the intraqueue scheduling priority of batch1 in the batch queue to type1.
Example:
# qmgr Mgr: set continuous_scheduling_number 3 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
Example:
# qmgr Mgr: set default scheduling priority = 3 batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the default scheduling priority of batch1 to 3.
| Home |
|---|
Example:
# qmgr Mgr: set fsg0_runlimit=(2kb) batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the file system group 0 runlimit of batch1 to 2 KB.
Example:
# qmgr Mgr: set fsg1_runlimit=(2kb) batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the file system group 1 runlimit of batch1 to 2 KB.
Example:
# qmgr Mgr: set fsg2_runlimit=(2kb) batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the file system group2 runlimit of batch1 to 2 KB.
Example:
# qmgr Mgr: set fsg3_runlimit=(2kb) batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the file system group 3 runlimit of batch1 to 2 KB.
| Home |
|---|
Example:
# qmgr Mgr: set memory_runlimit=(2kb) batch1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
The preceding procedure changes the memory runlimit of batch1 to 2 KB.
This attribute can be defined or modified after creating the queue. See Section 5.11.4 for details. This function is only available on cluster systems.
This attribute can be defined when creating the queue, but cannot be modified after creating it. See Section 5.12 for details. This function is only available on cluster systems.
This attribute can be defined or modified after creating the queue. This attribute is used to decide whether a request should be forcibly restarted when the related checkpoint file is unable to be opened or modified. A checkpoint file is a file opened by a request at checkpointing. By default, restarting aborts when the related checkpoint file is unable to be opened, and restarting is done forcibly when the related checkpoint file is modified.
# qmgr Mgr: set force_restart when_file_open_failed on batch1
The preceding procedure makes batch1 restart forcibly even if the checkpoint file cannot be opened.
#qmgr Mgr: set force_restart when_file_modified off batch1
The preceding procedure makes batch1 stop restarting if the checkpoint file has been modified.
You may need to add new pipe queues or pipe queues may be added due to the alteration of the operation mode, for example. When you create new pipe queues, take note of the relationship between the new and existing pipe queues. Chapter 4, Batch Operations, explains how to create a pipe queue.
| Home |
|---|
This section describes the inter-queue priority, maximum number of requests for simultaneous routing, usable server, and destination pipe queue attributes.
The queue priority is defined in the same way as the queue priority attribute of the batch queue.
This attribute can be defined or changed after the creation of the queue. The set run_limit subcommand of qmgr(1M) is used to change the attribute.
In the following, the maximum number of requests for simultaneous routing of the pipe queue called pipe1 is changed to 5.
Example:
# qmgr Mgr: set run_limit=5 pipe1
This attribute can be set or deleted after the creation of the queue. The set check subcommand of qmgr(1M) is used to set the check function.
Example:
# qmgr Mgr: set check pipe1
The set no_check command of qmgr(1M) is used to delete the check function.
Example:
# qmgr Mgr: set no_check pipe1
This Attribute can be set or deleted after creating the queue. See Section 4.2.8 for details.
This attribute can be set or deleted after creating the queue. See Section 5.11.4 for details. This function is only available on cluster systems.
This attribute must be defined when creating the queue, but it can be changed later. Use the set pipe_client subcommand of qmgr(1M) to change the server. In the following, the server is changed to /usr/lib/nqs/pipeclient2.
Example:
# qmgr Mgr: set pipe_client = (/usr/lib/nqs/pipeclient2) batch1
This attribute can be defined when creating the queue, or it can be set/changed/appended after the creation of the queue. This section provides a detailed explanation of the destination attribute.
A destination is the queue to which requests registered in the pipe queue are to be routed. When more than one queue is set as the destination, a check is made to determine whether the requests can be routed to the destinations in the lexicographic order. Requests are then sent to the routable queue.
If the following pipe queue is defined, the three cases shown in Figure 5-1 are possible. Destinations include QUEUE1, QUEUE2, and QUEUE3.
Figure 5-1 Queue Routing
| Home |
|---|
If none of the defined queues is able to accept the requests, routing is retried after a certain interval. Rerouting is repeated after the interval. However, if rerouting is still impossible after a fixed period, mail is sent to notify the user who submitted the request of the reason for the request routing failure.
The rerouting interval or the period is set as an NQS environment parameter (see Section 5.4).
The add and set subcommand of the qmgr(1M) command are used to define/change/append pipe queue destinations.
In the following, the batch1 queue on HOST1 is defined as the destination of the pipe queue called pipe1.
Example:
# qmgr Mgr: set destination=(batch1@HOST1) pipe1
If a destination is defined as shown in the preceding example, all previously set destinations are cleared.
Example:
# qmgr Mgr: add destination=(batch2@HOST1) pipe1
In the preceding example, the batch2 queue on HOST1 is added as a destination of the pipe queue called pipe1. If batch1 had already been defined as the destination of pipe1, then pipe1 would now have two destinations, namely, batch1 and batch2.
When a queue on a remote host is defined as the destination, that pipe queue becomes the Network Pipe Queue. This network pipe queue must be created to submit requests to a remote host (the most NQS network function). Specify the destination queue in the following format.
queue-name@host-name
Specify the name of a remote host as host-name to create a network pipe queue.
In the following, the procedure is performed on the HOST1 host. The netpipe1 pipe queue on HOST1 becomes the network pipe queue for submitting requests to the batch2 queue on the remote host HOST2.
Example:
# qmgr Mgr: set destination=(batch2@HOST2) netpipe1
New device queues may be required or device queues may be added (for example, due to the alteration of the operation mode). When you create new device queues, take note of the relationship between the new and existing device queues. Chapter 4, Batch Operations, explains how to create a device queue.
| Home |
|---|
This section describes the inter-queue priority and usable device attributes.
The usable device is the NQS device that processes the requests registered in the device queue. More than one NQS device can be defined as a usable device. In such a case, a check is made to determine whether the NQS devices can be processed in their lexicographic order. Requests are passed on to devices that can process them.
For example, if this device queue is defined, the three cases shown in Figure 5-2 are possible. Usable devices include DEVICE1, DEVICE2, and DEVICE3.
Figure 5-2 Device Requests
If none of the devices can process the request, passing requests to the devices is retried after a certain interval. A retry to process the request is repeated after the fixed period. If the devices still cannot process the requests after a fixed period of time, mail is sent to the user who submitted the requests indicating the reason that the requests could not be processed. The interval between requests for process (or the fixed period during which the request is repeated) are defined as an NQS environment parameter. Section 5.4 describes this parameter in detail.
The definition/alteration/addition of device queue usable devices is done with the add and set subcommands of the qmgr(1M) command. However, in the preceding example, the form was not specified when the user submitted the device request. If the user specifies the form when submitting the device request, devices that can be used are restricted to those belonging to the specified form (see Figure 5-3). Usable devices include DEVICE1, DEVICE2, and DEVICE3.
Figure 5-3 Device Request with Form Specified
In the preceding device queue and device status, the results are as follows. Form 2 is specified when submitting the device requests.
In case 3, the request for retry is carried out after a fixed period of time.
Example:
# qmgr Mgr: set device=(dev1) device1
Example:
# qmgr Mgr: add device=(dev2) device1
| Home |
|---|
The delete queue subcommand of the qmgr(1M) command is used for deleting queues. This command can be used regardless of the type of queue. However, the queue cannot be deleted if it is enabled and contains requests.
In the following, the batch queue called batch1 is deleted.
Example:
# qmgr Mgr: delete queue batch1
Chapter 4, Batch Operations, explains how to create a queue complex and define the attributes. This section explains how to alter a queue complex configuration, delete a queue complex, and alter the attributes.
The remove queue or add queues subcommand of the qmgr(1M) command is used to delete or add batch queues configuring the queue complex. In the following example, the queue called batch1 is removed from being a member configuring the queue complex named complex1.
Example:
# qmgr Mgr: remove queue=(batch1) complex1
In the following, the queue called batch4 is added as a member configuring the queue complex named complex1.
Example:
# qmgr Mgr: add queues=(batch4) complex1
The delete complex subcommand of the qmgr(1M) command is used for deleting queue complexes.
In the following, the queue complex called complex1 is deleted. The queues constituting the queue complex are not removed, even if the queue complex is deleted. Nevertheless, from the point of view of queues that are members of the configuration, it is better to consider them as having been released from the queue complex.
Example:
# qmgr Mgr: delete complex complex1
| Home |
|---|
A queue has the function to limit the entry of requests by users/groups. That is, certain users/groups are not allowed to use a certain queue. With this function, users/gr oups that can use a queue can be restricted by each queue. The status of access restriction is as follows.
When you use these methods, you can use the add users and add groups subcommand of qmgr(1M) to add users and groups to the list of who can access the specified queue, and delete users and delete groups subcommand of qmgr(1M) to delete users and groups from the list of who can access the specified queue.
| Home |
|---|
First, forbid access to the queue queue1.
# qmgr
Mgr: set no_access queue1
By this operation, all users and groups except root cannot access queue1. The qstatq(1) shows the following.
# qstatq -f queue1: ACCESS Group: User: root :
Next, add user1 to the users who can access queue1.
# qmgr Mgr: add users=user1 queue1
When you want to add group1 to the groups that can access queue1, issue as follows.
# qmgr Mgr: add groups=group1 queue1
By the above operations, superuser(root), user1, and users who belong to group1 are permitted access to queue1. At this time, qstatq(1) shows as follows.
# qstatq -f queue1 : ACCESS Group: group1 User : root user1 :
If you want to cancel the permission of a user/group, issue as follows.
# qmgr Mgr: delete users=user1 queue1 Mgr: delete groups=group1 queue1
| Home |
|---|
First, permit all users and groups access to queue2.
# qmgr Mgr: set unrestricted_access queue2
By this operation, all users and groups can access queue2. The qstatq(1) shows the following.
# qstatq -f queue2 : ACCESS Unrestricted access :
At a queue creation, the access to the queue is unrestricted. Therefore, you do not have to issue the set unrestricted_access subcommand if you have not restricted the queue access (i.e., the string "Unrestricted access" appears when you issue qstatq -f).
Next, delete user2from the users who can access queue2.
# qmgr Mgr: delete users=user2 queue2
When you want to delete group2 from the groups that can access queue2, issue as follows.
# qmgr Mgr: delete groups=group2 queue2
By the above operations, user2, and users who belong to group2 are forbidden access to queue1. At this time, qstatq(1) shows as follows.
# qstatq -f queue2 : ACCESS(DENY) Group: group2 User : user2 :
If you want to permit a restricted user/group access to the queue again, issue as follows.
# qmgr Mgr: add users=user2 queue2 Mgr: add groups=group2 queue2
| Home |
|---|
The default queue is the queue automatically selected if the user does not specify a queue when submitting a request. Its specification is optional. Default queues can be prepared for batch queue and device queue separately. The subcommand of qmgr(1M) is used for each setting.
In the following, batch1 becomes the default queue for batch requests.
Example:
# qmgr Mgr: set default batch_request queue batch1
To cancel the default queue (to have no default queue), use the following subcommand of qmgr(1M).
In the following, there is no default queue for batch requests.
Example:
# qmgr Mgr: set no_default batch_request queue
In NQS applications, new network queues may be required or network queues may need to be added due to the alteration of the operation mode. See Section 4.2.6.4.
| Home |
|---|
A network queue has attributes that include: interqueue priority, maximum number of requests for simultaneous execution, and destination.
You must define the queue priority when creating the queue, but you can change it later. Change queue priority with the qmgr(1M) subcommand set priority.
This attribute can be defined when creating a queue or it may be defined or modified after queue creation. This section describes how to define or alter this attribute after queue creation. (See Section 4.2.6.4 for information about defining this attribute at queue creation.)
When no value is specified for this attribute, the default value defined is 1. Use the qmgr(1M) subcommand set run_limit to change the maximum number of requests for simultaneous execution.
The following procedure changes the maximum number of requests for simultaneous execution for the network queue called net1 to 8.
Example:
# qmgr Mgr:set run_limit=8 net1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
This attribute can be defined when creating the queue and it can be changed later. Change the server with the qmgr(1M) subcommand set network_client.
The following procedure changes the usable server for network queue net1 to /usr/lib/nqs/netclient2.
Example:
# qmgr Mgr:set network_client=(/usr/lib/nqs/netclient2) net1 NQS manager[TCML_COMPLETE]: Transaction complete at local host.
This attribute must be defined when creating the queue. It cannot be changed. You can use the machine ID or machine name.
| Home |
|---|
This section explains the methods required when it is necessary to change the configuration of an NQS device in accordance with alteration of the NQS operation mode.
You can delete an NQS device that has currently become redundant or create a new one when necessary. Chapter 4, Batch Operations, explains how to create an NQS device. This section explains how to delete an NQS device.
The delete device subcommand of the qmgr(1M) command is used for deleting NQS devices. In the following, the NQS device called dev1 is deleted.
Example:
# qmgr Mgr: delete device dev1
As explained in Chapter 4, Batch Operations, a form groups NQS devices. There are valid form lists in forms. When a form is set, that form is registered in the valid form lists. Therefore, it is better to think of creating a form as registering the form in the valid form lists rather than creating a form.
Creating a form can be thought of as registering form lists to the form. Chapter 4, Batch Operations, explains how to create a form with the set forms subcommand of the qmgr(1M) command. If this command is executed, all previously set forms are cleared. This means that valid form lists are redefined. Execute the following procedure for adding forms, in order that new forms may be added without clearing the previously set valid form lists.
Adding a form is basically the same as the creation of a form. The only difference is that the addition of forms does not clear all previous set valid form lists as in the case with form creation. The add forms subcommand of the qmgr(1M) command is used for adding forms.
In the following, form2 is added to the valid form list. If form1 has already been set in the valid form list before the execution of the command, form1 and form2 are set in the valid form list by this procedure. If the set forms subcommand is executed instead of add forms, then only form2 is set in the valid form list.
Example:
# qmgr Mgr: add forms form2
When a form is deleted, its registration in the valid form list is canceled. The delete forms subcommand of the qmgr(1M) command is used for deleting forms. In the following, the registration of form2 is erased from the valid form list.
Example:
# qmgr Mgr: delete forms form2
Chapter 4, Batch Operations, describes the NQS device configuration. An NQS device is configured in the following manner.
Name -- Device Name
Special File -- UNIX device special file (/dev/lp, etc.)
Server program -- Program for processing requests
Form -- Grouping factor
The device configuration elements must be defined when creating the device. These elements cannot be changed or deleted after the creation of the device. Hence, the only way to change the device configuration is to re-create the device.
| Home |
|---|
There are functions in NQS for setting users to manage and operate the system. They are called NQS managers and NQS operators, respectively. These are entered into the NQS manager's list. A superuser is unconditionally registered as an NQS manager. Defining, adding and deleting functions are available for managing the NQS manager configuration.
Chapter 4, Batch Operations, explains how to define an NQS manager. If an NQS manager is defined as described in that chapter, the list of all previously set NQS managers is cleared and a new list of NQS managers is defined.
Add new NQS managers/operators in the previously set NQS manager's list as follows.
Example:
# qmgr Mgr: add managers user2: m
Example:
# qmgr Mgr: delete managers user2:m
| Home |
|---|
NQS provides environment parameters that can be specified to match the operation form. The user can thus arrange various operation forms by changing these parameters. Default values are set for these environment parameters during installation. The user can reference these environment parameters by using the show parameters subcommand of qmgr(1M). The following shows samples of the environment parameter displays.
Example:
# qmgr Mgr: show parameters Maximum global batch run_limit = 50 Maximum global network run_limit = 50 Maximum global pipe run_limit = 30 Debug level = 0 Default batch_request priority = 30 Default batch_request queue = NONE Default destination_retry time = 259200 seconds Default destination_retry wait = 300 seconds Default device_request priority = 31 No default print forms Default print queue = NONE (Pipe queue request) Lifetime = 168 hours Default network_retry time = 16 seconds Default network_retry wait = 0 seconds Default network_retry time_out = 30 seconds Default stage_retry time = 259200 seconds Default stage_retry wait = 300 seconds Default expire time = 259200 seconds Log_file = /dev/null Log_file size = 10240 bytes Log_file backup = YES Acctfile = /usr/adm/jacct Mail account = root Maximum number of print copies = 2 Maximum failed device open retry limit = 2 Maximum print file size = 1000000 bytes Netdaemon = /usr/lib/nqs/netdaemon Netclient = /usr/lib/nqs/netclient Netserver = /usr/lib/nqs/netserver (Failed device) Open_wait time = 5 seconds NQS daemon is not locked in memory Next available sequence number = 4943 Batch request shell choice strategy = FREE Mapping mode = TYPE1 Acct out mode = on Maximum batch request priority = 0 Checkpoint mode = on Budget_check mode = off Maximum global group submit limit = Unlimited Maximum global user submit limit = Unlimited Maximum global group run limit = Unlimited Maximum global user run limit = Unlimited Maximum global FSG0 (XMU) run limit = Unlimited Maximum global FSG1 run limit = Unlimited Maximum global FSG2 run limit = Unlimited Maximum global FSG3 run limit = Unlimited Maximum global memory run limit = Unlimited Global resource-occupy wait = Undefined Resource standard mode = off Inter Queue Scheduling mode = TYPE0 Acctcode handling mode = off Job_acct_file = /usr/adm/jobacct
| Home |
|---|
Individual environment parameters are explained next.
| Home |
|---|
| Home |
|---|
Lock status of NQS daemon
This parameter specifies whether the NQS daemon is locked in memory.
| Home |
|---|
qmgr(1M) subcommands are provided to define or change these environment parameters. Therefore, users can change environment parameters that are not suitable for their particular purpose by specifying these subcommands. For details of these subcommands, see the explanation of the qmgr(1M) command.
To increase the number of batch requests that can be executed simultaneously, see the following.
Example:
# qmgr Mgr: set global batch_request_limit 15
In this example, the number of batch requests is increased to 15.
| Home |
|---|
There are three types of shell strategies: FIXED, FREE, and LOGIN. These shell strategies are invalid when the shell for executing the batch requests is explicitly specified when the user submits the requests. If the user does not specify the shell when submitting batch requests, all the batch requests are executed according to the shell strategy defined by the NQS manager. A shell strategy is defined via the NQS environment parameters. The default shell strategy is FREE.
Using this strategy, the shell specified by the manager is used when executing batch requests.
In this strategy, the login shell of the user of the requests is first activated when executing the batch requests. Next, the login shell selects the most suitable shell for executing the batch requests. The selected shell subsequently executes the batch requests. It is as if the batch requests are executed interactively.
In this strategy, the login shell of the user of the requests is used as the shell for executing the batch requests.
In the following, the shell strategy is FIXED and the shell for processing the batch requests is /bin/sh.
Example:
# qmgr Mgr: set shell_strategy fixed=(/bin/sh)
In the following, the shell strategy becomes FREE.
Example:
# qmgr Mgr: set shell_strategy free
In the following, the shell strategy becomes LOGIN.
Example:
# qmgr Mgr: set shell_strategy login
| Home |
|---|
The NQS network environment briefly explained in Chapter 4, Batch Operations, is described in detail in this section.
There are functions in NQS that send or receive requests among the hosts via the network. For such functions to be possible, each host must have an NQS network environment. Generally, there are two types of NQS network environments: the first concerns the hosts, while the second concerns the users.
On UNIX, each machine is given a host name for differentiating the machines on the UNIX network. This host name is defined in /etc/hosts. NQS also uses this host name to identify the machine. However, as this host name is used for communication with the users, NQS actually identifies the host ID related to the host name. Therefore, the NQS manager must associate the host name with the host ID. Since this host ID is used only within NQS, it can be determined regardless of the IP address. The manager of the machines on the NQS network must ensure that host IDs are not duplicated.
Once the host IDs on the NQS network are determined, specify the host ID of the user machine in the system. This setting is normally provided when NQS is installed. However, it can be altered by the method explained later. Next, establish an association such that NQS on the user machine can recognize host IDs and host names of other machines on the NQS network. This association is called the remote machine definition.
UNIX manages users by their user IDs and group IDs. Since the same holds true for NQS, it is essential that these IDs be recognizable by NQS. Since information on the user IDs or group IDs of users on the local host may be referenced with the /etc/passwd file, no special definition is required. However, users from remote hosts must first be defined, and their IDs on the local host of remote users must be set. This is commonly known as remote user definition or remote user mapping. There are three forms for setting a user ID from a remote host. These forms are called mapping modes and are explained as follows.
Figure 5-4 NQS Mapping Modes
| Home |
|---|
Remote machine definition refers to the association of host names on the machines to host IDs used on the NQS network. Remote machine definition is done with the nmapmgr(1M) command. For example, the manager of HOST 1 in the diagram (Figure 5-4)in Section 5.6.2 defines remote machines as shown next. Example:
# nmapmgr NMAPMGR>: add mid 100 HOST1NMAP_SUCCESS: Successful Completion. |
Definition of own machine (supposed to be defined beforehand). |
NMAPMGR>: add mid 110 HOST2NMAP_SUCCESS: Successful Completion. |
Definition of machine 2. |
NMAPMGR>: add mid 120 HOST3NMAP_SUCCESS: Successful Completion. |
Definition of machine 3. |
In the preceding example, the preparation to accept network requests from machine 2 and machine 3 is complete. However, network functions cannot be used if your own machine (machine 1) is not defined in the appropriate machines (machine 2 and machine 3). Therefore, to link to the network, you must request the definition of your own machine (after discussion with the appropriate machine manager).
The remote machine once defined is altered as shown next. The host ID 110 of host 2 is changed to 200.
Example:
NMAP_SUCCES: Successful completion.
NMAP_SUCCES: Successful completion.
Remote user definition refers to the association of user IDs/group IDs on the remote hosts with user IDs/group IDs on the local host. You can do this with the nmapmgr(1M) command. In the following, the user whose ID is 200 on the machine with the host ID 100 is treated as the user with user ID 205 on the local machine.
Example:
In the following example, the user whose group ID is 300 on the machine with the host ID 100 is treated as the user with group ID 305 on the local machine.
Example:
| Home |
|---|
The NQS Job Occurrence Report reports operator information on items such as system resources used by a request entered by a user. Edit the /usr/lib/nqs/acctexe file with the editor to change the existing report format to a format that provides more or less information. The .usr/lib/nqs/acctexe file provided comes with the following script:
Information on system resources actually used by a request is obtained with the acctjob(1) command. To increase or decrease the amount of information reported by the NQS Job Occurrence Report, add options to, or remove options from, the acctjob command in the script. Only add or remove options before the _I in the script and make certain that the acctjob(1) command line always ends with -I $1 $2.
Example:
For more detailed explanation of the acctjob(1) command and a list of its options, see the SUPER-UX User's Reference Manual.
To modify the NQS Job Occurrence Report, such as by adding a header, add the necessary commands to the script in the /usr/lib/nqs/acctexe file.
Example:
NQS batch job account information must be output to make notification of a JOR. See Section 6.7 for a detailed explanation of NQS batch job accounts.
| Home |
|---|
When a request is submitted/executed, NQS can check whether the request owner's budget is exhausted. If the budget is exhausted, NQS refuses to submit and execute the request. NQS can also display if the user's budget is exhausted.
To modify the budget_checking style (for example, to have NQS only display warning messages without rejecting requests even in the case of an exhausted budget), you must modify /usr/lib/nqs/properlychk and /usr/lib/nqs/properlylist. The system provides these two files.
Checking the budget is done by budgetchk(1M). Dealing with the result of budgetchk(1M) determines the budget_checking style. The properlychk script file, however, must meet the following conditions.
Do not regard the following options as errors.
These options have the following meanings
Do not specify these options at the same time.
These options are specified when NQS starts the properlychk script file.
The following values are used as the script completion code.
NQS uses these completion codes as its own movement status. When another value is received, it is regarded as 0.
Options and completion status (NQS's movement status) may be added in future releases.
The properlylist script file must not be different from properlychk.
For instance, you can specify that properlychk should only display a warning message and return 0 as the completion status even if the user's budget is exhausted and that budgetchk(1M) should return 1 as the completion status. To match, you must also specify that properlylist does not call budgetchk(1M) or display budgetchk(1M) results. See the SUPER-UX User's Reference Manual for more information about budgetchk(1M) and its options. An example of a script image of properlychk and properlylist follows.
Example:
#! /bin/sh
#
#ident "@(#)$ID: properlychk,..."
# Copyright (c) 1992 NEC Corporation.
#
#
NQSLIB=/usr/lib/nqs
BUDGET=/usr/lib/budgetchk
ext_msg=" (Excess of the budget)"
usr_msg="You are not permitted to place requests in NQS. $ext_msg"
grp_msg="Your group is not permitted to place requests in NQS. $ext_msg"
act_msg="Your acctcode is not permitted to place requests in NQS. $ext_msg"
while getopts sdnau:g:m:g:p: opt > /dev/null 2>&1
do
case $opt in
s|d|n|a) from=$opt;;
u) uid=$OPTARG;;
g) gid=$OPTART;;
m) maddr=$OPTARG;;
q) queue=$OPTARG;;
p) acctid=$OPTARG;;
esac
done
if [ -z "$acctid" ]; then
$BUDGET -u "$uid" -g "$gid" > /dev/null 2>&1
else
$BUDGET -u "$uid" -g "$gid" -p "$acctid" > /dev/null 2>&1
fi
status=$?
exitcode=$status
printmsg=""
case $status in
1) printmsg=$usr_msg;;
2) printmsg=$act_msg;;
3) printmsg="$usr_msg\n$act_msg";;
4) printmsg=$grp_msg;;
5) printmsg="$usr_msg\n$grp_msg";;
6) printmsg="$act_msg\n$grp_msg";;
7) printmsg="$usr_msg\n$act_msg\n$grp_msg";;
*) printmsg=0;;
esac
mdir=$NOSLIB/.MailCtrl
muser=$mdir/$uid
case $ from in
a|s)
[ -n "$printmsg" ] && echo $printmsg
exit $exitcode
;;
d|n)
if [$exitcode -eq 0 ]
then
[ -f $muser ] && rm -f $muser
else
if [ -n "$maddr" ] # send a mail.
then
if [ ! -f $muser -o $from = n ]
then
if echo $printmsg | mail $maddr
then
[ -d $mdir ] || mkdir $mdir
> $muser
fi
fi
fi
fi
echo $exitcode >&3 # daemon read a exit-code from fd 3.
;;
esac
#! /bin/sh
#
#ident "@(#)$ID: properlylist,..."
# Copyright (c) 1992 NEC Corporation.
#
#
#
BUDGET=/usr/lib/budgetchk
msg="Excess of the budget."
echo " `$BUDGET -a ` " |
while read uname
do
if [ -z "$uname" ]
then
continue
fi
if [ -z "$prt_user" ]
then
echo "\tBUDGET:"
echo "\t\t$uname:"
prt_user=1
else
echo "\t\t$uname:"
fi
done
| Home |
|---|
lpserver is the standard program for processing device requests. This program is solely for line printers and is defined as an NQS device attribute. This program can specify the following arguments:
lpserver [-c][-f][-iindent][-l page length][-wpage-width] printer-name
The pipeclient program is used for request transfer. This program is defined as a pipe queue attribute. One pipeclient program must be specified for each pipe queue. The following three types of programs are available.
One of these programs is used, depending on how destinations are selected.
| Home |
|---|
The NQS system realizes efficient processing by balancing requests submitted to hosts on the network and executing them.
This section describes two pipe queues providing the balancing function, then explains the use of these pipe queues using practical examples.
In the NQS system, the pipe queue is used to transfer requests to other machines for execution there. Multiple destinations can be specified for the pipe queue. One of them is selected, then requests are routed to it. A program group called the pipe client actually selects the destination. There are several types of pipe clients. The characteristic of each pipe queue is determined by defining a pipe client for the pipe queue.
If the load balancing pipe client is specified for a pipe queue, it can be used as the load balancing pipe queue. If requests are submitted in this pipe queue, they are transferred to the queue with the lowest load among several destination queues. The load balancing is thus achieved.
Three load balancing methods are provided by NQS: the round robin method, the load information collection method, and the demand delivery method. Specify rrpipeclient for the pipe queue server to use the round robin method, and lbpipeclient to use the load information collection method.
The "load balancing in the round robin method" is the right method to choose for the system configuration to be used and the contents of requests to be executed. This method is best suited to an environment in which requests submitted are completed in a relatively short time and the amount of resources to be used does not vary significantly. Using different versions of NQS allows the hosts that execute the requests.
When the request processing time or the amount of resources to be used varies widely, the following methods are better suited to that environment.
The destination is changed serially every time a request is submitted in the queue. For example, for serial numbers from 147 to 153, requests are distributed as shown in Figure 5-5.
Figure 5-5 Round Robin Load Balancing Method
In the case of creating pipe queue with rrpipeclient, specify the server as follows.
| Home |
|---|
The load status of the destination host specified in the pipe queue is referenced, and a request is transferred to the host that can accept the request and has the lowest load. See Figure 5-6.
Figure 5-6 Load Information Collection Method
Several options can be specified for lbpipeclient. Specify appropriate options to provide proper tuning that matches the use and request type. (Tuning is explained later.)
The options are presented next.
If the number of queued requests in the batch queue in a destination host reaches the limit, requests are not transferred to the host. When the limit is reached in all destination hosts, lbpipeclient waits the time specified by interval, then retries. If a greater value is specified, requests are executed consecutively to achieve higher efficiency. However, if there are any requests requiring a long execution time, the load among hosts is unbalanced. If a smaller value is specified, the load among hosts is balanced but the idle status between requests reduces the efficiency. If there are a number of requests requiring a long execution time, specify a small value since it relatively reduces influence on the transfer efficiency. If there are a number of requests requiring a short execution time, specify a large value.
Specify a value slightly smaller than the number* (average request execution time) for a retry interval used when the number of requests reaches the number specified and the request cannot be transferred.
After collecting load information, lbpipeclient executes the load balancing based on the load information for the specified validity of the load information file. The longer the time specified, the more unbalanced the load on the hosts becomes. Specifying a short time increases the overhead for collecting load information. Specify a value obtained by multiplying the average request execution time by two or three.
The following shows typical examples of the results of insufficient load-balancing operation. Adjustments of parameters required to solve such problems are also explained.
The load balancing may cause requests requiring a long execution time to concentrate in one destination. In other situations, a request requiring a short execution time may have to wait for execution until a request requiring a long execution time is executed. In such cases, several requests may be waiting for execution at that destination even though no requests are waiting to be executed at other destinations.
To solve this problem, specify a smaller value for number (the maximum number of transferred requests). If 0 is specified for number, for example, requests can be entered as soon as there are no executing requests in the destination.
If number is changed, interval (wait time) should also be changed. However, specifying a smaller value for number may cause too frequent useless waits.
| Home |
|---|
To solve this problem, specify a greater value for number (the maximum number of transferred requests) to reduce the number of times the requests enter the wait status. Alternatively, specify a smaller value for interval (wait time) to restart the request transfer as soon as possible after the execution of requests in the destination has been completed.
If an excessive time (update time for load information) is specified, the actual number of requests in the destination may not be counted. In this case, lbpipeclient is likely to estimate more requests than necessary. As a result, it enters the wait status easily. To solve this problem, specify a slightly greater value for time.
To solve this problem, specify a greater value for time (update time for load information). Alternatively, specify a greater value for interval (wait time) if lbpipeclient is already put in the wait status for the completion of request execution. This specification reduces the update count.
NQS is provided with rrpipeclient in addition to lbpipeclient. This pipeclient has a lower load than lbpipeclient. Therefore, if there are several requests requiring a short execution time, specify rrpipeclient instead of lbpipeclient.
lbpipeclient operates best when all specified destinations are operating normally. It may transfer requests unequally if the load on the network is high, if the destination user has no execution right, or if queues stop in the destination.
In the demand delivery method, the pipe queue and batch queue communicate with each other. This mutual communication enables requests to be routed to the right batch queues in the right timing.
The demand delivery function can be used when the queue that sends requests is assigned as a load-balance pipe queue (LB-PIPE) and the queue that receives the requests as a load-balance batch queue (LB-BATCH).
Figure 5-7 shows the basic operation of the demand delivery function.
Figure 5-7 Configuration and Operation of the Demand Delivery Function
| Home |
|---|
In normal request submission, LB-PIPE inquires about the load information of the scheduler machine (1 in Figure 5-7), determines the order in which request transfer is attempted, and attempts the request transfer in load order (2 in Figure 5-7). LB-BATCH restricts requests to be accepted according to the status of the local machine as well as the request resource limit, user limit, and limit determined by the queue state (disable state, for example). The first limit is imposed in the machine-busy state. When a request is routed to an LB-BATCH queue, the request transfer terminates. Otherwise, either of the following two operations takes place:
When the LB-BATCH queue becomes ready to accept the request recorded in the backlog (request A in Figure 5-7), it asks LB-PIPE to transfer the request (5 in Figure 5-7). LB-PIPE returns the request from the wait state to the queued state and quickly transfers the request to LB-BATCH, giving it higher priority in scheduling. This operation is called demand delivery (6 and 7 in Figure 5-7).
A change in queue state or requests on the LB-BATCH queue, if any, are reported as an event to the scheduler machine (for example, completion of the current request or change in the run limit value of the queue). The scheduler machine is always informed of the latest load status (8 in Figure 5-7). Note that a request on the LB-PIPE queue is subjected to demand delivery only when LB-BATCH has the backlog of the request. When there are two or more machines with low load and an enabled LB-BATCH queue transfer request, requests can generally be accepted in the first load order transfer. When machines have high loads and the LB-BATCH transfer request is not found, this demand delivery method is very useful. The method enables the request to be immediately transferred and executed when an open position is found.
LB-PIPE module settings are described as follows:
For setting the machine group, see Section 5.11.7.
When the specified waiting time expires, the request exits from the wait state and is queued again. Another load order transfer is attempted. This prevents a request whose LB- BATCH backlog is erased because of a communication or machine failure from staying on LB-PIPE.
When NQS with LB-PIPE is reactivated, the wait state is cleared and a load order transfer is started.
| Home |
|---|
If other queues are specified, this function cannot be used. The following part describes the procedure for setting LB- PIPE together with qmgr subcommands. First, create a pipe queue in a normal method.
An LB-PIPE queue LBPIPE has been created. (Specify a desired queue state (disable, stopped).) The destinations of this queue are LB-BATCH queues on three machines. The default run limit is 1. Specify 2 or a larger value.
Assign this queue as an LB-PIPE queue.
Specify the run limit to be reserved for demand delivery after reserve_run_limit=. The default value is zero. Specify 1 or a higher value. Specify the period in which a request is left queued in the wait state in the machine-busy state after destination_wait=. Specify this period in seconds. The default period is 3600 seconds (one hour).
| Home |
|---|
The setting of LB-PIPE has been completed. To change those LB-PIPE parameters, execute the same command. To check the settings, execute the qstat -x command. To clear the LB-PIPE settings, specify the following subcommand.
LB-BATCH module settings are described as follows.
For the setting of the machine group, see Section 5.11.7.
During the waiting time, the demand delivery request is accepted with highest priority. Other requests are not accepted during the waiting time. When the waiting time expires, the wait for the highest priority request is cleared and the demand delivery function is executed for another request in the LB-BATCH backlog.
The request that cannot be transferred within the maximum waiting time is considered to be in the transfer disable state. The corresponding backlog is erased.
When a request is rejected because of the keep request limit, LB-PIPE reports that the request is not accepted because of the machine-busy state (with NQS R6.2, the machine-busy state is possible only when this condition is satisfied.)
The default keep request limit is zero. If you mind the idle state while a request transfer is waiting (time in which a current request is completed, backlog is checked, LB-PIPE is asked to transfer another request, the request is transferred, then the request is executed), specify 1 or a larger value. Alternatively, increase the run limit of the LB-BATCH queue.
The keep request limit is not absolute. The limit may be temporarily exceeded in some timing in which a request is accepted.
The backlog is erased when:
The following paragraphs describe the procedure for creating LB-BATCH (together with qmgr subcommands).
| Home |
|---|
Create a batch queue in a normal method.
An LB-BATCH queue LBBATCH has been created. (Select a desired queue state (disable, stopped).) Assign this queue as an LB-BATCH queue.
Specify a keep request limit after keep_request_limit=. The default value is 0. In the example above, the limit has been set to 1 so that idling during request transfer can be minimized. Specify the maximum transfer waiting time in the demand delivery method after deliver_wait=. The default time is 30 seconds.
The LB-BATCH has been created. To check the settings, execute the qstat -x command.
To clear the LB-BATCH settings, specify the following subcommand:
Setting a transparent pipe queue
A transparent pipe queue (TPIPE) is used to connect LB-PIPE with two or more local LB-BATCH queues classified according to the resource limit. For TPIPE, see Section 4.2.8.
When using TPIPE in a demand delivery configuration, note the following:
| Home |
|---|
This section explains how to construct the load distribution environment with NQS using several samples. Examples of the general use of NQS are shown first. The resource limit specified for the destination is then explained. Finally, the operation of a request submitted to the queue shown in the examples is explained.
Five machines, hosts 0 to 4, are used for load balancing in the following examples. To simplify the processing, requests are submitted only from host 0.
In this queue configuration, the load balancing pipe queue is created in host 0 and batch queues for executing requests are created in each machine. The load balancing pipe queue is named pipeL and the batch queues in each machine are named batch.
In the following, the load balancing pipe queue is created in host 0.
Example:
The load balancing pipe client is specified in the portion that follows server=. In this example -n 2 is specified to indicate the specification method of options. However, nothing may also be specified. The proper value for each option depends on the environment. The following sections explain the adjustment of these values.
The destination machines and queues are specified in the portion that follows destination=. staywait should be specified for the load balancing pipe queue. This specification allows the load balancing pipe queue to handle a request with the date and time specification. In the next example batch queues are created in each machine.
Enter qmgr in all machines as shown next.
Example:
All queues have been created. Each queue must be started and enabled before starting the actual operation.
Example:
The specifications in the examples shown in Section 5.11.5.1 allow the load distribution.
In the following examples the queue configuration is provided with the classification function by resource limit and other features.(See Section 4.1 for the classification by the resource limit.)
Classification is achieved in a single unit machine, shown as follows. Multiple batch queues with different resource limit values are prepared and a pipe queue is created to distribute requests to these batch queues. In this specification, list queues are in alphabetical order, starting from the queue with the severest limit. An attempt should be made to transfer pipe clients in alphabetical order. The request is transferred to the queue that clears the first resource limit.
To combine the classification function with the load balancing function, send requests from the load balancing pipe queue to the classification pipe queues in each machine.
Add the classification function to the previous example. In this example, batch queues in each machine are divided into two classes.
Figure 5-8 Establishing the Resource Limit
| Home |
|---|
In this queue configuration, requests are transferred from the load balancing pipe queue to the classification pipe queues in each machine, then routed to each batch queue. The check attribute must be specified for the classification pipe queues. If not, correct classification among multiple machines is impossible. Two batch queues are created in each machine and the file size of one batch queue is limited to 1 MB.
Assume that the classification pipe queue is named pipeC, and that the batch queues are named batch1 and batch2.
In the following, the load balancing pipe queue is created in host 0.
Example:
This example attempts to request the transfer of batch1 and batch2 in order.
Unlike the example in which no classification function is required, in this example, the destination of requests is pipeC.
In the following, classification pipe queues are created in each machine. Enter the following in all machines.
Example:
The pipe client for classification is specified in the portion that follows server=. This pipe client attempts to transfer requests in alphabetical order (actually, ASCII code sequence) of the specified destination queue.
Batch queues which actually execute requests are specified in the portion that follows dest=.
The check attribute is specified by check.
In the following, batch queues are created in each machine. Enter the following in all machines.
Example:
All queues have been created. Check the queue configuration.
| Home |
|---|
Example:
# qstat -x
pipeL@host0; type=PIPE; [ENABLED, INACTIVE]; pri=10
0 depart; 0 route; 0 queued; 0 wait; 0 hold; 0 arrive;
Run_limit = 1;
Unrestricted access
Staywait
Queue server: /usr/lib/nqs/lbpipeclient
Destset = {pipeC@host0, pipeC@host1, pipeC@host2, pipeC@host3,pipeC@host4};
pipeC@host0; type=PIPE [ENABLED, INACTIVE]; pri=10
0 depart; 0 route; 0 queued; 0 wait; 0 hold; 0 arrive;
Run_limit = 1;
Unrestricted access
Beforecheck
Queue server: /usr/lib/nqs/pipeclient
Destset = {batch1@host0, batch2@host0};
batch1@host0; type=BATCH; [ENABLED, INACTIVE]; pri=10
0 exit; 0 run; 0 stage; 0 wait; 0 hold; 0 arrive;
Run_limit = 3;
Unrestricted access
Per-process Permanent file size limit = 1 megabytes
batch2@host0; type=BATCH; [ENABLED, INACTIVE]; pri=10
0 exit; 0 run; 0 stage; 0 queued; 0 wait; 0 hold; 0 arrive;
Unrestricted access
Per-process Permanent file size limit = UNLIMITED <DEFAULT>
| Home |
|---|
Submit requests in the queues created in the preceding section. Submit three requests in pipeL. Specify the 2-MB permanent file size limit for the third request.
Example:
Request 1.host0 submitted to queue: pipeL.
# qsub -q pipeL job2
Request 2.host0 submitted to queue: pipeL.
# qsub -lf 2mb -q pipeL job3
Request 3.host0 submitted to queue: pipeL.
Check in which batch queue submitted requests are executed. Use the qstatr command to check requests. However, since the machine to which requests are transferred is unknown for the load distribution, append the -t option to the qstatr command. The qstatr command then automatically searches for the destination machine and displays the status of the machine.
Example:
# qstatr -t 2 ================================================= NQS (Rxx.xx) BATCH REQUEST HOST: host1 ================================================= REQUEST ID NAME OWNER QUEUE PRI NICE MEMORY TIME STT JID R --------------- -------- -------- -------- ---- --- ------ ------ --- ------ - 1.host0 job1 root batch1 31 0 877 0.143 RUN 3 - ------------------------------------------------------------------------------ ================================================= NQS (Rxx.xx) BATCH REQUEST HOST: host2 ================================================= REQUEST ID NAME OWNER QUEUE PRI NICE MEMORY TIME STT JID R --------------- -------- -------- -------- ---- --- ------ ------ --- ------ - 2.host0 job2 root batch1 31 0 545 0.075 RUN 5 - ------------------------------------------------------------------------------ ================================================= NQS (Rxx.xx) BATCH REQUEST HOST: host3 ================================================= REQUEST ID NAME OWNER QUEUE PRI NICE MEMORY TIME STT JID R --------------- -------- -------- -------- ---- --- ------ ------ --- ------ - 3.host0 job3 root batch2 31 0 701 0.112 RUN 1 - ------------------------------------------------------------------------------
In this case, the loads are satisfactorily distributed.
When a request is submitted in the load distribution pipe queue, the machine to which the request is transferred is unknown. However, the machine to which the request was transferred is recorded in the entering source machine. The commands operating the request read this record and transfer the operation request to that machine. For example, to cancel the first request in the preceding example, enter the following in host0.
Example:
# qdel -k 1.host0
This cancels 1.host0 transferred to any machine.
Figure 5-9 shows a sample queue configuration in which the demand delivery function is used to distribute and execute requests in a network environment:
Figure 5-9 Sample Queue Configuration
| Home |
|---|
Loads are distributed among four machines (host0 to host3). host0 submits requests. A machine group is specified in this sample configuration. Four machines (host0 to host3) belong to an identical group and host0 functions as a scheduler machine. The requests are first submitted to pipe queue pipeL for demand delivery (LB-PIPE queue). These requests are distributed to host1 to host3. A transparent pipe queue receives the requests and automatically transfers each request to an LB-BATCH queue best suited to the resource limit of the request. LB-BATCH is used instead of a normal batch queue since the demand delivery function is used.
The following part provides information for setting the queues.
Example:
When created, a queue is in the disable or stopped state. The queue must be activated by the following command. This step is required for all queues created in this section, but the description of this step is omitted in the subsequent part.
Example:
#
qmgr
Mgr: enable queue pipeL
Mgr: start queue pipeL
Example:
| Home |
|---|
Example:
pipeT has been assigned as a transparent pipe queue. Destination batch queues are specified after destination=. The order in which the destination queues are specified in this portion is very important. The transparent pipe queue tests the destination queues in the order in which they are specified in the portion to determine whether a request can be routed. In this example, the resource limit of the request is compared to the resource limit of the queue. If the limit of the request is smaller or is not specified, the request is routed to the batch queue. The batch queues must be tested in descending order of limit.
Example:
This setting means that machines of host0 to host3 constitute a single group. host0, which is specified first, functions as a scheduler machine.
The queues are created as illustrated above. The queue configurations can be checked by executing the qstat command as shown in the following example. (A brief summary of the output results also follows.) The queues of the host0 machine are displayed as listed in the example.
Example:
# qstat -x pipeL@host0; type=PIPE; [ENABLED, INACTIVE]; pri=10 0 depart; 0 route; 0 queued; 0 wait; 0 hold; 0 arrive; Run_limit = 2; Reserved_run_limit = 1; Unrestric