Re: Checking object create dates

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.