CPYFRMSTMF needs SRCCHGDATE parameter as on CPYSRCF

CPYFRMSTMF needs a new parameter SRCCHGDATE(*FROMMBR) that works just like the SRCCHGDATE parameter on the CPYSRCF command.

SRCCHGDATE(*NEW) can allow for compatibility with the existing behavior of the CPYFRMSTMF command.

Note that this proposed new SRCCHGDATE behavior need only apply when copying to a source physical file member, not any other type of physical file member(s).

Suppose I want to use git or any other popular Source Code Version Control tool for collaborative development. This usually requires copying all of the source members from source physical files to IFS streamfiles, to put them into the SCM/VCS repository. Then, when I need to pull them out of the SCM/VCS repository, I need to copy from a streamfile back to a source file member, if I want the benefits of the object-to-source cross reference information in the object information repository (OIR).

If I use CPYFRMSTMF today, the resulting source members will all have today's date/time as the last changed date/time.

This is also undesirable, because many make or build tools (like QUSRTOOLS TMKMAKE) will look at the file's last changed date/time to determine "what has changed" and to determine what needs to be recompiled.

Also, that is the last changed date that the compilers will insert into the *OIR for the compiled object's source cross-reference information.

This is important for any projects where customers would have a distributed team of developers sharing source code using git or github, or hg, or CVS or SubVersion, or almost any popular SCM/VCS to enable collaborative development across a widely disbursed development team.

This is also very important for shops that must have PCI compliance or Sarbanes-Oxley Act compliance and auditing requirements, etc.,if they want to be able to compile their production objects from source that is maintained using a SCM/VCS or they just want to keep the source in the IFS.