有 COBOL 编译过的程序 -- 缺少源代码
我们有一个非常重要的应用程序，但到目前为止还没有源代码。 该应用程序是用 COBOL 编写的，编译版本位于我们的生产系统中并且正在运行。
但是，我们需要迁移到新的服务器和新的 cobol 编译器。 我们的印象是，我们需要重新编译代码才能使其在新服务器上运行。 运行现有的已编译程序会出现运行时内存错误。
我们有该程序的一些源代码，但它很旧。 不确定它和编译的程序之间有什么区别。
好的，那么问题来了——我们应该做什么？
时间不在我们这边，因为我们必须将旧服务器发回才能获得信用。 想法、建议、疯狂还是其他？ （源代码控制是显而易见的，这不是我能做的，所以保存讲座）
We have a very important application, but so far no source code. The application was written in COBOL and a compiled version is in our production system and is running.
However, we need to migrate to a new server, and new cobol compiler. We're under the impression that we need to recompile the code to get it to work on the new server. Running the exising compiled program gave runtime memory errors.
We have some source code for the program, but it is old. Not sure what the diff is between it and the compiled program.
Okay, so the question -- what should we do?
Time is not on our side, since we have to send our old server back to get credit for it. Ideas, suggestions, crazy or otherwise? (source control is obvious and its not up to me to do it, so save the lectures)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
创建旧服务器的映像。 然后将旧服务器作为虚拟机在新服务器上运行。
但是，我同意更好的选择可能是保留您的生产服务器。
Create an image of your old server. Then run the old server as a virtual machine on your new server.
However, I agree a better option is probably to keep your production server.
从短期来看，安排保留旧服务器可能会更便宜。 从长远来看，您需要腾出时间和预算来重新设计程序，要么重新编写程序，要么看看将旧代码改造为程序当前所做的事情需要付出多少努力。
In the short run it would probably be cheaper to arrange to keep the old server. In the semi-long run, you need to make time and budget to reengineer the program, either re-write it or see how much effort it would be to hack the old code into shape doing what the program currently does.
真是可悲啊。 您应该咨询源恢复公司
It's sadly. You should consult the Source Recovery Company
如果您的源代码相对接近编译版本，请尝试以下操作：
为了增强这一点，可能作为第二步，因为它将使源代码远离新编译的版本，使用输入数据进行测试，然后根据创建所需的输出尝试进行逆向工程那个输出。 拥有的测试输入数据越多，效果就越好。
祝你好运！
If your source code is relatively close to the compiled version, try this:
To augment this, and probably as a second step, as it will bring the source code farther from the new compiled version, test with input data and just try reverse-engineering based on the output what would be needed to create that output. The more test input data you have the better this could work.
Good luck!
（我不是 COBOL 程序员，但是..）
如果你知道编译原始程序的编译器是什么版本，你至少可以编译旧的 cobol 源代码； 如果编译的版本相同，您就知道源实际上是当前版本。
如果它们不同，您可以尝试（以某种方式）反编译，或者至少反汇编，工作编译版本和新编译版本，并使用 diff 工具 了解差异有多大。
(I'm not a COBOL programmer but..)
If you know what version the compiler was that compiled the original program, you could at least compile the old cobol source; if the compiled versions is identical you know the source actually is the current version.
If they differ, you could try to (somehow) decompile, or at least disassemble, the working compiled version and the freshly compiled version and use a diff tool to get an idea of how big difference there is.
疯狂建议：COBOL DECOMPILER --> 来源 --> 新的 COBOL 编译器...？
（编辑：http://juggersoft.com - 付费 cobol 反编译器）
crazy sugestion: COBOL DECOMPILER --> SOURCE --> NEW COBOL COMPILER...?
(edit: http://juggersoft.com - PAID cobol decompiler)
如果您有 .int（中间）二进制文件，您可以在新服务器上运行，如果没有，则必须重新编译它们。
if you have the .int (intermediate) binary files you can just run on the new server, if not, them you musto to recompile.
该程序可能是由外部资源生成的，并且该个人或软件公司或组织可以在其存储库中拥有最新的源代码。 如果您最近合并，它可能由您的上级组织持有，或者可能位于您组织中的不同或备份计算机安装中。 开发人员的用户帐户上可能有一份副本，但可能尚未发送到生产或实时站点，或者总部的某人有一份副本来评估并尝试解决问题。 如果给这些人打电话，您可能会成功，或者您可以随时与安装计算机操作员或支持人员交谈，看看他们是否在磁带、CDROM 或其他备份存储上有一份。
The program could have been produced by an external resource and that person or software house or organisation could have the latest source in their repository. It may be held by your parent organisation if you have recently merged, or may be in a different or backup computer installation in your organisation. There may be a copy on the developer's user account and may not have been sent to the production or live site or someone from head office has a copy to assess and try to resolve the situation. You may have success if phone those people or you could always talk to the installation computer operator or support staff and see if they have one on mag tape, CDROM or other backup storage.