baffling arrays problem - comp.lang.fortran

hello one and all, right, I've been battling with f77 on a linux machine for 4 days now on what seems a stupid problem, but I simply do not see what's wrong. hope someone can help. here is a short version of a code I am writing (hopefully error free): definitions : parameter (no_of_files=13) integer kw(no_of_files,high),ukl(no_of_files,high),non_single integer kdf(no_of_files),kfi(no_of_files,high) char*5 kni(no_of_files,high),kl(no_of_files,high) main prog : 30 read a file whose index within the prog is file_number file_number=file_number+1 ! (=<no_of_files) ! a loop defines non_single do 10,icount=1,non_single kdf(file_number)=kdf(file_number)+1 kni(file_number,kdf(file_number))=kl(file_number,i) kfi(file_number,kdf(file_number))=1+icount kw (file_number,kdf(file_number))=2+icount (*) ukl(file_number,kdf(file_number))=5+icount (**) 10 continue ---------- do 20, icount=1,file_number do 40, jcount=1,kdf(icount) write (*,60) icount,kni(icount,jcount),kfi(icount,jcount), ukl(icount,jcount),kw(icount,jcount) 60 format (---stuff----) 40 continue 20 continue goto 30 ####### (the names of the vars are not the actual one : I used initials for readability) right, so until the dashed line I assign values (char or number) to arrays. no problem the problem is SEEN (I am not saying that's WHERE it is) in the write statement after the dashed line : basically what it does it print to the screen all contents of all arrays from file_number=1 to whatever value it has at any given time. (cxy = character array at index x,y; nxy = number at index x,y) so: file_number=1 gives 1 c11 n11 n11 n11 1 c12 n12 n12 n12 1 c13 n13 n13 n13 etc down to y=kdf(1) file_number = 3 gives (skipping 2 to get the idea quicker) 1 c11 n11 n11 n11 1 c12 n12 n12 n12 1 c13 n13 n13 n13 etc down to y=kdf(1) 2 c21 n21 n21 n21 2 c22 n22 n22 n22 2 c23 n23 n23 n23 etc down to y=kdf(2) 3 c31 n31 n31 n31 3 c32 n32 n32 n32 3 c33 n33 n33 n33 etc down to y=kdf(3) fine so far ... except that, what's above is what is SHOULD give! what I actually get is (going straight to file_number=3 to see clearly since the file_number=1 case is going to be identical to the one above) : file_number = 3 1 c11 n11 n11 538976288 1 c12 n12 n12 538976288 1 c13 n13 n13 538976288 etc down to y=kdf(1) 2 c21 n21 n21 538976288 2 c22 n22 n22 538976288 2 c23 n23 n23 538976288 etc down to y=kdf(2) 3 c31 n31 n31 n31 3 c32 n32 n32 n32 3 c33 n33 n33 n33 etc down to y=kdf(2) in other words all arrays work fine except for kw (marked *) above, which "forgets" its contents for all cases of file_number except the current one! I initially thought about a memory problem and so explored a number of avenues, to no avail. eventually I added ukl array as a test, which I did not have initially (marked (**) above, meaning of course that the fourth column for each case was absent), and ukl work fine! so, my question is : 1) why would this behaviour occur since the definition and use of kw is identical to the others 2) why kw in particular ? i am sure this indicates a particular type of error (like segmentation fault actual means an array boundary error), but I have no idea what, and why this 538976288 ? that's it. hope you computer whizzes out there can figure this out. I am fresh out of ideas and although I can use ukl instead of kw, I feel uneasy about leaving something like this which may hide some deeper problem that would kick me in the backside later. thanks everyone G.

news wrote: > hello one and all, > right, I've been battling with f77 on a linux machine for 4 days now on what > seems a stupid problem, but I simply do not see what's wrong. > hope someone can help. > here is a short version of a code I am writing (hopefully error free): > > definitions : > parameter (no_of_files=13) > integer kw(no_of_files,high),ukl(no_of_files,high),non_single > integer kdf(no_of_files),kfi(no_of_files,high) > char*5 kni(no_of_files,high),kl(no_of_files,high) > > main prog : > 30 read a file whose index within the prog is file_number > file_number=file_number+1 ! (=<no_of_files) > ! a loop defines non_single > do 10,icount=1,non_single > kdf(file_number)=kdf(file_number)+1 > kni(file_number,kdf(file_number))=kl(file_number,i) > kfi(file_number,kdf(file_number))=1+icount > kw (file_number,kdf(file_number))=2+icount (*) > ukl(file_number,kdf(file_number))=5+icount (**) > 10 continue > > ---------- > > do 20, icount=1,file_number > do 40, jcount=1,kdf(icount) > write (*,60) icount,kni(icount,jcount),kfi(icount,jcount), > ukl(icount,jcount),kw(icount,jcount) > 60 format (---stuff----) > 40 continue > 20 continue > goto 30 > ####### > (the names of the vars are not the actual one : I used initials for > readability) > right, so until the dashed line I assign values (char or number) to arrays. > no problem > the problem is SEEN (I am not saying that's WHERE it is) in the write > statement after the dashed line : > basically what it does it print to the screen all contents of all arrays > from file_number=1 to whatever value it has at any given time. (cxy = > character array at index x,y; nxy = number at index x,y) > > so: file_number=1 gives > 1 c11 n11 n11 n11 > 1 c12 n12 n12 n12 > 1 c13 n13 n13 n13 > etc down to y=kdf(1) > > file_number = 3 gives (skipping 2 to get the idea quicker) > 1 c11 n11 n11 n11 > 1 c12 n12 n12 n12 > 1 c13 n13 n13 n13 > etc down to y=kdf(1) > 2 c21 n21 n21 n21 > 2 c22 n22 n22 n22 > 2 c23 n23 n23 n23 > etc down to y=kdf(2) > 3 c31 n31 n31 n31 > 3 c32 n32 n32 n32 > 3 c33 n33 n33 n33 > etc down to y=kdf(3) > > fine so far ... except that, what's above is what is SHOULD give! > what I actually get is (going straight to file_number=3 to see clearly since > the file_number=1 case is going to be identical to the one above) : > > file_number = 3 > 1 c11 n11 n11 538976288 > 1 c12 n12 n12 538976288 > 1 c13 n13 n13 538976288 > etc down to y=kdf(1) > 2 c21 n21 n21 538976288 > 2 c22 n22 n22 538976288 > 2 c23 n23 n23 538976288 > etc down to y=kdf(2) > 3 c31 n31 n31 n31 > 3 c32 n32 n32 n32 > 3 c33 n33 n33 n33 > etc down to y=kdf(2) > > in other words all arrays work fine except for kw (marked *) above, which > "forgets" its contents for all cases of file_number except the current one! > I initially thought about a memory problem and so explored a number of > avenues, to no avail. eventually I added ukl array as a test, which I did > not have initially (marked (**) above, meaning of course that the fourth > column for each case was absent), and ukl work fine! > so, my question is : > 1) why would this behaviour occur since the definition and use of kw is > identical to the others > 2) why kw in particular ? > > i am sure this indicates a particular type of error (like segmentation fault > actual means an array boundary error), but I have no idea what, and why > this 538976288 ? > > that's it. hope you computer whizzes out there can figure this out. I am > fresh out of ideas and although I can use ukl instead of kw, I feel uneasy > about leaving something like this which may hide some deeper problem that > would kick me in the backside later. > > thanks everyone > G. What's 'high'? Do you initialize everything to zero before use? Does your compiler have an option to enable array bounds checking? 538976288 is hex 20202020, or four ASCII blanks. It looks like at least one of your character arrays is overflowing (probably because of an index out of bounds) into an integer array. Louis

news wrote: > hello one and all, > right, I've been battling with f77 on a linux machine for 4 days now on what > seems a stupid problem, but I simply do not see what's wrong. > hope someone can help. > here is a short version of a code I am writing (hopefully error free): Gee, if it is really error free, what's the problem? ;) Generally, funny numbers in arrays are caused by exceeding the subscript bounds somewhere. Have you tried turning on all of the bounds checking options your compiler supports? If it doesn't support bounds checking, try adding a couple of IF statements into the setup loop and check file_number and kdf(file_number) are in bounds. It looks to me like you increase kdf(file_number) every time through the inner do 10 loop. Is that likely to be the problem? I don't see where it is initially set or reset. The number "538976288" looks awful large. Having you tried printing it out with an A edit descriptor to see if it's one of the character strings you are assigning to kni? If you've got subscript problems, it's possible that the store into kni is actually goiong into kw. Dick Hendrickson > > definitions : > parameter (no_of_files=13) > integer kw(no_of_files,high),ukl(no_of_files,high),non_single > integer kdf(no_of_files),kfi(no_of_files,high) > char*5 kni(no_of_files,high),kl(no_of_files,high) > > main prog : > 30 read a file whose index within the prog is file_number > file_number=file_number+1 ! (=<no_of_files) > ! a loop defines non_single > do 10,icount=1,non_single > kdf(file_number)=kdf(file_number)+1 > kni(file_number,kdf(file_number))=kl(file_number,i) > kfi(file_number,kdf(file_number))=1+icount > kw (file_number,kdf(file_number))=2+icount (*) > ukl(file_number,kdf(file_number))=5+icount (**) > 10 continue > > ---------- > > do 20, icount=1,file_number > do 40, jcount=1,kdf(icount) > write (*,60) icount,kni(icount,jcount),kfi(icount,jcount), > ukl(icount,jcount),kw(icount,jcount) > 60 format (---stuff----) > 40 continue > 20 continue > goto 30 > ####### > (the names of the vars are not the actual one : I used initials for > readability) > right, so until the dashed line I assign values (char or number) to arrays. > no problem > the problem is SEEN (I am not saying that's WHERE it is) in the write > statement after the dashed line : > basically what it does it print to the screen all contents of all arrays > from file_number=1 to whatever value it has at any given time. (cxy = > character array at index x,y; nxy = number at index x,y) > > so: file_number=1 gives > 1 c11 n11 n11 n11 > 1 c12 n12 n12 n12 > 1 c13 n13 n13 n13 > etc down to y=kdf(1) > > file_number = 3 gives (skipping 2 to get the idea quicker) > 1 c11 n11 n11 n11 > 1 c12 n12 n12 n12 > 1 c13 n13 n13 n13 > etc down to y=kdf(1) > 2 c21 n21 n21 n21 > 2 c22 n22 n22 n22 > 2 c23 n23 n23 n23 > etc down to y=kdf(2) > 3 c31 n31 n31 n31 > 3 c32 n32 n32 n32 > 3 c33 n33 n33 n33 > etc down to y=kdf(3) > > fine so far ... except that, what's above is what is SHOULD give! > what I actually get is (going straight to file_number=3 to see clearly since > the file_number=1 case is going to be identical to the one above) : > > file_number = 3 > 1 c11 n11 n11 538976288 > 1 c12 n12 n12 538976288 > 1 c13 n13 n13 538976288 > etc down to y=kdf(1) > 2 c21 n21 n21 538976288 > 2 c22 n22 n22 538976288 > 2 c23 n23 n23 538976288 > etc down to y=kdf(2) > 3 c31 n31 n31 n31 > 3 c32 n32 n32 n32 > 3 c33 n33 n33 n33 > etc down to y=kdf(2) > > in other words all arrays work fine except for kw (marked *) above, which > "forgets" its contents for all cases of file_number except the current one! > I initially thought about a memory problem and so explored a number of > avenues, to no avail. eventually I added ukl array as a test, which I did > not have initially (marked (**) above, meaning of course that the fourth > column for each case was absent), and ukl work fine! > so, my question is : > 1) why would this behaviour occur since the definition and use of kw is > identical to the others > 2) why kw in particular ? > > i am sure this indicates a particular type of error (like segmentation fault > actual means an array boundary error), but I have no idea what, and why > this 538976288 ? > > that's it. hope you computer whizzes out there can figure this out. I am > fresh out of ideas and although I can use ukl instead of kw, I feel uneasy > about leaving something like this which may hide some deeper problem that > would kick me in the backside later. > > thanks everyone > G.

Gee, if it is really error free, what's the problem? ;) meant typo-wise of course:) > > Generally, funny numbers in arrays are caused by exceeding > the subscript bounds somewhere. Have you tried turning on > all of the bounds checking options your compiler supports? nope, since I check on the array bounds 30 read a file whose index within the prog is file_number >> file_number=file_number+1 ! (=<no_of_files) >> ! a loop defines non_single ($$$) >> do 10,icount=1,non_single >> kdf(file_number)=kdf(file_number)+1 >> kni(file_number,kdf(file_number))=kl(file_number,i) >> kfi(file_number,kdf(file_number))=1+icount >> kw (file_number,kdf(file_number))=2+icount (*) >> ukl(file_number,kdf(file_number))=5+icount (**) if I add a write statement here, I get correct answers,not just for the arrays, but for their boundsas well >> 10 continue as soon as I get here though (there is nothing in between both blocks of code), kw develops amnesia. as for kdf it is defined at ($$$) above. >> do 20, icount=1,file_number >> do 40, jcount=1,kdf(icount) >> write (*,60) >> icount,kni(icount,jcount),kfi(icount,jcount), >> ukl(icount,jcount),kw(icount,jcount) >> 60 format (---stuff----) >> 40 continue >> 20 continue > > The number "538976288" looks awful large. Having you tried > printing it out with an A edit descriptor to see if it's > one of the character strings you are assigning to kni? > If you've got subscript problems, it's possible that the > store into kni is actually goiong into kw. did as you suggested, it only prints out blanks. G > > Dick Hendrickson > >> >> definitions : >> parameter (no_of_files=13) >> integer kw(no_of_files,high),ukl(no_of_files,high),non_single >> integer kdf(no_of_files),kfi(no_of_files,high) >> char*5 kni(no_of_files,high),kl(no_of_files,high) >> >> main prog : >> 30 read a file whose index within the prog is file_number >> file_number=file_number+1 ! (=<no_of_files) >> ! a loop defines non_single >> do 10,icount=1,non_single >> kdf(file_number)=kdf(file_number)+1 >> kni(file_number,kdf(file_number))=kl(file_number,i) >> kfi(file_number,kdf(file_number))=1+icount >> kw (file_number,kdf(file_number))=2+icount (*) >> ukl(file_number,kdf(file_number))=5+icount (**) >> 10 continue >> >> ---------- >> >> do 20, icount=1,file_number >> do 40, jcount=1,kdf(icount) >> write (*,60) >> icount,kni(icount,jcount),kfi(icount,jcount), >> ukl(icount,jcount),kw(icount,jcount) >> 60 format (---stuff----) >> 40 continue >> 20 continue >> goto 30 >> ####### >> (the names of the vars are not the actual one : I used initials for >> readability) >> right, so until the dashed line I assign values (char or number) to >> arrays. no problem >> the problem is SEEN (I am not saying that's WHERE it is) in the write >> statement after the dashed line : >> basically what it does it print to the screen all contents of all arrays >> from file_number=1 to whatever value it has at any given time. (cxy = >> character array at index x,y; nxy = number at index x,y) >> >> so: file_number=1 gives >> 1 c11 n11 n11 n11 >> 1 c12 n12 n12 n12 >> 1 c13 n13 n13 n13 >> etc down to y=kdf(1) >> >> file_number = 3 gives (skipping 2 to get the idea quicker) >> 1 c11 n11 n11 n11 >> 1 c12 n12 n12 n12 >> 1 c13 n13 n13 n13 >> etc down to y=kdf(1) >> 2 c21 n21 n21 n21 >> 2 c22 n22 n22 n22 >> 2 c23 n23 n23 n23 >> etc down to y=kdf(2) >> 3 c31 n31 n31 n31 >> 3 c32 n32 n32 n32 >> 3 c33 n33 n33 n33 >> etc down to y=kdf(3) >> >> fine so far ... except that, what's above is what is SHOULD give! >> what I actually get is (going straight to file_number=3 to see clearly >> since the file_number=1 case is going to be identical to the one above) : >> >> file_number = 3 >> 1 c11 n11 n11 538976288 >> 1 c12 n12 n12 538976288 >> 1 c13 n13 n13 538976288 >> etc down to y=kdf(1) >> 2 c21 n21 n21 538976288 >> 2 c22 n22 n22 538976288 >> 2 c23 n23 n23 538976288 >> etc down to y=kdf(2) >> 3 c31 n31 n31 n31 >> 3 c32 n32 n32 n32 >> 3 c33 n33 n33 n33 >> etc down to y=kdf(2) >> >> in other words all arrays work fine except for kw (marked *) above, which >> "forgets" its contents for all cases of file_number except the current >> one! I initially thought about a memory problem and so explored a number >> of avenues, to no avail. eventually I added ukl array as a test, which I >> did not have initially (marked (**) above, meaning of course that the >> fourth column for each case was absent), and ukl work fine! >> so, my question is : >> 1) why would this behaviour occur since the definition and use of kw is >> identical to the others >> 2) why kw in particular ? >> >> i am sure this indicates a particular type of error (like segmentation >> fault actual means an array boundary error), but I have no idea what, and >> why this 538976288 ? >> >> that's it. hope you computer whizzes out there can figure this out. I am >> fresh out of ideas and although I can use ukl instead of kw, I feel >> uneasy about leaving something like this which may hide some deeper >> problem that would kick me in the backside later. >> >> thanks everyone >> G.

