Re: QRCVDTAQ

[Alan <cfuture@xxxxxxxxxxx>]

I worked at a shop once that delayed getting more disk until I finished 
up migrating their last functionality off a software package from which 
they had migrated. I took a break to change the way one particular 
most-used program (order entry I think) accessed customer information. 
Instead of each job with its own F-spec, I kept one program running in 
one batch job waiting on data queue requests. The user jobs would send a 
data queue entry to this program, it would get the record for the 
customer, then send it back to a data queue created for the user job.

It was lightning fast in comparison. Like whoosh! Of course they were 
maxing out the disk, and the job queue job took care of all the opens 
and closes, and security considered, if they were supposed to get the 
customer record then getting the record from the "service job" was all 
the same.

Data queues... If you absolutely, positively must get it there in 
nanosecond time...

--Alan

> Anyone know anything about the mechanics of QRCVDTAQ "under the hood".  In
> particular does it use much in the way of resource while waiting?
>
> Jon Paris
> Partner400
>
> www.Partner400.com
>
>