DISPLAY WHEN-COMPILED (it's a reserved word in COBOL)

>>> John Pitman <[log in to unmask]> 2/3/2008 10:06 PM >>>
In C programs we implement a line that produces a message at startup:
Last Compiled on dd/mm/yyyy at hh:mm:ss
This comes from a source line like:

printf( "Date of last compilation : %s time : %s\n\n",  __DATE__, __TIME__ );

There should be a similar capability in Cobol?

In some we also have in top left of screen or report printout a version no, and a condensed timestamp

jp
________________________________________
From: HP-3000 Systems Discussion [[log in to unmask]] On Behalf Of Olav Kappert [[log in to unmask]] 
Sent: Monday, 4 February 2008 2:03 PM
To: [log in to unmask] 
Subject: Re: [HP3000-L] Cobol object code compare

It will be fairly hard to determine which source goes with what object,
other than by name.

The key here will be to never let this happen again.  How about adding a
variable to the program which hold the version number and program name.
This variable will of course be hard coded into the source and should be
printed out when the executable is run.  Thereby having a one on one
match.  Strict controls will be needed to ensure version changes are
incorporated into every program and update for every new release.

From day one, I have implemented this concept into every program I have
ever developed, regardless to language and/or 4gl.  Even it you decide
not to print out the information; through debug, you can determine
variable fixed data.

Olav.

Peter M. Eggers wrote:

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

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

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

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