Re: Persistent CGIDEV2 problem -- WEB400

Hi Aaron,

As I have already said in an earlier reply, persistent CGI does handle this
and the fact that I can return to RPP with the variables unchanged suggests
that I understand this much correctly (although maybe not much more!).

My aim is to use exactly the same code for both 5250 and CGI environments,
switching between CGIDEV2 APIs and EXFMT etc., as appropriate for the
environment. As far as I have got, this is working. It all works fine in
5250 mode.

As far as file cursors are concerned, these are maintained by MAIN. I don't
use SQL as it doesn't have the capabilities that I need for handling
multi-dimensional data. In any event, even though my metadata and user data
are stored in standard DB2/400 physical files, SQL would have severe
indigestion if pointed at them.

I feel that there has to be a way of returning to the same instance of MAIN
and that there must be someone who has achieved this. It seems such a basic
requirement to me. I cannot combine RPP and MAIN as they total over 43K
lines of code which is I think more than SEU will allow in a single source
member. This may seem a lot but these cover both Development and
Operational environments.

I am also trying to create a "universal" solution, and, in 5250 terms at
least, have made significant progress - I can create complex applications
without new file creation or new program creation (for at least 90% of the
time) that work without bugs since no new programs have been created.
Trouble is people insist on GUI and there is no point in trying to put them
off. With AS/400 Workstation Gateway, which I have modified quite a lot,
all my applications work over the internet and already generate HTML and
Javascript. But AS/400 WSG is no longer supported and I have to find a new
way of handling the GUI side.

I would be interested in talking off line if you are.

Many thanks

Rob Dixon
www.erros.co.uk
rob.dixon "AT" erros.co.uk

2009/1/6 Aaron Bartell <aaronbartell@xxxxxxxxx>

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