RE: QRCVDTAQ

I agree that proper use of DtaQueues is excellent.
While I don't trust them to carry important data (for some of the
reasons you mentioned), they are excellent flags to trip other processes
without incurring resources.

One use we have for them is to stop polling jobs. We have jobs that need
to periodically poll for data, but at times we need to shut them down
nicely.

By having the job also checking the DtaQueue without a wait (or a wait
to controlling the polling cycle), the job could be told to shut down
normally - without being killed. This allows other applications (like
system control applications) to bring down systems and/or sub systems
very nicely.

I also like them as flags for 'data is ready for importing' from another
system, by using remote data queues.

So their use in certain situations I think is perfect.

Jim

 

 

The bitterness of poor quality remains long after low pricing is
forgotten! 

 

Cautillo, Leon M.



-----Original Message-----
From: midrange-l-bounces+jim.wiant=foodstuffs.co.nz@xxxxxxxxxxxx
[mailto:midrange-l-bounces+jim.wiant=foodstuffs.co.nz@xxxxxxxxxxxx] On
Behalf Of Steve Richter
Sent: Tuesday, 4 July 2006 14:46
To: Midrange Systems Technical Discussion
Subject: Re: QRCVDTAQ


On 7/2/06, Larry Bolhuis <lbolhuis@xxxxxxxxxx> wrote:

I believe it was John Sears that spoke at a COMMON conference long ago
where I learned this. While waiting on a *DTAQ the job uses no

resources

at all. It could sit there for weeks without using so much as a cycle.
Only when the wait timer expires and control transfers back to the
calling program does it use any cycles.  The actual reading and

writing

to queues is also impressively quick and as I recall uses only a few

MI

instructions for each read or write.

As I remember John explained that i5/OS (OS/400 back then) uses queues
extensively and therefore is very efficient at doing so.

*DTAQs are still my favorite i5/OS object. One object SOOO Many uses!

You can make a strong case that data queues have no place in
application systems. For programmers they are the system level
equivalent of the computer language GOTO.  They dont work well with
the debugger. They dont throw exceptions so errors go undetected.
They also violate the rule of isolating a user's job from the shaky
code being run by another job. Security wise consider this: how wise
would it be to implement a personnel or accounts payable system using
data queues? Where payment to a vendor was triggered by sending an
entry to a data queue?

-Steve