FD blah blah
05 FILE1-NO-OF-ENTRIES COMP PIC S9(4).
05 FILE1-ENTRIES OCCURS 10 TIMES DEPENDING ON FILE1-NO-OF-ENTRIES.
10 FILE1-BIT-OF-DATA PIC X.
05 WS1-NO-OF-ENTRIES COMP PIC S9(4).
05 WS1-ENTRIES OCCURS 10 TIMES DEPENDING ON WS1-NO-OF-ENTRIES.
10 WS-BIT-OF-DATA PIC X.
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.