1

我正在使用的大多数文件只有以下字段：

  • F00001 - 通常为 1 (f1) 或 9 (f9)
  • K00001 - 通常只有 1-3 个分区小数和 ebcdic 子字段
  • F00002 - ebcdic、分区和压缩小数的子字段

有时其他字段名称 K00002、F00003 和 F00004 会出现在交叉引用文件中。

示例数据：

+---------+--------------------------------------------------+--------------------------------------------------------------------------------------------+
| F00001  | K00001                                           |  F00002                                                                                    |
+---------+--------------------------------------------------+--------------------------------------------------------------------------------------------+
| f1      |  f0  f0  f0  f0  f1  f2  f3  f4  f5  f6  d7  c8  | e2  e3  c1  c3  d2  d6  e5  c5  d9  c6  d3  d6  e7  40 12  34  56  7F  e2  d2  c5  c5  e3  |
+---------+--------------------------------------------------+--------------------------------------------------------------------------------------------+

目前使用：

SELECT SUBSTR(HEX(F00001), 1, 2) AS FNAME_1, SUBSTR(HEX(K00001), 1, 14) AS KNAME_1, SUBSTR(HEX(K00001), 15, 2) AS KNAME_2, SUBSTR(HEX(K00001), 17, 2) AS KNAME_2, SUBSTR(HEX(F00002), 1, 28) AS FNAME_2, SUBSTR(HEX(F00002), 29, 8) AS FNAME_3, SUBSTR(HEX(F00002), 37, 10) AS FNAME_4 FROM QS36F.FILE

这是将 EBCDIC 值解压缩为字符串的最佳方法吗？

4

2 回答 2

3

您要求“最好的方法”。手动摆弄字节绝对不是最好的方法。@JamesA 有一个更好的答案：外部描述表并使用更传统的 SQL 来访问它。我在您的评论中看到您在同一个表格中有多个布局。这是几年前我们从穿孔卡片转换为磁盘时的典型情况。我感受到你的痛苦，经历了很多次。

如果您使用 SQL 来运行查询，我认为您有几个选择，所有这些选择都围绕着拥有一个健全的 DB2 表而不是一个混乱的 S/36 平面文件。如果没有关于业务问题的更多细节，我们所能做的就是提供建议。

1) 向 QS36F.FILE 添加一个触发器，它将混合的记录分解为单独的 SQL 定义的表。查询那些。

2) 编写一些将打包和解包数字的 UDF。如果您今天查询，明天您将更新，如果您认为您有机会维护 SELECTS 的原始 HEX(this) 和 HEX(that)，请等到您尝试以这种方式进行 UPDATE。

3) 编写存储过程，提取给定查询所需的位，将它们放入 SQL 表中 - 甚至可能是 GLOBAL TEMPORARY TABLE。让 SP 查询这些位并返回可由其他 SQL 查询使用的结果集。IBM i 也支持用户定义的表函数。

4) 让 RPG 团队为您编写一个转换程序，该程序将读取旧文件并创建一个您可以查询的数据仓库。

于 2014-02-13T15:41:22.960 回答
0

看起来好像旧的 S/36 文件正在被访问，并且系统在 CCSID 65535 下运行。这可能会导致混乱的“十六进制”表示问题以及至少一些列名问题。有关服务器环境的更多信息会很有用。

于 2014-03-15T14:32:23.013 回答