RE: data queues

Great description of Data Queues.

Just wanted to add that they should not be used to store 
information.  Only for inter program communications.

Data Queues have a nasty habit of not surviving system crashes 
and can not be counted on for data storage.

But when used for what they are intended, they work great!  Very 
fast and very easy to use.  I use them extensively in my product 
(Fax Server/401)

Regards,
Bob Crothers
Cornerstone Communications

-----Original Message-----
From:   qappdsn@ibm.net [SMTP:qappdsn@ibm.net]
Sent:   Thursday, January 22, 1998 3:52 PM
To:     MIDRANGE-L@midrange.com
Subject:        Re: data queues



Juris Krikis wrote:

> I would be grateful if somebody would give a brief summary on 
data
> queues, their usage, application and etc.
>
> Thanks.
>
>

Data queues are useful in inter program communications.  A 
sending program, let's
say order entry, sends information to a data queue that is 
received by another
program, let's say a bill of lading print program.

Several programs can add entries to a single date queue. 
 Several programs may
receive entries from a single data queue.

Data queues can be thought of as a data file, either sequential 
or indexed, with
a few limitations.  There is no OS command to display the 
contents of a data
queue but you will find a command to do this in QUSRTOOLS. 
 Maybe the R4Vx has
such a command.  The only way I know of to clean up a data queue 
is to
delete/create the queue. (It just grows and grows)

The receiving program waits for entries to appear on the data 
queue, and when one
appears, your program can process the entry.  We create a PF to 
map the data
queue format and use that as an external data structure 
definition to make life a
little easier should the format change.  The receiving program 
also may state how
long to wait for an entry (specified in seconds) before timing 
out.  You can test
for a time out condition within your program because the entry 
received length
will be zero.

When we map the data queue entry we also contain a field for 
"verb" to tell the
receiving program what to do: I.E.: seton LR and stop waiting, 
short wait, long
wait, etc.  And we also include a field to specify data format 
in the event that
multiple data formats are being sent to the queue.  The 
remainder of the data is
just called "DQDATA" which is moved to the appropriate data 
structure depending
upon verb/format entered.  The "format" helps for application 
version
compatibility.

When defining a data queue you would specify the maximum length 
of an entry, but
all entries do not have to be that length.  For example when we 
issue a shutdown
command, a 4 character entry is added to our queues which only 
contain the verb
*END and have a length of 4 characters.  Since this is added to 
the end of the
queue, any pending entries are processed then the *END would 
appear.  This
prevents entries from just hanging out there until the receiving 
programs are
restarted.

Under the CISC OS, when an entry is received from the queue it 
was automatically
removed from the queue.  If you need the entry again for another 
process it could
be added back to the queue but that practice could cause some 
serious cycle
stealing looping.  I thought I heard mention that the RISC OS 
versions has a
function to retain the entry, don't know for sure.

Our primary application is to drive print programs: shipping 
labels, bills of
lading, invoice printing, etc. where both a batch process and 
on-demand process
is desired and the actual print programs are constantly running 
is the background
waiting for entries to appear.  When an entry appears, the 
printer file is
opened, form produced, printer file closed, back to top of loop 
for a wait.

Another reason we included the "verb" is to let the program know 
that a bunch of
entries are batched together and to skip the printer open/close 
functions because
there will be no wait between entries.

Data queues are a handy little tool.  A look through QUSRTOOLS 
will give you sn
example of writing to and reading from a queue.




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to 
"MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---