Re: 5250 to Web Interface / Application Modernization

Yup.

And for old farts like myself handling persistence data is nothing new. We did it for S/34 and S/36 MRT apps, CICS, and on and on. Always found it funny that it was so much easier to teach web to a programmer who did not grow up with S/38 and AS/400 but always had to handle persistence themselves!


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Apr 8, 2019, at 12:57 PM, B Stone <bvstone@xxxxxxxxx> wrote:

I saw the same thing, Jon. Cookies work just fine and are the norm in most
cases.

On Mon, Apr 8, 2019 at 11:48 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

I'm guessing from this Nathan that you have seen no performance issues
with this approach? I know that when I first explored persistent CGI (that
is what you are talking about is it not?) that IBM warned against
performance impacts.

I suspect that it works fine when used in similar situations to
green-screen i.e. a number of known users. Perhaps not such a good idea for
a customer facing site where the number of users is indeterminate.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Apr 8, 2019, at 12:19 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Sessions. Cookies. The request. This problem is boilerplate for all
interactive web technologies.

Every web application framework for every platform and language

environment

that I'm aware of has support for sessions and cookies. However, the IBM

i

native virtual machine environment is somewhat unique in that you can

also

maintain session data by launching unique JOBs for every client session.
The "Job" maintains all session data, for the duration of the session.

When IBM i Jobs maintain sessions, that saves you the overhead of

parsing,

saving, and restoring session data for each and every request. It also
saves the transport overhead pertaining to sessions and cookies that are
the common lot of every other platform and language environment.

With a Job-based sessions, you can open as many files and SQL cursors as
you want, with any number of indexes and SQL filters (where clauses,

etc.).

You never have to re-position record pointers or refresh SQL result sets,
which is common with other platforms.

Job-based sessions free developers to focus on application functionality
without any thought about what data needs to be saved and restored

between

client-requests. You can call (activate) as many programs as you want and
they all share the same session data.

We typically launch a unique IBM i Job every time a user clicks on a menu
item in our web portal. A new tab appears, which displays the

application's

entry-point screen. The portal sends an "end" request to the Job when the
"Exit" link is clicked, or after a period of inactivity is reached, which
enables programs to close files, free resources, and finalize processing
before the Job and session are ended.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com