Re: V5R2: Source now allowed in the IFS

On Fri, 18 Oct 2002, Mark Waterbury wrote:

> The real problem with all these IFS path names is that the path can
> contain an arbitrary number of "levels" of subdirectory, before you
> even get to the actual file name, which in and of itself can be very
> long... the architected "limit", by the way, if you can call it that, for
> IFS path names in OS/400 is 16 Megabytes! (16 million+ characters)

I honestly don't know why anyone would care that the path to the original
source is stored in the binary?  What is the big deal?  Being able to use
the IFS to store source code adds a great deal of flexibility and opens a
new range of options for working on the iSeries.  I don't see how "all
these IFS path names" are a problem.  Please enlighten me.

> Unix weenies in the Unix world rely on "naming conventions"
> to find the corresponding source file for a given executable file.
> Crude utilities like "make" rely on the file date/time stamps, using
> the file system as a primitive database, to determine what changed,
> and hence, what objects need to be recreated from "corresponding"
> (by name only) source files.
>
> Why must we drag OS/400 down to this same level of functionality
> (the "lowest common denominator") in the name of strict Unix or
> Posix compatibility? Ugh!

Easy there.  What to you is dragging down is to me raising up.  Certainly
no functionality has been removed from the iSeries, rather useful features
have been added.  Features like these make the iSeries *more* useful, not
less.

Now let's look a little at what you've said:

"the Unix world rel(ies) on "naming conventions" to find the corresponding
source file for a given executable file."

Not really correct.  An executable file is one with the execution bit set.
But that executable file may itself be source code.  That's what scripts
are.  So no naming convention, the executable *is* the source code.

Ah, but what about compiled languages?  This is probably what you are
talking about.  It is common to compile things like this:

cc -o program program.c

This indicates that the source file program.c should be compiled to
produce the executable program.  The name of the resulting compiled code
is specified in the compile command.  But wait!  The AS/400 does the same
thing:

CRTBNDRPG PGM(MYLIB/TESTPGM) SRCFILE(MYLIB/QRPGLESRC) SRCMBR(TESTPGMSRC)

The command defaults to give the resulting compiled code the same name as
the source, but it certainly doesn't have to be this way - it is just a
naming convention.

So why doesn't the unix 'cc' command default this way, too?  Well it
doesn't, and that sucks.  But few people run cc directly.  Most everyone
uses make, and make does this quite nicely:

make program

But you don't like make!  You said:

"Crude utilities like "make" rely on the file date/time stamps, using the
file system as a primitive database, to determine what changed, and hence,
what objects need to be recreated from "corresponding" (by name only)
source files."

Well, every filesystem on earth is a primitive database, so nothing new
there.  But look what make does: it "determine(s) what changed, and hence,
what objects need to be recreated" - brilliant!  That's just what it is
supposed to do.  The relationships required to understand how something is
built are defined in a file (justly called Makefile).  I don't see how
this is crude.  It seems rather advanced to me.  I would love it if the
iSeries would notice that I've changed the source to a file and issue the
appropriate CRTPF command for me when I run CRTBNDRPG.

But make isn't needed very much on the iSeries, not because the iSeries is
immune to the problems that make solves, but because not many iSeries
programs rely on large numbers of source members to build.  You don't
really need a powerful make utility if you use one source member to create
one program.  But you do if you have 50 source files that together all
build to one executable.  An extreme example is the Linux kernel -
hundreds of source files all compile down to just one executable.  This is
only possible because make exists.

I am honestly interested in knowing why putting source in the IFS creates
problems.  I just don't see it.

(and be cautious about calling people weenies - perhaps someday "all your
servers are belong to us"  BUWAHAHAHA!! :^) )

James Rich