× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.