Fortran Programming Language :: repeated namelist behavior


	repeated namelist behavior Hi, Given a file containing multiple namelists with the same name, does the standard specify how that repetition should be handled? g95 exits the input file after the first occurrence of the namelist is read. Is this a behavior we can rely on? Thanks, -- Bil Kleb http://funit.rubyforge.org On Apr 27, 11:05 am, Bil Kleb <Bil.K@NASA.gov> wrote: > Given a file containing multiple namelists with > the same name, does the standard specify how that > repetition should be handled? > g95 exits the input file after the first occurrence > of the namelist is read. Is this a behavior we can > rely on? The standard says "A slash to terminate the namelist input" and "A slash encountered in a namelist input record causes the input statement to terminate.". So once the end of the namelist is seen, no further records are read. Note that if you do another NAMELIST read from the same file, it will look for the named group later in the file from the current position. There are no do-overs for namelist. What were you expecting - that it would somehow read the whole file and merge all the namelists? Steve Steve Lionel wrote: > What were you expecting - that it would somehow read the whole file > and merge all the namelists? Didn't really know what to expect, and wondered if the standard actually nailed this down so we could count on the behavior we observed with g95. Thanks for the info, -- Bil Kleb http://funit.rubyforge.org Bil Kleb <Bil.K@NASA.gov> wrote: > Steve Lionel wrote: > > What were you expecting - that it would somehow read the whole file > > and merge all the namelists? > Didn't really know what to expect, and wondered > if the standard actually nailed this down so we > could count on the behavior we observed with g95. Seems to me that the standard ties it down in pretty much the same way as most of the other I/O stuff. I suspect that you might be being mislead by thinking about some f77 (aka non-standard, as namelist wasn't standardized until f90) implementations of namelist, where the system would search for the namelist. The standard doesn't describe any such searching behavior. In particular, the standard doesn't say that namelist input can start with any amount of random stuff that doesn't look like the start of a namelist. -- Richard Maine \| Good judgement comes from experience; email: last name at domain . net \| experience comes from bad judgement. domain: summertriangle \| -- Mark Twain Richard Maine wrote: > Bil Kleb <Bil.K@NASA.gov> wrote: (snip) >>Didn't really know what to expect, and wondered >>if the standard actually nailed this down so we >>could count on the behavior we observed with g95. > Seems to me that the standard ties it down in pretty much the same way > as most of the other I/O stuff. I suspect that you might be being > mislead by thinking about some f77 (aka non-standard, as namelist wasn't > standardized until f90) implementations of namelist, where the system > would search for the namelist. The OS/360 NAMELIST (that is before f77) would read through anything until it found a line with &(namelist name), including reading through other NAMELISTs. If there were more than one with the same name, it should read them with successive READ statements. Ignoring other data can be convenient if you aren't sure where the previous I/O left off. Also, it would ignore column 1. It makes a little sense that NAMELIST output should put a blank on column one for carriage control purposes (at least in F66 days), but it isn't so obvious that means it should ignore column one on input, but that is what it did. Also, unlike the current standard, &END terminates input. > The standard doesn't describe any such > searching behavior. In particular, the standard doesn't say that > namelist input can start with any amount of random stuff that doesn't > look like the start of a namelist. It seems to allow blanks before the &(namelist name), and record terminators count, so it should accept blank lines, and also NAMELIST comments, which start with ! and go to the end of the line. -- glen On 2007-04-28 02:42:46 -0300, glen herrmannsfeldt <g@ugcs.caltech.edu> said: - Hide quoted text - > Richard Maine wrote: >> Bil Kleb <Bil.K@NASA.gov> wrote: > (snip) >>> Didn't really know what to expect, and wondered >>> if the standard actually nailed this down so we >>> could count on the behavior we observed with g95. >> Seems to me that the standard ties it down in pretty much the same way >> as most of the other I/O stuff. I suspect that you might be being >> mislead by thinking about some f77 (aka non-standard, as namelist wasn't >> standardized until f90) implementations of namelist, where the system >> would search for the namelist. > The OS/360 NAMELIST (that is before f77) would read through > anything until it found a line with &(namelist name), including > reading through other NAMELISTs. If there were more than one with > the same name, it should read them with successive READ statements. > Ignoring other data can be convenient if you aren't sure where > the previous I/O left off. > Also, it would ignore column 1. It makes a little sense that NAMELIST > output should put a blank on column one for carriage control purposes > (at least in F66 days), but it isn't so obvious that means it should > ignore column one on input, but that is what it did. > Also, unlike the current standard, &END terminates input. In really olden times of card decks the system commands had a dollar sign (currency symbol?) in column one. The namelist symbol was also a dollar sign (pre EBCDIC!) so column one was out of bounds. Hence column two. This started with FORTRAN IV as FORTRAN II did not have NAMELIST. In truly prehistoric times of F II the system symbol was a star. The looking for an exact match on the name allowed for the rest of things to be treated as comments. Spelling mistakes could cause a lot of confusion if there were repeated sets of inputs. There was an escape mechanism to allow for copying whole card decks much like what one sees in current Unx systems but that did not apply to the data portions of a job to be run. - Hide quoted text - >> The standard doesn't describe any such >> searching behavior. In particular, the standard doesn't say that >> namelist input can start with any amount of random stuff that doesn't >> look like the start of a namelist. > It seems to allow blanks before the &(namelist name), and record > terminators count, so it should accept blank lines, and also > NAMELIST comments, which start with ! and go to the end of the line. > -- glen Gordon Sande wrote: (snip, I wrote) >> Also, it would ignore column 1. It makes a little sense that NAMELIST >> output should put a blank on column one for carriage control purposes >> (at least in F66 days), but it isn't so obvious that means it should >> ignore column one on input, but that is what it did. >> Also, unlike the current standard, &END terminates input. > In really olden times of card decks the system commands had a dollar > sign (currency symbol?) in column one. The namelist symbol was also > a dollar sign (pre EBCDIC!) so column one was out of bounds. Hence > column two. This started with FORTRAN IV as FORTRAN II did not have > NAMELIST. In truly prehistoric times of F II the system symbol was > a star. The looking for an exact match on the name allowed for the > rest of things to be treated as comments. Spelling mistakes could > cause a lot of confusion if there were repeated sets of inputs. I first used NAMELIST with OS/360. I have heard some stories about 7090 Fortran, and some of the manuals might be available now. I believe there are people trying to run IBSYS and Fortran on emulated 7090s. I don't remember now if it is Fortran II or Fortran IV. I learned keypunching while my father was working on a program on the 7090, but I never ran anything on the 7090. > There was an escape mechanism to allow for copying whole card decks > much like what one sees in current Unx systems but that did not apply > to the data portions of a job to be run. So OS/360 uses /* to end input data, and PL/I uses /* for comments, so you can't start a comment in column 1. The escape mechanism for that didn't come until some years later. I did once know of a program that would duplicate whole card decks, JCL and all, reading the cards backwards such that the original column 1 is in column 80, and ignored by the OS. Yes, JCL still ignores column 73-80. -- glen On 2007-04-28 17:09:05 -0300, glen herrmannsfeldt <g@ugcs.caltech.edu> said: - Hide quoted text - > Gordon Sande wrote: > (snip, I wrote) >>> Also, it would ignore column 1. It makes a little sense that NAMELIST >>> output should put a blank on column one for carriage control purposes >>> (at least in F66 days), but it isn't so obvious that means it should >>> ignore column one on input, but that is what it did. >>> Also, unlike the current standard, &END terminates input. >> In really olden times of card decks the system commands had a dollar >> sign (currency symbol?) in column one. The namelist symbol was also >> a dollar sign (pre EBCDIC!) so column one was out of bounds. Hence >> column two. This started with FORTRAN IV as FORTRAN II did not have >> NAMELIST. In truly prehistoric times of F II the system symbol was >> a star. The looking for an exact match on the name allowed for the >> rest of things to be treated as comments. Spelling mistakes could >> cause a lot of confusion if there were repeated sets of inputs. > I first used NAMELIST with OS/360. I have heard some stories > about 7090 Fortran, and some of the manuals might be available now. > I believe there are people trying to run IBSYS and Fortran on > emulated 7090s. I don't remember now if it is Fortran II or > Fortran IV. Fortran II was before IBSYS. I do not know if there was a common name for the operating system. The assembeler was FAP for Fortran Assembley Program. Control cards had stars in column one. Blank common reused the area that had the major system i/o package so it started full of junk. There was no data statement or named common in Fortran II so there was no way to set initial values in any case. The curious semantics of blank common canbe blamed on Fortran II and the minimal control programs of its era. Fortran IV arrived with IBSYS. The assembler was MAP for Macro Assembley Program. Control cards had dollars signs in column one. - Hide quoted text - > I learned keypunching while my father was working on a program > on the 7090, but I never ran anything on the 7090. >> There was an escape mechanism to allow for copying whole card decks >> much like what one sees in current Unx systems but that did not apply >> to the data portions of a job to be run. > So OS/360 uses / to end input data, and PL/I uses /* for comments, > so you can't start a comment in column 1. The escape mechanism for > that didn't come until some years later. I did once know of a > program that would duplicate whole card decks, JCL and all, > reading the cards backwards such that the original column 1 is > in column 80, and ignored by the OS. Yes, JCL still ignores > column 73-80. > -- glen