news wrote: > Gee, if it is really error free, what's the problem? ;) > > meant typo-wise of course:) > >>Generally, funny numbers in arrays are caused by exceeding >>the subscript bounds somewhere. Have you tried turning on >>all of the bounds checking options your compiler supports? > > > nope, since I check on the array bounds Sure, but here's a case where you don't understand what's going on. If I had a nickel for everyone who said "but the problem can't be in that part of the code" I'd be a rich man. Why not let someone else check the subscripts also? > > 30 read a file whose index within the prog is file_number > >>> file_number=file_number+1 ! (=<no_of_files) >>> ! a loop defines non_single ($$$) >>> do 10,icount=1,non_single >>> kdf(file_number)=kdf(file_number)+1 >>> kni(file_number,kdf(file_number))=kl(file_number,i) >>> kfi(file_number,kdf(file_number))=1+icount >>> kw (file_number,kdf(file_number))=2+icount (*) >>> ukl(file_number,kdf(file_number))=5+icount (**) > > > if I add a write statement here, I get correct answers,not just for the > arrays, but for their boundsas well Adding WRITE statement to fix a problem is usually a symptom of one two problems. 1) subscripts out of bounds, but the changed code moves things around in memory and the outof bounds stores don't hit anything interesting. 2) An actual compiler error. The compiler might be totally wrong in where it stores things, but for the WRITE statement uses the correct register to pass the values onto the low level I/O routines. This is rare. f77 has been around for several years now, and it's more likely to be a user problem than a compiler error. > > >>>10 continue > > > > as soon as I get here though (there is nothing in between both blocks of > code), kw develops amnesia. > as for kdf it is defined at ($$$) above. > > >>> do 20, icount=1,file_number >>> do 40, jcount=1,kdf(icount) >>> write (*,60) >>> icount,kni(icount,jcount),kfi(icount,jcount), >>> ukl(icount,jcount),kw(icount,jcount) >>>60 format (---stuff----) >>>40 continue >>>20 continue > > > > >>The number "538976288" looks awful large. Having you tried >>printing it out with an A edit descriptor to see if it's >>one of the character strings you are assigning to kni? >>If you've got subscript problems, it's possible that the >>store into kni is actually goiong into kw. > > > did as you suggested, it only prints out blanks. Do you initialize anything to all blanks? If so, try setting that to "abcd" and see if that changes the output. Dick Hendrickson > > > > > G > > > > > >>Dick Hendrickson >> >> >>>definitions : >>>parameter (no_of_files=13) >>>integer kw(no_of_files,high),ukl(no_of_files,high),non_single >>>integer kdf(no_of_files),kfi(no_of_files,high) >>>char*5 kni(no_of_files,high),kl(no_of_files,high) >>> >>>main prog : >>>30 read a file whose index within the prog is file_number >>> file_number=file_number+1 ! (=<no_of_files) >>> ! a loop defines non_single >>> do 10,icount=1,non_single >>> kdf(file_number)=kdf(file_number)+1 >>> kni(file_number,kdf(file_number))=kl(file_number,i) >>> kfi(file_number,kdf(file_number))=1+icount >>> kw (file_number,kdf(file_number))=2+icount (*) >>> ukl(file_number,kdf(file_number))=5+icount (**) >>>10 continue >>> >>>---------- >>> >>> do 20, icount=1,file_number >>> do 40, jcount=1,kdf(icount) >>> write (*,60) >>> icount,kni(icount,jcount),kfi(icount,jcount), >>> ukl(icount,jcount),kw(icount,jcount) >>>60 format (---stuff----) >>>40 continue >>>20 continue >>> goto 30 >>>####### >>>(the names of the vars are not the actual one : I used initials for >>>readability) >>>right, so until the dashed line I assign values (char or number) to >>>arrays. no problem >>>the problem is SEEN (I am not saying that's WHERE it is) in the write >>>statement after the dashed line : >>>basically what it does it print to the screen all contents of all arrays >>>from file_number=1 to whatever value it has at any given time. (cxy = >>>character array at index x,y; nxy = number at index x,y) >>> >>>so: file_number=1 gives >>>1 c11 n11 n11 n11 >>>1 c12 n12 n12 n12 >>>1 c13 n13 n13 n13 >>> etc down to y=kdf(1) >>> >>>file_number = 3 gives (skipping 2 to get the idea quicker) >>>1 c11 n11 n11 n11 >>>1 c12 n12 n12 n12 >>>1 c13 n13 n13 n13 >>> etc down to y=kdf(1) >>>2 c21 n21 n21 n21 >>>2 c22 n22 n22 n22 >>>2 c23 n23 n23 n23 >>> etc down to y=kdf(2) >>>3 c31 n31 n31 n31 >>>3 c32 n32 n32 n32 >>>3 c33 n33 n33 n33 >>> etc down to y=kdf(3) >>> >>>fine so far ... except that, what's above is what is SHOULD give! >>>what I actually get is (going straight to file_number=3 to see clearly >>>since the file_number=1 case is going to be identical to the one above) : >>> >>>file_number = 3 >>>1 c11 n11 n11 538976288 >>>1 c12 n12 n12 538976288 >>>1 c13 n13 n13 538976288 >>> etc down to y=kdf(1) >>>2 c21 n21 n21 538976288 >>>2 c22 n22 n22 538976288 >>>2 c23 n23 n23 538976288 >>> etc down to y=kdf(2) >>>3 c31 n31 n31 n31 >>>3 c32 n32 n32 n32 >>>3 c33 n33 n33 n33 >>> etc down to y=kdf(2) >>> >>>in other words all arrays work fine except for kw (marked *) above, which >>>"forgets" its contents for all cases of file_number except the current >>>one! I initially thought about a memory problem and so explored a number >>>of avenues, to no avail. eventually I added ukl array as a test, which I >>>did not have initially (marked (**) above, meaning of course that the >>>fourth column for each case was absent), and ukl work fine! >>>so, my question is : >>>1) why would this behaviour occur since the definition and use of kw is >>>identical to the others >>>2) why kw in particular ? >>> >>>i am sure this indicates a particular type of error (like segmentation >>>fault actual means an array boundary error), but I have no idea what, and >>>why this 538976288 ? >>> >>>that's it. hope you computer whizzes out there can figure this out. I am >>>fresh out of ideas and although I can use ukl instead of kw, I feel >>>uneasy about leaving something like this which may hide some deeper >>>problem that would kick me in the backside later. >>> >>>thanks everyone >>>G. > >

