Re: V5R2: Source now allowed in the IFS

James

Inline responses

Vern

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

On Sat, 19 Oct 2002, Vernon Hamberg wrote:

> >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.

An interesting practice, to me, is to put symbolic links to the source
members into the IFS. IBM does that now with system includes for C/C++, in
the /QIBM/include folder. I've not tried putting a link to one of my source
members, using that link to compile the object, and see what it thinks was
used for source - does it follow the link and report the actual source?

If you use WRKLNK with *EXTENDED detail, you can put a 12 on a link and see
what it refers to.

> 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

Well the inode is a closely-coupled object to the program.  However I'm
sure that things are different on the iSeries.  Does CRTDUPOBJ modify the
last change date of the newly created object, like cp does on unix?
Hmm...

Yes, and create date/time, as well as usage counts. Use the DSPOBJD command
to see this info. There are 2 kinds of displays - *FULL and *SERVICE.
There's a *BASIC, too, which gives you a display to choose from the other 2.

I mentioned inode out of my very limited exposure to Linux - there's
something that manages (or ?) every so many blocks on the drive, right? Is
that the inode? EFS2?

Please tell me how the stuff in DMPOBJ help SCM apps or lets you KNOW
where an object came from.  The best I can see is that you know at one
time there was something called MYPROGRAM that was used to create *PGM
object MYPROGRAM, but there is no way to know that the current source file
MYPROGRAM is the same that was used to create the *PGM object MYPROGRAM.

Yeah, you're right, someone can always move the source or rename it or it
can get lost. But, in addition to the source name info, there is source
change date and time. These can be used to verify more completely that you
have the right reference. There are ways to circumvent this stuff, and
vendors sometimes do this to protect their assets - IBM does, too.

> There are advantages in terms of backup & recovery.

Can you give some examples?  All the backup and recovery stuff we've
needed is save to tape and restore to tape.  We certainly haven't needed
to do DMPOBJ on anything.

Actually, DMPOBJ is probably not used by anyone, except for diagnosis and
visual inspection. There are APIs that return all this stuff
programatically, and are not encoded in unreadable date formats or bit
fields or ???. And it doesn't show everything, like the data portion of
physical files. Information on what device or SAVF the object was last
restored on are there, as well as save/restore dates/times, what command
was used. Again, use DSPOBJD on an object and look at about the 4th or 5th
page in. I think that objects saved on multiple volumes will record which
volume (up to 10 in the old days, I think).

I used the word 'advantages'. I should have said 'good things', since the
former is comparative, and I don't have enough knowledge of how other
systems might accomplish some of this stuff. I assume that there would be
applications that could store this information in databases or some such.
As far as I can tell, these would be somewhat more prone to getting out of
sync than the very-closely-coupled design on iSeries.

> 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.

I did so and I *think* I saw what you are talking about.  Is there
something that identifies the OIR so I know for sure where in all the 78
pages to look?

Search for 'OIR DATA-' in the display of the spooled file. Or go to the
bottom and go back up a couple pages.

James Rich