Re: Persistent CGIDEV2 problem -- WEB400

Hi Brad,

It doesn't seem very complex and, so far, has required little change to my
existing code. Of course, if I cannot get it to work ...

Many thanks

Rob

2009/1/6 Bradley V. Stone <bvstone@xxxxxxxxxxxx>

Yes, if you set up "real" persisitent CGI with your HTTP config, it does 1
to 1 job per session.

I've tested it, but decided it wasn't worth the time and resources. This
was back in the days with the classic server. I haven't attempted it with
pbA server. I prefer session IDs/cookies for persistance now.

Bradley V. Stone
BVSTools - www.bvstools.com
eRPG SDK - www.erpgsdk.com

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]On
Behalf Of Vern Hamberg
Sent: Tuesday, January 06, 2009 10:55 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Persistent CGIDEV2 problem

That is what persistent CGI is going to do - keep things alive - here is
some text from a link at IBM for the iSeries -

Persistent CGI is an extension to the CGI interface that allows a CGI
program to remain active across multiple browser requests and maintain a
session with that browser client. This allows files to be left open, the
state to be maintained, and long running database transactions to be
committed or rolled-back based on end-user input.

The link is

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?to

pic=/rzaie/rzag3ch3ovrvwpercgi.htm<http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzaie/rzag3ch3ovrvwpercgi.htm>

Aaron Bartell wrote:

>As far as I know there is no way to associate a server job with a
specific client.

But you could do this with some coding. Create a main "doorway" app
that reads in the necessary stdin and puts it into a "accessible place"
(maybe a User Space). Then evaluate a session id sent up from the
client (i.e. hidden form variable) to determine what key to use on the
subsequent keyed data queue send/write. Then you would have a variety
of single user jobs listening on the keyed data queue for requests they
are listening for (i.e. they are listening for their specific key to
enter the data queue). These single user programs receiving entries
from the keyed data queue can operate similar to a traditional
5250-green-screen-programming-apprach, you just change out the EXFMT
with a rcvdtaq API call. You would also retrieve your input from a
different location and send your output to a different location vs.
occupying DSPF fields (though you could simulate writing DSPF records
with SPECIAL files). Note a lot of this is theory as I haven't done it
entirely in the RPG space but instead worked with Joe Pluta to have the
front end be Java (more specifically JSP).

An approach like the above would also make it easier to retain SQL
cursor positions and I find I use a lot more embedded SQL when I am
doing RPG+CGI.

The best part about it is the entire framework behind the data queue is
"safe" from the chosen front end which could be a variety of
technologies like .NET thick client, HTML+CSS+Javascript, Silverlight,
JavaFX, Flex.

I am just itching to try something like this and even get a rough
proof-of-concept on the net for people to play with - I just keep
getting tied up in billable work and that seems to take precedence
(butts need diapers - no, not my butt ;-)

Aaron Bartell
http://mowyourlawn.com

Brandon Peterson wrote:

Hi Rob,

I doubt this has anything to do with activation groups, but even if it
does you have a larger problem.

CGI is different than 5250. When you are logged in via 5250 you have

a

single job that services your session. But with CGI the web server

has

a pool of jobs that service users and every time you send a request

you

could potentially use a different job.

Basically you could think of it as every time you send a new request
your programs start over from scratch. As far as I know there

is no way

to associate a server job with a specific client.

HTH,
Brandon

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx

]

On Behalf Of Rob Dixon
Sent: Tuesday, January 06, 2009 7:44 AM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Persistent CGIDEV2 problem

I am using CGIDEV2 (in persistent mode) for the first time and thought
that
I was making reasonable progress but have now run against a problem

for

which I need help, although I am sure that it has been solved

many times

before.

My cgi program is RPGLE and is a request processing program (I

will call

it
RPP) that handles 5250 or HTML/Javascript output. It does not have

any

direct database access but calls a second program (I will call

it MAIN).

This handles business logic and reads records and passes them back to
the
RPP which displays them using 5250 or CGI. In CGI mode, the first call
by
RPP of MAIN works OK and the records are displayed by RPP using
wrtsection.
When I type something on my HTML display, the RPP is reactivated
correctly
so my Handle is presumably OK and I can read what I typed using
ZhbGetInput. However, when RPP calls MAIN again so that that program
can
retrieve the required records, a new instance of MAIN is called. I am
sure
that in the first call of MAIN I did not set on LR and the mechanism
works
fine in 5250 mode I imagine that this has something to do with
activation
groups.

Can anyone help please? I have tried compiling MAIN with the

same named

activation group and binding directory as RPP but this did not help.

Many thanks

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.