× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.