Re: CRTDUPOBJ: how to retain the create date and usage info

Joel:

OS/400 and IBM i does treat them as "important" -- that is why they do not let you change these dates to any value you want, e.g. using the QLICOBJD API ...

But, there are certain "rules" that OS/400 follows ... You might not like those rules, as they may not coincide with your ideas about how it "should" work ...

Have you consulted with the vendor of your change management system, to ask them what is the best way to do what you are trying to do, e.g. to bring some additional objects from another library under control of their change management application? Each change management product is slightly different, so the method(s) used to do this may differ considerably from one vendor to another. Their customer support help desk should be able to guide you. Also, RTFM (Read The Fine Manual) -- specifically, the manuals for the change management product you are using. There should be a whole chapter on this topic.

Mark

> On 7/19/2013 10:27 AM, Stone, Joel wrote:

Not "last changed" date, rather "last used date" and "create date" intuitively should be identical when savobj/rstobj or crtdupobj is used to dup an object.

I believe that on all other OS's that survived, creating a duplicate means just that; an identical instance of that object. It is frustrating that this is not possible on the "i" without MI or API programming.

I am trying to merge a rouge library into our change mgmt system. There are 700 objects in there. It is important to retain the last-used date so I can figure out which objects to import into our production system and which ones to retire.

Ditto for create-date (and also for change date).

If these date stamps weren't important then why does every OS treat them with importance - except os/400 ?


Please suggest some alternatives but the data is too important to drop.