Using QUERY, CANCEL and ALTERPRI in the common dump queue

The QUERY, CANCEL and ALTERPRI commands support the CDQ. The following considerations apply to QUERY processing:

• QUERY SETSYS displays the current SETSYS settings for the CDQ on the host that issued the query command. Message ARC1500I displays the SETSYS settings on this host.
• QUERY ACTIVE displays the current state of the CDQ and active requests running it.
  • The state and active requests that are reported are those that originated from the host issuing the query command
  • Active requests reported could be active in any member in the CDQ. XCF messaging is used to retrieve active requests by sending the query command to the master scheduler. These requests could be running in any member of the CDQ group and must match the filter criteria of the query. In this case, the active requests must have originated from the host issuing the query command. The generated messages on the master scheduler are returned to the query host using XCF and in turn the query host reports them. The query host then goes on to report its own active requests.
  • When the query host is also the master scheduler, no XCF messaging is used to obtain the active requests, as the CDQ queues are located on the master scheduler host.
• QUERY REQUEST or USER display requests that originated from the host issuing the query command that match the REQUEST or USER filter criteria.
  • Active requests reported could be active in any member in the CDQ and queued in the master scheduler. XCF messaging is used to retrieve these requests by sending the query command to the master scheduler. These active requests could be running in any member of the CDQ group or queued in the master scheduler and must match the filter criteria of the query. In this case, the requests must have originated from the host issuing the query command and match the REQUEST or USER criteria on the query command. The generated messages on the master scheduler are returned to the query host using XCF messaging and in turn the query host reports them. The query host then goes on to report its own requests.
  • When the query host is also the master scheduler, no XCF messaging is used to obtain the queued and active requests, as the CDQ queues are located on the master scheduler host.
• QUERY WAITING displays the number of requests that are queued in the CDQ that originated from the host issuing the query command.
  • Queued requests in the CDQ are queued in the master scheduler. XCF messaging is used to retrieve these queued request numbers by sending the query command to the master scheduler. These queued requests in the master scheduler must match the filter criteria of the query. In this case, the requests must have originated from the host issuing the query command. The generated messages on the master scheduler are returned to the query host using XCF messaging, and the query host reports them. The query host then determines its own queued request numbers, combines them with what was returned from the CDQ, and reports the totals.
  • When the query host is also the master scheduler, no XCF messaging is used to obtain the queued request numbers, as the CDQ queues are located on the master scheduler host.
• QUERY COMMONQUEUE(DUMP) displays all queued and active requests being managed by the CDQ. Use this query to get a snapshot of all CDQ activity from any host connected to the CDQ.
  • Queued and active requests in the CDQ are managed by the master scheduler for the CDQ group. XCF messaging is used to retrieve these requests by sending the query command to the master scheduler. These queued and active requests in the master scheduler have no matching criteria to satisfy. All requests are reported. The generated messages on the master scheduler are returned to the query host using XCF messaging, and the query host reports them.
  • When the query host is also the master scheduler, no XCF messaging is used to obtain the queued and active requests as the CDQ queues are located on the master scheduler host. The filter criteria is all queued requests running in the CDQ regardless of where the dump request command originated.
  • Messages ARC1562I and ARC1563I are reported for the active and queued requests in the CDQ.
• The CANCEL REQUEST or USERID commands cancel queued requests in the CDQ for requests originating in the host that issued the CANCEL command and matching the REQUEST or USERID filter criteria.
  • Queued requests in the CDQ are managed by the master scheduler for the CDQ group. XCF messaging is used to cancel these requests by sending the cancel command to the master scheduler. These queued requests in the master scheduler must have originated from the host issuing the CANCEL command and match the filter criteria of the REQUEST and USERID parameters. When matching, the requests are canceled. The generated messages on the master scheduler are returned to the cancel host using XCF messaging and the cancel host reports them.
  • When the cancel host is also the master scheduler, no XCF messaging is used to cancel the queued requests, as the CDQ queues are located on the master scheduler host.
  • To cancel an active request in the CDQ, issue CANCEL TCBADDRESS on the host that this request is active in.
• The ALTERPRI REQUEST or USERID commands change the priority of queued requests in the CDQ for requests originating in the host that issued the ALTERPRI command and matching the REQUEST or USERID filter criteria.
  • Queued requests in the CDQ are managed by the master scheduler for the CDQ group. XCF messaging is used to alter the priorities of these requests by sending the ALTERPRI command to the master scheduler. These queued requests in the master scheduler must have originated from the host issuing the ALTERPRI command and match the filter criteria of the REQUEST and USERID parameters. When matching, the requests priority is altered. The generated messages on the master scheduler are returned to the ALTERPRI host using XCF messaging, and the ALTERPRI host reports them.
  • When the ALTERPRI host is also the master scheduler, no XCF messaging is used to alter the priority of the queued requests, as the CDQ queues are located on the master scheduler host.