Re: QCDRCMDD differences at different releases - need to reconcile

Vern Hamberg wrote:

For the archives - as to changed members (the other main area
where I need to note changes), I was looking at the change
date/time on *MBRLIST option of DSPFD - wrong value - is affected
by restoring the file, it seems. Would need to use the result of
RTVMBRD, which gives the actual last change date/time on the
member, and this is trustworthy, so long as you don't restore on
another box. I tested this and saw that when the clock is set
with a different offset to Greenwich, there is a window of vulnerability, where a change could be made and have the same
source change date/time. Likely? No. Even remotely possible?
Probably not. But once is too many for the customer to whom it
happens. So for most people who are working only in their own
shops, the date and time of last source change that is returned
by RTVMBRD or the API QUSRMBRD is the way to go.

The *MBRLIST of DSPFD is just the wrong place to look for indication of source changes. The DSPFD has two sections for member information. The *MBR information [outfile QAFDMBR vs QAFDMBRL] has MBUPDC, MBUPDD, and MBUPDT for last source change date\time values.

Note that the "source change date\time" information may also be a moving target due to [source] member "copy" activity. This is because of a data area that was introduced due to [& introducing] defects along the way, which should be the only origin for the effect since the new v6r1 SRCCHGDATE command parameter on CPYSRCF and CPYF. From the link
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/dm/rbal3cpyfcmds.htm
"For new members that are added to the to-file, or if the MBROPT(*REPLACE) parameter is specified, you can specify whether the last source update date and time is a new date or is copied from the from-file with the source change date (SRCCHGDATE) parameter. This is also the default value for the CPYF command." Uhhh... and "this" is the former or the latter? ;-) It's the latter, where the default value from where the date is established, is *FROMMBR versus *NEW.
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/cl/cpysrcf.htm

Regarding the time offset issue. Note that nor is the leap adjust value part of the effective *DTS information, such that a 29-Feb may appear for a year which is not a valid leap year. The safest code will always adjust minus one [i.e. 28 vs 29] for the invalid case when attempting to convert the value to a date; reactively, as best performer, due to rarity. Ughhh!

Regards, Chuck