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

【问题标题】：Convert COMP and COMP-3 Packed Decimal into readable value with C使用 C 将 COMP 和 COMP-3 Packed Decimal 转换为可读值
【发布时间】：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 格式到达。
您应该在开始工作之前签署一份协议，说明这应该如何发生。你的一方应该为字符数据争论，他们会抱怨需要一个额外的程序。他们要么对你撒谎，要么不称职，要么就是不专业。在使用数据之前，您无需触摸数据（不是来自银行的数据，或者没有经过审计/合规/监管/法律人员的处理）。那是完全错误的。人们这样做。检查逻辑内容应该是您在处理之前需要做的所有事情。
我实际上是这个项目的新手，所以我不太了解这个项目的细节。一会儿我会问的。是的，我已经考虑过为此使用翻译表。我只是希望有另一种解决方法。

标签： c mainframe flat-file

【解决方案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 的优势在于它对固定或可变长度字段一无所知。