First off, you seem to have a serious source control and/or production code
control problem, and need to identify and fix the problem that allowed this
to happen immediately!

On Jan 31, 2008 9:15 PM, krikor Gullekian <[log in to unmask]> wrote:

> Does anybody know if there are out there any program that compares, HP
> cobol compile codes or re-creates the source from the object. We are
> having
> problems where multiple object codes don't match with the source.
>

 Eugene Volohk wrote a decompiler that generated good SPL source, but even
that was not the original source, except functionally.  Doing this with
COBOL source is nearly impossible, especially if any optimization is used.
If this was a result of a malicious hack job, it could be useful to find out
what has been compromised.  Probably just less than adequate system
administration and/or controls.

Also, be aware that different versions of the COBOL compiler can produce at
least slightly different executables.  Changing your compile parameters can
make dramatic differences in the object code, though not a character was
changed in the source.

We are going to compile the codes and compare them with the old ones. Any
> comment is appreciated.
>

Any object code in a production environment should be backed up as
installed, and ideally monitored for changes using cryptographic
checksumming.

You shouldn't have to recompile to get a good production executable, ever!
But, if there is some reason I have missed, then you need to have secure
backups of every COBOL compiler used to create any production executables,
plus the copylib versions, compile parameters, combined object code, and
anything else you might have done the affected the final executable.  This
is by far more trouble.  To keep things simple, any upgrades to MPE,
compilers, or other system software that could affect executables in
production should be loaded on a test machine along with your production
environment, and the system thoroughly checked and signed off as so by the
application(s) owner(s).  Best to start in your development systems though,
then migrate to the QA / user test system, and finally to production.

Bottom line, this should never happen again!  Protect and verify your
production executables, make sure that your source code and documentation is
securely managed and controlled.  If you are unsure about any of this, then
at least become very familiar with change management systems and concepts,
or hire a good security analyst.

Pete

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *