用C ++重写IBM汇编器+ COBOL

我是一家汽车租赁公司的出租代理/经理，该公司在1972年编写的出租系统上运行。我决定也许是时候进行更新了。作为一点背景，下面是我们每天必须从此程序中处理的疯狂的简短示例：

租赁代理商必须记住，在一个屏幕上进行打印时，在ACT字段中使用“ MXC”（所有内容均基于短代码），这令人困惑地表示“在合同上显示最大数量”，而在另一个屏幕上则需要PR（对于PRint）。 ACTION字段，但有几个屏幕在PT（对于PrinT）字段中使用Y，而另一个屏幕在PRT（对于PRinT）字段中使用Y，而另一个屏幕要求用户点击Enter（但不点击字母，因为这是换行符，必须是数字键盘上的回车键），然后是F8，一个不同但相关的屏幕仅需F8，某些屏幕上有一个标有PRT的字段，该字段应用于PRinT，但实际上该字段什么也不做，经过几次提示后，打印会自动完成，还有更多屏幕带有标有PRINT Y / N的字段，对于其他地点已经交付文书工作的操作，默认为Y；对于其他经销商将需要文书工作的操作，默认为N。

我决定可以做得更好，因此我决定与公司中的负责该更新的人联系。我最终与负责该计划的IT副总裁取得了联系。我从他那里得到了一些信息，并且得知我的汽车租赁公司的租赁程序是用IBM大型机组装程序编写的，其中混入了一些COBOL。他说，目前没有职位空缺，但是我应该无论如何，请给他发送我的简历给他（以防万一）。

这使我想到了我的问题。

首先是技术。考虑到将来改善可维护性的想法，我的想法是用比汇编语言更高级的语言来重写它。我的经验领域是C ++，因此这对我来说是显而易见的选择。该公司迫切需要一种更简便的方法来更新程序，正如我最近读到一篇文章时所引用的，当时与我交谈的那个人说，该团队工作很努力，他们很自豪地宣布该程序现在支持5位数字的位置代码（而不是4）和8位的车号（而不是7）。我的更新哲学，即使在这种可怕的情况下，也符合乔尔的观点：http : //www.joelonsoftware.com/articles/fog0000000069.html简而言之，重写应该是渐进式的，而不是扔掉以前的一切然后重新开始。

有没有一种简便的方法可以将IBM Assembly与C ++集成在一起，如果可以，该怎么办？我隐约知道了asm关键字，但是我不知道最好使用它还是做其他事情。这样的计划不明智吗？我在使用g ++和GNU make的Linux上完成大部分工作，因此欢迎您回答特定的答案，但绝对不需要（因为我不知道它们没有哪种构建系统，但我怀疑几乎没有）。

第二个问题更具政治性。我应该如何说服该公司他们需要进行转换？理论上的成本节省是巨大的（根据我的估计，该公司每年在浪费额外的百万美元左右，仅是增加了学习如何与该程序交互的培训成本），但是我建议的更改可能会将所有当前的程序员失业，应该将他们制定出来，因此存在很大的结构性变革阻力。

编辑：我应该解释为什么我修改公司已经拥有的东西对我来说似乎是最好的解决方案。我仍然愿意接受其他建议，因为这是程序的庞然大物。我以前从未从事过编程工作，因此请对我可能给出的任何错误分析进行更正。

首先，有现成的解决方案。

从我与几位中层管理人员的讨论中，切换到新系统的主要问题之一是，许多忠诚的员工已经在公司工作了数十年，并且对系统很满意。 。如果我有能力修改已有的内容，则可以将当前接口保持为某种“兼容模式”。用户已经必须登录才能使用当前系统，因此我可以添加在用户首次登录（在我进行此更改之后）时激活设置的功能，在此用户可以选择使用“经典”界面或“新”界面。我无法找到一种现成的解决方案来实现这一目标，

我公司还拥有我们使用的软件；我们不许可。这意味着我正在与之交谈的管理层实际上是可以授权我进行更改的同一个人。使用第三方解决方案，除了获得开发我们所使用产品的公司的必要权利外，我还必须获得公司的批准，这增加了另外的障碍。这还需要说服公司放弃“他们的”产品并购买其他产品，这似乎比尝试更新我们现有的产品更大的障碍，但是在这个问题上我很可能是错误的。

