AS/400 How does it look?

[Terrence Enger]

On Sat, 2008-08-23 at 14:42 -0400, William Muriithi wrote:
> Hallo there,
> 
> I happen to notice that a lot of Canadian companies uses IBM AS/400.
> However, I haven't been fortunate to come across it and I am curious
> how it look. Does it have any familiarity to Unix? What would be
> reason that make it more popular in Canada than in USA?
> 
> Just curious.
> 
> Regards,
> 
> William

Greetings,

I posted a message to an AS/400 mailing list on Sunday asking "What
should I say to a *nix community?"  The thread there has accumulated
more messages than anybody here would care about.  (Well, in case you
do care, the archives are at
<http://archive.midrange.com/midrange-l/200808/threads.html>.  Scan
for the question.)  Here I shall bring some points from that thread as
well as some of my own thoughts.


My first message to midrange-l copied William Munithi's question about
the relative popularity of the AS/400 in Canada compared to the US.  I
like the answer from Jon Paris ...

    It may or may not explain it, but Canadian companies tend to be
    smaller than comparable US companies and therefore less able to
    support the larger infrastructure that a Windows or Unix based
    solution would require.

    In my experience they also tend (like their European counterparts)
    to be a little more concerned with the practical utility of new
    hardware/ software/technologies/etc. than their American
    counterparts.  In other words there is a little less "management
    by airline magazine" going on in than in the USA.

and the response from Paul Nelson ...

    In other words, Canadians are smarter, eh?  :-))

Jon has experience in Canada, the US, and Europe.


Let me continue with a couple of "marketing" issues ...

The midrange community includes many passionate, even vociferous,
people.  A central "issue" for us is the platform's support for old
programs and old ways of working.  This is, on the one hand, a
valuable asset: companies with a large investment in software care
proportionatly about protecting that investment.  On the other hand,
this remarkable level of compatibility--about 3 decades back for
compiled objects, and considerable support for old-fashioned
skills--is seen to threaten the very existence of the platform by
encouraging disuse of modern capabilities.  On Mondays and Wednesdays
I agree with the former view; on Tuesdays and Thursdays I support the
latter one.  On Fridays, I can't make up my mind <grin />.

A closely related question is the name of our favourite platform.  The
earliest incarnation is the IBM System/38; the name AS/400 is well
known and indeed that is the name which William Munithi used when he
started this thread; the current name is IBM POWER System i (I think
<grin />).  The value (or otherwise) of backward compatibility at
least permits arguments based on ROI.  On the question of naming,
everybody wants to do whatever will best sell the system, but in the
absence of evidence the discussion includes a lot of "argument by
emphatic assertion".  For now, I declare that the new name has won.


Moving on to other issues ...

(*) People of average intelligence can run the system.  This is an
    important result of the architectural integrity of the system.  It
    just "makes sense".

    Windows administrators, in contrast, amaze me with the number of
    things they know.  Obviously, this is because I have not grasped
    their organizing principle, if any, but I know that I am not alone
    in this failure.

    As evidence for the simplicity of the Power System i, consider
    that the job title DBA is almost unknown in this environment.

(*) The system was designed from the ground up as a multi-user server
    with attention to scalability and profound attention to future
    viability.  "Of course" it is unmatched in reliability, security,
    and support for internationalization.


In this list, Christopher Browne mentioned "interesting aspects (in a
"CS geek" sense)".  Well, yes, now that you mention it, there are some
interesting design decisions ...

(*) According to Frank Soltis, the originator of the system, the
    design mistake hardest to fix is a too-small address space.
    System i is architected with an address space of 128 bits.

    Current implentations implement a mere 64 bits, but that has
    changed in the past and it can change again.  Implementation is a
    mere detail.  (And if you look at from the "right" level, a mere
    complete replacement of the implementation--giving vast increases
    in storage and processor power, hot swappable components, new
    packaging options, and lots more--is thin justification for
    changing the name of the platform, right?  I am writing this on
    Wednesday, remember.  <confession>I just do not know whether I am
    being serious or sarcastic here.</confession>)

(*) There is one address space for the whole system.  Some pointer
    manipulations become very expensive in comparison to similar
    operations under Linux.  On the other hand, task switching is very
    cheap, amounting to a GOTO instruction.  This is a commercial
    system, so it expects to do a lot of task switching.

(*) Pointers are differentiated by expected use.  A code pointer does
    not let you address data.  A data pointer does not let you execute
    code.  Can you say "resistance to stack-smashing"?

(*) Pointers are not data.  A program is free to change any or all of
    the bits in a pointer, but the result is no longer a pointer.
    There is simply no way to dereference the resulting bit pattern.
    Do you think this might improve system security?

    (This feature originated from a 32-bit word implemented with 8-bit
    memory chips.  The data needs four memory chips per word, but you
    want error correction--this is a commercial system--so you add a
    fifth memory chip.  But now you have one bit unused for each word.
    Behold, a "tag" bit to flag valid pointers.  The POWER processor
    provides hardware support for these tag bits.)

(*) The system is object-based.  Each of the many object types on the
    system supports its applicable methods, and by no means are the
    interchangeable.  For the most conspicuous example, files are
    files and programs are programs, and there is no way to update a
    program through the file methods.  Can you say "virus resistance"?

    ( Do not confuse this with "object-oriented": only IBM can define
    object types. )


The points are not exhaused, but I confess that I am.

Cheers,
Terry,
rent-a-geek and database-bithead.


--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists