Match program object to source member; CAN'T use source last update timestamp in object

This is a re-submit from last week when all the gurus were off having fun at
COMMON.  Now that you're all back... <g>

This particular mini-project I'm working on is killing me.  It is
mind-numbing, teeth-grinding grunt work, but someone's gotta do it.  It's
not an everyday task, but I get called upon to do this enough that I always
know I'll be exhausted by the end of a day from working on this stuff.  I
posted this to both the MI400 list (because I suspect that MI will be
involved in any possible solution) and the Midrange-L list (to cover the
wider audience who might have some insight to this).

*Background*
We're finding a lot of program (and, sometimes, display file) objects on a
client's system that we are unable to "definitively" match to source.
Typically, I'd use DSPOBJD LIB/OBJ *objtype  DETAIL(*SERVICE) to see what
source was used to compile the object.  Unfortunately, what I find is that a
lot of the objects were originally compiled from source in so-called user or
test libraries.  The compile works, it gets tested, and then the that
compiled object gets *MOVED* into production.  The source member is then
*COPIED* into the production source file, which sets the copied source
member's timestamps (both create & change) to the current date & time.  If
it were me, after testing, I'd move the source member into the production
source file and compile it into the production library from there.
Otherwise, it would be nice if it were possible to *easily* MOVE a source
member so that the member's timestamps carry over to the new location.

*Looking for this kind of solution*
Given what I've described above, IT WOULD BE NICE if I could run some kind
of "magic box" command that would take a specified object and a specified
source member and be able to return a result that tells whether compiling
that source will produce a new object that is operationally identical to the
specified object.  "Operationally identical" is the key phrase here, as
using the same source member to compile two different objects will create
binary differences that I am unable to discern (I have tested this,
comparing DMPOBJ's on the two program objects).  (Sidenote:  The Ohio
company that sells a decompiler supposedly has this exact tool, as I've
described it here, but only for a huge sum.  I exchanged several emails with
someone there suggesting that making this tool available for free or nearly
free might be a good sales generator for the the decompiler product, but
they didn't bite.  Oh well.)

*NOT looking for...*
Please, no advice on change management systems.  1, it ain't gonna happen
and 2, my work begins long after the problem seeds are sown.

TIA,

- Dan Bale
(I am *NOT* "Dale"
http://archive.midrange.com/midrange-l/200105/msg00281.html )
SAMSA, Inc.
989-790-0507
DBale@SAMSA.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)