IBM Mainframe Forum

David Jackson wrote:Also if it were me, I would define WS-ARR-MAZ-SIZE as a PIC S9(3) COMP-3 with a value of +40.

If it were me, I'd set it to PIC S9(4) COMP. The compiler will convert your COMP-3 into binary, so it avoids some generated code if it starts off as binary.

dick scherrer wrote:

Why do you want to get rid of the hard coding of 40?

As the pacha said. . .

But if hard code 40 instead of WS-ARR-MAX-SIZE, the code is working fine. I tried by giving PIC clause 'PIC S9(4) COMP' for WS-ARR-MAX-SIZE. But it did not work. Can anyone here please suggest way to remove the hard coding of 40.

The intent was to use the "discovered max" rather than hard-coding the max in the PERFORM. . .

I was blind-sided by the reference to OCCURS DEPENDING ON.

The "40" is the maximum possible entries (business limit, in whatever way), and the actual number of entries is discovered in the A100.

ATRINDEX is an index
WS-ARR-MAX-SIZE is a subscript

you need to compare indexes

From the reference guide:

index-name-1 Each index-name specifies an index to be created by the compiler for use by the program. These index-names are not data-names and are not identified elsewhere in the COBOL program; instead, they can be regarded as private special registers for the use of this object program only. They are not data and are not part of any data hierarchy. Unreferenced index names need not be uniquely defined. In one table entry, up to 12 index-names can be specified. If a data item that possesses the global attribute includes a table accessed with an index, that index also possesses the global attribute. Therefore, the scope of an index-name is the same as that of the data-name that names the table in which the index is defined.

COBOL probably uses a COMP field for the index values; if they are as fiddly as POINTER values you may have to make WS-MAX-ARRAY-SIZE PIC 9(4) COMP VALUE 40 to have it compare properly (your current one is a DISPLAY field).

I must admit I normally use a PIC S9(4) value and use subscript notation rather than INDEXED BY unless I'm doing a SEARCH ALL of a table - it's just easier to understand...

No matter which picture you give a subscipt , it will never compare to an index.
I should review the assembler code generated, but to my understanding indexes are actually adresses. When set to 1 it wil contain the start position of the table it is indexing. when adding 1 it actually adds the length of an occurence, and so on.

afaik you can not even compare indexes of two different tables.

GuyC wrote:When set to 1 it wil contain the start position of the table it is indexing

The index is a displacement from the start address of the storage for the table. When the index is looking at the first occurence of the table (ie "1" if it was a subscript) then it would contain the value 0. When it is looking at what would have been subscript 2, it contains the length of the storage that is occurring (as GuyC says). When Cobol uses the index, it adds the index value to the start of the table in storage, that being the reason it is faster than subscripting (does that matter much?).

Haven't used indexes so much myself. You have to be careful with comparisons and storing them. If your site uses them, read up thoroughly in the manual and practice until you are completely happy with everything it says.

BillyBoyo wrote:

GuyC wrote:When set to 1 it wil contain the start position of the table it is indexing

The index is a displacement from the start address of the storage for the table. When the index is looking at the first occurence of the table (ie "1" if it was a subscript) then it would contain the value 0. When it is looking at what would have been subscript 2, it contains the length of the storage that is occurring (as GuyC says). When Cobol uses the index, it adds the index value to the start of the table in storage, that being the reason it is faster than subscripting (does that matter much?).

Haven't used indexes so much myself. You have to be careful with comparisons and storing them. If your site uses them, read up thoroughly in the manual and practice until you are completely happy with everything it says.

Thanks for the correction/clarification. I was pretty close though, good enough to get the logic behind indexes.

GuyC wrote:I was pretty close though, good enough to get the logic behind indexes.

Yep. Some sites ban the use of indexes. If you use them, get to understand them as well as GuyC does, and you'll be OK. If you only half understand them (if you know how the verbs use them, but don't know how to compare and store them) then you'll likely get in a mess with them.

Someone wrote:Actually, for tables in WORKING-STORAGE, COBOL still allocates space for the maximum number of possible entries in the table -- ODO is more a programming convention than actually impacting memory.

Yes and no. Yes, it's true that COBOL allocates spaces for the maximum, but there's (a little) more to that. The variable on which the OCCURS depends also determines the length being used in MOVEs of the ODO field. That is, when you MOVE the variable on the level above the ODO to some other variable, COBOL won't move the maximum size but only the "actual" length. No big deal.... but sometimes using ODO can save a few CPU cycles (MVCLs are quite expensive)

So, I read, and get my data into FILE1. I move FILE1 to WS1. What happens? Excellent cycle-saving, because WS1-NO-OF-ENTRIES contains low-values (hex zeros) so the length of WS-1ENTRIES is calculated at zero.

Even more fun, as some people I used to know used to do, is if you move spaces to WS1 before moving the FILE1 to it (they do this right at the top of the program, as part of "good practice" to initialise everything ). Now, WS1-NO-OF-ENTRIES contains 4040 (hex for spaces). Which makes WS1-ENTRIES, well, quite long. By the way, after executing that move, you've wiped out a lot of your working-storage, and possibly even some of your program code.

So, if you want do a move to a level that is higher than the ODO count, you must do a seperate move to the ODO count first.

It is also a bit of a nightmare when some idiot comes along and puts more data after the ODO, ie at the same level, because the location of all of those data items moves every time you change the count.

In the end I avoided ODO in general use, because it was just too easy to screw up in a big way. Remember, the person maintaining your program might not be you. Or it might be you on a bad day. And it might get to be a very bad day (I've seen someone screw-up every record on a "masterfile" in this way - unlucky fluke that it didn't dump, always happens at the worst time).

For very specific uses, it can be fun. In Cobol-before-unstring, I used it for keyword-parsing. Also used it for an automated DOS-MVS conversion of about 600 cobol programs.