阅读Cobol生成的文件

我目前正在编写ac＃application，它将位于两个现有应用程序之间。 我所知道的第二个应用程序是它处理第一个应用程序生成的文件。 第一个应用程序是用Cobol编写的。

步骤：1）Cobol应用程序，将一些文件和副本写入目录。 2）第二个应用程序选择这些文件并处理它们。

我的C＃应用​​程序将介于1）和2）之间。 它必须拿起1）生成的文件，读取它，修改它并保存它，以便应用程序2）不知道我甚至在那里。

我有一些问题。

• 首先，如果我在记事本中打开由1）生成的文件，其中大部分都是不可读的，而其他部分则是。
• 如果我读取文件，修改并保存，我必须使用cobol应用程序使用的相同符号保存文件，以便app 2），不知道我在那里。

我试过这种方式读取文件，但它仍然不可读：

码：

string ss = @"filename"; using (FileStream fs = new FileStream(ss, FileMode.Open)) { StreamReader sr = new StreamReader(fs); string gg = sr.ReadToEnd(); } 

此外，如果我找到一种方法使其可读（使用某种编码技术），我担心当我再次保存文件时，我可能会改变它的原始格式。

有什么想法吗？ 建议？

Answer 1

要阅读COBOL-genned文件，您需要知道：

首先，您需要文件的记录布局 （副本）。 COBOL记录布局如下所示：

 01 PATIENT-TREATMENTS. 05 PATIENT-NAME PIC X(30). 05 PATIENT-SS-NUMBER PIC 9(9). 05 NUMBER-OF-TREATMENTS PIC 99 COMP-3. 05 TREATMENT-HISTORY OCCURS 0 TO 50 TIMES DEPENDING ON NUMBER-OF-TREATMENTS INDEXED BY TREATMENT-POINTER. 10 TREATMENT-DATE. 15 TREATMENT-DAY PIC 99. 15 TREATMENT-MONTH PIC 99. 15 TREATMENT-YEAR PIC 9(4). 10 TREATING-PHYSICIAN PIC X(30). 10 TREATMENT-CODE PIC 99. 

您还需要一份IBM的操作原理 （S / 360，S370，z / OS，对我们的目的并不重要）。 最新版本可从IBM获得

• http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a （但您需要一个IBM帐户。
• 可以免费获得旧版本， url为http://www.hack.org/mc/texts/principles-of-operation.pdf

第8章（十进制指令）和第9章（浮点概述和支持指令）是我们的目的。

没有它，你几乎迷失了。

然后，您需要了解COBOL数据类型。 例如：

• PIC定义了一个字母数字格式的字段（PIC 9（4），例如4个十进制数字，如果缺少空格字符可能会填充）。 图999V99是5位十进制数字，带有隐含的小数点。 所以，等等。
• BINARY [通常]是带符号的定点二进制整数。 通常的大小是半字（2个八位字节）和全字（4个八位字节）。
• COMP-1是单精度浮点。
• COMP-2是双精度浮点。

如果数据源是IBM大型机，则COMP-1和COMP-2可能不会是IEE浮点：它将是IBM的16位超额64浮点格式 。 你需要像S / 370操作原理这样的东西来帮助你理解它。

• COMP-3是“十进制的”，具有不同的长度。 压缩十进制是表示十进制数的紧凑方式。 声明如下所示： PIC S9999V99 COMP-3 。 这表示它是有符号的，由6位十进制数字组成，带有隐含的小数点。 压缩十进制表示每个十进制数字作为八位字节的半字节（hex值0-9）。 高位数字是最左边八位位组的高位半字节。 最右边的八位字节的低半字节是表示符号的hex值AF。 因此，上述PIC条款将要求ceil( (6+1)/2 )或4个八位字节。 值-345.67，由上面的PIC子句表示，看起来像0x0034567D 。 实际符号值可能不同（默认值为C /正，D /负，但A，C，E和F被视为正数，而只有B和D被视为负数）。 有关表示的详细信息，请参阅S \ 370操作原理 。

与COMP-3相关的是十进制分区。 这可能被声明为“PIC S9999V99”（带符号，5位十进制数字，带有隐含的小数点）。 EBCDIC中的十进制数字是hex值0xFO – 0xF9。 ‘解包’（主机机器指令）采用压缩十进制字段并转入字符字段。 过程是：

