Short version first. Your Report Mode code doesn’t do what you think it does. To see this use TEST DBLOG to view the Format and Record buffers for the READ. You will discover that you are only reading one occurrence of the fields DNDX2 and DKDX2.
In strict Report Mode (no DEFINE DATA clause), Natural examines the READ loop and asks Adabas for the variables that are explicitly mentioned in the READ loop. That is why it is illegal to reference a database field outside of the relevant READ or FIND loop.
In Structured Mode, or what I call “mixed mode” (old syntax (LOOP, etc) with a DEFINE DATA clause), Natural asks Adabas for all the fields mentioned in the View.
In your DEFINE DATA version of the program you probably have a view which includes entries like DNDX2 (1:20) (or, PEGROUP (1:20)). If you look (DBLOG) at the Record Buffer for such View you will see that you are asking for twenty members of the field DNDX2.
So, in the data area in your strict Report Mode version, there is only storage for DNDX2 (1), and Natural has only asked Adabas for the first occurrence.
UNFORTUNATELY, Natural will do the MOVE INDEXED statements. It is simply picking up what is lying around in memory where the 2:20 occurrences would be , if they were there (but they are not there).
In strict report mode, there is a “fix” for this. In the READ loop, you must have the statement
OBTAIN DNDX2 (1:20) DKDX2(1:20)
This is, in reality, not an executable statement. Instead, it is a message to the Natural compiler, telling it to ask Adabas for twenty occurrences for each field, and, allocating space in memory for twenty occurrences.
Again, use DBLOG and you will see that with the OBTAIN, Natural is asking Adabas for twenty occurrences.
Re your second question, CMU works just like CPE.
If you have more questions about this, just post them.