RE: What About Price vs. Performance?

Thanks for that joe. It brought a big smile to my face. It reminded me of a story.
Back in the middle 80s I had this interesting contract to rewrite a PC program to be commercially viable.
The insurance company I'd contracted to had just given an accountant a million dollars to buy out an Insurance Broker 'system' he had 'developed'.

In essence he had discovered the BASIC interpreter and had managed to cobble together enough code to record Insurance business and print necesssary documentation and reports. Because he was one of the first,he'd managed to sell some 60 of these systems around Australia, but the task of maintenance was getting bigger and bigger. Each time a client would call with a problem, he'd look at the source of their system and find the solution. He'd then ring them back and tell them to type 230 let a=x instead of 230 let a=y or some such. Basically he'd ended up with 60 different versions of his own system. It was a complete mess. I rewrote it as a compiled system and introduced the idea of sub-routines. And he got the million bucks!

I see the same thing happening again.
Every man and his dog who buys a copy of 'PCs for Dummies' thinks they can build an enterprise wide data processing system. Yeah, I got a copy of VB 4 and had a screen up in 30 minutes and cloned some code to make the screen do something. It's all a bit like teenage magazines. Instant gratification without the substance. Anyone can do it!

The PC world is full of interpretive code. Just keep changing it till it works and then secure that version as the system.

The technology turns over so fast, very few people can master it before it's out-of-date.
Perhaps it's time developers wore white coats and hung around in the glass enclosed computer rooms again?

-----Original Message-----
From:   Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent:   Thursday, 5 April 2001 9:47
To:     MIDRANGE-L@midrange.com
Subject:        RE: What About Price vs. Performance?

Scott, I disagree with you heartily.  If you think your FreeBSD system
running, say, Oracle, can handle a 100-million record transaction file, then
fine.  You're entitled to your opinion, whatever means you managed to come
by it.

You missed the point entirely.  I never touted the AS/400 as a webserver or
a file server.  It's a business logic server.  And you are sadly, sadly
mistaken if you think anything can match up to the AS/400 as a business
logic server.

Because I guarantee you it would take you at least three times as long to
write in C++ the type of business application I could write in RPG.  Mine
would run better, faster, have fewer bugs and be more maintainable.  Not
only that, OTHER programmers would be able to modify it.  If you try it in
SQL, you'll never get it working, much less be able to maintain it.  If you
don't think so, try writing an MRP generation in C++.  I can do it about
three weeks.  That includes database design, from the ground up.  You'd
still be figuring out your table layouts, and wondering how to access four
different input files simultaneously with matching record logic.

Take note of this comment: SQL-only databases are the worst possible
environment on which to develop business systems.  Through the use of stored
procedures, in which you basically write database I/O programs to get around
the limitations of SQL, you can begin to approach the abilities of a native
ISAM database, but only barely, and now you need another programmer to
maintain all your stored procedures.  Yeah, that makes sense.

If you need to take your system down to back it up, you don't understand how
to backup your system.  There are at least three ways I know of to
continuously back up an AS/400 without taking it down.  I usually IPL my
AS/400 once a month, although my model 150 often goes three months or more
without an IPL.  Even so, it only takes about 15 minutes for a complete
PWRDWNSYS *IMMED and IPL on my model 270.  Once a week is more usual in
production shops, but if you need absolute 24/7, you get a redundant
machine.

I've never had a business application fail because of an upgrade.  I don't
use operational descriptors, so I can't tell you about them.  My business
applications run fine from release to release.  I recently had to load a
bunch of old-fashioned CISC programs from who knows how many OS releases
ago - they re-encapsulated themselves and ran just fine.

As to the virus, you can't do it Scott.  Bluster and bravado, but absolutely
NOTHING to back it up.  Try.  Be my guest.  Write a virus for the AS/400.
You'll be as successful as you would be writing a business application in
C++.  And there are plenty of us old RPG and COBOL programmers out there,
and there are actually colleges teaching RPG today.  So I'm not terribly
worried about the lack of programmers.  What I AM worried about is the huge
glut of "Nintechnicians" who think that because they can whack together a
Microsoft Access database and a Visual Basic front end that they can write a
business application.  I've seen more people with CS degrees come into the
real world and blow up (and take small companies with them) because they
don't have the faintest idea what a business application is.

Anyway, enough of my time.  You bring up a point... the AS/400 will never be
the machine for a student.  No duh.  But thousands of small companies run on
AS/400's today, and they seem to be doing just fine.  You say the AS/400
isn't a webserver, and I agree - it's not designed to be a webserver.  It's
far better as a back-end to a webserver.  The best environment is a bunch of
Weblogic or iPlanet servers fronting an AS/400 data server.  But the AS/400
can be respectable as a web server, within limits.  You say the AS/400 isn't
a good fileserver.  You're right, AS/400 will never replace Unix in that
regard.  That's because the AS/400 isn't designed to fling stream files
around.  But again, the AS/400 can do the job respectably enough.  But the
AS/400 is the world's best business logic server.  Nothing comes close.

And a FreeBSD system (or Linux or Windows or any other SQL-based platform)
will NEVER be a respectable business logic server.  Because of the
insurmountable limitations of the database, it will always be nothing more
than a data collection device.  Preferably for an AS/400.

Joe, the Horribly Misinformed

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---