使用 C 将 COMP 和 COMP-3 Packed Decimal 转换为可读值

Posted 2023-02-16

【中文标题】使用 C 将 COMP 和 COMP-3 Packed Decimal 转换为可读值

【英文标题】：Convert COMP and COMP-3 Packed Decimal into readable value with C

【发布时间】：2014-03-12 09:08:02

【问题描述】：

我有一个 EBCDIC 平面文件要从大型机处理成 C 模块。将 COMP 和 COMP-3 值转换为可读值的好过程是什么？我是否必须将 ebcdic 字符转换为 ascii，然后为 COMP-3 转换为十六进制？那么COMP呢？谢谢

【问题讨论】：

到目前为止，最简单的做法是为 ASCII 系统创建没有任何非显示字段的文件。这将是一个简单的使用 SORT 的 COPY 步骤，然后您就无需执行任何操作。如果无法做到这一点，请查看此处标记为 ebcdic

的一些问题

所以你的意思是如果我的平面文件是 ASCII 格式会更好？

我们（来自大型机）通常尝试做的，好吧，也许只是那些已经存在较长时间的人，是专门为特定任务创建一个文件，这是一个逻辑副本物理上以“字符”格式的数据。当我们创建它时，它就是 EBCDIC。然后，使用任何实用程序将其传输到非大型机（FTP、NDM 等），让该实用程序执行其内置的 EBCDIC 到 ASCII 转换。然后接收只需要检查标题和尾部（预期日期、预期逻辑文件名、记录计数、一些哈希总计等）。然后您的文件以 ASCII 格式到达。

您应该在开始工作之前签署一份协议，说明这应该如何发生。你的一方应该为字符数据争论，他们会抱怨需要一个额外的程序。他们要么对你撒谎，要么不称职，要么就是不专业。在使用数据之前，您无需触摸数据（不是来自银行的数据，或者没有经过审计/合规/监管/法律人员的处理）。那是完全错误的。人们这样做。检查逻辑内容应该是您在处理之前需要做的所有事情。

我实际上是这个项目的新手，所以我不太了解这个项目的细节。一会儿我会问的。是的，我已经考虑过为此使用翻译表。我只是希望有另一种解决方法。

【参考方案1】：

Bill Woodger 通过他的 cmets 为您的问题提供了一些非常好的建议，实际上他回答了这个问题并且应该 发布了他的 cmets 作为答案。

我想重申他的一些观点并扩展其他一些观点。

如果您需要转换从可能是 COBOL 应用程序创建的文件，以便可以读取它 由其他一些非 COBOL 程序，可能在具有不同于创建它的架构的机器上，然后 您应该要求仅使用显示格式数据（即所有字符数据）创建文件。糖化不显示 （二进制、打包、编码）数据在创建它的操作环境之外只是一个公式 长期的痛苦。您将享受整理各种endianness 问题的乐趣 在架构和code page 转换之间。这些是 文件传输协议旨在管理 - 他们做得很好，所以不要试图重新发明它们。简短的回答，使用 FTP 或 类似的文件传输机制在机器之间移动数据。并且仅传输基于显示（字符）的数据。

压缩十进制 (COMP-3) 数据类型根据其特定的 PICTURE 布局占用不同数量的字节。小数点的位置 是隐含的，因此如果不参考用于定义它的图片就无法确定。压缩十进制字段可以是签名的 或未签名。如果有符号，则符号嵌入最低有效位的低 4 位。压缩十进制的每个字节 数据类型包含两位数字，可能除了第一个和最后一个字节。如果字段已签名，则第一个字节仅包含 1 个数字 并且包含偶数位数。如果无符号，最后一个字节包含 2 位数字，但如果有符号，则只有 1 位。还有其他一些微妙之处 您需要注意是否要进行自己的 Packed Decimal 到字符的转换。在这一点上，我希望你能看到 这不是一个简单的练习。

二进制 (COMP) 数据类型有一组不同但同样复杂的问题需要解决。同样，这不是一项简单的练习。

那你应该怎么做？基本上，按照比尔的建议去做。让生成此文件的程序使用显示格式 用于输出（意味着你什么都不做）。或者，如果做不到这一点，请使用 DFSORT/SYNCSORT 等实用程序进行转换 为你。使用实用程序 route 仍然要求您具有原始 COBOL 文件布局（并且您理解它）才能进行转换。 最后的手段是简单地编写一个简单的读取记录写入记录 COBOL 程序，该程序接收未格式化的数据 MOVEes 每个 COMP-whatever 字段到相应的 DISPLAY 字段并再次写出。

正如比尔所说，如果制作此文件的小组告诉您制作 DISPLAY 格式太难/太贵 输出文件他们在骗你或他们无能或只是懒得 做他们被雇用做的工作。我想不出其他借口了。

【讨论】：

是的，但此时的问题是在评论中:-)

【参考方案2】：

使用 XML 传输数据。

也就是说，编写一个程序，将您的文件转换为字符（如果在大型机上，请保留 EBCIDIC 但数字字段未打包等），然后将每个记录和每个字段包含在 XML 标记中。

这避免了格式问题（第 1 列中的哪些字段，第 2 列中的哪些字段，分隔符是空格还是逗号，等等，令人作呕）。

然后使用您喜欢的从 EBCIDIC 转换为 ASCII 的实用程序传输 XML 文件。

【讨论】：

数据是固定位置的，所以什么在哪里都没问题。 OP 没有要求 XML。即使使用分隔与 XML，也需要考虑性能（字段数、记录数）。

Bill Woodger，我很少让 OP 定义技术解决方案（XML 与文本）。在考虑 O(n) 与 O(n*2) 时，需要考虑性能。在考虑 100 字节记录与 500 字节记录时，性能不是考虑因素。如有必要，出于传输目的压缩数据集。

好的，抱歉，不知道他们为您工作。他们似乎忽略了你的规格，你最好解决这个问题。我说的是字段数，而不是字节数。如果您解析大量 XML 并与解析同等数量的分隔符进行比较，您应该会发现差异。与等价的固定长度字段的另一个更大的区别。为固定长度的字段建议 XML 很奇怪，但你是老板。

@Bill Woodger，“应该看到不同”，是的，但是你呢？除非两种方法之间存在数量级差异，否则不太可能。 XML 的优势在于它对固定或可变长度字段一无所知。