Re: QSHELL commands (was: Stmf copy with add) -- MIDRANGE-L

<SNIP>
An equally interesting topic is why the *$#% IBM decided to go with such a
flat filesystem.  I honestly don't understand or know of any reason to do
so.  It seems to me that a deep filesystem (one with many levels of
directories) is an advantage.
<SNIP>
James Rich
james@eaerich.com

-------------------
<SNIP>

Yes...  I've always thought that that was a mistake on IBM's part.  But,
you do have to remember that the origins of the IBM midrange computer's
filesystems go back to punch cards.

If you had been using punch cards for 10 years, you might find that a
filesystem like UNIX or even DOS uses would seem inordinately complicated.
Having to write your programs to account for varying length directory
names would make it significantly more complicated for the programmers.

Sure, for todays generation, the OS/400 filesystem seems too flat.  But,
when you think about what things were like 30 years ago, you begin to
see why...
SNIP>

Scott Klement
-----------------------------------

Scott, James

This got to be long winded, I apologize in advance.

This has been a very very enlightening discussion for me.  To see how
different the Unix type mindset is, how it approaches computer systems. The
mental divide between Directory File systems and RDB orientated
systems(among many other differences).

James,
Believe it or not,  the "Shallow Path length" was NOT an oversight. It has
nothing to do with being 23 years old, nor Punched Cards".    The
architecture of OS/400 with it's library concentric design was a goal not
an after thought.  As someone else pointed out much of it has to do with
Object Orientated design along with the RDB concentracism.

I will address the "Flat DB" in a second, but first,  the Object thing.  In
OS/400 each object type(*PGM, *FILE, *JOBQ, *ETC) are really like OO Java
Classes to a degree.  In that You cannot Call or Execute a *FILE type(it's
an invalid Method so to speak), and You cannot OPEN a *PGM Object as a File
type.  This concept is very fundamental to understanding why everything
else is like it is. (It really doesn't matter if the underlying program
plumbing was originally written in an OO Language from the outside world's
usage of the "Things").

We don't have a VTOC, You can't see where ANYTHING is on disk(ie Thru
mortal human means Leif).

On Most Directory File systems(*nix, DOS, etc)  You can write a C program
and Read the First 100 bytes of a .EXE type file and the OS would say
"Sure, if you want to and you have rights to it, here it is"   And likewise
you can masquerade a program as a .TXT if you want and then evoke it
somehow and the OS most of the time would allow it.

The above I believe is one precept that Viruses love to exploit.  That is
also why those types of things have a very hard time with OS/400.

Now the :Flat File System thing.

Bearing in mind that EVERYTHING was implemented as an Object. Object's were
'Tied" to a "Locale" or Library in our case.  Every Object was "Owned" by a
Library.  Since RDB files were just another Object(acually about five
internal objects)  so they also belonged to a "Library".

First, and this is not a small point,  Unix was developed by programmers
for engineering/scientific/computer science type of design point.

OS/400 (CPF really)  was designed first and foremost with a business
application system as a design point.  Meaning, EVERYTHING was designed
around DATA ! The Capture, Storage, Retrieval, Manipulation, and usage of
Business DATA.

This is the same design point of ORACLE, DB2(on what ever platform you use
it) and any other RDB.

The only difference between OUR DB and the others is that our DB was
designed at the same time, by the same people who were also AT THE SAME
TIME designing the Security, Programming Model,  Task Dispatching(via
Messages btw) and every other thing you see in the basic make up of OS/400.
(it wasn't even a named DB until just a few years ago and got labeled DB2.
I imagine if it were named today, The powers that be would have named it
"Websphere RD for the iSeries" or something)

On the Mainframe, Unix, it's like One group built a Car and then afterwards
went shopping for an engine.
While the OS/400 car was designed AROUND the engine.

So, The Library List structure of resource searching was much simpler and
easier FROM A BUSINESS APPLICATION programming perspective.

After using Java and the IFS for a while with ClassPaths, and all,  I long
for a very simple Library List orientation.  It REALLY is how one is
"brought up" and what your "first groundings" in computers I believe that
make visible the stark differences of approach, and perspective of *nix
orientated people and OS/400 orientated people.

If you REALLY want the correct background and understand why this machine
is designed like it is Please buy a copy of " Inside the AS/400" by Frank
Soltis.   ISBN 1-882419-13-8

It really is a good read. He also goes into why Unix is like it is and
other computer designs as a comparison.

I think you will find it a very very good reading experience.


Another thing.  NO Users EVER see the Command line in most shops. Their
interface is application menus and business programs.  Our users have never
seen one.

After looking at this thread, I am in awe that we JUST went thru the GUI is
King, The GREEN SCREEN(ie character based command lines etc)  IS DEAD !
debates in this forum a little while ago.

Who would have thought that Linux,  The new darling of the media IS
CHARACTER BASED FOR CRYING OUT LOUD !!

Doesn't anyone else see any irony in this???????????


Respectfully
John Carr