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

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.