×
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.
Re: DIM'ing data structures for 10,000 sessions for state web serving -
Aaaron wrote:<i> I can see how this approach would work for retaining
state of variables (global and local), but how would it work at
retaining state of things that you don't have immediate control over
like DB files and SQL cursors? If you potentially have two users making
use of the same job (one after another) then you can't rely on record
positioning and cursors to be in the same place and instead have to
initialize from ground zero which takes us back to regular CGI
programming. Note the V6R1 PF handlers might be able to be held in a
DIM.</i>
This is a really good point, Aaron. There are aspects of web
programming where one has to be more flexible in approach than with
5250, for example, the ironclad constraints we have with 5250 as to what
can be done and what will come back. Even if a web page didn't have any
options other than submit, one has to program as if crackers will send
anything in next, because they will.
So with stateless serving I reposition file pointers with SETLL for
READx from saved keys because I have to. With this state maintained with
shared file paths I still have to unless we can conclude that it is
worth maintaining an open data path to each file in every session. I'm
sure the SETLL will be light years less overhead.
So some aspects of the programming have to be more flexible and
security conscious just as with stateless programming. One being that
everything in between user IO's have to start as new functions rather
than a code pointer picking up following an EXFMT, and we have to have
state controls that says whether valid steps were taken to enter this
function.
The other being that sequential file IO has to be repositioned with a
SETLL, which implies a key down to that level, at least RRN. I hadn't
got to the point of realizing exactly how much has to be written in the
style of stateless programming, and the READx file IO repositioning is
definitely one of them.
Aaaron wrote:<i> Maybe I don't understand how your approach is working
entirely. How long does an entry in the DIM exist before being timed
out and removed for somebody else to use? I would imagine you would
have to have such a timeout feature.</i>
Yes, I have this aspect down in notes to code. You have a file with a
session source, session id or job number, a creation time, and a last
used time at a minimum, possibly some other environment type variables
stored to retrieve while you're at it.
It can be as simple as when a transaction comes in from a local
program such as a CGI program that is responsible for determining
session, your own in CGI or the Rennaisance system, an interactive
program with a job number, etc., the source and session id are checked
by key against the session file and if there the index is retrieved.
If not there the next session file record is read to record a new
session and index. If next index still in use, meaning you are running
up against max sessions in use, I would check a data area that a timeout
job will have recorded in for next available session index.
The timeout job is background and runs periodically, checking last
access time against configured constraints (can be per user or
environment) and ending session if timed out.
Whether session is ended with logout or timeout, a process is called
to re-init the session index throughout the dataq servers. This would be
done by writing a dataq record to each server being used from a list
with an INIT opcode amd the session index. At a minimum a variable with
that index in each server would be zeroed. This would cause the next use
of that server index to call the equivalent of *INZSR for the new session.
Aaaron wrote:<i> Are you open to combining our efforts in an online
repository like Assembla? I picked Assembla because it is free and we
can fairly easily store RPG code in there by using WDSC's iSeries
Projects (I can post a video showing how). This has to be a community
effort otherwise it won't fly. As I understand it the Renasianse
framework is completely open source as long as you submit enhancements
back which I have no problem with.<i>
Yes, absolutely, Aaron, I agree has to be community effort, and even
words of wisdom here is a big part of it. I was going to post the code
on Google open source but I can work with Assembla, not that I ever
heard of it before. :) But having a comfortable collaboration
environment is a good first step.
At least anything I write will be public domain rather than a Mozilla
or MIT license, not that I disagree with the reasons for using those.
But we have to be acutely aware that business shies away from licensed
code unless it comes through a vendor, such as IBM supplying tons of GPL
code through their products.
Whether it's called public domain or educational purposes, etc., the
point is for iseries shops to have a framework written in /free with
subprocedures and service programs, dataq servers with UI independent
programming, etc. that serve as a base for further programming and to
use the iseries to its fullest.
They're not going to give anything back unless they want to anyway
because they don't distribute the software, so any licensing is just an
impediment to being used in an iseries business environment.
Aaaron wrote:<i> The point I hope to get to with this framework is to
capitolize on all of RPG's wonderful features as it relates to the whole
environment (i.e. the OS, DB2, ODP, SQL cursors, etc).</i>
I agree. IBM put the infrastructure in place, it's up to us to push it
to its limits, if there are any. :)
rd
As an Amazon Associate we earn from qualifying purchases.
This thread ...
Re: Thinking out loud about a new RPG web framework, (continued)
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.