Dick Hendrickson wrote: >> >> if I add a write statement here, I get correct answers,not >> just for the >> arrays, but for their boundsas well > > > Adding WRITE statement to fix a problem is usually a > symptom of one two problems. > > 1) subscripts out of bounds, but the changed code moves > things around in memory and the outof bounds stores don't > hit anything interesting. > > 2) An actual compiler error. The compiler might be totally > wrong in where it stores things, but for the WRITE statement > uses the correct register to pass the values onto the low > level I/O routines. This is rare. f77 has been around for > several years now, and it's more likely to be a user > problem than a compiler error. And, based on my personal experience only, 99% of the time it's #1. Particularly when character strings are involved. I do so hate it when inserting a WRITE() statement fixes (or breaks) something. <shudder> Time for the OP to run the code in a debugger methinks (if he hasn't already done so.) cheers, paulv

Paul Van Delst wrote: > Dick Hendrickson wrote: > >>> >>> if I add a write statement here, I get correct answers,not >>> just for the >>> arrays, but for their boundsas well >> >> >> >> Adding WRITE statement to fix a problem is usually a >> symptom of one two problems. >> >> 1) subscripts out of bounds, but the changed code moves >> things around in memory and the outof bounds stores don't >> hit anything interesting. >> >> 2) An actual compiler error. The compiler might be totally >> wrong in where it stores things, but for the WRITE statement >> uses the correct register to pass the values onto the low >> level I/O routines. This is rare. f77 has been around for >> several years now, and it's more likely to be a user >> problem than a compiler error. > > > And, based on my personal experience only, 99% of the time it's #1. > Particularly when character strings are involved. I do so hate it when > inserting a WRITE() statement fixes (or breaks) something. <shudder> > > Time for the OP to run the code in a debugger methinks (if he hasn't > already done so.) IRC the OP was using G77 so could try the Salford FTN77pe (personal edition) with both /check and /undef for their bargain price of FREE. > cheers, > > paulv >

