AS/400 How does it look?

William Muriithi william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Wed Aug 27 23:37:08 UTC 2008


Terry,

Many thanks for your explanation. I am now more knowledgeable on
AS/400 platform. You really did a good job and I noticed it triggered
some serious conversation over there. It did even get off topic and
become car technology discussion. Noticed a lot of people there still
think a solid car is safe. Someone corrected them very well, an easily
collapsible car is far much safe.

Regards,

William

2008/8/27 Terrence Enger <tenger-P1ovA8G34VBEfu+5ix1nRw at public.gmane.org>:
> 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
>
--
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





More information about the Legacy mailing list