Paul Gilmartin wrote:
Aha!  At last I see.  That answers my question to Peter R.  But I
was envisioning a technique in which only one task at a time updates
the queue, handing it back and forth with two ECBs.  Now there's
still need to manage concurrent accesses to the queue.  I suppose
CS can be used for that purpose.

Indeed. We normally use CDS for the simplest (LIFO) queuing of requests. For 64-bit pointers, CDSG would suffice.

Whenever the queue is empty, the queue emptier WAITs.  But if the
queue is storage constrained, it can fill up.  What does the
queue filler do then?

Application dependent. The server can pre-allocate queue elements for the maximum number of expected requesters (similar to "free pool manipulation" in PoOp), or each requester can be responsible for providing its own queue element. (The latter technique can be more complex due to cleanup considerations.)

I usually abend when resources are unavailable. But, depending on the circumstances and relative importance to the "system" that the request be serviced, an argument might be made for timed retry or other similar stalling tactic. For example, consider actions one might take when IXCMSGO fails with RC=x'0C' and RSN=x'04':

*01* RETURN CODES:
*
*    C         IxcRetCodeEnvError:  Environmental error.  This
*              currently includes the case where all resources
*              associated with a destination system have been
*              exhausted.
*
*              Hex Reason       Meaning
*              Code
*
*              4           ixcMsgoRsnNoBuffer:  No message buffer
*                          available, timeout not specified.
*
*                          XCF signalling resources (message
*                          buffers) are temporarily unavailable.
*                          Retry the request after allowing some
*                          time for the condition to clear.
*                          Alternatively, retry the request with a
*                          nonzero TIMEOUT value to have XCF try
*                          to handle the condition.  If this
*                          condition reoccurs when a nonzero
*                          TIMEOUT value is specified, the
*                          message-out service will either accept
*                          the message with return code 4 or will
*                          reject the message with return code
*                          'C'x reason 'C'x.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to