news wrote: > file_number=file_number+1 ! (=<no_of_files) > ! a loop defines non_single > do 10,icount=1,non_single > kdf(file_number)=kdf(file_number)+1 > kni(file_number,kdf(file_number))=kl(file_number,i) > kfi(file_number,kdf(file_number))=1+icount > kw (file_number,kdf(file_number))=2+icount (*) > ukl(file_number,kdf(file_number))=5+icount (**) > 10 continue Reading backwards through the precedents for "kw()= kw (file_number,kdf(file_number))=... depends on kdf(file_number)=kdf(file_number)+1 depends on file_number=file_number+1 kdf(file_number)=... But where is kdf(file_number) initialized? Without knowing what it all means, I can still say for sure that kdf(file_number) must have some defined value /before/ you attempt kdf(file_number)=kdf(file_number)+1 kw (file_number,kdf(file_number))=... Just guessing ... but did you perhaps intend to do something like: kdf(file_number)=kdf(file_number-1)+1 That would still leave you with a special-case problem of initializing the first kdf (cannot say kdf(1) = kdf(0)+1). Maybe the problem would be simplified by using a scalar (similar to file_number) to initialize and maintain the value to be assigned to the next kdf(file_number). kdf_filenum = ... ! initial value .... file_number=file_number+1 ! (=<no_of_files) ! a loop defines non_single do 10,icount=1,non_single *** kdf(file_number)=kdf_filenum kni(file_number,kdf(file_number))=kl(file_number,i) kfi(file_number,kdf(file_number))=1+icount kw (file_number,kdf(file_number))=2+icount ukl(file_number,kdf(file_number))=5+icount *** kdf_filenum=... 10 continue -- Ted Hall