最后，展望未来，我不仅要改善用户界面并修复一些错误。在更新了这些“紧急”问题之后，我希望更新与技术相关的公司运营的基本方式。在这类问题上花了1-2年的时间后，我的计划是回到管理层并提出更重大的变化。公司目前有很多方法可以通过根本不使用的技术从根本上加以改善。例如，每个区域几乎都以相同的方式运行。当地的主要机场是分发汽车的中央枢纽。它们主要按需要发送。但是，机场被用作所有行动的基地。他们会用一辆车派两个人到我的位置，从我们这里接我们不需要的车，然后带着他们进来的汽车返回机场，再加上他们要收回的东西（我们距机场32英里）。然后，他们将乘坐两辆车到达距离我们5英里的位置，将其中一辆降下，然后将另一辆车返回机场。即使我们退还的汽车与他们在我们附近所需的汽车相同，他们也会这样做。我已经在该公司工作了大约两年，而我似乎只在最极端的汽车短缺紧急情况下才偏离了这一点（大约有过三次）。我将用一个自动调度系统代替在每个地区工作的4个人，该系统可以确定要去哪辆汽车，并尝试找到所需的时间最少的里程+里程+驾驶员来将所有汽车交付到需要的位置。我希望有一天可以添加更高级别的修复示例。

但是，在我提出所有建议之前，我认为通过执行较小的任务（例如更新接口）来了解公司和代码库将很有帮助。诸如外包或其他方式的解决方案将消除这种可能性。

局限于技术领域...

我建议您首先确定应用程序运行的环境。鉴于应用程序的使用年限，“大型机”可能意味着几件不同的事情，它可能是CICS或IMS。原始作者也可能写了他们自己的开始任务。

根据应用程序在何处运行，它可能会使用该环境的API，CICS现在使用的接口与早期的接口明显不同，我不能说IMS。如果应用程序是它自己的开始任务，那么它很可能具有自己的内部API-我花了大约七年的时间支持这种野兽，并且是在同一时代编写的。

考虑到应用程序的使用年限，还需要考虑的其他事项是，您希望与之集成C ++的汇编器早于语言环境（LE）的存在。因此，除非汇编程序已更新为符合LE标准，否则您将遇到一些困难，因为C和C ++符合LE标准，并且要求其调用者和被调用者也必须符合。

需要考虑的另一点是，如果此应用程序在濒死的大型机上运行，​​则您可能正在尝试与在不受支持的硬件和软件上运行的应用程序集成。这与尝试与1989年编写的在原始硬件上运行于DOS 4.01的应用程序进行集成没有什么不同。

你在跳枪。根据您的描述，您似乎还没有完全了解当前的技术环境（确切的操作系统是什么，数据的存储位置和方式，是否存在与其他系统的接口等）。但更重要的是：认真的计划应考虑对软件的部分或全部内部重写的替代方案，即现成的软件，外包的外包，软件即服务等。

无论公司最终采用何种方式，首先都需要对软件的功能以及新解决方案的要求进行可靠的分析。

那么，为什么不提供此分析呢？

我很惊讶您的回应如此客气！

让我们从他们的角度来看这个。

他们成功地管理了拥有三十多年历史的系统，其中可能包含成千上万的代码行，还可能与二十多个其他系统的接口相结合，这些系统体现了四十年来不断发展的业务流程。

他们可能是/很希望成为该领域的专家，因此，他们会将C ++视作IBM的“高级汇编语言”的下一个版本，以赋予它完整的名称。IBM的汇编语言非常强大，“ MACRO”语言是有史以来预处理/模板语言的最佳实现。

自系统首次实施以来，大约每五年就会有一次更换系统的提议。在进行可行性研究后，有些人会被拒绝，有些人在失去预算之前就到达了设计阶段，有些人甚至在遇到性能问题并得到解决之前就进入了代码和测试阶段。

C ++根本无济于事。在运行应用程序的环境中没有图形库。（有一个3270图形库，但由于没有人使用它，因此C ++不太可能支持它，并且有完整的“ X”客户端库，但是您需要在其他环境中使用它）。

他们的用户界面远非完美，但众所周知且快速。经验丰富的操作员将使用绿屏而不是等效的GUI来以大约三倍的速度填写表格。另外，他们在触摸打字时可以关注客户。

屏幕操作员将需要培训他们使用的任何界面，与仅在旧的系统上培训新员工相比，重新培训所有员工以使用新的和不熟悉的GUI将是一项庞大的预算项目。

几年前，我在南方贝尔公司遇到了类似的问题。我只是写了COBOL代码来逐字节扫描汇编语言程序，分离出操作码和操作数，将分支指令转换为tos，并将比较指令转换为IF。该程序将DC指令转换为等效的COBOL数据分区代码，并视情况转换了移动，快速移动等。

完成此操作后，我编写了第二个程序，将IF和GOTO转换为IF-THEN，并在这些群集之间进行了移动等操作（这并不是真的那么难-秘密是插入IF和从头到尾重新阅读第一阶段的“ pidgin” cobol时的ELSE。

IF-THEN-ELSER寻找可能在标签附近找到GOTO引用的情况，可以安全删除该标签（将其引用数减少1）。您可以迭代地运行此IF-THEN-ELSER程序（也就是说，您一次又一次地运行它，仅在最后一次通过找不到其他更改方法时才停止）。大多数关键工作都是由if-then-elser来完成的，其COBOL产品必须由经验丰富且精通的汇编语言程序员（即，我）仔细检查和审核。以我的经验，我的“ if-then-elser”能够消除原始分支指令产生的90％以上的GO TO。

