Two-dimensional variable-length array in Cobol

Question

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

Answer 1

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.