RE: Data Queues Beginner Question

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

>Correct me if I'm wrong, but the scenario you (buck)
>describe, would be more complicated than need be,
>if the client and the server were on the same box,
>because wouldn't it be quicker and easier to just
>write a procedure or external call to retrieve the
>quantity?

Yes, you're right.  Justin gave a sample application and I tried to show how
a data queue would fit.  It's contrived, sure.  I use data queues in places
where i literally need to queue things up.  So, for instance, if I have one
program that I use to relieve inventory.  I can't CALL it from multiple jobs
because of potential cascade effects (record locks, exploding BOM, etc.)  I
have several choices: SBMJOB the update program with a parameter or use a
data queue/server model.

The great thing about data queues is that they're scalable.  If my inventory
update job is bogging down, it can do a SBMJOB to start another one
listening to the same data queue!  This won't help if there are record
locking issues, but it does help for situations where you discover that one
division has larger volume than the others.  You can split off that division
onto it's own server job and still listen to one data queue.  So, there's
one pipe for work to flow down, and the server(s) decide how to split it up.

>Plus, if i remember correctly, aren't there data queue
>hooks for other platforms (windows, *nix, java, etc.)
>that were being pushed for the classic client/server model?

Right again.
  --buck