Re: Persistent CGIDEV2 problem

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

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