IBM S/390 大型机 COBOL 源代码答案

【问题标题】：IBM S/390 mainframe COBOL source codeIBM S/390 大型机 COBOL 源代码
【发布时间】：2018-08-24 04:30:03
【问题描述】：

在我的新工作中，我们有一台 S/390 大型机，自 90 年代末以来一直在运行 COBOL 应用程序。大型机已经足够老了，我们需要迁移到更新的系统。我们是一家足够小的企业，我们不能保证花钱升级到新的大型机硬件，并且程序逻辑已经持续了 30 多年，因此它具有很多功能价值。我一直在考虑将功能转移到 Linux 机器上，并使用 OpenCOBOL 之类的东西重新编译为可执行二进制文件，而不是尝试用更新的语言重写它。我还没有把大型机弄得一团糟，无法知道如何或在哪里访问这些信息，不幸的是，编写所有程序的那位先生已经不在我们身边了。我读过 SSH 是一种选择，但我什至不知道如何在大型机上实现这一目标。我经常使用 Linux，所以我对 SSH 很熟悉，但据我了解，这些大型机并不是一个简单的操作系统，你可以像在现代操作系统中那样连接并导航文件系统来检索数据.谁能给我一些指示，让我了解访问 COBOL 程序源代码的方向？是否有存储它们的默认位置等？它们是一些简单的程序，不使用任何 DB2 功能，并且有望在不同的系统上编译，并且调试和修复相对较少。我确定我遗漏了有助于回答这个问题的必要信息，我可以提供任何其他信息来帮助大家帮助我。我怀疑默认情况下没有启用 SSH，但也许我也错了。非常感谢任何帮助。谢谢大家！

【问题讨论】：

这个问题相当广泛，因为它涉及到大型机操作系统的基础知识。也许你最好看看这本红皮书：redbooks.ibm.com/abstracts/sg246366.html - 特别是第 5 章的第一个概述。
我强烈建议您与了解大型机并可以帮助您的卖家/经销商交谈。您可以通过多种不同的方式升级您的机器，和/或将程序移至托管环境，在该环境中您可以以很少的成本保持现有的服务质量。将事情从大型机中移出往往会对业务产生各种负面影响，而且往往进展不顺利。更重要的是，您需要在内部找一个了解大型机的人。我假设那里有人进行 IPL 和应用服务？
这个主题在 Superuser.com 上可能更合适
我只使用 FTP 卸载了源文件（如果可能，尝试文本模式，如果数据看起来不正确，请使用二进制模式和 iconv 传输数据），但得到了凭据 - 您是否有一个 sysprog 来处理机器及其管理）？我想说这在很大程度上取决于你对大型机做什么，如果它只是 COBOL 和一个 JCL 来启动它，没有人接触你可以让它快速工作，否则在移动大型机时会有更多的检查。
因为尝试使用 GnuCOBOL 编译源代码没有风险，所以我至少会尝试一下，您只需花费最少的时间来尝试（对于问题/错误报告，请使用 GnuCOBOL 讨论板或邮件列表）。如果您下载了源代码，您可以运行“完整”编译：cobc -std=ibm-strict -fmax-errors=9999999 -v -Wall *。有关如何从大型机获取源的问题，我建议在 superuser.com 或 serverfault.com 提问。

标签： ssh cobol mainframe gnucobol

【解决方案1】：

虽然不是编程问题，但我会提供一些我认为可能对您有所帮助的指导。

首先，这是关于投资地点的商业决策。

我们是否将系统升级到较新的型号并升级一些软件并获得保持系统运行的技能？（系统编程、操作系统升级和迁移成本、更新的平台（使用 z13 可能是一个经济的选择、支持大型机的存储系统）
将现有工作负载迁移到其他平台。（迁移代码的成本、性能需求的大小、取代现有访问方法（如 VSAM）的新技术，或者如果应用程序足够老，我敢说 ISAM）
现状 ... 把东西留在原处，保持灯亮

