我们有一个基于 OpenVMS 的遗留 COBOL 应用程序——我们对它的配置没有清晰的概念。在这种情况下,我所说的“配置”是:
- 哪些可执行文件包含应用程序;
- 哪些原始源文件对应于哪些可执行文件。
上面的 1 是未知的东西可能看起来很奇怪,但随着时间的推移,可执行文件“来来去去”(并且许多仍在使用)。由于不再需要哪些可执行文件的知识已经随着时间的流逝而丢失,因此不知道哪些可执行文件构成了当今存在的应用程序。实际上,该团队忠实地编译所有源代码文件并部署生成的可执行文件,尽管有明显不再使用的程序。
不用说,没有正式的配置管理流程,源代码也没有保存在版本控制系统中。由于应用程序运行在 OpenVMS 上,相应的基于Files-11的文件系统保留了旧版本的文件(包括源文件),这一直是不将应用程序源放入版本控制系统的借口(尽管使用一个 VCS 远远超出了仅具有以前版本的记录)。
当然,可以通过多种方式确定配置,但我想从第一个“小步骤”开始,即:确定构成应用程序的可执行文件集。在这一点上我应该提一下,应用程序的可执行组件不仅限于 OpenVMS 映像,还包括 DCL 命令文件。我想:
- 记录驻留在某个目录或一组目录中的所有图像调用;
- 记录驻留在某个目录或一组目录中的命令文件的所有调用。
如果我们在生产系统上运行这个日志记录很长一段时间,比如两个月,我们可以很好地了解应用程序包含什么。连同用户咨询,我们将能够确认是否需要未调用的可执行文件。
我想我对如何执行上述 1 有一个想法,尽管我不确定具体情况,即使用SET/AUDIT
. 第二部分,现阶段,我不知道该怎么做。
因此,这项工作的主要标准是尽可能少地影响现有系统以获得上述信息。由于围绕配置的问号(以及完全缺乏自动化测试),改变任何东西都是一件令人伤脑筋的事情。
使用操作系统级别的服务SET/AUDIT
可以让人们了解正在运行的内容,而无需更改源代码和/或重新编译任何内容。所以,我的问题是多方的:
- 这是在 OpenVMS 上执行此操作的最佳方式吗?
- 我需要做什么来限制
SET/AUDIT
只监视特定目录中的图像? - 如何在不更改
.COM
源文件的情况下记录命令文件调用? - 由于记录此类信息而导致性能下降,我应该期待什么?