AS/400 vs. Unix
Gerry Schenk
opinions on the strengths and weeknesses of the AS/400 vs. UNIX.
I work for a company that has a 150 retail locations. Our primary
platform at the store is Novell, with the Head Office system on Sun
Sparcs, which includes a Sparc 1000 running Oracle 7.
Most of the applications and reports have been developed in house,
written primarily in C and Uniface. This includes the Purchase Order
System and inventory control.
Recently a new VP of Finance was hired on, who is in charge of the IS
group. This new individual is very much against development and much
prefers "canned" packages. As such all development has pretty much
stopped. He is also familiar with IBM's AS/400 and wants to replace the
existing system with a AS/400 package. His complaint about the current
system is that it lacks proper inventory control. This is something that
we were working towards, but the project was cancelled.
We've had discussions about this and he is convinced that the AS/400 is
more popular, that packages on the AS/400 are less expensive and more
readily available. He claims that he cannot find a reasonably priced
Inventory Control UNIX based package.
I have very little exposure with an AS/400. What are the pros and cons
of the AS/400 vs. UNIX. I'd appreciate any feedback.
Thanks in advance.
->Gerry Schenk
->gsc...@wimsey.com
Bill Ezell
>The intent of this post is not to start a flame war, but rather get some
>opinions on the strengths and weeknesses of the AS/400 vs. UNIX.
I use both Unix systems and AS/400 systems. In my opinion, for the kind
of work I do, Unix beats the AS/400 hands down. Trying to do orderly
development on a 400 is a joke. However, as a turnkey application platform
the 400 is pretty good.
In specific, the user interface and command architecture is a throwback to
the 60's. Although there is a lot of neat technology buried down deep, it's
covered up by all those silly menus and the hundreds and hundreds of cryptic
commands. One very good Unix concept that is totally foreign to the 400 is
the idea that one command can operate on all kinds of things. On the 400,
you basically have a different set of commands for each and every different
type of object. There is absolutely no orthogonality.
The block-mode-model terminal I/O is just plain absurd in this day and age.
Speaking of I/O, DDS is another shining example of the senseless complexity
of the 400. Take something as simple as display attributes. Simple?
Unless you set UL, HI, and RI and the display happens to be a 5250, in
which case it really means ND. There are dozens of examples of silly
interactions and obscure details that are discovered mostly by trial
and error.
As for application development and maintenance, you might as well use
punched cards and have a shoebox to keep them in.
Part of our business is converting AS/400 applications to other systems.
As a result, we see lots of different sets of sources. Not one customer
yet has been able to find all of the correct sources for their application.
This is primarily because the 400 embeds a lot of information about things
externally from the actual sources. For example, the DDS source does not
specify the options that are used by the CRTxxx commands, even though
those options change the behavior of the compiled DDS! The parts of
an application get scattered all over; DDS, CL, RPG, COBOL, plus all of
the hidden information such as data areas, message files, queues, etc.
The price/performance of the 400's is really bad compared to almost
any Unix system. Of the applications we have moved, every one has run
faster and cheaper on a Unix box.
So, what's a 400 good for? It does, in some respects, make a good platform
for running a turnkey application, although the common myth that you don't
need a sysop is just that. What it really comes down to is that you pay
a lot to get IBM to keep you captive and give you the warm and fuzzies.
Now, what's wrong with Unix? Perhaps the biggest problem is that Unix was
designed for people that can think, a commodity in short supply. Unix is
a wonderful development envrionment and it gives you a lot of flexibility,
just the opposite of the 400. With this flexibility comes the difficulty of
figuring out how to use it effectively. Another (minor) problem is the
various different flavors of Unix. This is mostly of concern to the sysadmin,
since the core of Unix used by programmers (system calls, etc) ARE standard.
We have a compiler that has been running on dozens of different Unix systems
since 1981!
Hmm - actually, I seem to have worked my way around to saying that I would
be more than happy to sink all of our 400's in the river. My modest opinion
is that those people that say the 400 is great and wonderful have never used
a real computer. Oh well, so much for objectivity.
spa...@well.com
doesn't cut it from the point of view of the business. Developers will get their
rocks off on unix because of its tool kit, and the ability to get down and hack
stuff. However, AS/400 is far more robust, stable and easier to manage than a
unix box - anything goes wrong, it tells you *exactly* what to do, and when
desparate dials mummy (IBM) and gets help. Unix - its you and the man pages ...
The internal architecture is object based. Programs compiled on a 48-bit CISC
machine will run without you having to recompile on the new 64-bit RISC
processors - just try that with a unix box ...
Don't get me wrong - if I was writing a compiler I wouldn't even look at the AS/400,
it just doesn't have the tools.
Recent releases of the operating system have 'broken open' what was a very
closed box - TCP/IP is now native, there are SPEC/1170 APIs etc etc. Unfortunately,
the marketing people are very poor at explaining the openness - you have to fight
IBM to get the information you need - unfortunately Gerstner still hasn't wasted
enough of the suits and the dead wood.
Most unix people I know just start frothing at the mouth at the letters IBM and
then build some kind of rationale for being anti-AS/400 from there. Look for postings from
people who have *done stuff*.
If you like hacking, stick with unix and circulate your resume; if you want to get
something done get stuck into the AS/400.
Larry Loen
|> gsc...@wimsey.com (Gerry Schenk) writes:
|>
|> >The intent of this post is not to start a flame war, but rather get some
|> >opinions on the strengths and weeknesses of the AS/400 vs. UNIX.
|>
|> I use both Unix systems and AS/400 systems. In my opinion, for the kind
|> of work I do, Unix beats the AS/400 hands down. Trying to do orderly
|> development on a 400 is a joke. However, as a turnkey application platform
|> the 400 is pretty good.
|>
|> In specific, the user interface and command architecture is a throwback to
|> the 60's. Although there is a lot of neat technology buried down deep, it's
|> covered up by all those silly menus and the hundreds and hundreds of cryptic
|> commands. One very good Unix concept that is totally foreign to the 400 is
|> the idea that one command can operate on all kinds of things. On the 400,
|> you basically have a different set of commands for each and every different
|> type of object. There is absolutely no orthogonality.
|>
I, too, use both AS/400 and UNIX (AIX).
I find that at least as far as the command line interface goes, UNIX is
terribly backward and the hardest to learn of any system I've
encountered and this includes a great many, not all of which are IBM's.
AS/400's vowel-less interface does take a little adjustment, but it has
the property of pretty consistent regularity.
If I know there is a thing called a "device description" I can try:
CRTDEVD
DLTDEVD
DSPDEVD
WKRDEVD
and hit PF 4 for and find out how many of them work. Thus, even its lack
of "orthoganality" isn't a big penalty, because all the pieces usually
fit together and once you know a couple of commands, you tend to know
many, many more. In fact, it is something of an advantage, because you
tend to know what the command is _called_, something that often baffles
me on Unix. The command in Unix may be able to accept any kind of thing,
but if I don't know its name, it is useless to me.
AS/400 also beats the heck out of Unix where every command seems to have been
thought up by a different person using different rules.
And cryptic? What does -b mean on the flooble command (there is no
flooble command, but there is "grep" and "ls" and all kinds of real
obvious names for things). In AS/400, this can also be a problem, but
most commands have parms like PRINT that work only one or two ways and
it is a real, full blown word, not a -p on one command and a -P on
another.
In part, it is all what you are used to, but having had to go through
the pain of learning both command line interfaces without having learned
either in college, I can tell you that the AS/400 was easier, hands
down, than Unix (or, for that matter, MVS, VM, DOS, . . .).
--
Larry W. Loen | Science is often the act of trading
| comforting myths for exciting ideas
email to: lwl...@rchland.vnet.ibm.com
AB34093.pic.cat.com
>gsc...@wimsey.com (Gerry Schenk) writes:
>
>>The intent of this post is not to start a flame war, but rather get some
>>opinions on the strengths and weeknesses of the AS/400 vs. UNIX.
>
>I use both Unix systems and AS/400 systems. In my opinion, for the kind
>of work I do, Unix beats the AS/400 hands down. Trying to do orderly
>development on a 400 is a joke. However, as a turnkey application platform
>the 400 is pretty good.
>
>In specific, the user interface and command architecture is a throwback to
>the 60's. Although there is a lot of neat technology buried down deep, it's
>covered up by all those silly menus and the hundreds and hundreds of cryptic
>commands. One very good Unix concept that is totally foreign to the 400 is
>the idea that one command can operate on all kinds of things. On the 400,
>you basically have a different set of commands for each and every different
>type of object. There is absolutely no orthogonality.
>
Most customers purchase systems so they do not have to think about computers
but concentrate on their core business. They care about what it's going to cost
and what will they get for it. AS400 vs Unix vs VAX/VMS vs Windows NT doesn't
matter. Making money so you and your employees eat matters.
Lewis De Payne
>
>I work for a company that has a 150 retail locations. Our primary
>platform at the store is Novell, with the Head Office system on Sun
>Sparcs, which includes a Sparc 1000 running Oracle 7.
My experience credentials: I've been in Data Processing for 18 years
now, having set up and programmed PDP-11's (RT-11, RSX), RSTS/E
machines, HP's, and VAXes (DEC). My shop is now AS/400, having
replaced a (DEC) VAX running Open VMS. We are a large national
corporation, listed in the Forbes 100.
>Recently a new VP of Finance was hired on, who is in charge of the IS
>group. He is also familiar with IBM's AS/400 and wants to replace the
>existing system with a AS/400 package.
Experience -- PacTel Cellular (now AirTouch) replaced its VAX cluster
with an IBM box after they got a new I.S. Director. We're talking
millions of dollars here. The project was such a "success" that he
was asked to "resign". Now they're a VAX shop again.
> His complaint about the current system is that it lacks proper
> inventory control. This is something that we were working
> towards, but the project was cancelled.
Financially and strategically, his position makes no sense. Price out
the appropriate AS/400 and canned packages (versus the cost of
finishing your project). Either he'll be in for a rude awakening or
he'll be collecting unemployment.
>We've had discussions about this and he is convinced that the AS/400 is
>more popular, that packages on the AS/400 are less expensive and more
>readily available. He claims that he cannot find a reasonably priced
>Inventory Control UNIX based package.
There are plenty of packages, even custom-designed ones, that will do
inventory control for much less than his $250,000+ solution.
>I have very little exposure with an AS/400. What are the pros and
>cons of the AS/400 vs. UNIX. I'd appreciate any feedback.
I take it you want an honest answer. It's a completely different
world. The preferred environment is RPG/400, and if you're used to an
integrated program development environment, the source code editing is
like going back to the stone age. The user interface is a joke, and
the only way to salve it is to do screen-scraper applications on the
PC side, or client-server. Anything you want to do on the AS/400 is
expensive compared to the "open" solutions. Even CTI (computer
Telephone Integration) is a ripoff. Grief is a constant companion of
users who are trained on user-friendly screens, and have to endure the
constant bullshit of AS/400's scren-in-screen-in-screen concept.
Michael Brutman
I don't question your credentials, but the tone of your note was just a
wee bit offensive.
Without getting into the specific question at hand (ie: does it make sense
to kill an existing project and purchase an AS/400 to do the job instead),
let me address a few issues:
"The preferred environment is RPG/400."
Since when? You neglected Cobol, C, Pascal, etc. And probably C++ soon ...
|> integrated program development environment, the source code editing is
|> like going back to the stone age. The user interface is a joke, and
|> the only way to salve it is to do screen-scraper applications on the
|> PC side, or client-server. Anything you want to do on the AS/400 is
|> expensive compared to the "open" solutions. Even CTI (computer
|> Telephone Integration) is a ripoff. Grief is a constant companion of
|> users who are trained on user-friendly screens, and have to endure the
|> constant bullshit of AS/400's scren-in-screen-in-screen concept.
In an age of client/server computing, does the user interface on the host
really matter anymore? Isn't the user interface on the client more
important?
Think a bit. If I'm on a lan, I can use *any* machine I want to edit my
source & launch my compiles. With SQL and other distributed computing
goodies the user interface of the host machine doesn't matter - it is the
client that counts.
If you want the green screen it will be there .. But as time progresses
green screens will become rarer and rarer. And I'm not talking about
terminal emulation as a replacement either - think of true client
server computing. (Or network-centric, or whatever you want.) In that
paradigm, your comments are irrelevant.
Now, regarding Unix in general. I tend towards being a Unix bigot.
However, the 400 provides some nice features that Unix boxes don't, and
a lot of that is due to a difference in design philosophy.
[1] AS/400 is integrated. This is a strengh or a weakness, depending
on what you like. Unix requires a lot of integration work on the
part of the customer; work that they may not be prepared or
willing to do.
[2] AS/400s are solid. People don't like their businesses crippled
when the machine goes down, so we build them and program them like
tanks.
[3] Investment protection. Without getting hokey on this one, how many
competing systems allow you to change from a 48 bit to a 64 bit
implementation nearly transparently? Sure, the new RISC boxes do
translation, but you didn't need your source code to do it. Try that
on any other system - you will need source code and *you* will resolve
the compiler errors that you get. And you can use a new RISC box to
develop programs for older v3r1 and v2r3 targets too .. Try that
elsewhere.
[4] Expense - your initial outlay is more, then then again, you don't
have to pay somebody like me $50,000 to write the shell scripts to
keep the &%*_! running. Compare cost over the life of the product -
we look a lot better in that light.
Enough said. This is probably bordering on propaganda already ...
Mike
--
Michael B. Brutman
bru...@vnet.ibm.com
Standard Disclaimer: Not speaking for IBM
Vil...@cus.cul.ca
>My experience credentials: I've been in Data Processing for 18 years
>now, having set up and programmed PDP-11's (RT-11, RSX), RSTS/E
>machines, HP's, and VAXes (DEC). My shop is now AS/400, having
>replaced a (DEC) VAX running Open VMS. We are a large national
>corporation, listed in the Forbes 100.
My experience is similar, albeit with a few more years (abt 27 in total),
more of a bent on systems support rather than programming, no HP, and a sprinkling
of VM support (abt 3 yrs worth) thrown in. For the last 5 yrs, I have been
(the only one) supporting 4 AS/400s (3 remotely - up to 300 mi away),
and one little VAX.
>I take it you want an honest answer. It's a completely different
>world. The preferred environment is RPG/400, and if you're used to an
>integrated program development environment, the source code editing is
>like going back to the stone age.
I think that I would agree with this. Cobol and C are available, but the
vast majority of the code is still being written in RPG/400. Packages are
available to allow you to write your code on a PC - but we don't use it.
We don't do a lot of development, just local customizations (and as few of those
as possible please!!).
>The user interface is a joke, and
>the only way to salve it is to do screen-scraper applications on the
>PC side, or client-server.
The user interface is a joke, The standard system menus provide you with
contextual help, fill in the forms prompting, a reasonably thought out
menuing system. The one thing I do miss is the ability to speed dial
that SPF provides i.e. menu item 1.2.3.4. Type ahead though is almost
as good. These always the command line, type the command and hit F4 -
and fill in the blanks. etc
> Anything you want to do on the AS/400 is
>expensive compared to the "open" solutions. Even CTI (computer
>Telephone Integration) is a ripoff. Grief is a constant companion of
>users who are trained on user-friendly screens, and have to endure the
>constant bullshit of AS/400's scren-in-screen-in-screen concept.
user friendly ====> GUI
anything else need not apply!!
On the otherhand, a good consistant text based menuing system, with
built in contextual help, keyword search for commands etc is BAAAD
because its not GUI!! (I've seen some very bad GUIs !!)
AS/400 solutions do tend to be expensive.. on the other hand
Solid built in security, backup & recovery, file & message distribution,
good solid batch support, automatic software distribution for PCs,
TCP/IP support, an operating system that is built around a relational
database with virtually everything on the system being an object
within that database, remote database access, and
reliability, reliability etc etc etc...
I like my AS400, I'm too old to enjoy bit twiddling for the sheer sake
of proving that I can remember what each bit is used for. I do not
mind having a few more checks in place when I'm doing something
critical, I do not mind having JOB LOGS, that I can look at when a
user is having problems, or a system that tells me when hardware is
starting to get a little flakey.
20 system years, not a single byte lost due to equipment failure (one loss
due to stupid fingers - about 8 hours of data entry for one person). Disk
drives and controllers that scrub the living daylights out of a disk in an
effort to recover the data (No hard crashes - thank goodness!!).
Build in performance data collection. The tool to process the data is an
optional extra, but you only need that on one machine!!
I like my VAX, there are many features on it that I wish that the AS/400s
had, there are more features on the AS400, that I wish the VAX had..
AS/400s are expensive initially. There are however enough people reporting
ongoing operating and support costs that are significantly lower than
the competeing technologies to justify this up front cost.
In our own case, we have never lost our initial investment in our AS/400s.
Upgrades are always cheaper than a new system - usually significantly. This has
genertally not been my experience with either DEC or SUN. I.e. you need more
power, buy a new box.
Only my opinion, the UNIX believers I work with will get their little crosses
out and mutter incantations. They also tend not to want to work on the AS400s.
Not enough control they mutter.
Its a difference of perspective!
If I had a bunch of mail reading, adhoc programming type people - go UNIX!!
For a canned application that needs to work and work and work - GO AS400!!
In your case, I wouldn't care to hazard a guess as to the right decision.
How much more would need to be invested in your existing system, what are
the downsides to the existing system, how good is the "new" application??
My own preference these days is for an off the shelf, non client server (what
ever that means these days) app. Spend a lot of time looking and talking
with existing users. And then look some more.
Any opinions expressed are mine and mine alone, based upon whatever experience
that I have managed to gain.
Villy G. Madsen
Systems Consultant
Canadian Utilities Ltd
403-420-5093
Lewis De Payne
>
>Most customers purchase systems so they do not have to think about computers
>but concentrate on their core business. They care about what it's going to cost
>and what will they get for it. AS400 vs Unix vs VAX/VMS vs Windows NT doesn't
>matter. Making money so you and your employees eat matters.
I believe that so far, we've all been addressing the concerns you
state. In order to be fiscally responsible, a business must know what
[a solution] is going to cost them, and what the [payback] is. In his
book "Financial Strategy: A Guide for the Corporate Manager," James E.
Wharton explains valuation theory. What a computer is going to cost
you, both short and long term, is very dependent on which platform you
choose to go with. AS/400 vs Unix vs VAX/VMS vs NT Server is part of
that corporate decision making strategy. Claiming that it isn't is an
invitation to disaster.
Stefan 'Stetson' Skoglund
I find that at least as far as the command line interface goes, UNIX is
terribly backward and the hardest to learn of any system I've
encountered and this includes a great many, not all of which are IBM's.
AS/400's vowel-less interface does take a little adjustment, but it has
the property of pretty consistent regularity.
If I know there is a thing called a "device description" I can try:
CRTDEVD
DLTDEVD
DSPDEVD
WKRDEVD
I can't see the consistency in this ???
and hit PF 4 for and find out how many of them work. Thus, even its lack
of "orthoganality" isn't a big penalty, because all the pieces usually
fit together and once you know a couple of commands, you tend to know
many, many more. In fact, it is something of an advantage, because you
tend to know what the command is _called_, something that often baffles
me on Unix. The command in Unix may be able to accept any kind of thing,
but if I don't know its name, it is useless to me.
AS/400 also beats the heck out of Unix where every command seems to have been
thought up by a different person using different rules.
A lot of the utilities in UNIX is done by different users from the
beginning.
And cryptic? What does -b mean on the flooble command (there is no
flooble command, but there is "grep" and "ls" and all kinds of real
obvious names for things). In AS/400, this can also be a problem, but
most commands have parms like PRINT that work only one or two ways and
it is a real, full blown word, not a -p on one command and a -P on
another.
The short options and program names in unix is historical things.
It is simply inconvenient to write multiple characters if you don't
have good command line editing. I also think that upper-case
program-names, options and so on is unreadable.
--
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund I |
sp2s...@ida.his.se I |
<http://www.his.se/ida/~sp2stes1/> I _____/0\_____
I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige I I-+-I O I-+-I
I
I Viggen with two Rb04
---------------------------------------------------------------------
Michael Ozanne
gsc...@wimsey.com "Gerry Schenk" writes:
*The intent of this post is not to start a flame war,
OOPS
*
*I work for a company that has a 150 retail locations. Our primary
*platform at the store is Novell, with the Head Office system on Sun
*Sparcs, which includes a Sparc 1000 running Oracle 7.
*
*Most of the applications and reports have been developed in house,
*written primarily in C and Uniface. This includes the Purchase Order
*System and inventory control.
*
*Recently a new VP of Finance was hired on, who is in charge of the IS
*group. This new individual is very much against development and much
*prefers "canned" packages. As such all development has pretty much
*stopped. He is also familiar with IBM's AS/400 and wants to replace the
*existing system with a AS/400 package. His complaint about the current
*system is that it lacks proper inventory control. This is something that
*we were working towards, but the project was cancelled.
*
*We've had discussions about this and he is convinced that the AS/400 is
*more popular, that packages on the AS/400 are less expensive and more
*readily available. He claims that he cannot find a reasonably priced
*Inventory Control UNIX based package.
*
*I have very little exposure with an AS/400. What are the pros and cons
*of the AS/400 vs. UNIX. I'd appreciate any feedback.
*
*Thanks in advance.
*
*->Gerry Schenk
*->gsc...@wimsey.com
*
--
Michael Ozanne
Dan Hicks
>You'd be surprised how many AS/400s there are running different businesses.
>I find them in hotels, restaurants, financial institutions, etc., etc.,
>all the time. They aren't used by "programmers", they are used by "users".
There was a brief TV report on drug traffic in South America last week.
The reporter stated that even some sophisticated computer equipment had
been seized from the drug cartels, and then cut to a scene of some
confiscated equipment -- a rack-mount AS/400 system, complete with
Baldrige banner on the front.
So I guess AS/400s are used by pushers as well as users.
Dan Hicks
http://www.millcomm.com/~danhicks/
Michael McKnight
Remember one thing. When you go to the AS/400, IBM has you and there
is no escaping. You have to do a lot of things in the same ancient
IBM mainframe mindset.
You have to do special things to talk to the machines. Like, for
example, use a 5250 emulator. Sure, you might can use a vt100
emulator, but it wont work correctly in all cases. Try hooking
async devices to an AS/400 and you are asking for headaches.
Dont plan on buying an inexpensive SCSI CD-ROM and connecting it...
or hard drives for that matter. No, no... you have to buy DASD and
generally it is priced quite a bit higher than it should be.
Hows $1400 sound for a 542MB hard disk?
How about $2300 for an ethernet card.
Just a couple of examples.
I will give them one thing... they do not break. Ever. Never.
No way! The only time I have seen an AS/400 go down
unexpectedly was when some pinhead contractor of ours unpluged
the cable connecting the system to the DASD...
The 400 is a whole new world compared to UNIX. Sure, big blue
is opening the machine up, but remember, IBM has their own
definition of "open." They have a long, long way to go.
For canned business apps, it is probably a decent system. But,
then again, you could find a PC-based solution that uses a UNIX
backend for probably a lot less. Or even a Novell/NT based
system.
Be prepared to learn a new language. You will need to know RPG
to do anything. Sure, C and COBOL are supported, but the system's
native language is RPG and everything dealing with the 400 seems
to assume RPG is being used. RPG is another example of old IBM
hanging on... cryptic and unstructured (like you still have to
start a line in position X and a parameter goes in position Y).
Eeeech... gives me chills.
I have used AS/400's and UNIX for about the same amount of
time. I have to say, I like UNIX much more. It is far more
flexible and is truely "open." I'd rather put up with the
intricacies(sp?) of UNIX and be able to do EXACTLY what I
want to than to have to do something within the confines
of IBM telling me how I have to do it (which is usually
bass-ackwards anyway).
Plus, you cant just hop on the 'Net and find the resources
for an AS/400 like you can UNIX. There might be a few
here and there, but you either have to buy utilities from IBM
or write them in RPG. Not near as nice as hoping on the 'Net
and being confident that someone else has already done the work
and shares it freely.
A parting word... If they force you to an AS/400, they should
give you a substancial pay raise or you should RUN.
Just a few thoughts!
-Michael McKnight
mckn...@rbdc.rbdc.com
Ooi SC
>I have very little exposure with an AS/400. What are the pros and cons
>of the AS/400 vs. UNIX. I'd appreciate any feedback.
I had been using a unix box and am now using as/400. Here are my
opinions :
Advantages of AS/400 vs Unix
1. Its built-in database is very stable when compared against typical
unix dbms. Software running against db2/400 (that is name of
AS/400's built-in database manager) will never fail halfway.
2. Even when your machine fail because of lack of power e.g. UPS
failure, your file system will not become corrupted.
3. The batch job control system is much more mature than unix's. You
can control exactly how many jobs are active concurrently, jobs
from which queue get executed first, how much resources each job
gets, schedule a job to run at a particular time or at regular
intervals, etc (Standard unix cannot do these except with after
heavy system programming)
4. Spool file control on the AS/400 is very sophisticated. For
instance, you suspense a print job, restart at a different page,
transfer to a different printer, print equally well on a page
printer or a dot-matrix printer without reprogramming, etc.
Standard unix can emulate some of these features only by
stringing together a bunch of utilities - very tough to teach to
a computer operator.
5. AS/400 spreads each of its files across all the available
disks. Thus IO is always shared equally among all the disks. This
help to improve interactive programs response time greatly. This
feature is a double edge sword.
6. AS/400 is a very good virtual memory OS. In this area, it is much
more stable than unix.
7. The security features of the AS/400 is very good. Definitely much
better than most versions of unix. For instance, the password
file of the AS/400 is encrypted and is virtually invisible to
all standard file manipulation commands. That makes it very
tough on hackers.
8. Todate, the OS of the AS/400 and its dbms has gone though at
least seven releases. There are no software maintenance
charges on the OS. The first five releases were given free. IBM
only charge for the 6th release (V3R1) and maybe 7th release
(V3R6).
9. You can often get by without a dedicated system programmer or
database administrator for your AS/400. Unix boxes are
generally more complicated such as when you wish to amend
your database or add devices.
10. WAN communications are easier to set up for the AS/400 then
for unix boxes. If your wish to connect your AS/400 to the
internet, you may sleep slightly better knowing that most
hackers' knowledge of the AS/400 is poorer than their
knowledge of unix boxes. Hands up all those who have
used an AS/400 in the universities!
Advantages of unix vs AS/400
1. The dbms available on unix boxes are much more feature rich.
For instance, DB2/400 did not get partial or outer join until
V3R1. I must hasten to add that DB2/400 features while poor
but are adequate in all the important areas. There are also
numerous choices of dbms to choose form whereas you can
use only DB2/400 on the AS/400
2. The programming tools on a unix box is much better than that
available on the AS/400. Even vi on unix is far better than seu
on the AS/400. Compilation time on a unix box is often faster
than on the AS/400. This is very important as programmers like
fast edit-compile-test cycles.
3. The numerous utilities on the unix box together with the piping,
stdin,stdout,stderr mechanism form an excellent combination to
much problems without programing. Even if you have to
program, you can often write a short program to cater for the
missing feature, pipe it to the rest and there you go.
4. Current computing trend is very much in favour of unix boxes.
AS/400 shops like mind can only pray that the AS/400 can
continue to swim against the unix tide.
5. Client server implementations on unix boxes are still much
more popular.
6. The api on unix boxes are well known when compared against
the AS/400.
In conclusion, both machines have their strengths and weaknesses. I
would choose an AS/400 if I am in charge of a DP shop so that I can
sleep well. If I am a programmer, I will choose a unix box because it
is much more fun programming it.
I do not believe that AS/400 applications are cheaper. I also do not
believe that unix software are portable. I had just switch off a unix
box running an informix-based app because the porting cost to another
unix box is higher than buying a new lan-based package.
Kelley Jones
emotional issue as well as a technical and business issue. I am on the
AS/400 side. I have developed applications on the AS/400 and its
predicessor, the System/38, for 12 years.
The AS/400 is not a cute toy that is as fun to use as a PC. It is a
business tool. A very solid, consistant, stable and perhaps boring
business tools. Most good tools are boring. Most fun toys are not good
tools.
It is very different. RPG/400 is its primary lanquage although C, COBOL,
REXX and so on are supported by IBM compilers. It is the most sucessful
business computer ever. Over 300,000 real multiuser, systems are
installed world wide. I make the distinction as 300K single user PCs or
even servers is nothing in the scope of the quantity of CPUs sold. It
has a relational database built in, literally part of it is in hardware,
at no additional cost and it is FAST.
As for stable, they just do not go down. Programs written in 1985 for
the System/38 will execute on the new PowerPC based RISC AS/400s today
without even a recompile!
It is not everything to everyone but it is near perfect to hundreds of
thousands of major corporations world wide. Is it right for you? I do
not know, but it is worth researching and reaching a business decision.
If I can help any further, Mail me GWW...@Prodigy.com
ns...@1media.com
>is no escaping. You have to do a lot of things in the same ancient
>IBM mainframe mindset.
What does that mean? What's an IBM mainframe mindset? I always thought IBM
offered the very best in business solutions. I can't think of any other
company I would trust with running critical business applications. Can you
name any other company as reliable as IBM? I don't think any exist.
Our AS/400 runs 7 days a week - 24 hours a day. Does its own backups and
releases jobs unattended. Soon it will even page me at home if there are any
problem with a job. Hmm... Not bad huh?
>You have to do special things to talk to the machines. Like, for
>example, use a 5250 emulator. Sure, you might can use a vt100
You have to do special things to talk to any machine. Thats why they're
machines!
>Hows $1400 sound for a 542MB hard disk?
>How about $2300 for an ethernet card.
Reliabilty has a price. If you go dollar by dollar you will find that alot
more money is spent by companies in salaries to individuals figuring out PC
hardware/software conflics than anything that plugs into an AS/400.
>
>Just a couple of examples.
>
>I will give them one thing... they do not break. Ever. Never.
>No way! The only time I have seen an AS/400 go down
>unexpectedly was when some pinhead contractor of ours unpluged
>the cable connecting the system to the DASD...
That's what I call reliabile. Thats exactly what you pay for. IBM has never
let our company down.
>
>The 400 is a whole new world compared to UNIX. Sure, big blue
>is opening the machine up, but remember, IBM has their own
>definition of "open." They have a long, long way to go.
>
I used to think IBM should open the system up, but recently I came to the
conclusion that it should remain closed. Let the rest of the world fight
off the "open-incompatable" headaches.
Who needs security breaches anyway?
The AS/400 architecture (right now) is so far ahead of any other business
machine its not even funny. Oh BTW, did I mention the AS/400 comes with a
database integrated with the operating system. Does UNIX have a secure
database system?
>For canned business apps, it is probably a decent system. But,
>then again, you could find a PC-based solution that uses a UNIX
>backend for probably a lot less. Or even a Novell/NT based
>system.
>
I agree the one-time fixed cost is slightly more expensive but the
long-term costs is very much the same if not more on any other platform
(even PC's).
You don't compare one PC to the AS/400, you compare 60 PC's (one for each
client/server user). Now, multiple that by the cost of a PC's (about $1700
each). Now add a couple of maintence people to handle PC problems and their
salaries EACH year. And the number is?
But wait, I just remembered something - Was'nt it IBM who gave us the
Personal Computer? I don't recall it having changed much from the original
bios specifications.
>Be prepared to learn a new language. You will need to know RPG
>to do anything. Sure, C and COBOL are supported, but the system's
>native language is RPG and everything dealing with the 400 seems
>to assume RPG is being used. RPG is another example of old IBM
>hanging on... cryptic and unstructured (like you still have to
>start a line in position X and a parameter goes in position Y).
>Eeeech... gives me chills.
>
The native programming language of the AS/400 is not RPG but something
called MI (Machine Interface). All languages RPG, C, Cobol, Pascal, Basic,
get compiled into MI before they are executed. This keeps program bugs from
crashing the entire system. It just doesn't happen on AS/400. Sometimes I
like to kid around with the operator and ask her to CTRL-ALT-DEL the system
console.
There is nothing wrong with RPG. It is just another langauge amongst many of
them. It is positional, but sometimes that makes it easier to code and
maintain than "free-format" languages because restricts programmers from
getting "too cute and sloppy" with coding styles.
For example, when you want to know which files are used in a program, you
look at the top of your source for the F specs and there they are. When you
do this with "free-format" languages, you have to search the entire source
file.
All languages have their quirks.
Who was the smarty who came up with "{" and "}". Why did'nt they just use
Function "Name" and End Function. The "{" "}" is so unnatural and causes
the code to look like MODEM LINE NOISE. You don't have to code so cryptic
to write good code. Execution speed is NOT determined by the size of the
source statements but by the optimization capablities of the compiler. Code
tuning, on the other hand, is left to the programmer but still has nothing
to do with the source code.
I'm not knocking other languages because I've coded in most of them and RPG
does have a unique style that makes it very easy to use for business
computing and reporting.
>I have used AS/400's and UNIX for about the same amount of
>time. I have to say, I like UNIX much more. It is far more
>flexible and is truely "open." I'd rather put up with the
>intricacies(sp?) of UNIX and be able to do EXACTLY what I
>want to than to have to do something within the confines
>of IBM telling me how I have to do it (which is usually
>bass-ackwards anyway).
>
Does "what I want to" fall into the category of your business strategy or
just personal gradification?
>Plus, you cant just hop on the 'Net and find the resources
>for an AS/400 like you can UNIX. There might be a few
>here and there, but you either have to buy utilities from IBM
>or write them in RPG. Not near as nice as hoping on the 'Net
>and being confident that someone else has already done the work
>and shares it freely.
>
Nothing is FREE! There are TOO many mouths to feed out there.
>
>A parting word... If they force you to an AS/400, they should
>give you a substancial pay raise or you should RUN.
>
Alright, I'll agree to that! <G>
Just having some fun!
Nestor Sosa
Bob Shair
>
>The 400 is a whole new world compared to UNIX. Sure, big blue
>is opening the machine up, but remember, IBM has their own
>definition of "open." They have a long, long way to go.
blame IBM for that; just a sign of where the 400 lives.
>For canned business apps, it is probably a decent system. But,
For canned business apps, and transaction processing, it is an
OUTSTANDING system.
>then again, you could find a PC-based solution that uses a UNIX
>backend for probably a lot less. Or even a Novell/NT based
>system.
You certainly could. But what was that you said earlier about
400's "never breaking"? If a VP of Finance were to look at the
"Total Cost of Computing" simplicity and reliability might be
weighed heavily in favor of the 400.
>Be prepared to learn a new language. You will need to know RPG
>to do anything. Sure, C and COBOL are supported, but the system's
>native language is RPG and everything dealing with the 400 seems
>to assume RPG is being used. RPG is another example of old IBM
>hanging on... cryptic and unstructured (like you still have to
>start a line in position X and a parameter goes in position Y).
>Eeeech... gives me chills.
>
>I have used AS/400's and UNIX for about the same amount of
>time. I have to say, I like UNIX much more. It is far more
>flexible and is truely "open." I'd rather put up with the
>intricacies(sp?) of UNIX and be able to do EXACTLY what I
>want to than to have to do something within the confines
>of IBM telling me how I have to do it (which is usually
>bass-ackwards anyway).
>
This is, to my mind, the heart of the matter.
AS/400s are NO FUN!
The Perl motto, "There's more than one way to do it," can stand for the
entire Open Systems community. For the AS/400, it would be something like
"Do it my way and avoid problems."
>
>Plus, you cant just hop on the 'Net and find the resources
>for an AS/400 like you can UNIX. There might be a few
>here and there, but you either have to buy utilities from IBM
>or write them in RPG. Not near as nice as hoping on the 'Net
>and being confident that someone else has already done the work
>and shares it freely.
>
>A parting word... If they force you to an AS/400, they should
>give you a substantial pay raise or you should RUN.
>
Ah, but they won't! One of the attractions of the 400 (to our VP
of Finance) is that it takes a smaller, and less highly-paid, staff.
They also have little use for highly-paid "Open Systems Consultants".
Moving to an AS/400 may be a good business decision for your company.
It's unlikely to be career-enhancing for you.
--
Bob Shair Open Systems Consultant
1018 W. Springfield Avenue rms...@uiuc.edu
Champaign, IL 61821 217/356-2684
cro...@kuentos.guam.net
A similar thread just ran in the AIX group, titled RS/6000 vs. AS/400. It seems to
me once in a while, the AIXers get bored and started posting threads like
AIX vs. NT, AIX vs. HP-UX, AIX vs. SunOS. The RS/6000 vs. AS/400 thread ended
just before it got ugly as an intra-IBM brawl, as the title suggests. Sometimes
I can't help thinking that inside IBM, there is seething interdivisional rivalry
between the RS/6000 group and the AS/400 group. Both their products (the bulk
of the RS/6000 line are with midrange servers) are competiting head on, and
both embrace some fundamental differences in computing philosophy.
Interdivisional competition is no stranger for the AS/400 group. The other
enemy inside the Big Blue borders has been the big systems (MVS, VSE, VM)
group. The most powerful AS/400s could already compete with the low to
midline of the machines, while the smallest System 390s, like the PC Server
390, is of a size, price range and performance range that can easily fall right
into the middle of the AS/400 line. Anyone accusing the AS/400 group as a
sample of "mainframe think" should think otherwise---the ease of operation
and administration of an AS/400 can be as career damaging to the MVS
priesthood as much as the Unix gurus. In our island, the 100 or so plus
AS/400s have virtually eliminated every IBM 43xx mainframe. Every single
site went AS/400, and never upgraded to a System 390.
I should add that our island is located remotely in the Pacific, and has a
scarcity of skilled technicians, administrators and consultants. Administration
and support concerns are paramount in the decisions in choosing the AS/400.
We don't have a lot of midrange Unix boxes here either, and the few tend to
be RS/6000s. Most of the Unix installations run on PC servers, and they are chosen
only for the consideration of cost (SCO Unix, LInux, etc,.)
An issue from VARbusiness (June 1, 1995---Battle for the Midrange),
provides an interesting perspective about the AS/400 versus Unix and the
rest of the world.
Here are some interesting quotes---
"We have sold tens of thousands of AS/400 systems in the same amount of
time that our rivals boast they have made hundreds of converstions. And
all those installations were competitive bids, so I ask you: Who do you think
is winning the battle of the Midrange."---Buell Duncan, IBM.
"We have taken away business from Digital in more than a few VAX/VMS
shops, but we have found fewer AS/400 shops willing to make the jump."
---John Ranta, RS/6000 VAR, on how difficult selling against the AS/400 is.
Rgds,
Chris
Rei Hino/Sailor Mars Ami Mizuno/Sailor Mercury Minako Aino/Sailor
Venus Makoto Kino/Sailor Jupiter Haruka Tenoh/Sailor
Uranus Michiru Kaioh/Sailor Neptune Setsuna Meioh/Sailor Pluto
Usagi Tsukino/Sailor Moon Hotaeru Tomoe/Sailor Saturn
Chiusagi Tsukino/Sailor Chibimoon *****cro...@kuentos.guam.net*****
Kazimir Kylheku
>gsc...@wimsey.com (Gerry Schenk) wrote:
>3. The batch job control system is much more mature than unix's. You
> can control exactly how many jobs are active concurrently, jobs
> from which queue get executed first, how much resources each job
> gets, schedule a job to run at a particular time or at regular
> intervals, etc (Standard unix cannot do these except with after
> heavy system programming)
Not necessarily. Things like cron and at are quite adequate. Resources can also
be assigned to each job in all modern UNIXes, including the freeware ones.
Things like the maximum data and code sizes, maximum CPU time, maximum per-user
process limits, maximum open files, etc.
The System V cron can schedule jobs at particular times or regular intervals.
Maybe the AS/400 thing is more sophisticated, but this is not evident from your
description alone.
>4. Spool file control on the AS/400 is very sophisticated. For
> instance, you suspense a print job, restart at a different page,
> transfer to a different printer, print equally well on a page
> printer or a dot-matrix printer without reprogramming, etc.
> Standard unix can emulate some of these features only by
> stringing together a bunch of utilities - very tough to teach to
> a computer operator.
How does it deal with PostScript? Line printers are still important in some
applications, but noawadays even mundane things like printing the contents of
some log file or script report are dumped through an N-up thingy that creates
PostScript output.
>5. AS/400 spreads each of its files across all the available
> disks. Thus IO is always shared equally among all the disks. This
> help to improve interactive programs response time greatly. This
> feature is a double edge sword.
I'm sure this sort of "striping" is available in many UNIXes, so you have to
consider which UNIX incarnation you are talking about.
>6. AS/400 is a very good virtual memory OS. In this area, it is much
> more stable than unix.
Again, maybe somewhere you have run into some buggy version of some UNIX
_implementation_ that leads you to believe this.
>7. The security features of the AS/400 is very good. Definitely much
> better than most versions of unix. For instance, the password
> file of the AS/400 is encrypted and is virtually invisible to
> all standard file manipulation commands. That makes it very
> tough on hackers.
Maybe it is more secure. But your vague description doesn't make the AS/400's
password system sound superior that of a UNIX system that has shadowed
passwords (ever heard of that? It's very common).
Well, that's about it.
--
Gerry Schenk
interesting to see the different posts. As indicate in my original post we
have been a Unix/Novell shop for the last 5 years, running Oracle 6 and
Oracle 7. After reading the posts, I'm not convinced that the AS/400 is
any better than Unix. The majority of the posts have concentrated on the
hardware side and reliability. From what I can see there is not
much of a difference.
Having read the arguments, I more curious about the application side.
What makes the AS/400 and DB2 more attractive than Unix and Oracle.
We are running on Oracle 7.1.6, soon to be 7.2. We have been running in
a client server shop with Windows 3.1, using Uniface, Power Builder and
Objectview.
We are looking for a Inventory Control/Merchandising system, that can
support 150 locations running Novell, where the data is batched through a
nightly DOS process back to the Head Office. Currently JDA's MMS running
on the AS/400 is the favorite.
Perhaps someone can answer the following questions.
1. Are there more Business applications on the AS/400 than
there is on Unix?
2. Are the costs for these types of applications typically more or less
on these types of systems?
3. Any recommendations on either AS/400 applications or Unix
applications. For the Unix applications, it would be preferable that
they run with Oracle.
4. What kinds of Retail locations are running Unix and Oracle. I've
heard or read that Starbucks, Walmart and Home Depot are using AS/400s.
I look forward to the all the excellent responses.
Below is some of my thoughts on why Unix is better. Below that is the
original post, which I've included for the benefit of the readers of the
Oracle newsgroup, which I've cross posted to.
Thanks in advance.
regards,
->Gerry Schenk
->gsc...@wimsey.com
In support of Unix, this is what I can see.
1. It is very progressive. The OS has been around for 20 years and
foundations of the Internet are based on Unix. It has a lot of support
and is a very open system.
2. I can add practically anything to our Sparcs. In our shop, I have
used a variety of drives. Drive selection is based on price, availability,
speed and cache. I've added modems (Practical Peripherals, USR),
printers (HP 3D, 4SIMX, dot matrix), terminals(Wyse 60s), drives
(Seagate, Micropolis, Fast Wide - 20MBs), tape drives (DLT, 8MM, 4MM,
QIC).
3. Software. Ton of software from the Internet. eg. Cern's
httpd(has proxy capabilities with caching), Tpage(pager software that
allows us to page if a process or machine is down), various editors, ftp
utilities(ncftp), gnu tools (grep, gcc, rcs), news software(inn and cnews),
mail software (pop2, pop3, pine, elm, sendmail, smail), time sync
software(ntp), perl(scripting language), faxing software(hylafax), comm
software(uucp, ecu, kermit), compression software(gzip, pkzip, and pkzip
compatible unzip and zip). Plus many more.
4. Reliability. Our Sparc IPX with 64M RAM, 7G of disk, 2 SCSI
controllers and has been in operation since 1991. In
that time we've only had one serious problem and that was caused by the
power supply on the external case that we put two drives into. Other
than that it has been working reliably. It is running SunOS 4.1.3 and I
am inclined not to upgrade it to SunOS 4.1.4 because it works. It has
been a little work horse.
We also have a Sparc 1000 with 320M RAM, 60G of disk, 2 system boards,
4 CPUs and 6 SCSI controllers. The problems we've had included two
power supplies which gave out. One time the power supply went out at
9:00am on a Sunday and Sun had it repaired by 2:00pm the same day.
Other problems have been mainly with hard drives that we have added.
One of the problems involved a bad batch of drives from the manufacturer
and the other involves heat.
Our biggest problem has been that we didn't anticipate the amount of data
that were going to store. As a result, we have 18 seperate drives, where
we should have RAID.
The majority of the arguments that I have heard for the AS/400 is that it
is a Business box, it is more reliable and that you don't need the
same amount of support staff that is required for Unix.
As for the business part of the box, the AS/400 is certainly being
promoted that way. As for reliability, I feel it is just what you put
into the box. As for support, it depends on how you want to pay for it.
You either have it internally or you pay for it through service
contracts. We don't have a large staff. To service the boxes, we
basically have 1 sysadmin and 1 dba, and neither of us is 100% system admin.
***** Start of original post *****************
We have been using Unix since 1991, primarily SunOS 4.1.x and Solaris
2.x. Obviously our experience base is with Unix and Oracle, not with
RPG, DB2 and AS/400s.
The intent of this post is not to start a flame war, but rather get some
opinions on the strengths and weeknesses of the AS/400 vs. UNIX.
I work for a company that has a 150 retail locations. Our primary
platform at the store is Novell, with the Head Office system on Sun
Sparcs, which includes a Sparc 1000 running Oracle 7.
Most of the applications and reports have been developed in house,
written primarily in C and Uniface. This includes the Purchase Order
System and inventory control.
Recently a new VP of Finance was hired on, who is in charge of the IS
group. This new individual is very much against development and much
prefers "canned" packages. As such all development has pretty much
stopped. He is also familiar with IBM's AS/400 and wants to replace the
existing system with a AS/400 package. His complaint about the current
system is that it lacks proper inventory control. This is something that
we were working towards, but the project was cancelled.
We've had discussions about this and he is convinced that the AS/400 is
more popular, that packages on the AS/400 are less expensive and more
readily available. He claims that he cannot find a reasonably priced
Inventory Control UNIX based package.
I have very little exposure with an AS/400. What are the pros and cons
of the AS/400 vs. UNIX. I'd appreciate any feedback.
Thanks in advance.
Mark Woodruff
>It has a relational database built in, literally part of it is in
>hardware, at no additional cost and it is FAST.
One SQL statement/second is fast?
>As for stable, they just do not go down.
Except for those unfortunate to leave theirs on without re-IPling once
a week who run out of pointers and find their system trashed.
In a world of Yugos, I guess a Fiat is an improvement.
Mark Woodruff
Simple. The AS/400 works for most business applications. Customers can
buy it, have it set up, learn how to use it, and use it successfully.
That it works poorly does not matter; it works.
Unix, on the other hand, is difficult to set up and manage even for
experts, and impossible for mere mortals. Purchasing a Unix system
and business software means coordinating perhaps a dozen suppliers and
acquiring a small army of experts to get it to work.
It would be nice if IBM and the AS/400 went away. But they won't. Maybe
never.
Tom Haapanen
wood...@netcom.com (Mark Woodruff) writes:
> Unix, on the other hand, is difficult to set up and manage even for
> experts, and impossible for mere mortals. Purchasing a Unix system
> and business software means coordinating perhaps a dozen suppliers and
> acquiring a small army of experts to get it to work.
Or you buy your system and software from a systems integrator (like you
HAVE TO do with an AS/400). They'll buy your hardware, buy your software,
install the software and set up the machine at your office. After that
all people ever see are the "login:" prompt and tne business applications --
there is no need to ever give an end user a shell prompt.
There are hundreds of thousands Unix systems being used like this throughout
the world. Millions of people don't even *know* they're using Unix, and
their systems just keep running like the Energizer bunny without any need
to hire Unix gurus.
> It would be nice if IBM and the AS/400 went away. But they won't. Maybe
> never.
Maybe not. But it's a fallacy that a Unix system has to be hard to use,
or that it requires a knowledgeable sysadmin in the company.
--
[ /tom haapanen -- to...@metrics.com -- software metrics inc -- waterloo, ont ]
[ "it is not enough to have a good mind. ]
[ the main thing is to use it well." -- rene descartes ]
Christopher Robato
ites:
:>
:>Last week I posted the article "AS/400 vs Unix. It has been very
:>have been a Unix/Novell shop for the last 5 years, running Oracle 6 and
:>Oracle 7. After reading the posts, I'm not convinced that the AS/400 is
:>any better than Unix. The majority of the posts have concentrated on the
:>hardware side and reliability. From what I can see there is not
:>much of a difference.
:>
:>Having read the arguments, I more curious about the application side.
:>What makes the AS/400 and DB2 more attractive than Unix and Oracle.
:>
:>We are running on Oracle 7.1.6, soon to be 7.2. We have been running in
:>a client server shop with Windows 3.1, using Uniface, Power Builder and
:>Objectview.
:>
:>We are looking for a Inventory Control/Merchandising system, that can
:>support 150 locations running Novell, where the data is batched through a
:>nightly DOS process back to the Head Office. Currently JDA's MMS running
:>on the AS/400 is the favorite.
:>
:>Perhaps someone can answer the following questions.
:>
:>1. Are there more Business applications on the AS/400 than
:>there is on Unix?
25,000, possibly 30,000 applications versus about 10,000 for Sun or AIX.
:>
:>2. Are the costs for these types of applications typically more or less
:>on these types of systems?
My AS/400 application actually costs less than a similiar system for SCO
Unix. Quite depends from vendor to vendor and the number of users.
:>
:>3. Any recommendations on either AS/400 applications or Unix
:>applications. For the Unix applications, it would be preferable that
:>they run with Oracle.
:>
:>4. What kinds of Retail locations are running Unix and Oracle. I've
:>heard or read that Starbucks, Walmart and Home Depot are using AS/400s.
:>
That's true. So is Duty Free Shoppers around the world, and the top retail
businesses in my area.
:>I look forward to the all the excellent responses.
:>
:>Below is some of my thoughts on why Unix is better. Below that is the
:>original post, which I've included for the benefit of the readers of the
:>Oracle newsgroup, which I've cross posted to.
:>
:>Thanks in advance.
:>
:>regards,
:>
:>->Gerry Schenk
:>->gsc...@wimsey.com
:>
:>
:>In support of Unix, this is what I can see.
:>
:>1. It is very progressive. The OS has been around for 20 years and
:>foundations of the Internet are based on Unix. It has a lot of support
:>and is a very open system.
You should see how progressive OS/400 is. How about an object oriented
design and architecture, with microkernel. An interface built on hypertext
links. 64 bit architecture, data sizes and addressing capability. Single
level store, for instance, allows it to suspend threads or processes in
operation, shut down the machine, and continue the process later (like a
month from now). It now has 70 to 80% of Open Unix calls too.
For protocols it will support SNA/APPC/APPN, TCP/IP, outright; NetBIOS
/NetBEUI through LanServer/400 and the FSIOP, and later hopefully with IPX
using Netware 4.1.
IBM is now moving various internet software and utilities into the AS/400,
like the ability to be a Web server. They also got plans to turn the AS/400
into a Notes server as well.
The bundled Client Access/400 software allows immediete hookup to DOS,
Windows, and OS/2 clients, including ODBC support and for OS/2 stations with
DB2/2 v2, DRDA and synchronous updates.
AS/400s also mesh well with existing Unix sites. I heard of places that run
such mixed environs.
:>
:>2. I can add practically anything to our Sparcs. In our shop, I have
:>used a variety of drives. Drive selection is based on price, availability,
:>speed and cache. I've added modems (Practical Peripherals, USR),
:>printers (HP 3D, 4SIMX, dot matrix), terminals(Wyse 60s), drives
:>(Seagate, Micropolis, Fast Wide - 20MBs), tape drives (DLT, 8MM, 4MM,
:>QIC).
:>
:>3. Software. Ton of software from the Internet. eg. Cern's
:>httpd(has proxy capabilities with caching), Tpage(pager software that
:>allows us to page if a process or machine is down), various editors, ftp
:>utilities(ncftp), gnu tools (grep, gcc, rcs), news software(inn and cnews),
:>mail software (pop2, pop3, pine, elm, sendmail, smail), time sync
:>software(ntp), perl(scripting language), faxing software(hylafax), comm
:>software(uucp, ecu, kermit), compression software(gzip, pkzip, and pkzip
:>compatible unzip and zip). Plus many more.
:>
Unix can't be beat for free software. To ask for free software for the
AS/400 is like begging for free parts from your Mercedes Benz or Cartier
dealer. Good luck.
:>4. Reliability. Our Sparc IPX with 64M RAM, 7G of disk, 2 SCSI
:>controllers and has been in operation since 1991. In
:>that time we've only had one serious problem and that was caused by the
:>power supply on the external case that we put two drives into. Other
:>than that it has been working reliably. It is running SunOS 4.1.3 and I
:>am inclined not to upgrade it to SunOS 4.1.4 because it works. It has
:>been a little work horse.
:>
I have heard of AS/400s that never went down since they went up in 1989.
It's predecessor is even a tougher bitch---there are System 36s that hasn't
gone down for more than a decade. The base of such machines are still
significant, more than 200,000 of these System 36s, 38s and 34s, and the
users just won't give them up.
:> We also have a Sparc 1000 with 320M RAM, 60G of disk, 2 system boards,
:>4 CPUs and 6 SCSI controllers. The problems we've had included two
:>power supplies which gave out. One time the power supply went out at
:>9:00am on a Sunday and Sun had it repaired by 2:00pm the same day.
:>Other problems have been mainly with hard drives that we have added.
:>One of the problems involved a bad batch of drives from the manufacturer
:>and the other involves heat.
:>
:>Our biggest problem has been that we didn't anticipate the amount of data
:>that were going to store. As a result, we have 18 seperate drives, where
:>we should have RAID.
:>
:>The majority of the arguments that I have heard for the AS/400 is that it
:>is a Business box, it is more reliable and that you don't need the
:>same amount of support staff that is required for Unix.
:>
True true. The only thing easier to use in the world is a Macintosh. I
personally find the AS/400 easier to set up and use than a *PC*.
:>As for the business part of the box, the AS/400 is certainly being
:>promoted that way. As for reliability, I feel it is just what you put
:>into the box. As for support, it depends on how you want to pay for it.
:>You either have it internally or you pay for it through service
:>contracts. We don't have a large staff. To service the boxes, we
:>basically have 1 sysadmin and 1 dba, and neither of us is 100% system admin.
:>
That's more than enough. He does have to unlearn a lot of things about Unix,
since the AS/400 can be a culture shock. You have to understand the system
in terms of an object oriented paradigm, like everything in the system are
encapsulated objects that you don't hack at. A lot of system implementations
are hidden because of the paradigm, and security is extremely tight, with
every object given a security tag.
:>
:>***** Start of original post *****************
:>
:> We have been using Unix since 1991, primarily SunOS 4.1.x and Solaris
:>2.x. Obviously our experience base is with Unix and Oracle, not with
:>RPG, DB2 and AS/400s.
:>
:>The intent of this post is not to start a flame war, but rather get some
:>opinions on the strengths and weeknesses of the AS/400 vs. UNIX.
:>
:>I work for a company that has a 150 retail locations. Our primary
:>platform at the store is Novell, with the Head Office system on Sun
:>Sparcs, which includes a Sparc 1000 running Oracle 7.
Novell is a headache.
:>
:>
:>Most of the applications and reports have been developed in house,
:>written primarily in C and Uniface. This includes the Purchase Order
:>System and inventory control.
That's similar to what I have.
:>
:>Recently a new VP of Finance was hired on, who is in charge of the IS
:>group. This new individual is very much against development and much
:>prefers "canned" packages. As such all development has pretty much
:>stopped. He is also familiar with IBM's AS/400 and wants to replace the
:>existing system with a AS/400 package. His complaint about the current
:>system is that it lacks proper inventory control. This is something that
:>we were working towards, but the project was cancelled.
Inventory Control is the AS/400's hidden name. Lots and lots of packages out
there, some very specific to the type of retail operation you have (drug
store, jewelry store, video rental,)
:>
:>We've had discussions about this and he is convinced that the AS/400 is
:>more popular, that packages on the AS/400 are less expensive and more
:>readily available. He claims that he cannot find a reasonably priced
:>Inventory Control UNIX based package.
:>
AS/400 software can be cheaper because they are not as a big as a headache
compared to Unix packages in terms of support and maintenance. Just my
opinion.
:>I have very little exposure with an AS/400. What are the pros and cons
:>of the AS/400 vs. UNIX. I'd appreciate any feedback.
:>
Email me, if you wish to know more.
:>Thanks in advance.
:>
:>->Gerry Schenk
:>->gsc...@wimsey.com
:>
:>
*>>>Vote OS/2 for Presidential OS, Campaign '96<<<*
***** cro...@kuentos.guam.net *****
>>>> (On FUD) I came, I saw, I countered. <<<<
[[[ Anime .sig follows ]]]
"Seigi no Senshi, Sailor Fuku bishoujo senshi, Sailor Venus!"
"Sanjyo Yo!"---Minako Aino, Code Name wa Sailor V!
NUTMEG-EUROPE
>
>>4. Spool file control on the AS/400 is very sophisticated. For
>> instance, you suspense a print job, restart at a different page,
>> transfer to a different printer, print equally well on a page
>> printer or a dot-matrix printer without reprogramming, etc.
>> Standard unix can emulate some of these features only by
>> stringing together a bunch of utilities - very tough to teach to
>> a computer operator.
>
>applications, but noawadays even mundane things like printing the contents of
>some log file or script report are dumped through an N-up thingy that creates
>PostScript output.
It doesn't print post script ! It may be more sophisticated, but a
print job is a print job, it's very difficult to turn it into a
file, or back again. Spool jobs contain all kinds of instructions
to the printer. Unix is far better in this respect of an output
file being just a file rather than having a seperate entity for
output.
>
>>5. AS/400 spreads each of its files across all the available
>> disks. Thus IO is always shared equally among all the disks. This
>> help to improve interactive programs response time greatly. This
>> feature is a double edge sword.
>
>I'm sure this sort of "striping" is available in many UNIXes, so you have to
>consider which UNIX incarnation you are talking about.
The point is, if you add another disk, the file system will spread
itself onto that disk, so that all disks are running at equal
levels of 'disk used', partitons aren't fixed.
Nutmeg-Europe Ltd, Northampton, England.
Tel : +44 (0)1604 595900
Fax : +44 (0)1604 595907
Dennis Weiner
Its not as/400 vs unix
DB2 vs Oracle
open vs proprietary
Last year the prediction was that unix dominates in the year 2020.
This year i'm not so sure. It does not matter who's hardware or
software is superior.
IT's Bill and Client Server that will dominate.
peter hakanson
: >
: >>5. AS/400 spreads each of its files across all the available
: >> help to improve interactive programs response time greatly. This
: >> feature is a double edge sword.
: >I'm sure this sort of "striping" is available in many UNIXes, so you have to
: >consider which UNIX incarnation you are talking about.
: The point is, if you add another disk, the file system will spread
: itself onto that disk, so that all disks are running at equal
: levels of 'disk used', partitons aren't fixed.
Ok. So after adding some drives and one of them fails you have
to reload ALL your backups. Funny!
We did that in the 70-s on hp-3000 who also (by default) spread all
files on all available disks. Also very difficult to replace a drive
(you might find a drive with lower maintanance costs ..)
I'll keep my files where i know they are...
: Nutmeg-Europe Ltd, Northampton, England.
: Tel : +44 (0)1604 595900
: Fax : +44 (0)1604 595907
--
--
Peter Hakanson VolvoData Dep 2580 phone +46 31 66 74 27
Joel Garry
>mckn...@rbdc.rbdc.com (Michael McKnight) writes:
>>
>>A parting word... If they force you to an AS/400, they should
>>give you a substantial pay raise or you should RUN.
>>
>Ah, but they won't! One of the attractions of the 400 (to our VP
>of Finance) is that it takes a smaller, and less highly-paid, staff.
>They also have little use for highly-paid "Open Systems Consultants".
That's interesting, in most mature technologies the staff is highly
paid because all the hot-shots have left for what's hot. Creates
a scarcity of workers in the old stuff, especially in a situation where
there is a backlash against the new stuff.
>
>Moving to an AS/400 may be a good business decision for your company.
That's difficult to defend in todays business environment of
re-engineering, rightsizing, market adaptability, or whatever.
>It's unlikely to be career-enhancing for you.
Hey, some people make an entire high paid career out of maintenance programming.
My experience tells me to stick around, see what happens, could be
resume enhancing if nothing else. There may be more opportunities in
the future porting from stupid canned apps on AS400's to Solaris custom
C/S... although, if the guy is that much of a stick-in-the-mud, don't
try to get a raise by playing off another job opportunity. Once an empire
builder gets the scent that you might be looking around, you're history. They
just might not tell you right away.
>--
>
>Bob Shair Open Systems Consultant
Dang, that's what I shoulda called myself when I was an independent.
jg
>1018 W. Springfield Avenue rms...@uiuc.edu
>Champaign, IL 61821 217/356-2684
--
Joel Garry joe...@rossinc.com Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc. <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push. \ V /
panic: ifree: freeing free inodes... O
Larry Loen
This calls for a little story. I admit I work for IBM in Rochester,
so feel free to discount for that, but I mostly work in the lower layers
of the system and so when it comes to signing on and using the system,
I have no real advantage over anyone reading these words, except maybe
that I have used well over 1/2 dozen operating systems, not all of which
came from IBM and some prior experience with S/38.
I was running a test and had my choice of three platforms:
1. PC
2. VM
3. AS/400 (back before its initial release).
I had also MVS to choose from, but I didn't happen to have a signon
at the moment. AIX was possible, also, but I didn't know it well
enough; I might not even have had a signon yet, because I still had
a PC and not an AIX workstation in those days.
It was a Sunday (this work really needed to get done _now_).
Now, I had never signed on to an AS/400, though I had done work on
S/38.
But, the AS/400 did have significant differences in its user interface
over the S/38 and this turned out to matter.
I took a tape which consisted of binary data in two files. What I wanted
to do was read in the 32 bit words, sort them as words, and then compare
them (a la "diff" for you Unix hounds).
I defined the file as a series of 32 bit binary words, though it was
4K records on the tape. I don't think I needed DDS.
I created the file and read it in. I may have had to "reblock"
the records somewhere else first; I forget. But, I think I managed
to handle the blocking at the AS/400 somehow.
Anyway, I had it on AS/400.
I first tried AS/400 SQL. Turns out, I knew nothing of SQL and hoped
to learn enough to do what I needed to do (it was a very basic,
binary level sort).
Didn't happen. SQL is not something I could learn ,very casually, on
a Sunday afternoon with no manuals and no gurus in to guide me.
I then switched to Query/400.
I was able, using its online help text alone, able to take the file and
do the sort.
I think I was then able to do quite a bit of the file comparison also
using Query one way or another. The job was done or very nearly so
all on a machine I had never used before.
Consider:
1. I had never signed on to an AS/400 before, though I had some S/38
knowledge. Just enough to get started. The key facts I knew were to
use PF4 for prompts and PF1 for help (including context sensitive help).
This is what really mattered, especially when blundering around, looking
for commands that might help me.
2. I had not used S/38 Query in years, if ever, and certainly never
used AS/400 query.
3. I was able to get the job done without any manuals whatsoever on a
machine I had only a basic understanding of with no help.
4. I had not just a "programming" interface to deal with, but an
"operator" set of interfaces while I played tape jockey. Admittedly,
the S/38 knowledge helped on the latter, but the interface was still quite
different in appearance.
5. I wasn't particularly looking to use AS/400. If it could have been
managed faster, I'd have picked another of the platforms; in fact, I may
well have done some of the tasks (e.g. reblocking the tapes) on other
platforms. I was picking the machine where I could get the job done
fastest and AS/400 (I thought) could indeed do this job, even though I
had never used it before.
I could not do this with VM's Query By Example.
I don't know if I could do this with Sybase or Oracle.
I could not do this if all I had to work with was SQL verbs on any machine
(including AS/400).
Yet, I got the job done. I admit I blundered around quite a bit,
but I still got it done.
I was very impressed, being able to get the main meat done without any
programming (something I could not do elsewhere).
Now, I probably could figure out (now) how to do such a thing on Unix.
That's not the point. The point is, using little more than PF4 and PF1,
I worked through a process of medium difficulty on an unfamiliar computer.
To this day, I use AS/400 for tasks of that kind whenever I can't figure
it out elsewhere.
I am very certain that on my first AIX signon, I could not possibly have
done something like this. In fact, _I_ may not be able to do it today
due to the binary nature of the data.
I don't know if that's reason enough to buy the machine, but it illustrates
what some have been saying; what it does, it does very well and it is
pretty easy (once one knows a few very basic facts of navigation) to find
out how to do something.
Dan Hicks
>
>: >
>: >>5. AS/400 spreads each of its files across all the available
>: >> help to improve interactive programs response time greatly. This
>: >> feature is a double edge sword.
>: >I'm sure this sort of "striping" is available in many UNIXes, so you have to
>: >consider which UNIX incarnation you are talking about.
>
>: The point is, if you add another disk, the file system will spread
>: itself onto that disk, so that all disks are running at equal
>: levels of 'disk used', partitons aren't fixed.
>
>Ok. So after adding some drives and one of them fails you have
>to reload ALL your backups. Funny!
>
>We did that in the 70-s on hp-3000 who also (by default) spread all
>files on all available disks. Also very difficult to replace a drive
>(you might find a drive with lower maintanance costs ..)
>
>I'll keep my files where i know they are...
Well, to handle disk failure, AS/400 has had RAID (originally called
"checksumming" and done in software) since it's original release. Plus
now there's "hardware" (ie controller microcode based) RAID and
mirroring. And if you insist on specifying which disk your data is on
you can do that with access groups.
Dan Hicks
http://www.millcomm.com/~danhicks/
Garry Garrett
>mckn...@rbdc.rbdc.com (Michael McKnight) writes:
>>
>>The 400 is a whole new world compared to UNIX. Sure, big blue
>>is opening the machine up, but remember, IBM has their own
>>definition of "open." They have a long, long way to go.
>
>For example, no one has yet ported Kermit to the AS/400. Can't
>blame IBM for that; just a sign of where the 400 lives.
>
I'll give you another example. Their TCP/IP package says it
does NFS. IBM's idea of NFS is that it will be the NFS server
to everyone else (i.e. NFS server, but no NFS client software).
Further more, the files are exported in EBCDIC (a bit of a pain,
but considering the rest of the NFS world speaks ASCII, you would
think they could have taken it into account...). They don't
support PC-NFS. They did an okay job on FTP and TELNET (though
they seem to have done a lousy job with maping PF keys). I
haven't tried the SMTP or LPD stuff yet. Anyway, back to the
point, I think that the server but no client software is typical
of IBM's attitude that their computers are (or should be) the
hub of your architechture and that the is nothing else of value
anywhere else on the network. It's pretty short sighted if you
ask me.
--
Garry....@abii.com
(don't send big files here, write me for another address) ._o
*** I don't speak for ABI Inc. |>
*** I get into enough trouble speaking for myself! 4
Vincent LeVeque
of use, in my most recent UNIX shop, every programmer had a "cheat
sheet" of UNIX commands posted on their cubicle wall. This is a group
which works with this system day in and day out. In no AS/400 shop have
I seen this. I think this says a lot about the ease of use of the
command interface of these systems.
Vil...@cus.cul.ca
>Ok. So after adding some drives and one of them fails you have
>to reload ALL your backups. Funny!
>
>We did that in the 70-s on hp-3000 who also (by default) spread all
>files on all available disks. Also very difficult to replace a drive
>(you might find a drive with lower maintanance costs ..)
>
>I'll keep my files where i know they are...
I guess that it would seem that way Peter. In my experience, what happens is that the
excellent error reporting facililities on the AS/400 report a problem well before it becomes
catastrophic. The low level DST functions allow you to do DISK to DISK copies, or Disk to Tape
back to DISK again.
Another niceness, The new disk doesn't have to be the same size as the old one - just as long as
its not smaller. I don't think thats necessarily true on UNIX.
I have 4 systems * 5 years, about 6 disk failures - where failure is defined as too many
temp. errors for my taste. Never a single lost byte, and thats the bottom line!
Villy G. Madsen
Technical Consultant
Canadian Utilities Ltd
403-420-5093
Vincent LeVeque
Vincent LeVeque
Kazimir Kylheku
>In <4dgp1t$h...@nike.volvo.se>, pe...@cyklop.volvo.se (peter hakanson) writes:
>
>>Ok. So after adding some drives and one of them fails you have
>>to reload ALL your backups. Funny!
>>
>>We did that in the 70-s on hp-3000 who also (by default) spread all
>>files on all available disks. Also very difficult to replace a drive
>>(you might find a drive with lower maintanance costs ..)
>>
>>I'll keep my files where i know they are...
>
>I guess that it would seem that way Peter. In my experience, what happens is that the
>excellent error reporting facililities on the AS/400 report a problem well before it becomes
>catastrophic. The low level DST functions allow you to do DISK to DISK copies, or Disk to Tape
>back to DISK again.
Who needs some "DST function", when your block devices appear as ordinary
files under UNIX? I can easily copy one disk image to another, provided that
the destination can hold the whole thing. Under linux, just do a
cp /dev/hda /dev/hdb to copy one hard disk to another that is at least as big.
With dd, you can copy selected ranges of blocks.
>Another niceness, The new disk doesn't have to be the same size as the old one - just as long as
>its not smaller. I don't think thats necessarily true on UNIX.
It is. Though the resulting filesystem will be limited to the old size.
(unless you take some fs-specific steps to expand the thing).
You don't need any special stupid commands, either. Just a regular file copy
will do the trick, though wizards prefer to use dd.
Oh, and by the way, splitting filesystems across multiple volumes is even
available for Linux, which is GPLed freeware. Big deal!
--
Ingo Liessegang
> Well, to handle disk failure, AS/400 has had RAID (originally called
> "checksumming" and done in software) since it's original release. Plus
> now there's "hardware" (ie controller microcode based) RAID and
> mirroring. And if you insist on specifying which disk your data is on
> you can do that with access groups.
>
> Dan Hicks
> http://www.millcomm.com/~danhicks/
You mean Auxiliary Storage Pool (ASP), not access groups. You can have 16 of them,
that should be enough.
Ingo Liessegang
Steyr-Daimler-Puch Fahrzeugtechnik AG, Graz, Austria
Kazimir Kylheku
Are you sure these were programmers? I have never seen a programmer have a
cheat sheet on the wall in any "shop", though things like that are sometimes
set up for average users. These must have been extreme begginers unaccustomed
to UNIX. You say that every cubicle had a cheat sheet, which suggests that it
was not the programmers themselves who set up these cheat sheets, but perhaps a
manager concerned about those programmers who are inexperienced in the use of
the system.
For one thing, any reasonable programmer would put the cheat sheet into a text
file, which can at least be searched for patterns. Of course, exploiting the
versatility of text files doesn't readily suggest itself to UNIX newcomers.
Why don't we drag out a few UNIX commands and their AS/400 equivalents (in the
fortunate cases where there actually _are_ equivalents)?
--
Jeffrey Altman
Garry Garrett <Garry....@abii.com> wrote:
>In article <4d5vot$p...@vixen.cso.uiuc.edu>, Bob Shair <rms...@uiuc.edu> wrote:
>>mckn...@rbdc.rbdc.com (Michael McKnight) writes:
>>>
>>>The 400 is a whole new world compared to UNIX. Sure, big blue
>>>is opening the machine up, but remember, IBM has their own
>>>definition of "open." They have a long, long way to go.
>>
>>For example, no one has yet ported Kermit to the AS/400. Can't
>>blame IBM for that; just a sign of where the 400 lives.
>>
Actually you can. If IBM wanted a Kermit port available on the AS/400
there are several avenues they could go about to get one.
(1) contract to have it done
(2) allow one of their developers to port Kermit with Columbia assistance
(3) encourage its development through donations of equipment and software
Jeffrey Altman * PO Box 220415 * Great Neck, NY * 11022-0415 * (516) 466-5495
* 612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344
C-Kermit 5A(191) for OS/2: http://www.columbia.edu/kermit/cko191.html
Kermit 95 for Windows 95 : http://www.columbia.edu/kermit/k95.html
Dan Hicks
>You mean Auxiliary Storage Pool (ASP), not access groups. You can have 16 of them,
>that should be enough.
Right. I always get those terms confused.
Dan Hicks
http://www.millcomm.com/~danhicks/
Ooi SC
>In message <4dc12i$q...@vanbc.wimsey.com> - gsc...@wimsey.com (Gerry Schenk) wr
>ites:
>:>1. Are there more Business applications on the AS/400 than
>:>there is on Unix?
>
>25,000, possibly 30,000 applications versus about 10,000 for Sun or AIX.
I once read somewhere that the AS/400 applications range from coffins
to zoo management. I suspect the writer omitted A and B because C for
coffins sounds more spectacular.
>:>2. I can add practically anything to our Sparcs. In our shop, I have
>:>used a variety of drives. Drive selection is based on price, availability,
>:>speed and cache. I've added modems (Practical Peripherals, USR),
>:>printers (HP 3D, 4SIMX, dot matrix), terminals(Wyse 60s), drives
>:>(Seagate, Micropolis, Fast Wide - 20MBs), tape drives (DLT, 8MM, 4MM,
>:>QIC).
Will some AS/400 marketing bigshots take note of this.
>Unix can't be beat for free software. To ask for free software for the
>AS/400 is like begging for free parts from your Mercedes Benz or Cartier
>dealer. Good luck.
Oh yes, Unix is beaten by PCs for free software. There certainly are
far less free software for the AS/400. I can think of only QUSRTOOLS
(which is no longer free from V3R1 onwards unless you retrieve the old
version and compile it yourself) and utilities from News/400.
Perhaps someone on this newsgroup can contribute an ftp site and the
rest of us can contribute some of our software.
>:>4. Reliability. Our Sparc IPX with 64M RAM, 7G of disk, 2 SCSI
>:>controllers and has been in operation since 1991. In
>:>that time we've only had one serious problem and that was caused by the
>:>power supply on the external case that we put two drives into. Other
>:>than that it has been working reliably. It is running SunOS 4.1.3 and I
>:>am inclined not to upgrade it to SunOS 4.1.4 because it works. It has
>:>been a little work horse.
>I have heard of AS/400s that never went down since they went up in 1989.
>It's predecessor is even a tougher bitch---there are System 36s that hasn't
>gone down for more than a decade. The base of such machines are still
>significant, more than 200,000 of these System 36s, 38s and 34s, and the
>users just won't give them up.
>
I wonder if the reliability info on the Sparc include dbms-related
software crashes. It is my impression that an ORACLE db requires far
more dba effort than a DB2/400 db.
>That's more than enough. He does have to unlearn a lot of things about Unix,
>since the AS/400 can be a culture shock. You have to understand the system
>in terms of an object oriented paradigm, like everything in the system are
>encapsulated objects that you don't hack at. A lot of system implementations
>are hidden because of the paradigm, and security is extremely tight, with
>every object given a security tag.
I agree that going to the AS/400 can be a culture shock but it is not
veryt big. I went through that transition and I only miss the ease of
development on unix boxes. However, the extra reliability of the
AS/400 is a reasonable trade-off.
Mark Woodruff
>There is almost no similarity between the AS/400 and mainframes (MVS).
Funny. OS/400 is *VERY* close to OS/360 MVT. They renamed everything,
but the concepts and design are identical is most respects. It's
a truly pathetic operating system with perhaps five good ideas in it
total.
>Hardware, data management, user interfaces, everything else I can think
>of that you see on a day-to-day basis is different.
The 5250's are 3270's with reduced functionality. The panel manager is
PDF with reduced functionality. The file system is much more primitive
(reminds me of RPS on the Series/1). Okay, so we have printer files
rather than Data Definitions. But OS/400 really is MVT stripped with
a handful of features added.
>If you want to connect from a TCP/IP device to an AS/400, use any of
>the widely available (even public domain) TN5250 emulators.
As long as you don't want to transfer files, perhaps. But if you do,
you'll spend fifteen minutes fiddling with libraries, files, and
documents.
>If you want the legendary IBM quality,
Legendary as in it doesn't exist? Peel off the labels on those drives
and see who really made them. IBM couldn't match the reliability or
performance of its competitors until very recently, so it bought their
drives and relabeled them.
>Not everybody wants 'open'. I'll probably be burned for heresy, but
>there are still an awful lot of DP managers and financial executives
>who want reliability at a reasonable cost.
Most of whom would really be much happier with typewriters.
>And, if you're a hacker, you'll still have plenty of stuff to do late
>at night. Once you get the apps up and running, the AS/400 will pretty
>much take care of itself. Give you more time to play with Windows and
>try to remember what grep stands for.
Only developing for the 400 is 100-1000 times slower than developing
for any other platform. I've never seen a system that takes as long
to edit and save a file as the AS/400. Ever the 256K Series/1s were
faster!
>I've managed data centers that have both AS/400 and Unix systems
>installed. The AS/400's are more expensive initially, but they cost *A
>LOT* less to support. The applications seem to cook right along, while
>the Unix boxes are always surrounded by programmers on Monday morning.
How many different applications were being developed on those AS/400?
The reasons the AS/400 has such low maintenance costs is because it is
performs so poorly that after the application it was bought for is
installed, no one touches it.
Productivity is more important.
Roger Marquis
>Unix, on the other hand, is difficult to set up and manage even for
>experts, and impossible for mere mortals. Purchasing a Unix system
>and business software means coordinating perhaps a dozen suppliers and
>acquiring a small army of experts to get it to work.
It may be difficult to setup some Unix systems exactly the way you want
them but depending on your needs they should require very little
ongoing management once properly configured.
I have almost a dozen customers using Unix servers as Internet
firewalls, mail servers, web servers, file servers, print servers,
etc. Sometimes they don't even know they have a Unix server on the
network. Most of these sites have no Unix system administrator.
Often nobody has an account on the server. These systems run
unattended for months at a time. On the rare occasion when there is a
problem they call me, I dial-in or telnet in, and fix it.
What other operating system has this much flexibility?
Roger Marquis
Vincent Leveque
of vi (not UNIX per se, but still a standard part of it). These were
not beginners, either. vi was the only text editor in use in this shop
(unfortunately), so these folks were using it all the time & STILL
needed the hardcopy reminder. While vi may be more obscure than the
UNIX command interface, neither one is particularly intuitive (IMHO).
Unfortunately, UNIX shops without a good windowing front end are stuck
with the command line interface. Many commercial installation fall into
this category.
This may be an extreme example, but I do consider it indicative of the
difficulty of remembering the names and syntax of UNIX commands (vs.
AS/400).
I haven't programmed an AS/400 full time for many years, but I can still
find my way around SEU without referring to a manual.
Of course, a good GUI-based source code editor would easily beat both vi
and SEU.
Marc Salvatori
> You should see how progressive OS/400 is. How about an object oriented
> design and architecture, with microkernel.
OS/400, an object-"based" kernel, I can understand. But object-oriented?
Hmmmm. Please expand on your thoughts here. An object-oriented kernel
should allow you to add modules without the need to re-IPL, let alone
reconstruct the kernel package.
--
>< Marc J. Salvatori |
><
>< sa...@eskimo.com | MIME & NeXTMail are accepted
><
Dan Hicks
>In <4dqfbo$j...@ixnews8.ix.netcom.com>, tmc...@ix.netcom.com(Tom McCann ) writes:
>>There is almost no similarity between the AS/400 and mainframes (MVS).
>
>Funny. OS/400 is *VERY* close to OS/360 MVT. They renamed everything,
>but the concepts and design are identical is most respects. It's
>a truly pathetic operating system with perhaps five good ideas in it
>total.
You're mostly wrong, though there is a grain of truth to what you say.
Unfortunately the "mother duck" syndrome was in effect for the original
S/38 developers, so certain aspects of the system (spool, SEU, some
aspects of the job structure, etc) were copied from existing IBM
systems. It's pretty far-fetched to say OS/400 and MVT are "identical
in most respects", howeever.
>>Hardware, data management, user interfaces, everything else I can think
>>of that you see on a day-to-day basis is different.
>
>The 5250's are 3270's with reduced functionality.
Actually, 5250s have MORE functionality than the 3270s that were
developed at about the same time -- the ability to force an input field
to be upper case, force one to be numeric, etc. Of course, what they
WERE copied from is the old card record equipment, but the features that
were copied were (and are) very important features from an operator
productivity point of view.
I don't think anyone will argue, though, that the AS/400 desperately
needs a new display protocol.
Dan Hicks
http://www.millcomm.com/~danhicks/
Christopher Robato
:>
:>In <4dqfbo$j...@ixnews8.ix.netcom.com>, tmc...@ix.netcom.com(Tom McCann ) writes:
:>>There is almost no similarity between the AS/400 and mainframes (MVS).
:>
:>Funny. OS/400 is *VERY* close to OS/360 MVT. They renamed everything,
:>but the concepts and design are identical is most respects. It's
:>a truly pathetic operating system with perhaps five good ideas in it
:>total.
:>
You sure? Every thing I have seen shows OS/360 to be as different from
OS/400 as anything possible. In fact, nothing on this Earth, including all
the non-IBM OSes ever made, is as different from OS/360 as OS/400. The sheer
architecture and its very concept alone---from the very root of OS/400---is
diametrically different from OS/360.
Don't confuse SAA interface guidelines as any sort of familiarity between
OS/360 and OS/400.
:>>Hardware, data management, user interfaces, everything else I can think
:>>of that you see on a day-to-day basis is different.
:>
:>The 5250's are 3270's with reduced functionality. The panel manager is
:>PDF with reduced functionality. The file system is much more primitive
:>(reminds me of RPS on the Series/1). Okay, so we have printer files
:>rather than Data Definitions. But OS/400 really is MVT stripped with
:>a handful of features added.
:>
:>>If you want to connect from a TCP/IP device to an AS/400, use any of
:>>the widely available (even public domain) TN5250 emulators.
:>
:>As long as you don't want to transfer files, perhaps. But if you do,
:>you'll spend fifteen minutes fiddling with libraries, files, and
:>documents.
Oh really? It takes me seconds.
:>
:>>If you want the legendary IBM quality,
:>
:>Legendary as in it doesn't exist? Peel off the labels on those drives
:>and see who really made them. IBM couldn't match the reliability or
:>performance of its competitors until very recently, so it bought their
:>drives and relabeled them.
I got an AS/400 here, and IBM is on those drives. I have been to different
AS/400 sites, and none of them have what you described. Furthermore, it is
considered by many industry analysts that IBM's DASD technology is about as
much as 5 years ahead of the nearest competitors.
I have run IBM DASDs on non-AS/400s like IBM PCs and PS/2s. I even got IBM
drives on PC clones and even on my Macintosh. I never lost a single byte
from all those cumulative years of usage and experience, from IBM DASDs.
:>>Not everybody wants 'open'. I'll probably be burned for heresy, but
:>>there are still an awful lot of DP managers and financial executives
:>>who want reliability at a reasonable cost.
:>
:>Most of whom would really be much happier with typewriters.
:>
:>>And, if you're a hacker, you'll still have plenty of stuff to do late
:>>at night. Once you get the apps up and running, the AS/400 will pretty
:>>much take care of itself. Give you more time to play with Windows and
:>>try to remember what grep stands for.
:>
:>Only developing for the 400 is 100-1000 times slower than developing
:>for any other platform. I've never seen a system that takes as long
:>to edit and save a file as the AS/400. Ever the 256K Series/1s were
:>faster!
:>
???????
My AS/400 does not perform as you said.
:>>I've managed data centers that have both AS/400 and Unix systems
:>>installed. The AS/400's are more expensive initially, but they cost *A
:>>LOT* less to support. The applications seem to cook right along, while
:>>the Unix boxes are always surrounded by programmers on Monday morning.
:>
:>How many different applications were being developed on those AS/400?
:>The reasons the AS/400 has such low maintenance costs is because it is
:>performs so poorly that after the application it was bought for is
:>installed, no one touches it.
Why would anyone develop close to 30,000 applications for it then?
:>
:>Productivity is more important.
:>
:>
That's why I administer an AS/400 (which I also own, by the way, because I am
also one of the major proprietors of the company.)
Capitalists like me have a lot of other things to do than bother with
computers. Being the Boss gives me a unique perspective of
"productivity"---maybe the unquestioned, absolute bottomline view of such.
Also, I don't have any expensive "system consultants" on my payroll. Never
needed any.
Rgds,
Chris
Tom McCann
The management at this account probably wanted to save the $30-$50 they
would have to spend to buy a Unix book for every programmer. Depending
on your view of what a 'reasonable' programmer is, they may or may not
have a 'cheat sheet' on the wall. I have yet, however, to see any Unix
programmer who didn't have some kind of reference manual in his office,
to supplement / complement the man pages (even at computer science
schools!).
On the other hand, most AS/400 shops only have one copy of the command
manuals, because the command language is self-prompting, and offers
both on-like doc and available options. This is in addition to list of
commands sorted by verbs, nouns, and subjects. This may not be as
intututive to you as something like
ps -ef | grep process
or,
find / -name myfile -print
but it sure is a lot easier to stumble through.
The Unix command system is very powerful. It also is very extensible
through the scripting language, which I think is worlds better than CL.
However, you can't claim that it's intuitive, and the inconsistencies
in syntax and semantics drive me nuts.
--
Tom McCann
President, Technomics Inc.
P.O. Box 42462
Cincinnati, Ohio, 45242-0462
Tom McCann
Woodruff) writes:
>
>In <4dqfbo$j...@ixnews8.ix.netcom.com>, tmc...@ix.netcom.com(Tom
McCann ) writes:
>>There is almost no similarity between the AS/400 and mainframes
(MVS).
>
>Funny. OS/400 is *VERY* close to OS/360 MVT. They renamed everything,
>but the concepts and design are identical is most respects. It's
>a truly pathetic operating system with perhaps five good ideas in it
>total.
>
think
>>of that you see on a day-to-day basis is different.
>
>The 5250's are 3270's with reduced functionality. The panel manager is
>PDF with reduced functionality. The file system is much more primitive
>(reminds me of RPS on the Series/1). Okay, so we have printer files
>rather than Data Definitions. But OS/400 really is MVT stripped with
>a handful of features added.
Fortunately, you lost all credibility with your opening. There is
nothing in common between OS/400 and MVT. MVT didn't have virtual
storage, had only a very primitive TSO command language and an early
SPF (PDF didn't come along until much later - on MVS) and certainly
didn't support any concept like single-level store.
<< snipped the rest of it, because you clearly just don't understand >>
Michael Wojcik
>In message <woodruffD...@netcom.com> - netco...@netcom.com (Mark
>Woodruff) writes:
>:>Only developing for the 400 is 100-1000 times slower than developing
>:>for any other platform. I've never seen a system that takes as long
>:>to edit and save a file as the AS/400. Ever the 256K Series/1s were
>:>faster!
>:>
>
>???????
>
>My AS/400 does not perform as you said.
Small AS/400s are very slow, compared with other systems with similar
processing power, at processing source members (editing, searching,
compiling -- whatever), at least in my experience. That may be
due to inefficiencies in SEU or some overhead peculiar to source
members, but I can transfer a bunch of source members from the 400
to my 6000 and search them faster than I can search them in SEU.
Generally, other types of file I/O (eg. C/400 record processing)
seemed much faster than doing just about anything with source members.
Actually, the last time I did any serious 400 development was
probably over a year ago now; development tools may have improved
since. But I have to agree with Mark on this point, so far as the
small 400s of a couple of years ago go.
Michael Wojcik m...@mfltd.co.uk
AAI Development, Micro Focus Inc.
Department of English, Miami University
Allister
> What other operating system has this much flexibility?
Windoze! If it won't do the job, just upgrade next year.
+---------------------------------------------+-------------------------+
| Allister Jenks. aje...@central.co.nz | Absolutely, Positively, |
|---------------------------------------------| WELLINGTON, NEW ZEALAND |
| The conspiracy is out! Reality has bugs! | -*-*-*-*-*-*-*-*-*-*-*- |
+---------------------------------------------+-------------------------+
Vil...@cus.cul.ca
>
>Who needs some "DST function", when your block devices appear as ordinary
>files under UNIX? I can easily copy one disk image to another, provided that
>the destination can hold the whole thing. Under linux, just do a
>cp /dev/hda /dev/hdb to copy one hard disk to another that is at least as big.
>With dd, you can copy selected ranges of blocks.
>
a little more interesting. In the AS/400s case, striping is normal, and easier to implement than
the approach of allocating files to specified disk(s) as is implemented in UNIX and VAX/VMS.
Bottom line, UNIX has its uses, OS/400 has its uses. THe strengths of each tend to be the
weaknesses of the other.
I have used both fairly extensively, have supported both (as well as OS/2, RSTS/E, RT-11, PC/DOS
VAX/VMS, VM/370 (as well as HPO), a couple of telephone type switching systems (for those that
care #1ESS 2W & 4W, SP1 ESS, 2W, 4W & 2/4W) and probably a few systems that I have forgotten about
over the years.
Just for my own curiosity, what are your credentials ???
Tom McCann
Kylheku) writes:
>
>In article <30f673fe...@news.jaring.my>, Ooi SC
<oo...@jhlib.pc.my> wrote:
<<snip>>
>Not necessarily. Things like cron and at are quite adequate.
<<snip>>
Hmmm.... I use to work on requirements for 'Unix Large', meaning, what
do high-end users need to have in Unix to make it a complete system.
Number 2 on the list was always batch - right after data managemment.
Seems that most high end users don't think that cron and at are job
schedulers. They can cause time-driven things to happen, but they offer
no conditionality, and cannot be event-driven (e.g., trigger on the
completion of another process or the existence of a file).
Vanilla Unix also has almost no process control; that is, the ability
to manage the performance of multiple workloads in a complementary
fashion. Try starting up a bunch of batch tasks (for example, a batch
database read) and maintain good response time while you do it. Almost
impossible on Unix, but standard fare in most mid-range or high end
proprietary operating systems.
>>4. Spool file control on the AS/400 is very sophisticated. For
>> instance, you suspense a print job, restart at a different page,
>> transfer to a different printer, print equally well on a page
>> printer or a dot-matrix printer without reprogramming, etc.
>> Standard unix can emulate some of these features only by
>> stringing together a bunch of utilities - very tough to teach to
>> a computer operator.
>
>How does it deal with PostScript? Line printers are still important in
some
>applications, but noawadays even mundane things like printing the
contents of
>some log file or script report are dumped through an N-up thingy that
creates
>PostScript output.
No problem for the AS/400. Look at the latest release of the AFP
Utilities. Handles PostScript, PCL, IPDS, and a few other print streams
transparently. Other than the RS6K, I don't know of a Unix system that
can do this. Maybe there are some - I haven't shopped it in about a
year.
>
>>5. AS/400 spreads each of its files across all the available
>> disks. Thus IO is always shared equally among all the disks.
This
>> help to improve interactive programs response time greatly. This
>> feature is a double edge sword.
>
>I'm sure this sort of "striping" is available in many UNIXes, so you
have to
>consider which UNIX incarnation you are talking about.
Available AT EXTRA CHARGE and WITH EXTRA IMPLEMENTATION in almost all
Unix's. Standard on AS/400.
>
<<snip>>
>
>>7. The security features of the AS/400 is very good. Definitely much
>> better than most versions of unix. For instance, the password
>> file of the AS/400 is encrypted and is virtually invisible to
>> all standard file manipulation commands. That makes it very
>> tough on hackers.
>
>Maybe it is more secure. But your vague description doesn't make the
AS/400's
>password system sound superior that of a UNIX system that has shadowed
>passwords (ever heard of that? It's very common).
Neither one of them is much good unless you have Kerberos (DCE). The
thing that really makes the AS/400 more secure is it's very poor
(nonexistent) support of ASCII terminals. That helps keep the hackers
out.
cro...@kuentos.guam.net
>since. But I have to agree with Mark on this point, so far as the
>small 400s of a couple of years ago go.
That explains much of it. The small AS/400s a couple of years ago aren't
that fast.
The newer Model 200s (black) are as much as 82% faster than the small
F series, and I think you got something even earlier than an F. The RISC
models (the current ones) are of course, can be as much as three times
faster than the black CISC models.
As with the current Unix machines, the current AS/400 lineup are also moving
targets, which also see generational improvements.
Personally I would like to see how the 64 bit PPC AS RISC chips hold up against
the RS/6000's 604s and 604Es.
Rgds,
Chris
Rei Hino/Sailor Mars Ami Mizuno/Sailor Mercury Minako Aino/Sailor
Venus Makoto Kino/Sailor Jupiter Haruka Tenoh/Sailor
Uranus Michiru Kaioh/Sailor Neptune Setsuna Meioh/Sailor Pluto
Usagi Tsukino/Sailor Moon Hotaeru Tomoe/Sailor Saturn
Chiusagi Tsukino/Sailor Chibimoon *****cro...@kuentos.guam.net*****
Larry Loen
|> tmc...@ix.netcom.com(Tom McCann ) writes:
[snip]
|> But have you ever used a recent UNIX version with a graphical user
|> interface? I know the current openwindows and it is far away from the
|> cryptic command line driven UNIX, everybody nows. I will see CDE in
|> the next Solaris release.
|>
|> When judging UNIX by its user interface you have to take the current
|> UNIX interface and not some ancient version. AS/400 is also judged by
|> its current user interface.
|>
The problem I have with AIX's Unix, at least, is that its X-windows stuff
(its GUI) is very good. Clearly better than any command line.
Trouble is, I seem to "fall off" of it when I need to do anything
serious. Then, it's right back to the ol' command line and Unix/AIX
suffers.
In short, I hope for, but did not find that my Unix is fully
GUI-ized yet.
My experience with nonIBM Unix' are limited, but so far similar
(e.g. Sun).
--
Larry W. Loen | Science is often the act of trading
| comforting myths for exciting ideas
email to: lwl...@rchland.vnet.ibm.com
Michael Brutman
|> In <DLJyw...@eskimo.com>, sa...@eskimo.com(Marc Salvatori) writes:
|> >In <4dcacb$c...@lehi.kuentos.guam.net> Christopher Robato wrote:
|> >> You should see how progressive OS/400 is. How about an object oriented
|> >> design and architecture, with microkernel.
|> >
|> >OS/400, an object-"based" kernel, I can understand. But object-oriented?
|> >Hmmmm. Please expand on your thoughts here. An object-oriented kernel
|> >should allow you to add modules without the need to re-IPL, let alone
|> >reconstruct the kernel package.
|> >
|>
|> there should be such a thing called a kernel deep inside the AS/400, and the
|> thing I know closest to that would be the Machine Interface. So it's really
|> hard to say where the kernel ends or begins. The only time the term kernel is
|> used, is with the current IBM Workplace microkernel version used on the
|> RISC AS/400s (OS/400 v3.6 and above).
Correction - v3r6 (RISC) is not using a microkernel. When I think hear
the word microkernel, I think of something like Mach which provides the
bare minimum and relies on higher layers to define & present the
operating system. AS/400s might use a microkernel some day, but our
current implementations do not.
Regarding an object-oriented kernel: the ability to add modules without
needing to re-IPL has nothing to do with being object-oriented. That is
more dependent on the link loading philosophy of the system and on the
requirements of the code being changed. You can be object-oriented without
supporting dynamic linking.
AS/400s can do both:
[1] PTFs can be "no-IPL" PTFs, which can be activated as soon as
they are applied.
[2] More sensitive code might require an IPL to become active because
of possible consistency problems that would result if you just
"threw it in there."
|> And yes, modules are added on the fly without rebooting the machine
|> unless it involves changes in parts of the operating system that can
|> be considered 'kernel'.
|>
|> The new Microkernel version appears very much the same as the CISC
|> OS/400 v3.1 from the wrappers, and older AS/400 CISC software, like
|> those working under version 2.x of the OS, will run directly without
|> any code changes, on the RISC version of the OS, assuming observability
|> is built to the code (what AS/400 software that isn't?) Just install your
|> current software; no need to call your VAR for the RISC upgrade of your
|> programs.
The MI interface is an abstraction layer. Which allows us to change
anything we want underneath it, as long as we adhere to the original
"contract" specified by the MI interface. This is a very object-oriented
way of looking at the system.
|> In fact, the RISC version looks practically the same as the CISC version,
|> and every part and module has the same behaviour that I think they are
|> literally the same. Only the 'kernel' is switched.
|>
|> The term "object oriented" also applies to the very paradigm and concepts of
|> the OS/400 itself. Everything is treated as an encapsulated object. Everything has
|> an object header tag, which includes among others, the owner of the object,
|> the security status of the owner, which is inherited by the object. Adding
|> and configuring devices in the AS/400 are derived from a base class of
|> preconfigured objects and templates, which the device inherits its characteristics
|> from. New users are configured and inherit the qualities from preexisting
|> classes of users.
We can't go too far with this object-oriented stuff now. The AS/400 has
always been "object based", ie: we manipulate objects. That is not
necessarily the same as "object-oriented."
The newer RISC versions are now more object-oriented in their implementation
than previous versions. Unfortunately, just like on the older models, the
user sees very little of that. This translates to "we define the objects
and you may use them, but you can't inherit from them or define your own
new objects."
|> One interesting aspect of the architecture is that OS/400 does not use
|> byte addressing, which MVS and OS/390 uses (and just about every OS in this
|> world.) Instead, it uses "object" addressing. Pointers in OS/400 never point
|> to byte addresses; rather, they point to objects (a 128 bit address decoded
|> by the microcode in the Machine Interface.) The objects can reside anywhere
|> in the vast "single level store" memory space or universe---the AS/400 does not
|> make a distinction on what is RAM or main memory, and what is virtual memory.
|> It will address whole arrays of disks like they are RAM in a single contingous
|> space of memory.
|>
|> Rgds.
|>
|> Chris
|>
|> Rei Hino/Sailor Mars Ami Mizuno/Sailor Mercury Minako Aino/Sailor
|> Venus Makoto Kino/Sailor Jupiter Haruka Tenoh/Sailor
|> Uranus Michiru Kaioh/Sailor Neptune Setsuna Meioh/Sailor Pluto
|> Usagi Tsukino/Sailor Moon Hotaeru Tomoe/Sailor Saturn
|> Chiusagi Tsukino/Sailor Chibimoon *****cro...@kuentos.guam.net*****
|>
|>
--
Michael B. Brutman
bru...@vnet.ibm.com
Standard Disclaimer: Not speaking for IBM
cro...@kuentos.guam.net
>In <4dcacb$c...@lehi.kuentos.guam.net> Christopher Robato wrote:
>> You should see how progressive OS/400 is. How about an object oriented
>> design and architecture, with microkernel.
>
>OS/400, an object-"based" kernel, I can understand. But object-oriented?
>Hmmmm. Please expand on your thoughts here. An object-oriented kernel
>should allow you to add modules without the need to re-IPL, let alone
>reconstruct the kernel package.
>
First of all, the word "kernel" does not exist in the AS/400 language. I'm sure
there should be such a thing called a kernel deep inside the AS/400, and the
thing I know closest to that would be the Machine Interface. So it's really
hard to say where the kernel ends or begins. The only time the term kernel is
used, is with the current IBM Workplace microkernel version used on the
RISC AS/400s (OS/400 v3.6 and above).
And yes, modules are added on the fly without rebooting the machine
unless it involves changes in parts of the operating system that can
be considered 'kernel'.
The new Microkernel version appears very much the same as the CISC
OS/400 v3.1 from the wrappers, and older AS/400 CISC software, like
those working under version 2.x of the OS, will run directly without
any code changes, on the RISC version of the OS, assuming observability
is built to the code (what AS/400 software that isn't?) Just install your
current software; no need to call your VAR for the RISC upgrade of your
programs.
In fact, the RISC version looks practically the same as the CISC version,
and every part and module has the same behaviour that I think they are
literally the same. Only the 'kernel' is switched.
The term "object oriented" also applies to the very paradigm and concepts of
the OS/400 itself. Everything is treated as an encapsulated object. Everything has
an object header tag, which includes among others, the owner of the object,
the security status of the owner, which is inherited by the object. Adding
and configuring devices in the AS/400 are derived from a base class of
preconfigured objects and templates, which the device inherits its characteristics
from. New users are configured and inherit the qualities from preexisting
classes of users.
One interesting aspect of the architecture is that OS/400 does not use
Michael Wojcik
>But have you ever used a recent UNIX version with a graphical user
>interface? I know the current openwindows and it is far away from the
>cryptic command line driven UNIX, everybody nows. I will see CDE in
>the next Solaris release.
>
>When judging UNIX by its user interface you have to take the current
>UNIX interface and not some ancient version. AS/400 is also judged by
>its current user interface.
On the other hand, some of us Unix programmers much prefer the
command line to any of the GUIs that have come by to date (on any OS).
I use X Windows almost exclusively for multiple xterms (which I
keep tiled, not overlapped). GUIs annoy me to no end, though nearly
all of my programming career has featured them. I find that "ancient"
Unix UI much more elegant and usable than CDE, thanks just the same.
It would be more appropriate to judge the OSes by all the interfaces
they present than by whatever the new-design fans are trumpeting,
I think -- and keeping in mind that in some environments variety
may not be a desirable quality.
Mikhail Teterin
wrote on Jan 22, 1996 (in article <4e12fb$2...@cloner2.ix.netcom.com>):
=Vanilla Unix also has almost no process control; that is, the ability
=to manage the performance of multiple workloads in a complementary
=fashion. Try starting up a bunch of batch tasks (for example, a batch
=database read) and maintain good response time while you do it. Almost
=impossible on Unix, but standard fare in most mid-range or high end
=proprietary operating systems.
What is "vanilla Unix" anyway? But, the problem you describe may
be solved by changing the priorities of the processes. Granted, it
is not always convinient, and there is only command-line interface to
do that. Unix is kind of like a stanbdard-transmission car against
automatic...
=No problem for the AS/400. Look at the latest release of the AFP
=Utilities. Handles PostScript, PCL, IPDS, and a few other print streams
=transparently. Other than the RS6K, I don't know of a Unix system that
=can do this. Maybe there are some - I haven't shopped it in about a
=year.
Due to Unix's overall openess, there are plenty of good convinient
printer-filters, for all your formats. And they smoothly integrate
into the OS.
=.............................................................. The
=thing that really makes the AS/400 more secure is it's very poor
=(nonexistent) support of ASCII terminals. That helps keep the hackers
=out.
"And today, students, we will be talking about turning our weaknesses
into strength." Or, at least, make it look so.
-mi
--
"Windows for dummies"
Mario Klebsch
>In <4dbf4q...@keats.ugrad.cs.ubc.ca> c2a...@ugrad.cs.ubc.ca (Kazimir
>Kylheku) writes:
>>
>>In article <30f673fe...@news.jaring.my>, Ooi SC
><oo...@jhlib.pc.my> wrote:
>>>5. AS/400 spreads each of its files across all the available
>>> disks. Thus IO is always shared equally among all the disks.
>This
>>> help to improve interactive programs response time greatly. This
>>> feature is a double edge sword.
>>
>>I'm sure this sort of "striping" is available in many UNIXes, so you
>have to
>>consider which UNIX incarnation you are talking about.
>Available AT EXTRA CHARGE and WITH EXTRA IMPLEMENTATION in almost all
>Unix's. Standard on AS/400.
Available for Solaris. Called ODS. Cannot be used for /, /usr,
/usr/openwin, /var, /opt and anything needed for upgrading.
Our 2GByte /opt just ran out of space. So I thought: give it a try. I
read the manuals and saw that I lost. :-(
This does not sound the same to me.
73, Mario
--
Mario Klebsch, DG1AM, M.Kl...@tu-bs.de +49 531 / 391 - 7457
Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany
Larry Loen
|> In <4e3ac8$11...@locutus.rchland.ibm.com>, bru...@bruteforce.rchland.ibm.com (Michael Brutman) writes:
[snip]
|> On the OS/400 structure, it appears to me that much of what OS/400 appears
|> to be for the user and the programs are very high level, while the Machine
|> Interface or MI seems to provide only rudimentary hardware functions, much like
|> a kernel does. I can be wrong, just stating an opinion.
|>
It's not far off, just a tad overstated, at least from where I sit.
I didn't look at what the web page says, but the microkernels I know of
(those from Carnegie Mellon or the later versions of it from Open
Software Foundation) are relatively small, containing maybe 100,000 lines
of code or less, plus other servers that might be called "midware" that
run in problem state that might run in the kernel elsewhere. For instance,
in the OSF microkernel, the "default pager" and the "name server" run
in problem state. In AS/400, equivalent parts of the code are
part of the kernel.
The "licensed internal code" that creates the MI (Machine Interface) is
upwards of a couple of million lines of code, but a lot of that is I/O
support, of which we have a generous amount. So, the part of the machine
that runs the pager and dispatcher and so on, are not quite that big.
But, there is perhaps a million lines of you-couldn't-possibly-subset
it code in there.
Along with the I/O code, there is a substantial fraction of the DB2
support "under" the MI, too.
Even if you throw out all I/O and all data base related stuff, what you
are left with is probably comparable, in size, to a Unix kernel, which
is much bigger than at least the OSF / Carnegie Mellon Microkernel;
indeed, the latter was done, in part, to show just how much stuff you
could throw _out_ of a standard Unix kernel.
Still, one man's micro is another man's huge. OS/400 and all its
licensed programs makes even a million lines or two seem small; in that
since one might argue it is "micro". But, at least in terms of the
academic literature on microkernels, today's AS/400 below-MI code
is not really a microkernel.
|> As for being object oriented, everything OO seems to imply that you have
|> a prexisting supply of base classes of objects. New objects are then created
|> from these base classes, using inheritance. But isn't that how users,
|> printers, display terminals and other stuff, created and configured inside
|> OS/400? Such as creating a new printer configuration from *PRT class, etc?
|> Or the way every object created by the user inherits that user's security class,
|> even for just a simple file?
|>
You must understand that our notions of object-oriented precede either
Smalltalk or C++ by about a decade and more. Therefore, you should
not expect a one-to-one correspondence between what one sees in today's
OO languages and how AS/400 is constructed. We were _really_ on the
leading edge of objects; we had them before anyone really had time to
dream up many of today's critical ideas.
In spite of this, the object structure of AS/400 and OS/400 is not
that far off of what developed. It is easy to show we have something
like "inheritance" going on. For instance, both a data base file and
a spool file inherit from the basic "below MI" data base object; they
just use them differently. There is a notion of "object subtype" that
enables one to see the "object hierarchy" between the machine level
objects and the various versions created by XPF (and, before that,
CPF) to run the system. It directly provides the "is-a" notion.
I am not as expert on the above-MI work, but certainly, one sees many
echoes of a class definition/meta-data, especially in the data base
area.
You could draw nice Bootch-type or other OO style diagrams for
every existing XPF object, though it might be a little odd at first in
that the XPF part, being the "leaf" object, would tend to be drawn below
the base microcode "below MI" object, so the pictures would be
upside-down compared to most literature about AS/400, either in or
outside of IBM, that show our objects. Once you get over this issue,
which is really just a graphical art thing, it all falls out pretty nicely.
The major thing we didn't anticipate was polymorphism. Our "methods"
tend to say "delete data base" and not "delete".
I don't know how or whether more of this structure will be made visible
to the user. Or, for that matter, how aggressively a C++ coder could
"wrapper" the existing System API set in a way that corresponded closely
to the actual object structure. But, at a "here's how it looks" level,
you could draw a very recognizable picture of the system using any
of the object-oriented documentation protocols and see readily
where we anticipated the late 80's revolution and where we
didn't back in the '70s when all this was invented.
cro...@kuentos.guam.net
>the word microkernel, I think of something like Mach which provides the
>bare minimum and relies on higher layers to define & present the
>operating system. AS/400s might use a microkernel some day, but our
>current implementations do not.
In all due respect, since you work for IBM, I should take your word from it.
But I did thought that I read that OS/400 r3.6 uses the microkernel from IBM's
own web pages on the AS/400 (http://www.as400.ibm.com). Maybe I should
check again.
On the OS/400 structure, it appears to me that much of what OS/400 appears
to be for the user and the programs are very high level, while the Machine
Interface or MI seems to provide only rudimentary hardware functions, much like
a kernel does. I can be wrong, just stating an opinion.
As for being object oriented, everything OO seems to imply that you have
a prexisting supply of base classes of objects. New objects are then created
from these base classes, using inheritance. But isn't that how users,
printers, display terminals and other stuff, created and configured inside
OS/400? Such as creating a new printer configuration from *PRT class, etc?
Or the way every object created by the user inherits that user's security class,
even for just a simple file?
Rgds,
Mark Woodruff
>In article <woodruffD...@netcom.com>, netco...@netcom.com (Mark Woodruff) writes:
>|> Our 30S clocks in as equivalent to a 1 Mhz 486. It takes 100 times
>|> longer to run equivalent benchmarks on the 30S running V3R1 than it does
>|> to run them on OS/2 Warp on my 100 Mhz 486 at home.
>
>And just what benchmark was that?
It was a series of benchmarks doings things that I needed to do right
then: editing, compiling, copying files, etc.
>Why is it that an AS/400 can support
>many multiple users by your 100 486 can't?
A 486 can easily support hundreds of users if you add the tens of
thousands of dollars worth of extra hardware that is built in to the
AS/400. I remember an 8 mhz 8086 supporting 40 users 14 years ago
at CitiCorp. All it takes is hardware...
>Don't you think that
>perhaps the benchmark is questionable?
No, since it was a benchmark of activities I have to do every day on
the beast. If you have to do similar activities, the benchmarks would
apply to you to.
>(Ever benchmark a Ferrari by parallel parking it?)
A very good benchmark if you want to ever want to parallel park your
car. The Lamborghini Countach, for example, is a real bitch to park.
My coworker's Porche 930 takes 30 minutes to warm up or cool down at
times. These are important considerations if you want to own and use
a car rather than just look at it in a magazine.
The black AS/400 looks quite snazzy in a magazine. But I find it nearly
impossible to do my work on it. Unlike the VM, MVS, RPS, and OS/2
machines I have used in the past.
mark
I thing I could do anything with Xedit, Rexx, and Pipes under VM
faster, easier, and cheaper than with all the gimmicks in OS/400.
Vil...@cus.cul.ca
>When UNIX programmers use the online man pages, UNIX is top
>complicated. When AS/400 programmers use the AS/400 online
>documentation, this is the strength of AS/400.
That should read "AS/400 online documentation", rather AS/400 command line prompting.
Online documentation is available on the AS/400, but the real strength of the user interface
is the prompting/fill in the blanks/contexual help that is available with the F4 and F1 keys.
Think of it as having hypertext available on your command line...
Michael Brutman
|> >Correction - v3r6 (RISC) is not using a microkernel. When I think hear
|> >the word microkernel, I think of something like Mach which provides the
|> >bare minimum and relies on higher layers to define & present the
|> >operating system. AS/400s might use a microkernel some day, but our
|> >current implementations do not.
|>
|>
|> But I did thought that I read that OS/400 r3.6 uses the microkernel from IBM's
|> own web pages on the AS/400 (http://www.as400.ibm.com). Maybe I should
|> check again.
|>
|> On the OS/400 structure, it appears to me that much of what OS/400 appears
|> to be for the user and the programs are very high level, while the Machine
|> Interface or MI seems to provide only rudimentary hardware functions, much like
|> a kernel does. I can be wrong, just stating an opinion.
|>
|> As for being object oriented, everything OO seems to imply that you have
|> a prexisting supply of base classes of objects. New objects are then created
|> from these base classes, using inheritance. But isn't that how users,
|> printers, display terminals and other stuff, created and configured inside
|> OS/400? Such as creating a new printer configuration from *PRT class, etc?
|> Or the way every object created by the user inherits that user's security class,
|> even for just a simple file?
|>
|> Rgds,
|>
|> Chris
Don't take my word for it because I work at IBM. Take my word
because I work at IBM on this "beneath the MI" stuff for the
RISC AS/400s. ;-)
I think what we are getting caught on is the definition of kernel
and microkernel. And then there is the definition & purpose of
the MI boundary ..
A typical microkernel, is, well micro-sized. That is why I think
of Mach when I think of a microkernel.
All of the stuff that implements the MI interface is *far* larger
than a microkernel. Calling it a "kernel" is more accurate, but
still a loose usage. We push more down into this kernel than
most systems will ever see with every optional package installed.
(Ok, that might be slightly exagerated - but think about it. SNA,
TCP/IP, Database, object-level security, etc. are all built in.
Much of it is directly supported by the kernel beneath the MI
layer.)
And then there is the definition of MI and what it provides. I
like to think of the MI as an API for accessing this kernel,
not as "the hardware boundary" as some of the marketing types
would have it. MI has no resemblence to PowerPC instructions;
it is pretty far removed from the hardware. It gives you access
to communications, database, the filesystem, system management,
etc. I guess it just depends on what you call rudimentary - as
an operating systems programer that's all high level stuff!
Onto objects ..
Don't confuse inheritance with instantiating an object. When you define
a user, a printer or a tube you are instantiating an existing object
with some unique attribute data. In most cases, you have not created
a new class using inheritance - you have only created another instance
of a pre-existing class.
If *you* the user woke up one day and said, "What if I could combine
a printer with a user profile?" (or something along those lines ..)
and the operating system let you create a new class to do that from
the pre-existing classes, then yes, that is inheritance. But AS/400s
don't let users do that. (At least not yet.)
Please feel free to respond to me directly via email.
Mike
Mark Woodruff
>The newer Model 200s (black) are as much as 82% faster than the small
>F series, and I think you got something even earlier than an F. The RISC
>models (the current ones) are of course, can be as much as three times
>faster than the black CISC models.
Our 30S clocks in as equivalent to a 1 Mhz 486. It takes 100 times
longer to run equivalent benchmarks on the 30S running V3R1 than it does
to run them on OS/2 Warp on my 100 Mhz 486 at home.
mark
I hate being sick and not being able to sleep
cro...@kuentos.guam.net
And what sort of benchmarks are you using? What manner of equivalency do
you have to maintain between your PC with Warp and an AS/400 30S for
a benchmark?
Ever tried running a good number of users on your 486-100? And try it on a
very high level of memory overcommit?
Dan Hicks
>On the other hand, some of us Unix programmers much prefer the
>command line to any of the GUIs that have come by to date (on any OS).
>I use X Windows almost exclusively for multiple xterms (which I
>keep tiled, not overlapped). GUIs annoy me to no end, though nearly
>all of my programming career has featured them. I find that "ancient"
>Unix UI much more elegant and usable than CDE, thanks just the same.
One of the strengths of the AS/400 command language is the fact that
there's no separation between the prompter interface and the command
line interface. When you create one you create the other, and a user
can use as little or as much of the prompter as desired. And "help" is
available on a context-sensitive basis, so that you can get help for an
individual field without having to scroll through several pages of man
text.
Unix commands, on the other hand, will only prompt if significant extra
effort is expended by the programmer, and then some of the inputs may
not be available in prompting mode, while others may ONLY be available
in prompting mode.
Dan Hicks
http://www.millcomm.com/~danhicks/
Andrew Gierth
>In article <woodruffD...@netcom.com>, netco...@netcom.com (Mark Woodruff) writes:
>|> In <4e1vh6$1...@lehi.kuentos.guam.net>, cro...@kuentos.guam.net writes:
>|> >The newer Model 200s (black) are as much as 82% faster than the small
>|> >F series, and I think you got something even earlier than an F. The RISC
>|> >models (the current ones) are of course, can be as much as three times
>|> >faster than the black CISC models.
>|>
>|> Our 30S clocks in as equivalent to a 1 Mhz 486. It takes 100 times
>|> longer to run equivalent benchmarks on the 30S running V3R1 than it does
>|> to run them on OS/2 Warp on my 100 Mhz 486 at home.
>|>
>|> mark
>|>
>|> I hate being sick and not being able to sleep
>
>many multiple users by your 100 486 can't? Don't you think that
>perhaps the benchmark is questionable?
You might be surprised at how many users a 100MHz 486 can support. Just
give it a real operating system, and it tanks along quite nicely, thank
you very much. And for a fraction of the cost of even a small AS/400.
I can well believe mark's results; they are a bit more extreme than mine,
but his benchmark is probably different... (BTW, Mark, what _is_ your
benchmark?)
The AS/400 is just in an inferior league when it comes to CPU-intensive
tasks. It might have (indeed does) have great I/O performance, but as
soon as you need to really process your data rather than just shuffle it
around, you can forget it.
There are a couple of specific cases where programs on the AS/400 take
really *stunning* performance hits. One of these is procedure call
overhead. I have timed a particular ILE procedure call at 25us per call
on an (admittedly obsolete) E10; this is easily 100 times slower than
the same call on a 486DX4-100.
Anyone have Dhrystone figures for a few AS/400s for comparison?
>--
>Michael B. Brutman
>bru...@vnet.ibm.com
>Standard Disclaimer: Not speaking for IBM
-- Andrew (and...@microlise.co.uk)
[.sig under construction]
Kazimir Kylheku
Andrew Gierth <and...@microlise.co.uk> wrote:
>You might be surprised at how many users a 100MHz 486 can support. Just
>give it a real operating system, and it tanks along quite nicely, thank
>you very much. And for a fraction of the cost of even a small AS/400.
>
>I can well believe mark's results; they are a bit more extreme than mine,
>but his benchmark is probably different... (BTW, Mark, what _is_ your
>benchmark?)
>
>The AS/400 is just in an inferior league when it comes to CPU-intensive
>tasks. It might have (indeed does) have great I/O performance, but as
>soon as you need to really process your data rather than just shuffle it
>around, you can forget it.
I guess IBM's backward "mainframe" mentality is showing.
CPU performance is important in a distributed environment, even for things like
communication. If you want to do fast networking, you are looking at great
overhead for marshalling data into datagrams, encryption, buffer copying and
the like. Fast CPU's are not just for graphics and compiling.
I'd love to see what an AS/400 would do if that 486/100 flooded it with packets
over a 100MB/s data link.
>There are a couple of specific cases where programs on the AS/400 take
>really *stunning* performance hits. One of these is procedure call
>overhead. I have timed a particular ILE procedure call at 25us per call
>on an (admittedly obsolete) E10; this is easily 100 times slower than
>the same call on a 486DX4-100.
Sheesh, I can probably just about fork() a Linux process in that time.
--
Kazimir Kylheku
Tom McCann <tmc...@ix.netcom.com> wrote:
>>
>>>5. AS/400 spreads each of its files across all the available
>>> disks. Thus IO is always shared equally among all the disks.
>This
>>> help to improve interactive programs response time greatly. This
>
>>> feature is a double edge sword.
>>
>>I'm sure this sort of "striping" is available in many UNIXes, so you
>have to
>>consider which UNIX incarnation you are talking about.
>
>Available AT EXTRA CHARGE and WITH EXTRA IMPLEMENTATION in almost all
>Unix's. Standard on AS/400.
Linux has it now. Free.
That something is at extra charge doesn't mean a thing. It's just a different
packaging. You can just as well see it as a saving, since you don't have to pay
for something that you aren't going to use. Extra implementation? That's also
not really an issue of concern. It _takes_ extra implementation to do this.
>>>7. The security features of the AS/400 is very good. Definitely much
>>> better than most versions of unix. For instance, the password
>>> file of the AS/400 is encrypted and is virtually invisible to
>>> all standard file manipulation commands. That makes it very
>>> tough on hackers.
>>
>>Maybe it is more secure. But your vague description doesn't make the
>AS/400's
>>password system sound superior that of a UNIX system that has shadowed
>>passwords (ever heard of that? It's very common).
>
>Neither one of them is much good unless you have Kerberos (DCE). The
So have Kerberos. What is stopping anyone from using Kerb?
>thing that really makes the AS/400 more secure is it's very poor
>(nonexistent) support of ASCII terminals. That helps keep the hackers
>out.
Just think! If you get rid of that keyboard, monitor and network adapter,
you could keep all those damn pesky users out!
--
ns...@1media.com
>thousands of dollars worth of extra hardware that is built in to the
>AS/400.
Then its not a 486 anymore! Is it? Hey, theres an idea; AS/486
>I remember an 8 mhz 8086 supporting 40 users 14 years ago
>at CitiCorp. All it takes is hardware...
As a file server maybe, but no 8086 can run 40 interactive jobs at the same
time. They can hardy handle one job.
Nestor Sosa
ns...@1media.com
>give it a real operating system, and it tanks along quite nicely, thank
>you very much. And for a fraction of the cost of even a small AS/400.
The AS/400 is not about COST, it's about BUSINESS SOLUTIONS!
>The AS/400 is just in an inferior league when it comes to CPU-intensive
>tasks. It might have (indeed does) have great I/O performance, but as
>soon as you need to really process your data rather than just shuffle it
>around, you can forget it.
How about a "divide by zero" on a 100mhz 486? How does it handle that?
Just Curious,
Nestor Sosa
Kazimir Kylheku
Dan Hicks <danh...@millcomm.com> wrote:
>One of the strengths of the AS/400 command language is the fact that
>there's no separation between the prompter interface and the command
>line interface. When you create one you create the other, and a user
>can use as little or as much of the prompter as desired. And "help" is
>available on a context-sensitive basis, so that you can get help for an
>individual field without having to scroll through several pages of man
>text.
>
>Unix commands, on the other hand, will only prompt if significant extra
>effort is expended by the programmer, and then some of the inputs may
>not be available in prompting mode, while others may ONLY be available
>in prompting mode.
I have no clue what you are talking about. An example would help.
I think we are slipping into application issues; remember, UNIX commands (with
the exception of shell built-ins) are tiny application programs, not features
of the shell or the operating system. Some have prompts, some aren't even
interactive. Some have full-screen interfaces that respond to individual
keystrokes.
There is no "command language" in UNIX. The shells have programming languages
that are similar to things like C. There are few built-in commands; rather
there are control structures like while / do / done, if / then / else / fi,
case / esac and so on.
The GNU Bourne-Again shell has help on any of the built-in stuff:
turing:~/txt$ help cd
cd: cd [dir]
Change the current directory to DIR. The variable $HOME is the
default DIR. The variable $CDPATH defines the search path for
the directory containing DIR. Alternative directory names are
separated by a colon (:). A null directory name is the same as
the current directory, i.e. `.'. If DIR begins with a slash (/),
then $CDPATH is not used. If the directory is not found, and the
shell variable `cdable_vars' exists, then try the word as a variable
name. If that variable has a value, then cd to the value of that
variable.
Discerning UNIX users use the Bash shell, which has all kinds of nice
features, such as powerful command editing and command completion, aliases,
function definitions and so on.
The external comands are not part of the shell's language, so it can't
provide a consistent interface across the invocation of these commands.
When you run a command like "find", it is in charge regardless of what
shell you use. You are running a program, not a command.
How good is AS/400's interactive job control? Let's see how you would run a
command as a background job.
--
Kazimir Kylheku
Vincent Leveque <pp0...@interramp.com> wrote:
>Yes, These were REALLY programmers - the commands were actually for use
>of vi (not UNIX per se, but still a standard part of it). These were
>not beginners, either. vi was the only text editor in use in this shop
>(unfortunately), so these folks were using it all the time & STILL
>needed the hardcopy reminder. While vi may be more obscure than the
Really? I use vi and don't need anything like that.
Maybe they should have gotten Vim, which has built-in help. There are many
alternatives, including editors that are Wordstar-like, favoured by people from
the DOS world, to lame-brained easy programs like Xedit and pico.
If these people were real programmers, a) have the good sense to install
another editor, or b) not require a vi cheat sheet in the first place.
Of course, we still have not established whether 1) these programmers _wanted_
a different editor but were stuck against their will, 2) put up the help sheets
themselves or someone else put them up just in case.
I'm afraid that what you are saying is starting to leak a little water.
First you said they had UNIX commands on the wall. Now we learn that they are
vi commands. The next thing you are going to say that the cheat sheets really
contain the grammar rules of sendmail.cf, which is being edited with vi.
>UNIX command interface, neither one is particularly intuitive (IMHO).
>Unfortunately, UNIX shops without a good windowing front end are stuck
>with the command line interface. Many commercial installation fall into
>this category.
Well, what do you want without a windowing front end but a command interface?
I'm afraid the choices are little limited.
>This may be an extreme example, but I do consider it indicative of the
>difficulty of remembering the names and syntax of UNIX commands (vs.
>AS/400).
>
>I haven't programmed an AS/400 full time for many years, but I can still
>find my way around SEU without referring to a manual.
But some people are not interested in finding their way around their text
editor. I already have mastery over vi; I'm interested in speed editing.
It's a different goal.
Now, I can find my way around ed even though I don't use it much. In fact I can
more than just find my way around it. Does that mean that ed is just as easy as
SEU? You must see how we are slipping into hopeless relativism here.
>Of course, a good GUI-based source code editor would easily beat both vi
>and SEU.
In what sense? Maybe for newbies, but now many computer neophytes are asked to
edit source? The learning curve makes no difference once you have total mastery
over a program.
--
Kazimir Kylheku
Tom McCann <tmc...@ix.netcom.com> wrote:
>The Unix command system is very powerful. It also is very extensible
>through the scripting language, which I think is worlds better than CL.
>However, you can't claim that it's intuitive, and the inconsistencies
>in syntax and semantics drive me nuts.
So?
--
Mark Woodruff
>You might be surprised at how many users a 100MHz 486 can support. Just
>give it a real operating system, and it tanks along quite nicely, thank
>you very much. And for a fraction of the cost of even a small AS/400.
A 25 Mhz 486 supported over 100 users using Novell 3.1 (256 mbytes ram,
many gigabytes dasd) where I used to work.
As for I/O speed, a fast/wide SCSI-2 card with a coprocessor will blow
any model of AS/400 out of the water (for less than a tenth of the cost).
The AS/400 is a successful machine because it has three letters on its
side. Aside from prompting and command definition, what else is good
about it? I can only think of:
1. Reliability
2. Auto-configuration of devices (plug'n'play)
3. Altered pointer bit
Everything else is either poorly designed, attrociously implemented, or
otherwise ruined by compromises. (This category includes things like
the single-image storage, which buys the user absolutely nothing in
the final evaluation--the Unix boxes run circles around it despite
their cache problems).
I really would like to believe the hype that IBMers tell themselves
about the AS/400. But after looking at 10,000 pages of documentation
and being apalled at how difficult it is to do trivial things, I can
only conclude that the whole business is a scam.
mark
Dan Hicks
>A 486 can easily support hundreds of users if you add the tens of
>thousands of dollars worth of extra hardware that is built in to the
>at CitiCorp. All it takes is hardware...
And software.
Dan Hicks
http://www.millcomm.com/~danhicks/
Michael Ozanne
c2a...@ugrad.cs.ubc.ca "Kazimir Kylheku" writes:
*How good is AS/400's interactive job control? Let's see how you would run a
*command as a background job.
Suppose I want to initialise a tape as a background job and
don't know how to do it
Find a command line press F4 to see a list of major command groups.
See option 8 "Work Management Commands and select it
See option 2 "Job Commands" and select it.
see option 38 "Submit Job" and select it
See prompt "Command to Run" and don't know what to do
Press F4 to see major command groups
See Option 8 "Data Management Commands" and select it
See Option 12 "Tape Commands" and select it
See Option 11 "Initialise Tape" and select it
Enter Tape device name and other details (all with prompted
context sensitive help if necessary) press enter. the command
Inztap and its parameters are then carried back to the
"Command to Run" prompt of the Sbmjob command. Press enter
and the Command Inztap is submitted to run in background.
Those of us with a bit of practice type in
sbmjob cmd(inztap dev(*device name*) newvol(*volume name*)
check(*no) clear*(yes)) *enter*
Those with even more practice will have created a command
that submits the job with its parameters.
Is this what you mean by running a command as a background job.
If not sorry for spending the bandwidth :-)
--
Michael Ozanne
Michael Brutman
|> In <4e6n3j$k...@microl4.microlise.UUCP>, and...@microlise.co.uk (Andrew Gierth) writes:
|> >You might be surprised at how many users a 100MHz 486 can support. Just
|> >give it a real operating system, and it tanks along quite nicely, thank
|> >you very much. And for a fraction of the cost of even a small AS/400.
|>
|> A 25 Mhz 486 supported over 100 users using Novell 3.1 (256 mbytes ram,
|> many gigabytes dasd) where I used to work.
Sorry, but Novell 3.1 is not an operating system. It is a file server.
Are you going to count all of the bytes of RAM and all of the hard
drives of the PCs connected to the Novell server? That would be fair,
because after all, those PCs were still running their *own* operating
system.
Are you going to count the cost of those individual PCs too? You should -
you are comparing an AS/400 with 100 users against a file server with
100 PCs attached .. Compare the whole package!!
|>
|> As for I/O speed, a fast/wide SCSI-2 card with a coprocessor will blow
|> any model of AS/400 out of the water (for less than a tenth of the cost).
Hmm, you know, I think we use quite a bit of those. Right along with:
[1] Special memory to ensure that pointers are actually pointers, not
copies that somebody created to try to hack the system.
[2] The service processor that allows the system to automatically turn
itself on and off on a given schedule (ie: not just a simple reboot),
displays diagnostic info when the machine goes belly up (which most
people never see), etc.
[3] Well made enclosures that can survive being dropped off of loading
docks, stabbed by forklifts, etc.
I don't design the hardware, so I'm sure that there is a lot more
tender loving care that goes into the physical design of a 400. It's
not just a few SCSI cards thrown together ...
|> The AS/400 is a successful machine because it has three letters on its
|> side. Aside from prompting and command definition, what else is good
|> about it? I can only think of:
|>
|> 1. Reliability
|> 2. Auto-configuration of devices (plug'n'play)
|> 3. Altered pointer bit
|>
|> Everything else is either poorly designed, attrociously implemented, or
|> otherwise ruined by compromises. (This category includes things like
|> the single-image storage, which buys the user absolutely nothing in
|> the final evaluation--the Unix boxes run circles around it despite
|> their cache problems).
|>
|> I really would like to believe the hype that IBMers tell themselves
|> about the AS/400. But after looking at 10,000 pages of documentation
|> and being apalled at how difficult it is to do trivial things, I can
|> only conclude that the whole business is a scam.
|>
|> mark
|>
Ok Mark, in your informed opinion it is a scam. I guess you won't be
one of our customers then. From somebody who doesn't know the difference
between a file server and an operating system, I don't expect much.
As I've said before, it's not a hackers box, and it is a poor
development platform. On the other hand, it does what it was designed
to do very well. And that's why it sells so well.
Mike
Michael Wojcik
>In article <4e6n3j$k...@microl4.microlise.UUCP>,
>Andrew Gierth <and...@microlise.co.uk> wrote:
> >tasks. It might have (indeed does) have great I/O performance, but as
> >soon as you need to really process your data rather than just shuffle it
> >around, you can forget it.
>
Those "backward" mainframes still do most industrial DP -- managing
large data sets, moving financial transactions, etc. The "mentality"
behind the 400 was "let's give S/36 and S/38 customers an upgrade
path they'll buy into rather than switching to something we don't
own". And IBM did. If I were an IBM stockholder (and I would be,
had I had the $$$ back when it was selling for < $60 a share...),
that's precisely the mentality I'd want to see. The 400 is a cash
cow.
>CPU performance is important in a distributed environment, even for things like
>communication. If you want to do fast networking, you are looking at great
>overhead for marshalling data into datagrams, encryption, buffer copying and
>the like. Fast CPU's are not just for graphics and compiling.
This is a swell theory, but in fact old SNA networks run by old machines
with slow CPUs continue to push an awful lot of enterprise data around.
I like a fast CPU as much as the next guy, and I'm not eager to do
more development on the 400 anytime soon. But I've seen enough real-
world computing to know that no one has yet built a hardware-software
combination that's ideal for every task. Those 400s and mainframes
have their niches.
>I'd love to see what an AS/400 would do if that 486/100 flooded it with
>packets over a 100MB/s data link.
It processes them. Not worth seeing, really.
> >There are a couple of specific cases where programs on the AS/400 take
> >really *stunning* performance hits. One of these is procedure call
> >overhead. I have timed a particular ILE procedure call at 25us per call
> >on an (admittedly obsolete) E10; this is easily 100 times slower than
> >the same call on a 486DX4-100.
>
>Sheesh, I can probably just about fork() a Linux process in that time.
How quickly does your Linux box bind SNA LU6.2 independent sessions to
VTAM?
The 400 is lousy at a lot of things. That doesn't mean it's useless.
Linux is good at a lot of things. That doesn't mean it's perfect.
Mark Woodruff
>>I remember an 8 mhz 8086 supporting 40 users 14 years ago
>>at CitiCorp. All it takes is hardware...
>time. They can hardy handle one job.
They were all interactive sessions. Citicorp had all their asynch
terminals running into a master concentrator, which was tied directly
to the Altos running Unix (System III?) and their other systems.
It was a strange system. But I didn't know anything about Unix at the
time; I was busy keeping their funds-transfer system running on a pair
of Series/1 processors. (Another IBM system with a remarkably slow
processor. The Series/1 made up for it by sticking additional processors
on each communications card to handle the load. I believe the newer
AS/400 use the same I/O system copied from the Series/1.)
mark
Mark Woodruff
>You can pick on the hardware or pick on the code gen, it really doesn't
>matter. Spouting numbers off is useless. If you can provide the
>insight as to why the numbers appear that way, then something is learned.
Why is it that, having created the hardware base you did, IBM created
such a crappy operating system? Why SEU when IBM already had Xedit? Why
such a poorly integrated file-system? Why the Roll Up/Page Up swap?
Why are F7 and F8 recognized but ignored? Why create a system that at
the outset is already inferior to all your other systems except in one
respect?
My conclusion is that IBM, like so many companies, does its absolute best
to give its customers the absolute least even when it costs them more
to do so.
mark
Mark Woodruff
>No! It takes software too ..
>What rebuilds the database indexes when the machine crashes?
If it's a modern database, nothing; the indexes are never corrupted
because of journaling.
>What part of the operating system tries to prevent the
>machine from crashing?
If one of the bits in your PSW register sticks, what part of OS/400 will
prevent it from crashing?
>Measure the whole package
I do, and I find it lacking. Just like I find GM lacking when they ship
their cars with defective bearings, or ones that explode when hit from
behind. The issue is excellence and quality, two words that can't be
associated with OS/400.
>Benchmarking the editing, compiling and copying of files is deceptive.
>That all depends on cache effects, the compilers used, and the
>underlying operating system.
Yet I get totally consistent results (only user on the system, all other
subsystems shut down)?
>It is great to note the difference, but
>don't just stop there - ask why. Did it occur to you that the overhead
>of our operating system penalizes small jobs, but on longer jobs the
>overhead becomes negligible?
Why design such a system when you can do the same thing without the
overhead?
>Does your 486 with it's operating system
>provide the same function?
No, the operating systems I've used with a 486 did not provide the
feature of being deplorably slow.
>On the other hand, we are discussing features and benchmarks.
>Saying that the 400 runs like a 1mhz 486 is rediculous. And then
>saying that it is all a magazine ad illusion because you can't
>make effective use of it is even worse ... That discounts the
>experience of everybody else in the universe who does make
>productive use out of it.
I've twisted many operating systems to get them to do what I wanted. But
when one is intentionally designed to prevent people from using it, as
OS/400 must have been given the wealth of research into operating
systems and human/machine interactions, I gotta flame it.
I'll give credit to anyone who has tried to do anything productive with
an AS/400. But I won't give credit to scum who perpetuate a value system
of mediocrity at any cost.
>Anybody who purports to have used VM before should not have a problem
>with OS/400. One version of cryptic is just as bad as another.
VM is easier to use than OS/400. It isn't certainly isn't *easy* to use,
but it is easier to use--it's original designers made efforts to make
it as easy to use as they could. OS/400, being a later product, should
be even easier if IBM had any committment to quality. But it's not....
Your gloss reminds me of department heads defending their use of
foreign professors who did not speak english. "Well mathematics is
a difficult subject anway..."
>And what do you mean by "cheaper" and "gimmicks" ?
It's taken me a couple thousand lines of code to do something I regard
as trivial: pick an arbitrary spool file, read it in and interpret the
printer commands (SCS et al) displaying them in an easy-to-read
graphical format. And to add it to the WRKSPLF menu? I'll have to
rewrite it completely since almost none of the OS/400 menus have any
provision for extensibility. The design of OS/400 makes it difficult
to get my job done.
As for gimmicks, how 'bout advertising a "256 bit address" when nothing
in the system actually supports such pointers, or "super fast I/O" when
really all you have is fast/wide SCSI II?
>If your just out to bash the 400 for the heck of it, have a ball ...
I'd just like to bash one notion into IBM's heads: excellence. The idea
of doing your best. Markedly absent from the AS/400-OS/400 pair.
mark
Stefan 'Stetson' Skoglund
>>>>> "Allister" == Allister <aje...@nest.central.co.nz> writes:
Allister> Windoze! If it won't do the job, just upgrade next year.
You are killing baby seals i see.
--
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund I |
sp2s...@ida.his.se I |
<http://www.his.se/ida/~sp2stes1/> I _____/0\_____
I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige I I-+-I O I-+-I
I
I Viggen with two Rb04
---------------------------------------------------------------------
Steve Farrell
man -k tape
man <whatever>
<..read..>
<dump, or whatever> &
...maybe this is why unix is more popular?
Jose Pina Coelho
>>>>> "Garry" == Garry Garrett <gar...@abii.com> writes:
Garry> Further more, the files are exported in EBCDIC
Garry> (a bit of a pain, but considering the rest of the NFS world
Garry> speaks ASCII, you would think they could have taken it into
Garry> account...).
Garry,
NFS does not export a file on ASCII (or EBCDIC) - it exports it in
binary, no interpretation whatsoever. If you 'say' a file is text,
then it's up to the user to convert it to the codepage he prefers.
The only part where NFS recognizes ASCII (text) representation is
in filenames - those are indeed ASCII.
PS: I don't speak for IBM - I'm not paid enough to do THAT !
--
PS: If you follow-up please check BOTH the Newsgroups and Followup-To lines
Jose Pedro T. Pina Coelho | TimeZone=NFT-1DFT
Internet: j...@ibm.pt | IBM Phone/Fax: (+351) (1) 7915709/7955588
IP Net: j...@pt.ibm.com |
VNET: PO21780 at LISBVM1 (alias j...@vnet.ibm.com)
AIX at LISBVM1 82221780 at EHONE
COELHO at WTSCPOK PTIBMZ2M at IBMMAIL
- If all men were brothers, would you let one marry your sister ?
Michael Brutman
|> >In article <woodruffD...@netcom.com>, netco...@netcom.com (Mark Woodruff) writes:
|> >|> longer to run equivalent benchmarks on the 30S running V3R1 than it does
|> >|> to run them on OS/2 Warp on my 100 Mhz 486 at home.
|> >
|>
|> then: editing, compiling, copying files, etc.
|>
|> >many multiple users by your 100 486 can't?
|>
|> thousands of dollars worth of extra hardware that is built in to the
|> at CitiCorp. All it takes is hardware...
No! It takes software too .. What rebuilds the database indexes when the
machine crashes? What part of the operating system tries to prevent the
machine from crashing?
There is more in the high initial cost of an AS/400 than the hardware
that you think can be thrown at a 486 .. There is a fairly fault tolerant
operating system underneath it.
Measure the whole package - find your hardware and accompanying software
that provides equivalent function, even when software bugs are hardware
faults are considered. Sure, the 400 doesn't crunch numbers as fast as
a technical workstation, but that isn't what we optimize it for either ...
Benchmarking the editing, compiling and copying of files is deceptive.
That all depends on cache effects, the compilers used, and the
underlying operating system. It is great to note the difference, but
don't just stop there - ask why. Did it occur to you that the overhead
of our operating system penalizes small jobs, but on longer jobs the
overhead becomes negligible? Does your 486 with it's operating system
provide the same function?
|> >Don't you think that
|> >perhaps the benchmark is questionable?
|>
|> No, since it was a benchmark of activities I have to do every day on
|> the beast. If you have to do similar activities, the benchmarks would
|> apply to you to.
|>
|> >(Ever benchmark a Ferrari by parallel parking it?)
|>
|> A very good benchmark if you want to ever want to parallel park your
|> car. The Lamborghini Countach, for example, is a real bitch to park.
|> My coworker's Porche 930 takes 30 minutes to warm up or cool down at
|> times. These are important considerations if you want to own and use
|> a car rather than just look at it in a magazine.
|>
|> The black AS/400 looks quite snazzy in a magazine. But I find it nearly
|> impossible to do my work on it. Unlike the VM, MVS, RPS, and OS/2
|> machines I have used in the past.
|>
|> mark
(Heresy time)
I use Unix at work more than OS/400, and OS/2 is my operating system at
home. Like many people reading this, I find the user interface of the
400 substandard. I much prefer the Unix command line to the AS/400
command line. (Except for the prompting support on the 400 - that is
nice to have.)
On the other hand, we are discussing features and benchmarks.
Saying that the 400 runs like a 1mhz 486 is rediculous. And then
saying that it is all a magazine ad illusion because you can't
make effective use of it is even worse ... That discounts the
experience of everybody else in the universe who does make
productive use out of it.
|> I thing I could do anything with Xedit, Rexx, and Pipes under VM
|> faster, easier, and cheaper than with all the gimmicks in OS/400.
|>
Anybody who purports to have used VM before should not have a problem
with OS/400. One version of cryptic is just as bad as another.
And what do you mean by "cheaper" and "gimmicks" ?
If your just out to bash the 400 for the heck of it, have a ball ...
Michael Brutman
|> In <4e60rt$1b...@locutus.rchland.ibm.com>, bru...@bruteforce.rchland.ibm.com (Michael Brutman) writes:
|> >In article <woodruffD...@netcom.com>, netco...@netcom.com (Mark Woodruff) writes:
|> >|> >The newer Model 200s (black) are as much as 82% faster than the small
|> >|> >F series, and I think you got something even earlier than an F. The RISC
|> >|> >models (the current ones) are of course, can be as much as three times
|> >|> >faster than the black CISC models.
|> >|>
|> >|> longer to run equivalent benchmarks on the 30S running V3R1 than it does
|> >|> to run them on OS/2 Warp on my 100 Mhz 486 at home.
|> >|>
|> >|>
|> >|> I hate being sick and not being able to sleep
|> >
|> >many multiple users by your 100 486 can't? Don't you think that
|> >perhaps the benchmark is questionable?
|>
|> give it a real operating system, and it tanks along quite nicely, thank
|> you very much. And for a fraction of the cost of even a small AS/400.
|>
|> but his benchmark is probably different... (BTW, Mark, what _is_ your
|> benchmark?)
|>
|> tasks. It might have (indeed does) have great I/O performance, but as
|> soon as you need to really process your data rather than just shuffle it
|> around, you can forget it.
|>
|> really *stunning* performance hits. One of these is procedure call
|> overhead. I have timed a particular ILE procedure call at 25us per call
|> on an (admittedly obsolete) E10; this is easily 100 times slower than
|> the same call on a 486DX4-100.
|>
I think that you are comparing apples to oranges. You are not
comparing the relative strenghs of the processors. You are
comparing code gen. There is quite a difference.
On the older AS/400s, the processors were pretty weak. No doubt about it.
But then again, we don't sell AS/400s for technical computing - we sell
them for the "commerical" environment (whatever that means) .... And
in a commercial environment, the trick is to be able to move the data
around efficiently, not to do Fast Fourier Transforms on somebody's
order of canned jelly.
The code gen differences are also a reflection of the design philosophy.
ILE C adds a lot of overhead to procedure calls, most of it to support
hooks for the operating system. We provide a lot of trace support and
operating system integrity checks at procedure boundaries that don't show
up on Unix boxes, and unfortunately it shows up in our call overhead.
On the other hand it gives the system that legendary stability that
people buy it for.
You can pick on the hardware or pick on the code gen, it really doesn't
matter. Spouting numbers off is useless. If you can provide the
insight as to why the numbers appear that way, then something is learned.
|> -- Andrew (and...@microlise.co.uk)
Kevin A. Gloff
>How good is AS/400's interactive job control? Let's see how you would run a
>
>
>
>
Submit it to batch and forget it until it has finished!
Christopher Robato
uff) writes:
:>
:>In <4e60rt$1b...@locutus.rchland.ibm.com>, bru...@bruteforce.rchland.ibm.com (Michael Brutman) writes:
:>>In article <woodruffD...@netcom.com>, netco...@netcom.com (Mark Woodruff) writes:
:>>|> longer to run equivalent benchmarks on the 30S running V3R1 than it does
:>>|> to run them on OS/2 Warp on my 100 Mhz 486 at home.
:>>And just what benchmark was that?
:>
:>It was a series of benchmarks doings things that I needed to do right
:>then: editing, compiling, copying files, etc.
:>>Why is it that an AS/400 can support
:>>many multiple users by your 100 486 can't?
:>A 486 can easily support hundreds of users if you add the tens of
:>thousands of dollars worth of extra hardware that is built in to the
:>AS/400. I remember an 8 mhz 8086 supporting 40 users 14 years ago
:>at CitiCorp. All it takes is hardware...
Actually a multiple port serial board, lots of terminals, and a decent
multiuser OS. That machine you just described sounds like something running
M/PM-86 on an S-100 bus. Too bad Digital Research went extinct. Those S-100
cages can support a good number of serial boards, and some of them have their
own processor like a Z80 or something.
Mainframes used to support hundreds of users for the same amount of memory
you have with PCs now. A lot has to do with the OS. Unfortunately MVS and
it's ilk don't run on Intel processors. Most of the current Unices use too
much memory to support hundreds of users for the maximum amount of memory a
typical PC board can support, unless, perhaps, you can find an old copy of
Xenix.
:>>Don't you think that
:>>perhaps the benchmark is questionable?
:>
:>No, since it was a benchmark of activities I have to do every day on
:>the beast. If you have to do similar activities, the benchmarks would
:>apply to you to.
:>
:>>(Ever benchmark a Ferrari by parallel parking it?)
:>
:>A very good benchmark if you want to ever want to parallel park your
:>car. The Lamborghini Countach, for example, is a real bitch to park.
:>My coworker's Porche 930 takes 30 minutes to warm up or cool down at
:>times. These are important considerations if you want to own and use
:>a car rather than just look at it in a magazine.
:>
:>The black AS/400 looks quite snazzy in a magazine. But I find it nearly
:>impossible to do my work on it. Unlike the VM, MVS, RPS, and OS/2
:>machines I have used in the past.
:>
:>mark
:>
:>I thing I could do anything with Xedit, Rexx, and Pipes under VM
:>faster, easier, and cheaper than with all the gimmicks in OS/400.
:>
There are things the AS/400 can do painfully slow. It's damn slow to boot
up. It takes you a day to upgrade the OS, and an entire evening to install a
licensed program. I don't think it's the hardware, but the way the operating
system works, which may treat objects like the French bureaucracy. I think
it has to verify, register, bind, link and whatever on every object that is
created in the system by installation or compilation. If it's slow,
it's doing a lot more.
On the other hand, that thing eats databases like sandwiches. I used to run
a database that took a few hours to index and sort on a PS/2 with
a 486SLC-75 and a SCSI drive. That same database, now with more records and
a magnitude more fields added, now takes about 10 minutes to do that
process on a Model 200/2031. When that thing takes multiple query hits from
many users, it shrugs it off without a sweat, with near instantaneous
response.
Rgds,
Chris
*>>>Vote OS/2 for Presidential OS, Campaign '96<<<*
***** cro...@kuentos.guam.net *****
I don't really advocate OS/2. I actually advocate Productivity.
I just don't see the difference between the two.
[[[ Anime .sig follows ]]]
"Ai no, Seigi no, Sailor fuku bishoujo senshi, Sailor Venus!"
"Sanjyo Yo!"---Minako Aino, Code Name wa Sailor V!
Dan Hicks
>Why is it that, having created the hardware base you did, IBM created
>such a crappy operating system? Why SEU when IBM already had Xedit? Why
>such a poorly integrated file-system? Why the Roll Up/Page Up swap?
Actually, SEU predates XEDIT by several years. The roll up/page up
confusion is purely a terminal issue -- some terminals have the keys
backwards. ("Backwards" being defined primarily in comparison to the PC
-- which was introduced more than a year after the S/38.) Most
reasonable emulator packages map the keys the way you expect them.
>Why are F7 and F8 recognized but ignored? Why create a system that at
>the outset is already inferior to all your other systems except in one
>respect?
Alas, the F keys have been jerked around several times in the name of
"standardization". The original S/38 mapping was a lot more intuitive,
but the mappings were changed when SAA swept the company during initial
AS/400 development.
Dan Hicks
http://www.millcomm.com/~danhicks/
Jorma F. Korkiakoski
>How quickly does your Linux box bind SNA LU6.2 independent sessions to
>VTAM?
I'd rather ask: How quickly does you AIX box bind SNA LU6.2
independent sessions to VTAM?
Answer: Two weeks that it takes to configure the connection
on the mainframe.
--
And George can't dance.
Christopher Robato
tes:
:>
:>In <4eb5mq$m...@locutus.rchland.ibm.com>, bru...@bruteforce.rchland.ibm.com (Michael Brutman) writes:
:>>No! It takes software too ..
:>>What rebuilds the database indexes when the machine crashes?
:>If it's a modern database, nothing; the indexes are never corrupted
:>because of journaling.
:>
:>>What part of the operating system tries to prevent the
:>>machine from crashing?
:>
:>If one of the bits in your PSW register sticks, what part of OS/400 will
:>prevent it from crashing?
:>
And tell me how that will ever happen in the AS/400?
:>>Measure the whole package
:>
:>I do, and I find it lacking. Just like I find GM lacking when they ship
:>their cars with defective bearings, or ones that explode when hit from
:>behind. The issue is excellence and quality, two words that can't be
:>associated with OS/400.
:>
:>>Benchmarking the editing, compiling and copying of files is deceptive.
:>>That all depends on cache effects, the compilers used, and the
:>>underlying operating system.
:>
:>Yet I get totally consistent results (only user on the system, all other
:>subsystems shut down)?
:>
:>>It is great to note the difference, but
:>>don't just stop there - ask why. Did it occur to you that the overhead
:>>of our operating system penalizes small jobs, but on longer jobs the
:>>overhead becomes negligible?
:>
:>Why design such a system when you can do the same thing without the
:>overhead?
Why run a vehicle with four wheels when you can do it with two?
:>
:>>Does your 486 with it's operating system
:>>provide the same function?
:>
:>No, the operating systems I've used with a 486 did not provide the
:>feature of being deplorably slow.
:>
How about the feature of crashing?
:>>On the other hand, we are discussing features and benchmarks.
:>>Saying that the 400 runs like a 1mhz 486 is rediculous. And then
:>>saying that it is all a magazine ad illusion because you can't
:>>make effective use of it is even worse ... That discounts the
:>>experience of everybody else in the universe who does make
:>>productive use out of it.
:>
:>I've twisted many operating systems to get them to do what I wanted. But
:>when one is intentionally designed to prevent people from using it, as
:>OS/400 must have been given the wealth of research into operating
:>systems and human/machine interactions, I gotta flame it.
And what do you mean by this? OS/400 certainly does let me use it. I got
"non-computer" people using it.
:>
:>I'll give credit to anyone who has tried to do anything productive with
:>an AS/400. But I won't give credit to scum who perpetuate a value system
:>of mediocrity at any cost.
:>
:>>Anybody who purports to have used VM before should not have a problem
:>>with OS/400. One version of cryptic is just as bad as another.
Cryptic? Are talking of the same OS here?
:>
:>VM is easier to use than OS/400. It isn't certainly isn't *easy* to use,
How? Easy enough to keep a staff religeously around it?
:>but it is easier to use--it's original designers made efforts to make
:>it as easy to use as they could. OS/400, being a later product, should
:>be even easier if IBM had any committment to quality. But it's not....
I don't know about VM, but in my business, I don't keep any tech heads,
gurus, or high priests here. While I control the QSECOFR strings, all my
employees---many of them have no PC experience---don't have problems running
the system.
Now tell me again if the AS/400 is hard to use.
:>
:>Your gloss reminds me of department heads defending their use of
:>foreign professors who did not speak english. "Well mathematics is
:>a difficult subject anway..."
:>
:>>And what do you mean by "cheaper" and "gimmicks" ?
:>
:>It's taken me a couple thousand lines of code to do something I regard
:>as trivial: pick an arbitrary spool file, read it in and interpret the
:>printer commands (SCS et al) displaying them in an easy-to-read
:>graphical format. And to add it to the WRKSPLF menu? I'll have to
:>rewrite it completely since almost none of the OS/400 menus have any
:>provision for extensibility. The design of OS/400 makes it difficult
:>to get my job done.
Why do you want to change an OS/400 menu? Why not make one your own? The
OS/400 isn't intended to be hacked, changed or modified.
:>
:>As for gimmicks, how 'bout advertising a "256 bit address" when nothing
:>in the system actually supports such pointers, or "super fast I/O" when
:>really all you have is fast/wide SCSI II?
Yeah right. Except that the controller comes with its own RISC chip and runs
the bus through fiberoptics.
Not your everyday Adaptec.
Rgds,
Chris
* * * Sailor Moon Joins Team OS/2 * * *
Holding Warp CD ROM up, she shouts, "Warp 32 bit Power, Transform!"
Serena turns into Sailor Moon. The Sailor Team OS/2 gals crashes the
Red Moon Palace. Sailor Moon threatens the evil Queen Beryl Gates.
"In the Name of I-B-Moon, I shall right FUD and that means you!"
>>>> cro...@kuentos.guam.net <<<<
Kazimir Kylheku
Michael Ozanne <moz...@pcsngb.demon.co.uk > wrote:
>In article <4e8cff...@keats.ugrad.cs.ubc.ca>
> c2a...@ugrad.cs.ubc.ca "Kazimir Kylheku" writes:
>
>*How good is AS/400's interactive job control? Let's see how you would run a
>*command as a background job.
>Suppose I want to initialise a tape as a background job and
>don't know how to do it
>Find a command line press F4 to see a list of major command groups.
>See option 8 "Work Management Commands and select it
>See option 2 "Job Commands" and select it.
>see option 38 "Submit Job" and select it
>See prompt "Command to Run" and don't know what to do
>Press F4 to see major command groups
What if my terminal doesn't have function keys that jive with the AS/400? I
have heard that support for non-IBM terminals is flakey. You'd think they'd
have the good sense to use some sort of printable characters or standard
control keys.
>See Option 8 "Data Management Commands" and select it
>See Option 12 "Tape Commands" and select it
>See Option 11 "Initialise Tape" and select it
>Enter Tape device name and other details (all with prompted
>context sensitive help if necessary) press enter. the command
>Inztap and its parameters are then carried back to the
>"Command to Run" prompt of the Sbmjob command. Press enter
>and the Command Inztap is submitted to run in background.
>
>Those of us with a bit of practice type in
>sbmjob cmd(inztap dev(*device name*) newvol(*volume name*)
>check(*no) clear*(yes)) *enter*
Heh, so I have to learn Lisp to use AS/400? I'm not exactly an avid
Emacs user. ;)
>Those with even more practice will have created a command
>that submits the job with its parameters.
>
>Is this what you mean by running a command as a background job.
>If not sorry for spending the bandwidth :-)
Now compare UNIX:
mt erase &
That works on the /dev/tape device by default. If you want some other device,
say /dev/othertape.
mt -f /dev/othertape erase &
Submitting jobs? If I wanted to play mainframe, I'd use "at" or put the job
into my crontab:
shell_prompt$ at 12:35
mt erase<Enter Ctrl-D>
Job c00d143b3.00 will be executed using /bin/sh
shell_prompt$ atq
Date Owner Queue Job#
12:35:00 01/28/96 kaz c c00d143b3.00
The tape will start erasing at 12:35. The way I see it, typing "at 12:35"
followed by a simple command to run is easier.
I was talking about more interactive job control, however, such as the ability
to simply background a job while retaining its association with my
terminal---not the submission of jobs into batch queues. Under UNIX, I can
choose to have such a program block whenever it wants to do output to the
terminal or to just spam the terminal whenever it feels the urge. I can
"foreground" it at any time, and "background" an already executing program (any
job). It's all part of POSIX job control. So the proper question to ask would
be whether OS/400 supports an open standards like POSIX.1 and POSIX.2, and more
specifically, POSIX job control.
--
Kazimir Kylheku
Michael Wojcik <m...@raederle.mfltd.co.uk> wrote:
>In article <4e89sh...@keats.ugrad.cs.ubc.ca> c2a...@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
>>In article <4e6n3j$k...@microl4.microlise.UUCP>,
>>Andrew Gierth <and...@microlise.co.uk> wrote:
>> >tasks. It might have (indeed does) have great I/O performance, but as
>> >soon as you need to really process your data rather than just shuffle it
>> >around, you can forget it.
>>
>
>Those "backward" mainframes still do most industrial DP -- managing
>large data sets, moving financial transactions, etc. The "mentality"
>behind the 400 was "let's give S/36 and S/38 customers an upgrade
>path they'll buy into rather than switching to something we don't
>own". And IBM did. If I were an IBM stockholder (and I would be,
>had I had the $$$ back when it was selling for < $60 a share...),
>that's precisely the mentality I'd want to see. The 400 is a cash
>cow.
>
>>CPU performance is important in a distributed environment, even for things like
>>communication. If you want to do fast networking, you are looking at great
>>overhead for marshalling data into datagrams, encryption, buffer copying and
>>the like. Fast CPU's are not just for graphics and compiling.
>
>This is a swell theory, but in fact old SNA networks run by old machines
>with slow CPUs continue to push an awful lot of enterprise data around.
Encrypted, secure enterprise data? Real-time multimedia kind of data? Or just
little 100 byte employee records containing COBOL-format dollar amounts?
How well do these networks integrate diverse platforms? Isn't it true that
everything else has to be bent toward supporting the SNA network rather than
vice versa?
>I like a fast CPU as much as the next guy, and I'm not eager to do
>more development on the 400 anytime soon. But I've seen enough real-
>world computing to know that no one has yet built a hardware-software
>combination that's ideal for every task. Those 400s and mainframes
>have their niches.
Yes, stemming more from entrenchement than anything else.
>>I'd love to see what an AS/400 would do if that 486/100 flooded it with
>>packets over a 100MB/s data link.
>
>It processes them. Not worth seeing, really.
What if they were encrypted? I guess you could hire some EE whipper snapper to
wire you up a custom piece of hardware to do the decoding fast enough to keep
up. That's so much easier than using existing, portable software.
>> >There are a couple of specific cases where programs on the AS/400 take
>> >really *stunning* performance hits. One of these is procedure call
>> >overhead. I have timed a particular ILE procedure call at 25us per call
>> >on an (admittedly obsolete) E10; this is easily 100 times slower than
>> >the same call on a 486DX4-100.
>>
>>Sheesh, I can probably just about fork() a Linux process in that time.
>
>How quickly does your Linux box bind SNA LU6.2 independent sessions to
>VTAM?
Like, who cares...
>The 400 is lousy at a lot of things. That doesn't mean it's useless.
>
>Linux is good at a lot of things. That doesn't mean it's perfect.
Says it all.
--
Kazimir Kylheku
Christopher Robato <cro...@kuentos.guam.net> wrote:
>On the other hand, that thing eats databases like sandwiches. I used to run
>a database that took a few hours to index and sort on a PS/2 with
>a 486SLC-75 and a SCSI drive. That same database, now with more records and
>a magnitude more fields added, now takes about 10 minutes to do that
>process on a Model 200/2031. When that thing takes multiple query hits from
>many users, it shrugs it off without a sweat, with near instantaneous
>response.
Maybe that's because you used OS/2 on the SLC-75. OS/2 has a brainless static
cache system. Tasks that can potentially cause a lot of head seeks take far
longer under OS/2 than under FreeBSD or Linux; from personal experience I'd
guess about 5 to 10 times slower.
Also, it could easily have had something to do with the algorithms used in the
indexing. You don't even say whether it was the same indexing method, and
whether the records were indexed on the same category on both machines, or how
much RAM was available to the indexing process on the 486 vs. the AS/400.
--
Richard D Phillips
and S36 etc. I thought I would comment.
We have been running IBM S32, 34, 36, and A/S 400 hardware since
1977. We have experienced 8 hours of unplanned downtime for two
disk replacements on a 9335 disk set on the A/S 400. Typically the
only time we shut down is for a RCLSTG prior to a Version / Release
install. Knock on Wood.
Regarding Inventory Control on the A/S 400. We are an "old style"
RPG only shop with about 40 % of our application mix running
"inventory control" both typical "count/move" and not so typical
"produce/use" applications. Chemical conversions for liquids and
solids, lot tracking, and recall procedures are what typically give
most canned software the hardest time. SSA or SAA (I never can
keep that company name straight) and Prizm are both very nice
packages.
We are currently running in parallel with a ES9000 with R2 SAP and
R3 SAP on some big HP9000 servers. They can not handle liquid to
solid conversions. Other than that, SAP is very complete and
really overkill for most small to mid-size companies.
Litrik De Roy
MW> In <4e1vh6$1...@lehi.kuentos.guam.net>, cro...@kuentos.guam.net writes:
MW> The newer Model 200s (black) are as much as 82% faster than the smallF
MW> series, and I think you got something even earlier than an F. The RISC
MW> models (the current ones) are of course, can be as much as three times
MW> faster than the black CISC models.
MW> Our 30S clocks in as equivalent to a 1 Mhz 486. It takes 100 times
MW> longer to run equivalent benchmarks on the 30S running V3R1 than it
MW> does to run them on OS/2 Warp on my 100 Mhz 486 at home.
Do you use your AS/400 to run benchmarks or to run your business ?
Please keep silly comparisons out of this newsgroup. Thanks.
___
{~._.~} Litrik De Roy
( Y ) Home : lit...@nbre.nfe.be
()~*~() Work : lit...@be.ibm.com
(_)-(_) Fido : 2:292/603.61
... They say the best in life is free,
but if you don't pay then you don't eat.
- Bryan Adams / Another day
Mario Klebsch
>In <4e6n3j$k...@microl4.microlise.UUCP>, and...@microlise.co.uk (Andrew Gierth) writes:
>>You might be surprised at how many users a 100MHz 486 can support. Just
>>give it a real operating system, and it tanks along quite nicely, thank
>>you very much. And for a fraction of the cost of even a small AS/400.
>A 25 Mhz 486 supported over 100 users using Novell 3.1 (256 mbytes ram,
>many gigabytes dasd) where I used to work.
Users on a PC running Novel 3.1?
Doesn't it just serve the disks and printers? I never heard of a
multi-user OS for PC's from Novel other than UNIX. Is Novel 3.1 the
Novel UNIX or is it something else?
73, Mario
--
Mario Klebsch, DG1AM, M.Kl...@tu-bs.de +49 531 / 391 - 7457
Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany