Cobol 中的二维变长数组

发布于 2024-08-18 17:34:16 字数 201 浏览 6 评论 0原文

如何在 Cobol 中定义一个二维 MxN 数组，其中 M 和 N 的长度都是可变的？

这是我在尝试将变量数组放入另一个数组时在 Net Express 中收到的消息：

COBCH0144S OCCURS DEPENDING subsidiary to OCCURS only allowed with ODOSLIDE

原文

How do you go about defining a two-dimensional MxN array in Cobol of which both M and N are of variable length?

Here's the message I get in Net Express when attempting to have a variable array inside another:

COBCH0144S OCCURS DEPENDING subsidiary to OCCURS only allowed with ODOSLIDE

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

剩一世无双 2024-08-25 17:34:16

您试图定义的是“复杂发生取决于”结构（复杂ODO）。

您可以定义一个复杂的 ODO，其中表格是矩形，如下所示：

       01  TABLE-REC.

           05  M             PIC S9(4) BINARY.
           05  N             PIC S9(4) BINARY.
           05  ROWS OCCURS 10 TIMES DEPENDING ON M.
               10 COLUMNS OCCURS 10 TIMES DEPENDING ON N.
                  20 CELL PIC X(1).

技巧是 N 的声明不能出现在变量内
表的一部分。例如，以下声明：

       01  TABLE-REC.
           05  M             PIC S9(4) BINARY.
           05  ROWS OCCURS 1 TO 10 TIMES DEPENDING ON M.
               10 N          PIC S9(4) BINARY
               10 COLUMNS OCCURS 1 TO 10 TIMES DEPENDING ON N.
                  20 CELL PIC X(1).

会给你一个错误，因为声明意味着每行可能包含不同的
列数（即不是矩形表格）。

一般来说，对于 COBOL 中的 ODO 结构有很多困惑
真的“买”你。有一个常见但错误的观点，即它可能
用于节省内存
因为数据结构的大小可以动态调整。这是
当 ODO 在 LOCAL 或 WORKING STORAGE 下声明时绝对错误。
COBOL编译器会分配足够的内存来容纳
M 和 N 的最大值。

它为您“购买”的是一种物理组织数据的机制
记忆中。看看下面的程序以及什么
它显示：

       IDENTIFICATION DIVISION.
         PROGRAM-ID. EXODO.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       77  I                 PIC S9(4) BINARY.
       77  J                 PIC S9(4) BINARY.
       01  DIMENSIONS.
           05  M             PIC S9(4) BINARY VALUE 6.
           05  N             PIC S9(4) BINARY VALUE 7.
       01  TABLE-REC-1.
           05  ROWS OCCURS 1 TO 10 TIMES DEPENDING ON M.
               10 COLUMNS OCCURS 1 TO 10 TIMES DEPENDING ON N.
                  20 CELL PIC X(1).
       01  TABLE-REC-2.
           05  ROWS OCCURS 10 TIMES.
               10 COLUMNS OCCURS 10 TIMES.
                  20 CELL PIC X(1).
       PROCEDURE DIVISION.
           PERFORM VARYING I FROM 1 BY 1 UNTIL I > M
              PERFORM VARYING J FROM 1 BY 1 UNTIL J > N
                 MOVE 'X' TO CELL OF TABLE-REC-1 (I J)
                 MOVE 'X' TO CELL OF TABLE-REC-2 (I J)
              END-PERFORM
           END-PERFORM
           DISPLAY TABLE-REC-1
           DISPLAY TABLE-REC-2
           GOBACK
           .

显示：
<代码>

    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXX   XXXXXXX   XXXXXXX   XXXXXXX   XXXXXXX   XXXXXXX

请注意，ODO 版本已将所有数据很好地整合到一起
6 X 7 矩阵，而固定表版本保留 10 X 10
矩阵中有一堆“洞”来填充每个洞
行达到其最大 OCCURS 数。有时，这
区别很重要（但大多数情况下并不重要）。

我看到您使用的是 Net Express，我对它不熟悉，所以您
可能需要摆弄才能让下一部分工作。和
IBM Enterprise COBOL for Z/OS 您可以执行以下操作：

