Browse Prior Art Database

Intermediate Queue Solution to Queue Busy Exceptions

IP.com Disclosure Number: IPCOM000046715D
Original Publication Date: 1983-Aug-01
Included in the Prior Art Database: 2005-Feb-07
Document File: 2 page(s) / 49K

Publishing Venue

IBM

Related People

Rourke, DJ: AUTHOR

Abstract

In a computer system implemented with a queue-driven architecture, certain queue-referencing instructions (dequeue first on queue, receive first on queue) cannot be interrupted. Other queue-referencing instructions (dequeue by message key) that take longer to execute may be interrupted, but another program attempting to use the queue that is being searched will encounter a queue-busy exception. This situation can occur when one Input Output Manager (IOM) program is controlling several high-priority operation unit (OU) tasks running multiple I/O programs. In this case, the OU tasks must share the IOM's Input Queue. The IOM must handle the incoming messages in a certain sequence: cancel messages first, followed by error recovery programs, and then the I/O programs in the order in which they were issued.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 58% of the total text.

Page 1 of 2

Intermediate Queue Solution to Queue Busy Exceptions

In a computer system implemented with a queue-driven architecture, certain queue-referencing instructions (dequeue first on queue, receive first on queue) cannot be interrupted. Other queue-referencing instructions (dequeue by message key) that take longer to execute may be interrupted, but another program attempting to use the queue that is being searched will encounter a queue-busy exception. This situation can occur when one Input Output Manager (IOM) program is controlling several high-priority operation unit (OU) tasks running multiple I/O programs. In this case, the OU tasks must share the IOM's Input Queue. The IOM must handle the incoming messages in a certain sequence: cancel messages first, followed by error recovery programs, and then the I/O programs in the order in which they were issued. This requires that the IOM program search for messages on its Input Queue by message key. While the IOM program is referencing the Input Queue using the dequeue by message key instruction, the OU tasks may interrupt the IOM to place a completed program on the Input Queue. This results in a queue-busy exception. The usual response to this problem would be to provide a Component Specific Exception Handler for each OU task. The exception handler would detect the queue-busy exception and cause the OU task to wait a certain time interval and then retry the queue-access instruction. This method requires that Component S...