在 SSC，我们多年来一直使用 Progress（自 1985 年以来），并且 Progress Software Corporation 没有，并且据我们所知，将来也不会提供 Progress 的 Linux 端口。我们决定研究使用 iBCS 模拟软件包以及良好支持的 SCO Unix 版本的 Progress 的可行性。

SSC 的数据库在整个办公室用于订单处理、订阅、销售报告和图表、营销、广告、账单报表、标签打印和发货。与数据库集成的是通过内部开发的认证外部程序对信用卡订单进行授权和结算。数据库的未来计划包括从我们的网站自动订购以及具有 CASS（编码精度支持系统）认证的地址匹配软件。SSC 倾向于继续使用 Progress，而不是更改为专门移植到 Linux 的另一个数据库，例如 Postgress，因为我们投入了大量时间来为 SSC 不断增长的需求定制数据库。Progress 还具有非常稳定和可靠的良好记录。这一切都很好，但是 iBCS 是什么？iBCS 代表英特尔二进制兼容性规范，该规范指定了基于 i386 的系统的应用程序程序与周围操作系统环境之间的接口。这允许许多为其他 Unix 操作系统开发和编译的二进制文件在 Linux 上运行。免费提供的软件包仍在开发中，但最近版本的 iBCS 在 Linux 内核 1.2.13 下编译和安装时没有任何问题。我们订购的 SCO Progress 演示版装在一个黑色盒子里，附带手册和 DAT 磁带。安装过程并非一帆风顺；按照规定的步骤进行，仅在应该从磁带读取剩余存档时才有效。我最终“手动”使用 cpio 读取了它们，并调整了安装脚本以在磁盘上查找。

在那之后，结果证明文件权限和组/用户 ID 设置不正确，并且标准 shell 脚本中的目录路径不正确。拥有现有的 Progress v6 设置会有所帮助，尽管在没有它的情况下肯定可以修复此问题。在这一点上，我能够在单用户和多用户模式下运行数据库服务器——是时候开始寻找其他更隐蔽的问题了。结果证明，SCO Progress 需要设置 TZ 环境变量并使用本地密码文件；否则，您会遇到很多内存违规。一个帮助您解决此类问题的宝贵工具是 itrace，它包含在 iBCS 软件包中。为了适应迁移，我们花了一些准备时间来调整我们自定义的 Progress 代码，但在此之后，过渡主要只是将所有 SSC 数据库相关文件复制到新系统的问题。我甚至不必对数据库进行耗时的转储和重新加载，因为这两个架构都是基于 x86 的。经过几天的测试，我们对设置非常有信心，可以继续订购“真实”版本的 SCO Unix 版 Progress。出于不太清楚的原因，该程序是通过软盘到达的，起初看起来比磁带更麻烦，但实际上更容易调整安装脚本以使其正常工作，只需要耐心和大量的磁盘交换。服务器无法在“raw”模式下运行，这是标准 SCO 版本的主要问题。也就是说，无法保证数据库的一致性。事实证明这是 SCO 版本中的一个错误，在请求并应用最新的补丁 (6.3F08) 后，这个问题得到了修复。

从旧服务器切换到新服务器对每个人（除了我）来说都是一个惊喜，它仅仅包括登录到另一台计算机——其他一切看起来和工作方式都相同。我们都为一些多用户故障做好了准备，但没有发生任何故障。

在 Linux 下运行 SCO Progress 几乎没有缺点，除了某些小的安装不兼容性和没有“官方”Linux 支持（尽管 Progress SCO 技术支持非常乐于助人）。除了 Linux 下的 Progress v6 显示与 SCO 下相同的错误之外，我想不出其他任何缺点！

相反，对于已经使用 Linux 的 SSC 或任何办公环境来说，有很多优点。首先，在过去的几个月中，新系统被证明同样稳定。SSC 的大多数操作都围绕 Progress 数据库服务器进行，没有它，业务就会陷入代价高昂的停顿。现在它与网络的其余部分非常吻合；共享目录或略有不同的命令和环境不再有问题。它更快、响应更快；记录搜索和扫描速度更快。其中一个原因是 Linux 具有动态缓冲（使用可用内存），这加快了整个系统 I/O。当然，它也更便宜——Linux 是免费的——SCO 不是。

但是，有什么比让 SSC 的一名员工和 Progress 的长期用户 Lydia Kinata 用她自己的话来盛赞新系统的优点更好的证明呢。

自 1994 年 4 月以来，我一直在使用 Progress 数据库。当我刚开始工作时，SSC 是一家规模小得多的公司，我的工作职责范围很广，从发货和订单录入到应收账款和营销。我一直处于可以定期使用数据库的大部分（如果不是全部）最终用户功能的位置。作为用户，我屏息等待数据库从 AT&T SVR4 Unix 过渡到 Linux。我参与了新数据库的测试阶段，但我已经工作了足够长的时间，知道如此大规模的过渡通常不会顺利进行。《Linux Journal》的出版商兼 SSC 的首席纠缠者 Phil Hughes 反复宣布 Peter 和我们的系统管理员 Liem Banneman 将通宵工作进行过渡，让我们都为坎坷的旅程做好了准备。我准备相信他。

到星期三晚上 5 点，我们都清空了我们在计算机上的主目录，该计算机是 SVR4 版本 Progress 的所在地。第二天早上我来到公司，准备看到 Peter 和 Liem 眼睛布满血丝，脾气暴躁。我 telnet 连接到安装了 SCO 版本 Progress 的计算机，然后开始了我认为将是漫长的一天错误处理。我欣喜地发现一切正常！事实上，数据库的功能几乎与以前完全相同，只有一些令人愉快的例外。在 SVR4 下，vi 工作非常糟糕。新用户经常会觉得他们在命令行上意外地按下了大写字母，或者 vi 只是“奇怪”。整行会不规则地重复，或者光标实际上并不在它出现的位置。在 Linux 下，这个问题消失了。某些耗时的数据库操作（如全局密钥搜索）在 Linux 下更快；在所有计算机上访问相同的主目录文件也是一个优势。以前，我们必须 rcp 文件才能将它们放在 SVR4 系统和我们的个人工作站上，这有点烦人。

对于大多数用途，数据库在星期四上午 8 点的外观和行为与星期三下午 5 点时相同。到目前为止，我们没有遇到任何数据库崩溃，也没有发现任何可以追溯到 Linux 的错误。在所有情况下，错误都可以追溯到 SCO Progress 本身或程序员级别的临时错误。

在 Linux 下运行的 SCO Progress 可以工作。