RE: At the risk of sounding like an AS/400 rah-rah...

Some of this is a generalization about how folks segment applications to
servers.  I do know that a lot of Unix admins, DBA's and Unix-centric
managers don't like the idea of running multiple apps on one Unix server.
There are some valid reasons and some folklore behind it.

We're running lots of large, packaged apps on one very large Unix server.  I
feel that it's a lot harder to isolate one application's impact from
another's, particularly in batch.  This is because Unix is a
bring-your-own-batch operating system.  A process is a process is a process.
The application is, for the most part, responsible for throttling tasks and
resources.  Unlike the AS/400, where unlike applications share the same
queue and subsystem concepts, Unix (and Windows) apps may each have
completely different concepts for managing batch/offline processing.
Lawson's "Environment" looks a lot to me like an OS/400 Emulator.  A job
scheduler process maintains batch job requests in Lawson's own queue
constructs and launches them as Unix processes according to Lawson queue
definitions.  Other apps use daemon processes to either spawn child
processes or manage high volume database requests.  When one app steps on
another we have to decide how to scale back resources according to the
architecture of the specific app, assuming we can.  Often you just live with
the resource contention.  On the AS/400 we would just tune the queues and
subsystem entries.

Adam Lang says, "...cron and shell scripts are very powerful."  I agree.
With the proper skill and effort you can use them to write a nice work
management system -- one even more powerful and versatile that than base
OS/400 Work Management.  What's frustrating for me is:  1)  You have to.
and 2)  If you're working in a package software world everyone is writing to
their own standard.

Also, I think some folks run lots of Unix servers because it's a lot harder
to manage OS upgrades and patches in the context of canned software apps on
Unix servers.  To make a huge generalization, a Unix OS patch generates more
concern about application compatibility than an OS/400 PTF.  And with the
permutations of OS, database, and application release it can be much harder
to plan a Unix OS upgrade.  Load two software apps running two different
releases of Oracle on one Unix server and watch the fun begin.

With the exception of lengthening library lists (sorry, Al) upgrading a
system to a new release of OS/400 has never been a big deal on any multi-app
system I've ever dealt with.

Still, it's possible to reduce the number of Unix servers that you run and
to benefit by sharing the resources on one box.  In the process you'll
justify your sys admins and DBA's salaries.

-Jim

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Thursday, January 16, 2003 3:14 PM
To: Midrange Systems Technical Discussion
Subject: At the risk of sounding like an AS/400 rah-rah...


...because let's face it, I am.

Here's a message I stole from the MCPressOnline forums.  I'm not going to
comment, I think it does pretty darned well all by itself.

-------
Keith,

I am in the same boat as you. I took a Unix class, but was on the 400 until
about three months ago. I don't remember much about Unix either.

Everything here is so segmented and siloed, it's ridiculous. Forget the
20,000 users. We don't have nearly as many as that, and the servers crash at
least once every week or two. AND we can't run production batch jobs until
our client service center goes down for the day, because of the negative
impact the batch jobs have on the service center screens. It's crazy to have
to stay late to run these jobs. That's what queues and schedulers were
invented for. I am taking a backwards step that I don't like.

Our 400 application supported 24 clients in production, and test. We also
had IVR and internet production and test running on the same server. No
problems whatsoever. Now we have 7 production servers, 7 replication
servers, 7 test servers, and 7 development servers. Also have two servers
dedicated to processing long running client jobs. THAT'S EFFICIENT?? I don't
even want to think about the personnel required to support that. That does
not include our network servers. AAAHHH!!

Thanks, Keith

Doug.
-----------

For those interested in the whole thread (hello Malcolm!), you can find it
here:

http://www.mcpressonline.com/mc?128@38.nU3Papa056v.111310@.6ae57658

Joe