× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: data queues
  • From: qappdsn@xxxxxxx
  • Date: Thu, 22 Jan 1998 12:51:38 -0800



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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.