| View previous topic :: View next topic |
| Author |
Message |
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
 Posted: Fri Feb 12, 2021 3:11 am Post subject: COBOL nested array with IN verb |
 |
|
After so many years, I almost feel embarrassed to ask this, but here goes.
First the relevant parts of my copybook (note that KUND-TBL is "under" KONTO-TBL) :-
| Code: |
05 konto-tbl.
10 konto-rows occurs 40.
15 konto-details.
20 id-kundnr pic 9(9).
.......
20 kund-tbl.
25 kund-rows occurs 5.
30 kund-details
35 id-kundnr pic 9(9).
......
|
Now any reference to
| Code: |
move 12345 to id-kundnr in kund-tbl(index-1 index2)
|
or any variation on that theme I can think of gives compiler error
| Quote: | | ID-KUNDNR was not a uniquely defined name. |
I found this online and am wondering whether maybe I've been hit by the same probem ?
Stack overflow question
_________________
Michael |
|
| Back to top |
|
 |
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
| Posted: Fri Feb 12, 2021 9:31 am Post subject: |
|
|
I read it and it doesn't seem to be what I'm looking for . (BTW, we're on COBOL 6 if that's relevant).
I tried
| Code: |
MOVE W-ID-KUNDNR TO UT-ID-KUNDNR
IN UT-KONTO-DETAILS
IN UT-KONTO-ROWS(IXA)
|
which failed, and
| Code: |
MOVE W-ID-KUNDNR TO UT-ID-KUNDNR
IN UT-KONTO-DETAILS(IXA)
|
and (the one I thought would be correct)
| Code: |
MOVE W-ID-KUNDNR TO UT-ID-KUNDNR
IN UT-KONTO-ROWS(IXA)
|
but they all give the same error.
_________________
Michael |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Fri Feb 12, 2021 12:40 pm Post subject: |
|
|
| misi01 wrote: | | I read it and it doesn't seem to be what I'm looking for . (BTW, we're on COBOL 6 if that's relevant). |
misi01,
Not sure if you tried what is mentioned in that topic as your examples don't show the same thing. Here is something that should work.
| Code: |
01 KUND-RECORD.
05 KONTO-TBL.
10 KONTO-ROWS OCCURS 40 INDEXED BY I1.
15 KONTO-DETAILS.
20 ID-KUNDNR PIC 9(9).
20 KUND-TBL.
25 KUND-ROWS OCCURS 5 INDEXED BY I2.
30 KUND-DETAILS.
35 ID-KUNDNR PIC 9(9).
MOVE 12345 TO ID-KUNDNR
OF KUND-TBL
OF KONTO-TBL (I1 I2)
|
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
| Posted: Fri Feb 12, 2021 2:34 pm Post subject: |
|
|
I changed your code a "smidgen" to the following (I commented out the INDEXED BY since the repository generator where I'm working now doesn't allow that sort of definition)
| Code: |
01 KUND-RECORD.
05 KONTO-TBL.
10 KONTO-ROWS OCCURS 40
* INDEXED BY I1
.
15 KONTO-DETAILS.
20 ID-KUNDNR PIC 9(9).
20 KUND-TBL.
25 KUND-ROWS OCCURS 5
* INDEXED BY I2
.
30 KUND-DETAILS.
35 ID-KUNDNR PIC 9(9).
|
Here's my code
| Code: |
*
MOVE 12345 TO ID-KUNDNR
OF KUND-TBL
OF KONTO-TBL (IXA IXB)
*
MOVE 12345 TO ID-KUNDNR
OF KONTO-TBL (IXA)
|
The problem is that the first move compiles okay, but the second one fails (if it is my fault, then it's staring me in the face and I can't see it)
_________________
Michael |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Fri Feb 12, 2021 3:49 pm Post subject: |
|
|
misi01,
Unfortunately you canNOT refer the FIRST ID-KUNDNR with the current definition. The only way you can get around is have another variable before it.
Something like this . I added the variable KONTO-LEVEL1 before the first ID-KUNDNR
| Code: |
01 KUND-RECORD.
05 KONTO-TBL.
10 KONTO-ROWS OCCURS 40 INDEXED BY I1.
15 KONTO-DETAILS.
20 KONTO-LEVEL1.
25 ID-KUNDNR PIC 9(9).
20 KUND-TBL.
25 KUND-ROWS OCCURS 5 INDEXED BY I2.
30 KUND-DETAILS.
35 ID-KUNDNR PIC 9(9).
MOVE 12345 TO ID-KUNDNR
OF KONTO-LEVEL1 (I1)
MOVE 67890 TO ID-KUNDNR
OF KUND-TBL
OF KONTO-TBL (I1 I2)
|
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
| Posted: Sat Feb 13, 2021 4:35 am Post subject: |
|
|
Thanks for your reply. I thought I'd expand on it a bit for "educational" purposes.
Here's the code with your change and my moves.
| Code: |
01 KUND-RECORD.
05 KONTO-TBL.
10 KONTO-ROWS OCCURS 40.
15 KONTO-DETAILS.
20 KONTO-LEVEL1.
25 ID-KUNDNR PIC 9(9).
20 KUND-TBL.
25 KUND-ROWS OCCURS 5.
30 KUND-DETAILS.
35 ID-KUNDNR PIC 9(9).
*
PROCEDURE DIVISION.
*
STYR SECTION.
*
MOVE 12345 TO ID-KUNDNR
OF KUND-TBL
OF KONTO-TBL (IXA IXB)
*
MOVE 12345 TO ID-KUNDNR
OF KONTO-LEVEL1(IXA)
*
MOVE 12345 TO ID-KUNDNR
OF KONTO-DETAILS (IXA)
*
GOBACK.
|
When I compiled the, the first 2 were okay, but the last one failed. Why ?
In the first example, I think the compiler looks for each ' OF ' statement (excluding the last one)
and follows the logic for the second example below. Ie, "OF KUND-TBL is at level 20 and there is only one unique ID-KUNDNR between that level 20 and the next one.
(If I'd written
| Code: |
MOVE 12345 TO ID-KUNDNR OF KONTO-DETAILS OF KONTO-TBL (IXA)
|
then the compiler would have complained. Here, KONTO-DETAILS is at level 15, and we can see that there are two ID-KUNDNR variables "under it")
In the second one, we're saying "OF KONTO-LEVEL1". KONTO-LEVEL1 is at level 20,
so we have to look at all the fields between this level 20 and the next one that
is at the same level or lower (ie, 15, 10, 05 etc). Here, the next "relevant" level is KUND-TBL at level 20 as well.
Between these two, there is only one ID-KUNDNR (at level 25), so we're good to go here.
Now, the last one (which fails). Same logic again. ID-KUNDNR is addressed as being "OF KONTO-DETAILS",
which is at level 15. How many ID-KUNDNR do we have at a level higher than 15? Answer 2;
one at level 25 and one at 35. And it's for this reason that the compiler complains.
A final point. Some people reading this might wonder why I define my tables as
| Code: |
05 KONTO-TBL.
10 KONTO-ROWS OCCURS 40.
|
rather than something like
| Code: |
05 KONTO-TBL OCCURS 40.
|
The reason is simple; I avoid code such as
| Code: |
perform varying index from 1 by 1 until index > 40
|
Instead, I code in my init section the following
| Code: |
compute w-nr-konto-rows = length of konto-tbl
/ length of konto-rows(1)
|
and my perform loop becomes
| Code: |
perform varying index from 1 by 1 until index > w-nr-konto-rows
|
Now you might think this is no big deal, but wait until you have to change a program containing 2 or more tables, each with, say , occurs 10. Now, you're asked to change one of the tables from occurs 10 to occurs 11.
Have fun !!!! (Yes, of course it's doable, but I'll make the change in a fraction of the time it takes you to do it,and with no need to test?).
_________________
Michael |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Sun Feb 14, 2021 9:29 am Post subject: |
|
|
| misi01 wrote: | | Thanks for your reply. I thought I'd expand on it a bit for "educational" purposes. |
Misi01,
I think you need to remember phrase Keep it simple. I question the need for coding duplicate names. It would have been a simple coding had you chose unique names. Simplicity should be a key goal in design, and unnecessary complexity should be avoided.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
| Posted: Mon Feb 15, 2021 12:07 am Post subject: |
|
|
KISS principle. Agree with you completely, but the repository where I'm working is, I believe, home-grown. Let's just say I've seen better designs.
_________________
Michael |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
