× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

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

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.

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

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

James Rich



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.