Browse Prior Art Database

Asynchronous Wait On Multiple Data Queues

IP.com Disclosure Number: IPCOM000120243D
Original Publication Date: 1991-Apr-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 4 page(s) / 157K

Publishing Venue

IBM

Related People

Blais, MN: AUTHOR [+2]

Abstract

Described is a method for a process to asynchronously wait on a data queue for a message to arrive. The wait request may be for an indefinite or specific amount of time, and the process is free to continue with other work while it is "waiting".

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Asynchronous Wait On Multiple Data Queues

      Described is a method for a process to asynchronously
wait on a data queue for a message to arrive.  The wait request may
be for an indefinite or specific amount of time, and the process is
free to continue with other work while it is "waiting".

      This invention sets up means of notifying the AS/400* process
when data is available on a particular data queue rather than having
the process wait for it.  That way the process can concurrently
service requests from all PC processes.  This requires an interface
to the data queue which allows the requesting process to wait
asynchronously for data.  It also requires data structures within the
data queue and requester programs which keep track of which programs
are waiting on which data queue, and for what length of time.

      Overview:  Two distinct programming parts were identified in
the solution of this problem.  First is the data queue part, which
must keep track of which processes on the machine are currently
waiting for data from the various data queues and then signal an
event to each of these processes when data is placed on the data
queue.  Second is the requester part.  The requester is the process
on the AS/400 which makes requests to the data queues on behalf of
the PC.  (This requester is actually a server from the PC's point of
view, but will be called the requester since it is directing requests
to the data queue part.)

      The Data Queue Part:
  The operations which must be managed by the data queue part are the
following:
  1.  Data queue receive requests that have no data to return must be
stored away for later when the data actually does arrive on the data
queue.  Any number of AS/400 processes may have outstanding receive
requests to a given data queue.
  2.  When data is sent to a data queue, an event must be signaled to
all processes that have outstanding receive requests to that data
queue.  If the queue is keyed, then only those requests where the key
value and search criteria also qualify are signaled.
  3.  If a data queue is deleted, an event must be signaled to all
processes that have outstanding receive requests to that data queue
allowing them to perform clean-up activity.
  4.  A process must be able to cancel an outstanding receive request
to a particular data queue.

      As a result of the above operations, the data queue part must
keep track of the following information:
  1.  A list of all waiting receive requests, each with its own
unique identifier.
  2.  The identification of the process that initiated the request.
  3.  The key and relational operator for each of these receives for
keyed data queues.
  4.  The number of receive requests waiting on each data queue.

      The Requester Part:
  The operations which must be managed by the requester part are the
following:
  1.  Initiation of a new waiting receive request.
  2.  Notification that dat...