RE: What About Price vs. Performance?

I'm not going to waste a lot of time on this, as it's all but pointless.  I
did read your post.  The parts where you say Unix can outperform the AS/400
as a LAN server are correct, the points where you say you can write business
applications on it are not.  FreeBSD has no integrated database, uses crap
like Oracle, and so will never work as a business logic server.

That's all I want to say.  Read whatever you want into it.  FreeBSD can
never support a real enterprise-level business application and an AS/400 can
(and no, Yahoo is not a real business application, it's a web application -
different animal).  You like FreeBSD?  Great.  Use it.  Just don't compare
it to OS/400.  They're different beasts.

Joe


> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of Scott Klement
> Sent: Thursday, April 05, 2001 12:29 AM
> To: MIDRANGE-L@midrange.com
> Subject: RE: What About Price vs. Performance?
>
>
>
>
> On Wed, 4 Apr 2001, Joe Pluta wrote:
>
> > 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.
>
> I specifically said that the As/400 is the best database server in the
> world.   They don't even MAKE Oracle for FreeBSD.   What are you getting
> at here, because I never claimed it could match the AS/400's database
> engine?!
>
> > 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.
>
> "And can act as your central server, not just for email, but for printing
> and file serving as your company grows?"  This is a direct quote from
> your message.   See the "file serving" part of it?
>
> ANYTHING can do business logic.  Business logic is based on your ability
> to program, not on the capabilities of a 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.
>
> Joe, I make my living as an RPG programmer.  Take a look at the archives
> for the RPG400-L mailing list at midrange.com.   Ask around.  I'm no
> beginner in RPG.
>
> First of all, OTHER programmers can also read C code.  C is far, far, far
> mode widely used than RPG.  I saw a survey done in 1996 (sorry, I dont
> remember the source anymore) that showed that C was the most widely used
> programming language in the world.
>
> As for C++... It's not that common on the UNIX platforms.  Usually when
> I see C++, its for Windows.
>
> >  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.
>
> The more I read your reply, the more I think that you didn't read my
> message.  I never said I liked C++.   I never said I liked SQL.  I
> specifically said I liked the databases on the AS/400 better.
>
> > 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.
>
> But why would I use SQL?   It's IBM's direction to move away from the
> useful tools like OPNQRYF and to concentrate on crap like SQL, not mine.
>
> > 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.
>
> and a re-IPL (re-boot) on FreeBSD takes under 3 minutes, but its not even
> necessary. A "save while active" has the same risks on AS/400 that it does
> on FreeBSD.   Redundant machines are also possible...   You seem to have
> no real point here what are you trying to say?
>
> My point was that a FreeBSD or Linux server can be 24/7 just as much or
> more than an AS/400 can.   Not that redundant AS/400's couldnt be 24/7!
>
> > 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.
>
> Well, if your applications ran fine it must mean that the upgrade process
> never fails, right?   And, of course, in your vast experience with FreeBSD
> you've seen that it's less reliable in this respect than OS/400?  No?
> I didn't think so.  Why?  Because you don't have any experience with it!
>
>
> > 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.
>
> And ONCE AGAIN, I don't even like C++.  I said that in the first message
> -- you know, the one you didn't read...   But, I could write a business
> app in it if I wanted to.  I just don't like it.
>
> In fact, go look at professionally developed software for Windows NT,
> UNIX, Novell, Sun, HP, etc.  I'm fairly confident that the vast majority
> will be written in C or C++.    How about Microsoft Office?  The single
> most widely used business app in the world -- written in C/C++.
>
> Do you have anything to back up your absurd claim that business apps
> can't be written in C++?   It must be all Bluster and Bravado, Joe,
> since MANY MANY apps are in fact written in these languages.
>
> The AS/400 is not immune to viruses, Joe.  If you think it is, you're
> leaving in dreamland.  I've already given examples (you know, in that
> message you didnt read) of how this could be done.   But instead of
> thinking about what I said, and either giving a well thought out reply
> saying something like "no, that wouldnt work for xxx reason" or saying
> "yes, you're right"...  you taunt me.
>
> Here it is again... Maybe you'll read it this time.   All I'd have to
> do to implement a virus on OS/400 is have it look for a command in the
> system -- DSPOBJD to find a command that's in a user portion of the system
> that the user running me has access to.   Then interpose myself between
> the COMMAND and the PROGRAM that processes it.   BING!  I've spread
> myself.   Now I will be run from somewhere else, again, I can check for
> a command I can exploit -- possibly I can insert myself into another
> command, or maybe the user running me has adequate access to allow me
> to register myself as an exit program, or as a validity checking
> program for another command...
>
> Do you really think this wouldn't work?  Can you give a reason why
> not, or are you just bluster and bravado, Joe?
>
> > 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.
>
> On that topic you have my full agreement.  Every year the new generation
> of IT people knows less and less.  Back in the 80s, IT people knew what
> computers were and how they worked...  by the end of the 90s, people who
> could uninstall and reinstall Windows were considered IT people.  They
> even go so far as to call that "fixing" the problem.
>
> >
> > 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.
>
> Yes, and don't you think the AS/400 would grow more as a platform it IBM
> were able to make it more available to students?  Or make the
> price/performance ratio make more sense in a small business enviornment?
>
> I work for a small business, Joe.  I'm saying these things because I'm
> LIVING the experience of a small business in an AS/400 enviornment.
>
> In 1988, the AS/400 was an ideal fit for our business.  In 1994, the
> prices made sense, the machine made sense.   the models available in
> 2000, however, seemed to offer a lot less for what we were paying.
>
> If IBM continues this trend (and it only sounds like its going to get
> worse) by 2006, we won't be able to keep using this platform.  And THATS
> what I'm saying here!   I'm trying to SAVE this platform by waking people
> up to the REALITY of the world out there!
>
> > 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.
>
> Amen.  It's not a good webserver.   Thats what I've been trying to say!
> IBM is touting it as a webserver, instead of focusing on its strengths..
> the database, the reliability... these are its strengths.  Thats what I
> said in the last message.
>
> > 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.
>
> This also is very close to what I said...
>
> > 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.
>
> FreeBSD is not an "SQL-based platform".   You seem really stuck on the
> whole SQL idea...   I run 8 FreeBSD servers, and not a single one of
> them has a single SQL database on it.
>
> I could create a business app without using a single database.  You have
> to be a bit more careful about the design of the files, but it's possible
> to do everything with flat stream files.
>
> FreeBSD also has btree (binary tree), hash and recno-style database
> support built in.   I could use these to develop business apps if I needed
> a database.  All without SQL.  But no, the database will never be as good
> as the AS/400's. Thats what I keep saying.  The database is its strength
> -- not the webserver. 5250 is its strength, not GUI.  CHAIN/SETLL/READE
> are its strengths, not SQL.   Why can't IBM see that?
>
> >
> > Joe, the Horribly Misinformed
> >
>
> This is getting a bit more heated than I really wanted it to.  Sorry about
> that.
>
> +---
> | 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
> +---
>

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