Re: Checking object create dates -- MIDRANGE-L

Paul

All of those programs were still created from modules that were created with CRTRPGMOD and linked using CRTPGM into the programs, as Rob described that also happens when you make your own modules.

All that CRTBNDRPG does is let you still have an option 14 in PDM, so it feels like OPM compilation.

Hence, a possible reason for confusion about program vs module create dates.

What source was used to create any ILE program? None? The source was used to create the module. It's just a trivial case (in the mathematical sense) that there is a 1-to-1 mapping in your shop for most things.

HTH
Vern

On 2/14/2014 4:04 PM, Steinmetz, Paul wrote:

Rob,

We have 10,000 plus RPGLE programs. They all have only 1 module.
20 at the most, a few more for the vendors, that may have multiple modules.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, February 14, 2014 4:54 PM
To: Midrange Systems Technical Discussion
Subject: RE: Checking object create dates

Gary,

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.
Is this like the first this person has started dabbling with ILE programs?

You can lament all you want about the good old days and how you want that back, or, you can knuckle down and learn the APIs.

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)

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: "Monnier, Gary" <Gary.Monnier@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/14/2014 04:40 PM
Subject: RE: Checking object create dates
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Can you repeat it? What is the compiler level for the programs missing
module create date?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Friday, February 14, 2014 11:52 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Checking object create dates

Gary,

Sorry, I must have missed that note somewhere along the way. This isn't
even a CRTDUPOBJ issue, but RPG compiler is not populating source date for
RPGLE programs, only for the modules.
Why did IBM do this?

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Monnier, Gary
Sent: Friday, February 14, 2014 11:40 AM
To: Midrange Systems Technical Discussion
Subject: RE: Checking object create dates

Not to beat a dead horse but for ILE programs can't you use the module
information to determine create date and ror OPM programs can't you use
the source file change date/time? Neither changes when CRTDUPOBJ is used
to replicate a program.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Friday, February 14, 2014 7:30 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Checking object create dates

First, I want thank everyone for all the input.
Second, we have no controls over these object create processes, they are
3rd party product install/upgrade processes, and the same vendor will not
do it consistently.
Sometimes they will restore directly from a savf, all original object
detail is persevered.
Other times they will restore from a savf, but then use crtdupobj later in
the process.
Third, of the 20+ software vendors we use, only one, besides IBM, uses
Object level, Licpgm name, Licpgm level, PTF number, APAR.
Fourth, then we have our own add-on custom programs, which have our own
totally different in-house rules.
Summarizing, because there is no consistently, there is no simple easy
solution.
I still feel strongly that CRTDUPOBJ should keep original create date and
user, this would solve many of the issues.
Do you think IBM would consider a DCR, maybe using a data area, or a new
parameter on the command, to keep original create date and user?
For Duplicate file identifiers, I see the default is NO but IBM gave a YES
option It makes you wonder if IBM is rethinking how CRTDUPOBJ should
perform.
*NO
The file level and member level identifiers of the existing database
file will not be used for the newly-created file. The file level
and member level identifiers for the newly-created file will be
generated by the system; for example, 1070224092922.
*YES
The file level and member level identifiers of the existing database
file will be used for the newly-created file. Having two database
files with the same file level and member level identifiers can
impact database operations. This value should only be used when an
exact duplicate database file is expected.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, February 14, 2014 7:43 AM
To: Midrange Systems Technical Discussion
Subject: Re: Checking object create dates

<snip>
If the objects could be assigned an Object Control Level, an APAR or
PTF identifier, or some other value that defines what is the specific
object [beyond its name], would that assist to know that the duplicated
object was a copy of the original? Even without actually delivering
objects via a product and PTFs, the PTF\APAR details and product
information can be set for an object. The object control level also can
be assigned, having no relation to product and\or PTF/APAR activity.
These attributes are available to be set using the Change Object
Description (QLICOBJD) API:
<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qlicobjd.htm>
</snip>

Hmm, I thought those attributes were not allowed by set by users. From
the help:
The Program Temporary Fix that resulted in the creation of the displayed
object. This field is blank for user-created objects.
Oh, but here's good news. On the APAR id.
The Change Object Description API, QLICOBJD, can change this field to any
value. But also note: If this is a command and you run CHGCMDDFT it
replaces this apar id with CHGDFT.

Ok, so that api does allows us to change some of these.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 02/14/2014 04:54 AM
Subject: Re: Checking object create dates
Sent by: midrange-l-bounces@xxxxxxxxxxxx

On 13-Feb-2014 12:30 -0800, Steinmetz, Paul wrote:

I'm working on a utility to find objects that exist in a
custom/emergency fix library that would have a create date *LT the
create date of the object in the standard library, thus sign of an
issue. Utility done, working.
However, I found a scenario where we received a new object (*prtf) for
an upgrade. Because we change some print attributes on a few of these,
we place a copy of these prtf file objects in the fix library.
The upgrade is done, replacing the objects in the standard library.
Here's the issue.

The prtf object in the fix library was created with crtdupobj, prior
to the upgrade being done.
Creation date/time . . . . . . . . . : 08/15/11 10:41:44
The prtf object in the standard library has a create date for the day
of the upgrade.
Creation date/time . . . . . . . . . : 08/28/11 10:49:35

The objects are valid, but being flagged because of the create date
issue. I'm looking for some other field on the object, not finding
any.

Many of our upgrade processes do this. The upgrade process does a
CRTDUPOBJ, thus the object loses its original info, (create date,
created by user)

I had not previously responded to this message, the OP, because I did
not understand the scenario. I still do not understand, so perhaps the
following is not germane, but I offer anyhow as a SWAG with regard to
handling upgraded objects:

If the objects could be assigned an Object Control Level, an APAR or
PTF identifier, or some other value that defines what is the specific
object [beyond its name], would that assist to know that the duplicated
object was a copy of the original? Even without actually delivering
objects via a product and PTFs, the PTF\APAR details and product
information can be set for an object. The object control level also can
be assigned, having no relation to product and\or PTF/APAR activity.
These attributes are available to be set using the Change Object
Description (QLICOBJD) API:
<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qlicobjd.htm>

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.