Re: 5250 and un-do -- ROW CHANGE TOKEN warning

This is correctly a RPG list that includes using RPG in any device
environment, but it is years since we have had punch
card discussions and even 5250 discussions, that is ancient 20th century
devices, is fading out.

How to handle row updates in a multiuser environtment has nothing to do
with the programming language or device, it is a generic
DB/System problem and is generally solved by placing an update counter in a
column tha works in both SQL and NoSQL DB's
or using the SQL ROW CHANGE TOKEN that only works in SQL based DB's.

That SQL has such a feature should tell you that it is a sustainable
technique!

Most browserbased systems today rely on REST/CRUD services that provide
stateles acces to any DB table for any number
of users. In RPG based on Apache these services runs under one or several
QZSRCGI jobs allocated to the HTTP domain.

So you may have one HTTP domain with 5 QZSRCGI job that runs all call's
from 500 users.

So you may GET a record for update by QZSRCGI job 1, but when you POST your
update it may shift to QZSRCGI job 2
if job 1 is busy serving another user. If the REST/CRUD service that served
you the data from job 1 isn't active in job 2
a new instance of the REST/CRUD service is automatically initiated to
handle the update transaction.

So the REST/CRUD service must be build so it is able to handle updates
without any connection to the original read and
that means no internal variables carried forward.

In practise this is solved by either sending the update counter/token to
the browser where it resides as a hidden field and
is included in the update transaction OR a token to the transaction is
created in a generic request table on the server and
passed back and forth between the server and the client.

In many cases you should use both techniques for security reasons where the
request token to the service must exist on the
server to make any use of any specific REST/CRUD service thus preventing
unautorized access and updates.

But that is a complete other discussion.

In the above scenario your 5250 method will fall short simply because the
number of layors of code that has to be in sync if
you implement a new field or changes in the table and you have no way to
control the clients cash that may hold old version
of the code that dosn't include the new field or you will slow the system
down if you force a refresh of the cash in every call.

To give you an idea of how such a REST/CRUD service may look like here is a
link to one of my services that are program
generated and may output data in various formats.

http://powerext.com/pxsvpxxr.txt

and a live result of a request (for a dataset) where the token to the
server/service is in the req parm

http://5.103.128.110:6380/pextcgi/pxsvpxxr.pgm?ses=19913976321249717620172303481332&req=20097351681255255220172317481368%20&func=getRows&limit=25&pxTS=20171106135048845&_dc=1514033455728&start=25&limit=25


On Sat, Dec 23, 2017 at 2:40 AM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

A couple of points.

First, I am retrieving the original data; as many fields as needed. But
so aren't you. That's kind of the starting point for both of us. So there
is no issue about that part. We both do it.

Second, this is the RPG list; I feel comfortable in using RPG techniques
in this setting. The idea of refusing to use any RPG feature that isn't
also available in HTML strikes me as an odd business decision.

Third, whilst not part of the discussion, you raise an interesting
problem. What do you do in the browser version when there is a data
collision? What extra work is created if there is a false positive? I had
not considered the browser solution, but it must be a real thorn when there
are data collisions?


On 12/22/2017 5:19 PM, Henrik Rützou wrote:

Well it may seems pretty straight forward to you indicating that you are a
programmer locked-into stateful 5250 RPG because it simply
dosn't work in a stateless environment (even programmed in RPG) or in any
other program languages that hasn't got "datastructures"
the proprietary none objectoriented RPG way.

A REST/CRUD service on a server that is the most common way to communicate
file maintenance between a browser based client
and a server dosn't hold any information from previous call to it, so
where
do you expect to store the "before values" in the client?

That means a lot of hidden fields that must reside in the browser since
the
REST/CRUD service is unable to store the information.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD