CPYSRCF problem at V7R3

All,

I recently encountered a problem at a customer site that could also cause problems for other sites, so I want to ask if anyone else has seen this issue on V7R3 (or on V7R4 or V7R5).

The CPYSRCF command has the parameter:

   SRCCHGDATE(*FROMMBR)

Source change date . . . . . . . SRCCHGDATE     *FROMMBR 

 the default *FROMMBR specifies to copy the source member, and retain the source last changed date of the "From" member.

But, on at least one of my client's systems, this does NOT work.

The CPYSRCF command is behaving as if SRCCHGDATE(*NEW) was specified.   But it is not specified.  

I have tested this with this customer, and even when we "hard-code" SRCCHGDATE(*FROMMBR), it still stamps the copied member with the current date/time when the CPYSRCF ran.

This causes trouble for change management tools that verify the integrity of compiled objects by checking to ensure that the compiled object source member last changed date/time stamp "matches" the actual date/time stamp of the corresponding source physical file member.

You can quickly test this by creating a file in QTEMP, e.g.:

   CRTSRCPF QTEMP/QCLSRC

Then WRKMBRPDM QGPL/QCLSRC  (or any QCLSRC file), and then press F14 to see the member dates, or type an "8" next to a member to see the "last changed" date for the member. (This is the date updated by SEU or RDi etc. when you edit the source member.)

Then, prompt the CPYSRCF command as shown below:
    
    CPYSRCF FROMFILE(QGPL/QCLSRC) + 
            TOFILE(QTEMP/QCLSRC) + 
            FROMMBR(QSTRUP) + 
            SRCCHGDATE(*FROMMBR) 

Press enter to perform the copy.

Then, issue WRKMBRPDM QTEMP/QCLSRC and type an "8" next to the member.   You should see something like this (for example):

 Member  . . . . . . . . :   QSTRUP       
 File  . . . . . . . . . :   QCLSRC       
   Library . . . . . . . :     QTEMP      
 Member type . . . . . . :   CLP          
                                          
 Creation date . . . . . :   04/12/24     
 Creation time . . . . . :   11:05:27     
 Change date . . . . . . :   03/07/14     
 Change time . . . . . . :   15:52:27     


If you have this particular issue, you will see, e.g.:

 Member  . . . . . . . . :   QSTRUP       
 File  . . . . . . . . . :   QCLSRC       
   Library . . . . . . . :     QTEMP      
 Member type . . . . . . :   CLP          
                                          
 Creation date . . . . . :   04/12/24     
 Creation time . . . . . :   11:05:27     
 Change date . . . . . . :   04/12/24     <---<<<
 Change time . . . . . . :   11:05:27     <---<<<

I suspect some "PTF in error" that is relatively recent, because I do not see this issue on my "test" V7R3 system, but on the client system, they have a few group PTFs that are slightly newer than what our "Test" system currently has. 

Please reply, either on-list, or privately, to let me know if anyone else is seeing this issue.

(I cannot open a "case" for this with IBM because it is not happening on my system.)

Thanks in advance.

All the best,

Mark S. Waterbury