Re: QRCVDTAQ

I wrote an article for Midrange Computing some years back which addressed this 
very topic. It showed how you could save resources by moving all the processing 
to batch and just using the interactive job to gather the information or 
request and display results. It also showed how you could tune performance by 
increasing or decreasing the number of active batch server jobs.

Albert

----- Original Message -----
From: Alan <cfuture@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: QRCVDTAQ
Date: Sat, 01 Jul 2006 19:10:44 -0700


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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.