Re: V5R2: Source now allowed in the IFS -- MIDRANGE-L

At 12:05 AM 10/19/02 -0600, you wrote:

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.

The reason for having that information, and a raft of other info, is
history of usage, KNOWing where something came from, so SCM apps can
function better. All the info you see in DSPPGM is stored in the object, or
in some closely-coupled object to the program. In DOS, e.g., there is an
archive bit - on the 400 there is info on how an object was saved, when,
date of last change (yes, that's in DOS-based and UNIX-based FS's, I
think). But am I rignht, that this stuff is not stored in the object but in
the directory, or maybe the FAT (or equivalent) or the FS inode (?). I'm
probably weak on the exact details.

There are advantages in terms of backup & recovery.

The newer ILE programs have added a new level of complexity. They can be
built by linking multiple modules, just as Unix & DOS folk are used to
doing. The resulting program object does not have a source file, per se,
but the object contains a list of the modules (like .o's) that comprise it,
and they contain the original source information inside each of them.

Other systems are adding more info in their executables. Win NT & following
have copyright stuff, descriptions, etc., in them now, if you put them there.

I think we'd be happy if there were a way to store the path name. Issue is
length. I believe it is probably possible but might be a change with wide
implications. Nonetheless, it might be a matter of adding a piece to
executables, a pathname section, just like IFS objects have now.

Just for fun, execute the DMPOBJ command on a *PGM object. You'll see a
spooled file with the various items that comprise a program. One will be
the OIR that was mentioned (it might stand for Object Information Record -
who knows for sure?). Part of that has the source information, if applicable.

And for more fun, try DMP on a *STMF. There's more stuff there, too, than
would normally be found on other systems.

HTH

Vern

-snip-