Re: Subsystems and ODP

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hi Charles,

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

That's true, but you can have several jobs all waiting on the same data 
queue.  Then, each request that's sent to the queue is handled by 
whichever data queue server happens to read the queue first.  (There's 
no danger of two jobs reading the same data queue entry.)

That way, you can have several jobs all processing data queue entries, 
and therefore it's handling several requests concurrently.

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

That depends on how you structure the server.  If you use what I call a 
"handoff server" then it will work the way you describe.

I've actually written a service program that's intended to make it easy 
to write a handoff server (among other things).  (Assuming that you're 
working with RPG code, that is...)

Actually, now that I'm thinking about it, I have a bunch of bug fixes 
that need to be made to my TCP service program.  I keep forgetting to 
make them... sigh.

If this interests you, I can provide links to my articles on the subject 
-- but I'll have to remember to fix the bugs, first. :)

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

Not that I know of...   also, I'm not sure that SQL is capable of 
sharing an ODP. I know you can share ODPs with traditional RPG native 
I/O, but I'm not sure how possible it is with SQL.  Personally, I think 
a "server" approach is the way to go.   I wonder if you're making this 
out to be more complicated than it really is?  It's pretty darned simple.