我想从这一点开始可以直接转换为C（或C ++）-我也很熟悉的语言。但是，在南方贝尔，我们选择的目标语言是COBOL / II。总的来说，由于剩余标签具有多个GO TO引用（很多情况下，这些情况由COBOL PERFORMs处理，但有时可以由OR和AND构造表示），这会带来一些复杂性。

我认为，使用带有EVALUATE（Case构造）和88级条件名称的优雅的块结构化COBOL / II生成代码非常好。添加这些修饰后，又产生了另一对程序，这对不源自汇编程序的COBOL程序非常有用。

我不知道这是否有帮助。

正如以上其他人所评论的那样，您必须谨慎进行此过程。拥有10-12年的汇编程序编码经验可为您的决策流程提供帮助。拥有这些经验的我们很难再找到了。

最后要注意的是：那时我们只用汇编器编写，因为高级语言的编译器产生了繁琐且效率低下的目标代码。当今的“优化” COBOL编译器没有同样的坏习惯。----------

乔尔的建议通常是正确的，但是在这种情况下，完全可以重写。理想情况下，使用战斧重写，因为您在此处处理的是怪物。

我不确定确切要添加什么，因为您已经为此重写了一个很好的论据。我唯一的建议是完全跳过C ++并直接进入出租系统的Web界面，因为这样可能更容易培训工人，并且可以节省很多UI用户界面（以及更容易在项目中获得新的血液，甚至只是将整个事情外包出去。

至于现有的COBOL程序员-也许他们可以帮助记录现有系统和迁移过程。

至于技术方面，很大程度上取决于汇编代码的质量-模块化。一些程序员理解使用标准的IBM子例程链接约定来创建具有特定功能，有限功能和清晰，简单的参数化接口的模块的重要性。然而，绝大多数人倾向于制造整体怪兽。

使用前者，可以实现重用，并且假设您的汇编器模块使用标准（或至少一致）的调用序列，那么在C ++和汇编器之间解决“胶水”就不那么困难了。但是，汇编代码极有可能是一团糟。尽管可以编写结构化汇编程序，但是很少有人写，并且几乎不可能辨别要从其开始重写的任何“设计”。

另一方面，与当今的微处理器相比，360/370汇编器相当高级，并且简单得多，有时C被认为是“高级汇编器”。我在一家DBMS公司工作，该公司的产品完全是370汇编程序，我们的首席架构师认为，可以将汇编程序代码机器翻译为C（以实现将来的可移植性）。我对此表示怀疑，但关键是距离并不像您想象的那么大。

不知道这是否有帮助。正如我所说，我认为这很大程度上取决于原始代码的质量和大小。

我不知道这是不是在开玩笑-您的公司正在认真运行39年前编写的代码吗？如果它在System / 360上运行，则必须从源代码编译g ++。

老实说，我什至不考虑使用任何旧代码。您需要采取一种全新的方法，坐下来思考一下设计需要考虑的内容，然后从头开始。是的，这将涉及很多计划，但是我什至认为Joel也不会说这是进行增量更改的理由。

至于说服您需要更换的公司，您需要指出一些可以提高效率，降低成本的特定原因，并且/或者表明您现在所使用的正在损害企业的底线。

另一则评论-我想其他汽车租赁公司也将在21世纪加入我们的行列。我会做一些检查，看看他们是如何做的（我想是基于Web的），并可能在其中一个系统之后对它进行建模（即，不要重新发明轮子）。

祝好运！

从理论上讲，如果可以证明高层管理人员可以为他们节省大笔费用，那么说服高层管理人员更换旧系统应该不难。而且会的。寻找程序员来维护该系统将变得越来越困难，并且这些程序员将变得越来越昂贵。这不是“如果”的问题，而是“何时”的问题。它确实必须进行更新。

但是，问题是，您是否可以说服他们不仅需要更新（他们可能仍然知道），还应该说这是一个内部项目。特别是如果团队只是您。这样的主要替代品通常是外包的。甚至可能有一些现成的软件可供考虑。这些选项需要进行调查，如果明智的话，您的经理会坚持要这样做。

至于任务，如果您要这样做，我实际上认为在这种情况下推土机重写可能是合适的。乔尔的论点并非在所有情况下都适用。但是我真的不知道就不知道。

1. 增量更改是不可能的。

2. 可能会有现成的解决方案可用。有很多汽车租赁公司。

3. 如果作为最后的选择，您需要重写它，那么首先要花一些时间考虑新系统的工作方式。
   确定功能和接口后，可以选择最适合需要（和您的技能）的开发工具。

最小化对最终用户的压力的一种策略是开始模仿用户所知道的旧的丑陋界面，并添加诸如丑陋助记符的下拉列表之类的一些细节，然后逐渐添加UI功能并将其断续到现代UI上。

您可能不想保留相同的数据文件格式，因此一旦切换，就不会再返回。