在程序 LINKAGE SECTION 中定义 ODO，这样就没有内存
已分配，它只是一个记录布局。那么你可以
根据表的实际大小动态分配足够的内存
需要（即 M 乘以 N 个元素）。使用连接两者
类似于：将 ODO-DATA-STRUCTURE 的地址设置为 mem-address
（在CICS下使用GETMAIN，在batch下使用CEEGTST来获取内存）。
现在你有了一个动态数据结构
确实使用了最少的空间并且仍然可以正确索引
由于上面所示的布局属性。

在 COBOL 中还有其他使用（或不使用）ODO 的方法，但是
这些是我所知道的最常见的。

What you are trying to define is a "Complex Occurs Depending On" structure (complex ODO).

You may define a Complex ODO where the table is rectaguar as follows:

       01  TABLE-REC.

           05  M             PIC S9(4) BINARY.
           05  N             PIC S9(4) BINARY.
           05  ROWS OCCURS 10 TIMES DEPENDING ON M.
               10 COLUMNS OCCURS 10 TIMES DEPENDING ON N.
                  20 CELL PIC X(1).

The trick is that the declaration of N cannot occur within the variable
part of the table. For example, the following declaration:

       01  TABLE-REC.
           05  M             PIC S9(4) BINARY.
           05  ROWS OCCURS 1 TO 10 TIMES DEPENDING ON M.
               10 N          PIC S9(4) BINARY
               10 COLUMNS OCCURS 1 TO 10 TIMES DEPENDING ON N.
                  20 CELL PIC X(1).

will give you an error because the declaration implies that each row may contain a different
number of columns (ie. not a rectangular table).

In general, there is a lot of confusion as to what an ODO structure in COBOL
really "buys" you. There is a common, but mistaken view, that it may
be used to save memory
because the size of the data structure can be dynamically sized. This is
absolutely false when the ODO is declared under LOCAL or WORKING STORAGE.
The COBOL compiler will allocate enough memory to accomodate
the largest value of M and N.

What it does "buy" you is a mechanism to physically organize data
in memory. Look at the following program and what
it displays:

       IDENTIFICATION DIVISION.
         PROGRAM-ID. EXODO.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       77  I                 PIC S9(4) BINARY.
       77  J                 PIC S9(4) BINARY.
       01  DIMENSIONS.
           05  M             PIC S9(4) BINARY VALUE 6.
           05  N             PIC S9(4) BINARY VALUE 7.
       01  TABLE-REC-1.
           05  ROWS OCCURS 1 TO 10 TIMES DEPENDING ON M.
               10 COLUMNS OCCURS 1 TO 10 TIMES DEPENDING ON N.
                  20 CELL PIC X(1).
       01  TABLE-REC-2.
           05  ROWS OCCURS 10 TIMES.
               10 COLUMNS OCCURS 10 TIMES.
                  20 CELL PIC X(1).
       PROCEDURE DIVISION.
           PERFORM VARYING I FROM 1 BY 1 UNTIL I > M
              PERFORM VARYING J FROM 1 BY 1 UNTIL J > N
                 MOVE 'X' TO CELL OF TABLE-REC-1 (I J)
                 MOVE 'X' TO CELL OF TABLE-REC-2 (I J)
              END-PERFORM
           END-PERFORM
           DISPLAY TABLE-REC-1
           DISPLAY TABLE-REC-2
           GOBACK
           .

Displays:

    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXX   XXXXXXX   XXXXXXX   XXXXXXX   XXXXXXX   XXXXXXX

Notice the ODO version has all of the data nicely compated into
a 6 X 7 matrix while the fixed table version retains the 10 X 10
matrix with a bunch of "holes" in it to fill out each
row to its maximum number of OCCURS. There are times when this
distinction is important (most often it isn't though).

I see you are using Net Express, which I am not familiar with so you
may have to fiddle around to get the next part to work. With
IBM Enterprise COBOL for Z/OS you can do the following:

Define an ODO in the program LINKAGE SECTION so no memory
is allocated, it is just a record layout. Then you can
dynamically allocate enough memory for the actual size of table
needed (ie. M times N elements). Connect the two using
something like: SET ADDRESS OF ODO-DATA-STRUCTURE TO mem-address
(under CICS use GETMAIN and under batch use CEEGTST to obtain memory).
Now you have a dynamic data structure
that does use the minimum amount of space and will still index properly
because of the layout propreties illustrated above.

There are other ways of using (or not using) ODO's in COBOL but
these are the most common ones I am aware of.

回复收藏 0 原文