|
I was debating whether this was worthy of posting or not. It is hard to tell how serious this bug might be in terms of its side-effects. We ran into this with one of our customers when it caused a problem in our software. If you copy a source member using *REPLACE, such as when copying source from Development to QA or Production. The member change date of the target file is not being updated. This happens whether you use the CPYF or CPYSRCF command. I did some searching and discovered that there is an APAR open for this. The APAR id is SE19615. Here are the details: http://www-912.ibm.com/n_dir/nas4apar.nsf/c79815e083182fec862564c00079d117/34315b64034910e386256fc70042aac2?OpenDocument In testing, I have uncovered more that is not in the APAR: 1) It isn't just CPYSRCF it is also CPYF. 2) It also happens when using CPYF *REPLACE to copy between two data members, not just source. 3) If you use CHGPFM on a source member it does not update the member change date, even if you change the member description or source type. The same command on a data member will update the change date even if you specify *SAME for all parameters. By the way, to see the member change date use option 8 from WRKMBRPDM. I am having trouble gauging how serious this is. What I know for certain is that it effects things like auditing info. If you edit some source in your development source file, then copy it to production and compile. The production source date does not update, and the compiled object will show that it was compiled today, but the source date will be some time in the past. I do not think this is the end of the world, but it might cause some people some SOX problems. Of course it also has the potential to effect software that cares about the member change dates. It seems like this could also effect backup procedures, especially if you had a routine that was looking for members that have changed since the last backup in order to save them. This is the part I am unsure of, and why I decided to post it. It would obviously be terrible if this is effecting peoples backup routines and they do not know it. The object change date seems to be updated correctly so I think it would only effect code that looks at the member change dates. We are not the ones that reported the APAR, so obviously someone else has run into it. We will be calling in to add this additional information. Feel free to do the same. Thanks Mark _____________________________________________________________________________ Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs. _____________________________________________________________________________
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.