Hello Buck

If you have the JDBC-connection in a separate Job and communicate via data queues you have a asynchronous communication between the consumer and the service-program. Or don't I understand you correct?

What could I do, if I want a synchronous communication?

Best regards


Am 15.11.2016 um 21:54 schrieb Buck Calabro:
On 11/15/2016 12:00 PM, Justin Taylor wrote:
I have an CGIDEV2 RPGLE program running in a named activation group that does not set on LR. It calls a service program that uses JDBCR4 to access SQL Server. The service program leaves the connection object open for repeated calls, which works fine for non-CGI. For my CGI program, other global variables in the service program are still set but my connection object is null. This causes a delay while the service program reestablishes the connection.

Any thoughts on what's causing the connection problem?
Are you doing something special to force a given browser's requests to
be serviced by the same job? The point being that a typical incoming
CGI request is served by whatever job the system decides to use.

Leaving LR off means that the program stays connected to the database,
but there's no guarantee that an incoming CGI request will be routed to
the job that's running that program. This means that it's very possible
that the system dealt the second incoming CGI request to a job in which
the CGI program has not connected to the database yet. Until all the
prestart jobs have connected, there'll be a delay.

I think the more typical approach is to move the JDBC work to yet
another job; one that stays active all the time. Communicate in and out
via data queue. Then it doesn't matter if the request is coming from
the web, from an RPG service program, or from a trigger fired via some
update from an RPG38 program.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].