Re: California Software/Infinite Corporation

and you hit the nail on the head and a big reason that the iSeries is
dying.

I don't know how many shops I have been in. File is being downloaded with a
file transfer triggered from a PC program or done manually by some staff
person and then some Windows programmer write programs that read the file
and do the actual work needed and then write back another file that get
uploaded to the iSeries again either through some Windows program or a user
and, of course, it is not working because somebody put garbage in a file.

Why not simply download Scott's JDBC handler and update the file directly
or something modern. Because the programming staff says if it isn't green
screen, monolith and program calls we won't do it.

Again and again the CEO or CFO or CIO comes to the iSeries staff and says
we need to do the following and what they hear. "We can't do that or we
can't do that without the Windows programmers to write something for us.

If management keeps hearing the same again and again that the iSeries can't
handle it or whatever solution that was created doesn't run or crashes or
doesn't get done, how long is it going to be before the management says
that iSeries is obsolete and we need to get a Windows box or Unix box
because they can do what we want? Not long.

The central overriding problem is the people working on the iSeries refuse
to advance and that message keeps getting sent back to management. The
iSeries cannot handle it.

Most of the people on this forum know that is not the case but you are not
going to do the job with green screen, monolith code and program calls.

Again and again I hear the same thing. I am not going to call a procedure,
I am not going to use anything modern. I won't use anything unless it has a
program call. The field name has to be 6 characters. Just create files.
Don't worry about normalizing. I will not use SQL. On and On.

Unfortunately I just don't see it changing.

On Thu, Feb 26, 2015 at 12:45 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

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.

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