Re: Match program object to source member; CAN'T use sourcelast update timestamp in object -- MI400

I guess if this were my project, I'd use MI to get the actual executable
code of the program, and create an MD5 checksum of it.   Then I'd compile
the source to QTEMP, and take an MD5 checksum of that, and see if they're
the same.

Slow & ugly, I know. :)


On Thu, 25 Apr 2002, Dan Bale wrote:

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