Re: Checking object create dates

Chuck

I agree with your statements about programmer perception, esp. when option 14 is still available in PDM for ILE programs.

Now although I can see your point about putting source member information in an ILE executable, I think it also adds a certain level of confusion - namely, in one circumstance (1 module) you have that information, in the other circumstance (> 1 module) you probably don't.

So what do you do to get that information using APIs? Does the ILE API for getting program information - does that have to check multiple places, depending on the number of constituent modules?

For me, that would not fly very well. Still, to each his own.

Cheers
Vern

On 2/14/2014 4:40 PM, CRPence wrote:

On 14-Feb-2014 13:54 -0800, rob@xxxxxxxxx wrote:

Nothing has changed in the 10-15 years of it doing this.
What amazes me is that there are still OPM programs out there that
people can still do DSPOBJD on and see source file information.

What's so amazing about that? Those OPM program were created
directly from, a compile of, a specific source member.

<<SNIP>>

In this service program
Service program . . . . . . . . . . . . : SRVPGM
Library . . . . . . . . . . . . . . . : ROUTINES
Creation
Module Library Attribute Date
SRVPGM CRAIGS RPGLE 09/17/12
DATEMODULE DEV CLLE 12/29/13
IFSMODULE DEV RPGLE 05/14/11

What date and source file should appear on a DSPOBJD?

Don't think CRTBNDRPG. Instead, think CRTRPGMOD and CRTPGM.
CRTPGM PGM(MYPGM) MODULE(SRVPGM DATEMODULE IFSMODULE)

Sure. But even knowing that does not negate a perception that a
CRTBNDRPG is effectively identical to the CRTRPGPGM, from the OPM
perspective noted above; i.e. that the program was created directly
from, a compile of, a specific source member.

The issue essentially is an equivalent to the "letter of the law" vs
the "spirit of the law". Just like CRTDUPOBJ creates a NEWOBJ, the
former perspective could demand a new creation-date, but argued
according only to the latter perspective the "duplicate" might just as
well have maintained the original creation-date. One might similarly
argue that the bound ILE compiled object [that named just a specific
source member] might just as well have maintained the
created-from-source information regardless of actual
design\implementation whereby the actual *PGM object is created without
any actual source... such that it was only the intermediate module that
was created with source.

To a programmer operating with that not-so-unrealistic notion of what
transpired with CRTBNDRPG, knowing that the program object was created
instead via CRTPGM binding to various service programs like QNRXIE and
QLEAWI is moot. To that programmer, intuitively, that specific source
member should be reflected in the source attributes of the object
description, because that was the only "source file.mbr" input on the
CRTBNDRPG CL request.

I solved that dilemma for myself [because I had been of that mindset
originally], by adding the information to the object using the QLICOBJD
API. For a period of time each of my CRTBNDCL, CRTBNDRPG, and
CRTSQLRPGI requests for creating bound CLLE (ILE CLP), RPGLE, and
SQLRPGLE program objects were invoked with a single PDM option BP that
followed up a successful compilation with an update of the source
information. Again the command change exit [with QCARPLCM API] could be
used to effect similar, globally, if desired.