在评估任何选项时，您必须评估业务风险以及中断成本是多少？恕我直言，它与 Linux 上的 SSH 或 COBOL 等技术无关，但需要对当前状态、可接受的场景以及追求其中一种选择的成本进行一些认真的评估。

我的 cmets 并不是要灌输恐惧，而是提供一个框架，让我了解如何分析如此巨大的挑战。

【讨论】：

【解决方案2】：

在 z/OS 上没有存储源代码的默认位置（您说的是 z/OS，对吗？）。源代码通常存储在 PDS 数据集中。它们的命名取决于安装，即公司，以及是否使用Endevor、ChangeMan 等任何软件来维护源。

由于这是旧的 z/OS (OS/390) COBOL 代码，因此该代码可能会利用操作系统的细节，例如记录级 I/O、VSAM 数据集等。这些部分将不起作用在没有重大重写的非 z/OS 平台上。因此，您需要查看来源。

SSH 在 z/OS 上可用，但需要配置和启用。您需要检查您的 z/OS sysprog。 FTP 和 NFS 是其他选项，但同样需要配置和启用它们。

我会说，转移源代码是您最少的问题。

【讨论】：

以防万一您想进一步扩展您的答案：如果加载模块与 ChangeMan ZMF 编译/链接，那么您可以简单地浏览加载模块，并找到 ChangeMan ZMF“包 ID”和“SSI”（一种时间戳），去寻找源代码被编译/链接到您正在查看的加载模块的更改包......甚至是在所有的日子里的编译/链接列表那事发生了。顺便说一句，ChangeMan ZMF 大约在 1990 年就存在了（当我第一次开始为它提供技术支持时）。

【解决方案3】：

我必须同意前两个答案，但还有一些额外的建议。这是在系统上做什么的业务决策。

找到程序以了解它的作用是首要要求。由于您知道正在运行的程序可能是源文件的名称。你需要找到。源文件可能会在某个库管理器中，首先要查看的是 ISPF 菜单系统。如果您正在使用一个库管理器，那么您正在使用的库管理器将有一个选项。根据您的描述，您可能正在使用应该启动的称为 SCLM 的东西，或者您可能会看到 Librarian 或 Panvalet。您需要通过使用 3270 连接仿真器连接来进入 ISPF。一旦找到文件，使用 FTP 或 SFTP 可能是最好的，或者您的模拟器可能只是提供一种传输机制。您还需要找到相关文件，这些文件也应该在库管理器中定义。

一旦你有了这个文件，你需要弄清楚它上面提到的用途，它将处理某种数据文件，这将是最重要的部分。

如果它是批处理程序，它可能是计划的一部分，并且还有其他程序也在运行，您需要找到并弄清楚它们如何组合在一起。

了解所有部分后，您就可以就如何运行做出正确的业务决策。您可能想要升级，如果您不想升级但想要该功能，您可能想要将 z/OS 作为云服务。或者它可能是一个您可以移动的简单程序。一旦你掌握了细节，这将更容易弄清楚。

【讨论】：

【解决方案4】：

您说程序逻辑已经改变了 30 多年。是不是只有一个人做出了所有的改变？团队中是否有人对用户有权访问的 PDS 有所了解？那可能是要寻找的地方之一。正如之前的答案所暗示的那样，大多数商店会将源代码存储在某种配置管理工具中，例如 SCLM 或 panvelet。如果您有权访问加载代码，则有一些实用程序可用于检查加载成员以获得 CSECT 列表，其中包含构成该加载的 obj 成员的名称。您可以与大型机管理员联系。这可以获得源代码文件名。我们在我们的商店中使用来自 USS 的 SSH 将代码从 HFS 文件夹移动到 gitlab。我还使用普通 FTP 将源代码文件传输到我的工作站。但是，是的，首先你必须找到它的存储位置。

【讨论】：