Re: 5250 programmer to web programmer

It would be extremely interesting to take a common and typical project such as Bucks "Union Worker Self Service" and solve it with the various alternatives you identified (CGIDev2, Zend/PHP, OpenRPGUI, Lansa, Hibernate, ... , etc) and compare and contrast the results. A consumer reports output that includes metrics and other important technical attributes. Similar to comparing cars... Miles Per Gallon, 0 - 60MPH in 4.5 secs, Leather seats, power windows, cost, time to develop, etc). How valuable would this be to customers looking to migrate to web development? -Paul


Henrik RÃtzou wrote:

Raul,

in fact "just" restricting access to programs and tables isn't enough. You
have to be able
to grant access to only portions of the tables, "customers" are allowed into
the system and
that means extended serverside protection that not only handles basic
security but also
can hold hidden and unchangeable parameters that restrict program access to
only part of
the tables.

Buck,

the easiest way to get yourself started is to use an exsisting high level
framework that
uses a RIA UI framework that dosn't look 10 years old.

Yes, they will require some skilles, but you will be able to build these
skills step by step
with your "new hobby" and still be productive very quickly.

They are out there for RPG, not many but they are there. Kevin Turner
has one, my own is
another, Aaron Bartell's OpenRPGUI is yet another - all Open Sourced. In
your position,
forget of making anything from the "bottom".

There is also payable frameworks like Valence, Isak, Icebreak, Websydian,
Lansa etc. and
then all the non RPGLE frameworks like Zend etc. and then again the
multi-tier approach
mostly based on MS and then there is RPGOA.

You write that your boss wants to screen-scape, that is what I
call modernization, but screen-
scraping dosn't belong in apps that is presentet for third parties
(customers, members etc.)
basically because it is more expensive to build in required security to
seperate one client
data from another and because a screen-scraped 5250 app for internal use
will look and feel
awkward for a thirdparty user because most 5250 programs requires entering
key data (such
as customer number) for each and every screen/program, will have "internal
codes" that has
to be understood and filled in etc. etc. Most 5250 programs are just not
made for third party
client access, it is as simple as that, it is a new kind of user we haven't
seen in the apps
before, so how could they be?

But why not do both thing at the same time ? Building apps for new users and
screen-scrape
for internal users - if that what management want's ?