RE: Subsystems and ODP

Is there something simpler to do what I want to do? Sharing ODP between
calls of my process, considering that each call can be done by different
users / jobs?

No. Having one or more server jobs/threads doing the actual work is the only way.

But a data queue server is a blocking
server. It can process only one request at the time.

You could simply have more than one job servicing requests off the queue.

Generally speaking from a results standpoint, there's not much difference between having multiple jobs
and having multiple threads. The only real difference is that a thread is "cost less" to start. If
you leave the job/thread running, that doesn't matter.

Now, the real question I have, is what makes you think they way things work now is a problem? And
what makes you think having everything shared would help?

If you've got 1000's of jobs being submitted an hour and each run in a second or so, then I'd agree
that moving to one or more server jobs may be beneficial. But even then perhaps not as much as you'd
think.

On the other hand, if the jobs take more than a second or two to run, then the job start-up and file
open costs are probably insignificant when compare to the rest of the work being done.

You mention queries, so the question is have you already looked for common query performance issues?
--having the right indexes
--using static SQL instead of dynamic
--blocked fetches of data
--CLOSQLCSR(*ENDACTGRP)
--ALWCPYDTA(*OPTIMIZE)
--ensure SQE is being used instead of CQE
--SQL DDL used instead of DDS to create tables and LF/indexes


Now I will admit that SQL queries in particular may benefit from having one or more server jobs doing
the work given that SQL queries can make use of "reusable" ODPs. However, that wouldn't really help
without the "basic" tuning above. Nor is it going to matter if you're only talking about a 100 jobs
over the course of the day.

HTH,


Charles Wilt
--
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Charles St-Laurent
Sent: Wednesday, August 13, 2008 1:15 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Subsystems and ODP

Hi!

The situation is:

We have a big process that is used all day long by our sellers. This
process
uses many queries within SQLRPGLE programs. Each time a seller launchs
this
process, it is launched as a batch job. All the programs within this
process
are service programs, running in QILE. And there is a night job that uses
this process too.

Even if we run this process in QILE, when the batch job ends, all the
ressources that have been allocated in the activation group are reclaimed,
because the activation group is linked to the job. What I want to do is to
keep these database files open between calls by other users / jobs.

I know that is is possible to start a never ending program, a kind of
server, that waits for requests. Once the program receives a request, it
processes the request and returns the result to the requester. The easy
way
to do that is a data queue server. Another way is a TCP
server, with one parent process and many children processes. So the parent
process waits for a request. Once it receives a request, it dispatches
this
request to one of its children processes. Then, the child process returns
the result. Because the server is a never ending job, all the ressources
allocated in QILE will stay open until I stop the job, including ODP.


Charles St-Laurent
Consultant Berco
Technologies
Industrielle Alliance, Assurance auto et habitation
Téléphone : 418 650-4600, poste 3216
Sans frais : 1 800 463-4382
Télécopieur : 418 650-4612
Sans frais : 1 877 650-4612
Courriel : charles.st-laurent@xxxxxxx <mailto:pcharles.st-laurent@xxxxxxx>
www.inalco.com/assurancegenerale


--
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.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.