直接连接：从大型机发送文件到 Unix答案

【问题标题】：Connect Direct : File sending from Mainframe to Unix直接连接：从大型机发送文件到 Unix
【发布时间】：2014-02-24 01:11:27
【问题描述】：

当我从 Mainframe Connect 直接发送一个可变长度文件到 UNIX 框时，UNIX 上的文件在 Mainframe 文件的开头有一些额外的字节，我尝试使用不同的 SYSOPTS 选项，但我仍然得到那些初始字节。有什么想法吗？

【问题讨论】：

发布此类问题时，您绝对应该包含一些额外字节的示例。这对我们确定问题非常有用。

标签： java unix mainframe

【解决方案1】：

您应该先将文件复制到大型机上的固定长度记录 (recfm=FB) 文件，然后再进行传输。有许多大型机实用程序可以做到这一点（即排序）。

如果您将其作为 VB 文件传输，您还应该将其保留为 EBCDIC 文件（BDW/RDW 字段是二进制字段，不应转换为 ASCII）。

正如其他人所说，有一个文件示例会很有用。

从 NealB 开始。大型机上的一个vb文件就是这样存储的

<BDW><RDW>Record Data 1
     <RDW>Record Data 2
      ....
     <RDW>Record Data n-1
<BDW><RDW>Record Data n
     <RDW>Record Data n+1
      ....
     <RDW>Record Data o-1
<BDW><RDW>Record Data o
     <RDW>Record Data o+1
      ....

在哪里

BDW : 块描述符字是4个字节；前 2 个字节是块长度（大端格式）；磁盘文件的最后 2 个字节将是十六进制 0（磁带文件可以使用这 2 个字节）。
RDW : 记录描述符字是4个字节；前 2 个字节是记录长度（大端格式）；最后 2 个字节将是十六进制 0。

因此，如果块长度为 240（并包含 3 个 80 字节的记录），那么文件将是

---BDW--- ---RDW---
00F0 0000 0050 0000 80-bytes of data (record 1)
          0050 0000 80-bytes of data (record 2)
          0050 0000 80-bytes of data (record 3)

可能有一个用于处理大型机 VB 文件的 unix 实用程序

Connect-Direct (NDM) 有一些 vb 选项（请参阅http://pic.dhe.ibm.com/infocenter/sb2bi/v5r2/index.jsp?topic=%2Fcom.ibm.help.cd_interop_sysopts.doc%2FCDP_UNIXSysopts.html）。

看文档，不能把vb选项和ascii翻译结合起来；在大型机上将文件转换为固定长度记录 (recfm=FB) 可能很有意义。

注意：您可以尝试使用Record Editor 并使用文件向导（布局名称左侧的按钮）查看文件。向导应该知道它是一个 Mainframe-VB 文件。

注意：虽然将文件转换为大型机上的固定长度记录是最好的选择，但如果需要，java 项目JRecord 可以读取大型机 VB 文件

【讨论】：

【解决方案2】：

一些额外的字节......“一些”是多少？

如果总是有 4 个字节，这些可能是承载记录长度的 RDW（记录描述符字）。

我对 Connect Direct 了解不多，但您可以通过大型机上的命令行 FTP 会话可以使用 LOCSTAT 命令验证 RDW 状态，如下所示：

 Command:
LOCSTAT RDW
 RDW's from VB/VBS files are retained as part of data.
 Command:

如果您看到上述消息，您可以使用以下命令删除 RDW：

LOCSITE NORDW

如果您是从大型机中拉取数据，那么您可以使用 FTP 命令查看 RDW 是否被剥离：

 QUOTE STAT

然后您将看到几条消息，其中一条报告 RDW 状态：

 211-RDWs from variable format datasets are retained as part of the data.

同样，您可以使用以下方法解决此问题

QUOTE SITE NORDW

之后 QUOTE STAT 应该给你：

211=RDWs from variable format datasets are discarded

【讨论】：

【解决方案3】：

额外的字节是0xEF 0xBB 0xBF、0xFF 0xFE 还是0xFE 0xFF？这就是 UTF 字节顺序标记。

如果是 UTF-8，请忽略它。把它剥掉，如果你喜欢。没意义。

如果是 UTF-16，那么您可以使用字节来确定字节顺序。如果您知道字节顺序，则可以安全地忽略或剥离它们。

如果您控制生成文件的应用程序，请将其更改为保存 UTF。只需将文件保存为 ASCII，BOM 就会消失。

【讨论】：