| Chuck Stevens 2004-06-28, 8:55 pm |
| Warren Simmons asked:
<<How would you reply, if the specifications said, a. only when copy is NOT
used; or if it said, the source would be the same as the compiler generated
from; or if copy were made obsolete?>>
I would reply the same; I think a backup methodology applied completely and
unconditionally that is effective less than 100% of the time is worse than
no methodology at all, because it lulls the user into a false sense of
security.
<<Other methods might be possible. And yes, current implementations would
all probably have
to be impacted in some way.>>
"Other methods" include backing up source files. In our implementation
that's fairly straightforward, and there are third-party products that
automate the backup process and simplify the restoration process even
further.
<<Yet, it seems the input to the compiler in all cases has to include the
resulting source code. >>
It does indeed, but in our environment there may be other things (have the
descriptions of the data base been updated since the program was last
compiled? Would those changes impact the execution of the program? Are the
specifications that prevailed at the time of the previous compilation still
available, and should they be used in preference to the current ones?) that
would come into play.
Also, others alluded to the idea that incorporating the source code into the
object files wouldn't increase the size of the object code much. In the
Unisys MCP environments, source files for most languages (probably excepting
RPG) are generally *several times* larger than the corresponding executable
object code files, so I would contend that the increase in disk requirements
associated with archiving the program source into the compiled object code
would not be negligible.
-Chuck Stevens
|