×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.