Re: Data Queues -- MIDRANGE-L

Raj,

The reason that data queues are so difficult to grasp is because they are
incredibly simple.  It just doesn't get easier than this, and that just
doesn't seem right, does it?

If you've ever coded an application that periodically wakes up and looks
for something, such as an object, data in a file, a status code in a
record, then you have a prime candidate for a data queue. Think of it like
this-  You could get up and go to your front door every 5 minutes and look
out to see if you have a visitor, or, you could hook up a door bell and
only answer the door when the door bell rings.

An application that is waiting on the que is just waiting for such an
event.  It isn't taking up the kind of resources that it would be using if
it were waking up periodically and doing, for example, a CHKOBJ.

Here's how it works-
An application or various applications send entries to the que, formatted
anyway that you like.  You decide what's in it.  Typically, I'll have some
data that needs to be processed, a part number for example, and some coding
to tell the receiving program what I'd like it to do, such as update the
onhand quantity. When I'm defining a data queue entry format, I always
create a dummy externally defined physical file so that I can reference it
as a data structure in the programs.  

Another application is waiting on the que.  You can tell it how long to
wait, it may be indefinitely.  When an entry shows up in the que, this
application receives it and it disappears from the que.  This application
then does whatever it was that you needed it to do.

The first time I used data queues was for a client with a very interesting
setup.  This was a dairy (this is Wisconsin after all!) that used an
automated stacking storage system to warehouse their milk crates of various
milk products, a rail system that looked something like a little elevated
train track, known as EASS.  EASS was hooked up to a pc which kept track of
the milk inventory, and ran the milk crates around on the little train
track.  The client had converted their order entry/ distribution
applications from a Prime to an AS/400.  These applications needed to query
and update the inventory on the EASS.

The first programmer in here just replicated the process that had existed
on the Prime, using a looping system to check for 4 different types of 
transaction files.  He then kicked off an ICF process to communicate
with the EASS.  The ICF process worked great, but the looping process was
incredibly slow and resource intensive.  It constantly took between 5 and
10 percent of the CPU, if I remember correctly, a B40? 35? (a long time
ago!) 
It would check for each of the 4 files (ouch), open any it found (ouch),
process the 
transactions, then delete the file (ouch). For the queries, it would create
a file (ouch) 
and put transactions in it.  All of this ran fine on the Prime, but the
AS/400 hated it.

I wasn't at all sure at the time of how to use data queues, and didn't know
anyone who did, and was somewhat nervous that it wouldn't work out and I'd
have wasted a lot of effort and client's money, but this looked like an
ideal candidate for them, so I plunged in.  

I created a format for the 4 transaction types, to contain the data
formerly residing in the 4 transaction files.  The format looked something
like the record layouts, plus a transaction type code.  I changed the ICF
application
 to wait on a data queue until a transaction request was received, then
process it the 
same way it had previously processed the records.

Then I changed the applications to send appropriately formatted data queue
entries to the queue, instead of the former process of creating a file and
then placing a record in it.  So, order entry sent queries for on hand
quantities, picking sent pick requests, manufacturing sent inventory
transactions, etc. For the queries, a data queue entry was sent back to the
querying program, which was waiting on it's own data queue.
It all worked like a charm, sped the process up greatly, stopped
using all that resource, and it wasn't difficult to implement and no
client's money was wasted.  In fact, the client was thrilled. 

These two processes, the send data queue entry and the receive data queue
entry, are handled using the QSNDDTAQ and QRCVDTAQ APIs.  It sounds like
you have the reference material, so I won't go into the technical details,
but rest assured that these are two of the simpliest APIs out there.

As it happens, I just completed some applications today that use data
queues to 
handle ticketing info at an airline, so if you have additional questions,
it's all fresh at the 
moment.

HTH,

Kathleen Kostuck
___________________
(414) 402-0820       fax (414) 495-4986
kkostuck@execpc.com
Providing AS/400 Solutions
Secretary - Wisconsin Midrange Computer Professionals Association   
___________________


----------
> From: Rajan.Srinivasan@Allfun.com
> To: MIDRANGE-L@midrange.com
> Subject: Data Queues
> Date: Friday, November 20, 1998 3:51 PM
> 
> Hello All,
>                        Could anyone please throw some light on Data
Queues.
> I read some books, but still I
> Could'nt  able to get the idea. What is Data Queues?.  On what situation
we
> need to use that in  Programs?.
> What is the difference between Data areas and Data Queues?.  Where can I
> get info about this?.
> 
> Thanks in advance
> 
> Raj
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@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 subscribe to this list send email to MIDRANGE-L-SUB@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
+---