Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

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:

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 Un*x systems but that did not apply
to the data portions of a job to be run.

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 Un*x 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:

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.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc