Incorrect extracting data from the fields of periodic groups

, ,
1

Hi!

I have a problem with extracting data from the fields of periodic groups. Extracted data is not correct.

Code:

RESET MAXX(N2) D1(N6) D2(N6)
READ KADR
   MAXX = C*PEREM
   FOR H 1 MAXX
     MOVE INDEXED DNDX2(1)<H> TO D1
     MOVE INDEXED DKDX2(1)<H> TO D2
     DISPLAY D1 D2 
   LOOP
LOOP

I know that the use a MOVE INDEXED undesirable, but I use dynamic variable declaration and the other way I have not found.

The strange thing is that with the previous table I did not have these problems (although using the same method). The data extracting correctly.

I note that when I declare variables using DEFINE DATA, I get correct data. But in this case I cant know the count records in a periodic groups (C* not working).

And one more question: How I can know the count of records in the multiple-field?

Thanks in advance!

2

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.

1 Like
3

Thank you for your reply, Steve!

Once again you have saved me :slight_smile: After your post in my head cleared. I should have known about OBTAIN, I’ve have met him and guessed of his appointment.

Thanks a lot!

4

Hi Alexander,
Just my 2 cents (of course I would not be so good in saving your life like Steve :slight_smile:

Perhaps, you would avoid many problems if you could NOT use reporting mode at all (moreover, it is not recommended either by Software Ag) :
http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat638vms/pg/pg_mode.htm
Purpose of Programming Modes

Natural offers two ways of programming:

Reporting Mode

Structured Mode

Note:
Generally, it is recommended to use structured mode exclusively, because it provides for more clearly structured applications.

So, why bother? :slight_smile:
Best regards,
Nikolay

1 Like