• 从最右边的八位字节开始。 反转它，因此符号半字节位于顶部并将其放入目标字段的最右侧八位字节。

• 从右到左（源和目标两者）工作，剥离压缩十进制字段的每个剩余半字节，并将其放入目标中下一个可用八位字节的低半字节。 用六角F填充高半字节。

• 当源或目标字段耗尽时，操作结束。

• 如果目标字段没有用尽，则通过用十进制“0”（oxF0）填充剩余的八位字节来左填充零。

因此，如果使用默认符号值（hexD）存储，我们的示例值-345.67将被解压缩为0xF0F0F0F3F4F5F6D7（’0003456P’，在EBDIC中）。

[你去吧。 稍后会有一个小测验]

1. 如果COBOL应用程序位于IBM大型机上，文件是否已从其本机EBCDIC转换为ASCII？ 如果没有，你将不得不进行自我映射（提示：它不一定像看起来那么简单，因为这可能是一个选择性过程 – 只转换字符字段（COMP-1，COMP-2，COMP） -3和BINARY被排除在外，因为它们是二进制八位字节的序列。更糟糕的是，由于不同的打印机使用不同的国家实现和不同的打印链，有多种EBCDIC表示forms。

哦……最后一件事。 大型机硬件倾向于喜欢在半字，字或双字边界上对齐的不同事物，因此记录布局可能不直接映射到文件中的八位字节，因为在字段之间可能存在填充八位字节以维持所需的字对齐。

祝好运。

Answer 2

我从您的问题附带的评论中看到，您正在处理“经典”COBOL批处理文件结构：标题记录，详细记录和预告片记录。

如果您负责创建预告片记录，这可能是个坏消息！ 典型的“预告片”记录用于识别文件结尾并提供控制信息，例如其前面的记录数量以及“详细”记录的各种校验和和/或总计。 换句话说，您可能需要阅读并汇总整个文件才能创建预告片。 除此之外，文件中的大部分数据都是Packed Decimal，Zoned Decimal或其他COBOLish数字数据类型的可能性，您可能会陷入困境。

您可能想要质疑为什么要将拖车记录添加到这些文件中。 通常，“预告片”由创建“详细”记录的相同程序或应用程序生成。 预告片应该作为validation发送应用程序/程序写入它应该的所有数据。 接收应用程序使用摘要总计，计数等来validation详细记录与前面的详细信息一致。 这应该作为另一个validation，发送应用程序没有消除数据或它没有在途中损坏（不，这不是一个笑话 – 但也许应该是）。 当一个“中间人”创造了预告片时，它会破坏演习的整个目的（无论它开始时有多么有缺陷）。

Answer 3

• 知道你正在处理哪个Cobol方言会很有用，因为没有单一的Cobol格式。 一些Cobol编译器（Micro Focus）在文件的前面放置了“文件描述”（对于Micro Focus VB /索引文件）。

• 看一下RecordEditor（ http://record-editor.sourceforge.net/ ）。 它有一个文件向导 ，可能对你非常有用。

  • 在文件向导中将文件设置为固定宽度文件（在Cobol中最常见）。 该程序允许您尝试不同的记录长度。 当您获得正确的记录长度时，文本字段应该排成一行。
  • 在向导中，后面有字段搜索，可以查找二进制，Comp-3，文本字段。
  • 关于使用带有未知文件的RecordEditor向导有一些注意事项http://record-editor.sourceforge.net/Unkown.htm

• 除非文件来自Mainframe / AS400，否则不太可能使用EBCDIC（cp037 – Coded Page 37是US EBCDIC），任何文本最有可能出现在Ascii中。

• 该文件可能包含Packed-Decimal（Comp3）和Binary-Integer数据。 大多数Cobols甚至在Intel（小端硬件）上使用Big-Endian（用于Comp整数）。

• 使用Cobol PIC s9（6）V99 comp时要记住的一件事是存储为二进制整数，x’0001’代表0.01。 因此，除非你有Cobol定义，否则你不能告诉二进制1是1 0.1,0.01等