Potentially serious V5R2 and V5R3 bug?

[Mark Phippard <MarkP@xxxxxxxxxxxxxxx>]

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. 
_____________________________________________________________________________