To stop the migration of IBM i applications to say Windows, there is a lot
of good advice in recent modernization Redbooks and other sources. I'd
highlight the following:

Normalize the database to 3rd normal form and clean up the data (invalid
values, referential integrity concerns).

Remove data validation, RI constraints, and business rules from
"applications", and place that code in "handlers" triggered by DB I/O
events.

Deploy a Web Portal to handle all authentication, authorization, and
application access concerns.

Divide applications into modular ILE components, including DB I/O modules,
browser I/O modules, and programs which dispatch HTTP requests to
appropriate I/O handlers.

Convert to RPG free.

Use dynamic SQL for inquiry and report purposes.

Convert report programs to generate HTML, and optionally transform it to
PDFs for precise printing.

Support mobile (hand held) devices.

Extend applications to customers and business partners - not just internal
users.

Do new types of applications, such as some form of social networking.

Look for opportunities to migrate data off other platforms to IBM i,
supported by new applications deployed using the suggestions above.

Nathan.



On Thu, Feb 26, 2015 at 11:37 AM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Thu, Feb 26, 2015 at 12:45 PM, DrFranken <midrange@xxxxxxxxxxxx> wrote:
Splattering the data across the datacenter on desperate systems and
servers and databases is fraught with peril. Just ask anyone who's tried
it.

I don't disagree with this, but...

Here is just one real life example of a customer who has trod
that
path:
[gory details of train wreck]

As someone who "grew up" outside of the midrange community, and who
tries to keep abreast of all developments in computing, regardless of
platform, I would like to stress that stories like these, while true
and informative, are still just cherry-picked anecdotes. To someone
like me, the takeaway isn't "oh, see how superior the i is". It's
"gosh, they really hired a bunch of amateurs".

Because the folks who came up with that "solution" would most likely
have produced a pile of crap even if they had done the whole thing on
the i.

The sad fact is, most code written on ANY platform is pretty much
crap. But the best code on ANY platform is a thing of beauty. You
see it all the time: The quality of the developer transcends and
trumps the platform. If you put a gun to Scott Klement's head and
tell him he has to use <insert name of whatever language you find
horrible, on whatever operating system you find horrible>, he'll wind
up making something better than most of us could make using all our
favorite tools.

So all the horror stories are what they are. I know there are tons of
them. I've witnessed some firsthand. But all that really *proves* is
that it's hard to move off of what you're currently running. I'm
confident that the migration path in the other direction (to IBM
midrange from something else *that's already working*) is just as
fraught with peril, if not worse.

All of which suggests what would be much more convincing: *success
stories* of businesses which have migrated *to* IBM midrange. That's
what folks promoting the i should be super-eager to share. Because
failures (in any direction) are easy to find, and don't prove much of
anything.

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.