Prev: execution times for Open64 Fortran 95 compiler
Next: data types inside interface
From: nmm1 on 30 Jul 2010 06:37
In article <197c4f59-aa19-4ec4-a8dd-e50386359a59(a)i4g2000prf.googlegroups.com>,
<robert.corbett(a)oracle.com> wrote:
>
>You are correct that there are operating systems where it is
>difficult,
>if not impossible, to tell if a file is open. The problem for a
>Fortran
>run-time input/output system is a little different. For the INQUIRE
>statement, the question is not if the file is open, but if the file is
>connected to a Fortran external unit. The implementation of INQUIRE
>by
>file in the Fortran run-time systems I have supported for the past 30
>years is to scan the unit table looking for a unit connected to the
>file.
>The Fortran run-time systems for UNIX and UNIX-like operating systems
>have assumed that the devno and inode numbers taken together uniquely
>identify a file. On other operating systems, the file name has been
>assumed to uniquely identify the file.

I could probably remember most of the MVS rules, but they would make
no sense to anyone not familiar with that system (now zOS). The
overlap of concepts between it and Unix is very small, especially
in this area. And the concept that files can be uniquely identified
by a file name is one that Unix has, but not MVS.

Indeed, the very concept of 'open' doesn't necessarily make sense
under either MVS or Unix once you get away from simple files!


Regards,
Nick Maclaren.
From: glen herrmannsfeldt on 30 Jul 2010 08:40
nmm1(a)cam.ac.uk wrote:
> In article <197c4f59-aa19-4ec4-a8dd-e50386359a59(a)i4g2000prf.googlegroups.com>,
> <robert.corbett(a)oracle.com> wrote:

>>You are correct that there are operating systems where it is
>>difficult, if not impossible, to tell if a file is open.
(snip)

> I could probably remember most of the MVS rules, but they would make
> no sense to anyone not familiar with that system (now zOS). The
> overlap of concepts between it and Unix is very small, especially
> in this area. And the concept that files can be uniquely identified
> by a file name is one that Unix has, but not MVS.

Well, traditionally programs didn't know about file names
at all, but only DD names. Depending on how you look at it,
DDnames aren't all that different from unix file descriptors.
You can even make analogies between SYSIN, SYSPRINT and SYSTERM
DDnames and unix' stdin, stdout, and stderr, respectively.

> Indeed, the very concept of 'open' doesn't necessarily make sense
> under either MVS or Unix once you get away from simple files!

Well, there is an OPEN macro, and corresponding SVC, buy
past that, yes, it doesn't work the same. But deeper than that,
the idea of using DDnames such that programs can be written
independent of the actual device that will be used for the
I/O is somewhat similar, and yet different than unix.

-- glen
From: nmm1 on 30 Jul 2010 08:49
In article <i2uh7p$sus$1(a)speranza.aioe.org>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>nmm1(a)cam.ac.uk wrote:
>> In article <197c4f59-aa19-4ec4-a8dd-e50386359a59(a)i4g2000prf.googlegroups.com>,
>> <robert.corbett(a)oracle.com> wrote:
>
>>>You are correct that there are operating systems where it is
>>>difficult, if not impossible, to tell if a file is open.
>(snip)
>
>> I could probably remember most of the MVS rules, but they would make
>> no sense to anyone not familiar with that system (now zOS). The
>> overlap of concepts between it and Unix is very small, especially
>> in this area. And the concept that files can be uniquely identified
>> by a file name is one that Unix has, but not MVS.
>
>Well, traditionally programs didn't know about file names
>at all, but only DD names. Depending on how you look at it,
>DDnames aren't all that different from unix file descriptors.
>You can even make analogies between SYSIN, SYSPRINT and SYSTERM
>DDnames and unix' stdin, stdout, and stderr, respectively.

Actually, no. The metadata of files could be inspected directly,
and the dynamic allocation of files has existed since MVT's TSO.
Quite a few language run-time systems used that. Attaching a
DDNAME is (usually) an 'inactive' process, whereas creating a
Unix descriptor is a very 'active' one (and is done by opening
the file).

>> Indeed, the very concept of 'open' doesn't necessarily make sense
>> under either MVS or Unix once you get away from simple files!
>
>Well, there is an OPEN macro, and corresponding SVC, buy
>past that, yes, it doesn't work the same. But deeper than that,
>the idea of using DDnames such that programs can be written
>independent of the actual device that will be used for the
>I/O is somewhat similar, and yet different than unix.

That's not what I was thinking of. Once you have (MVS) devices,
UNIX sockets etc., the opening process becomes multi-step, and
each step is 'active' (i.e. affects the 'file' and does not just
change its attachment).


Regards,
Nick Maclaren.
From: Steven Correll on 30 Jul 2010 18:21
<robert.corb...(a)oracle.com> wrote:
> >The Fortran run-time systems for UNIX and UNIX-like operating systems
> >have assumed that the devno and inode numbers taken together uniquely
> >identify a file.  On other operating systems, the file name has been
> >assumed to uniquely identify the file.

On Jul 30, 3:37 am, n...(a)cam.ac.uk wrote:
> In article <197c4f59-aa19-4ec4-a8dd-e50386359...(a)i4g2000prf.googlegroups.com>,
> And the concept that files can be uniquely identified
> by a file name is one that Unix has, but not MVS.

I believe Robert Corbett's point was that files cannot be uniquely
identified by name on Unix, at least not for purposes of implementing
INQUIRE. Because many links with different names may point to the same
file, the runtime system must map the name to a devno/inode pair, and
ask itself whether any logical unit is connected with that pair.
From: glen herrmannsfeldt on 30 Jul 2010 18:55
Steven Correll <steven.correll(a)gmail.com> wrote:

> <robert.corb...(a)oracle.com> wrote:
>> >The Fortran run-time systems for UNIX and UNIX-like operating systems
>> >have assumed that the devno and inode numbers taken together uniquely
>> >identify a file. �On other operating systems, the file name has been
>> >assumed to uniquely identify the file.

> On Jul 30, 3:37 am, n...(a)cam.ac.uk wrote:
>> In article <197c4f59-aa19-4ec4-a8dd-e50386359...(a)i4g2000prf.googlegroups.com>,
>> And the concept that files can be uniquely identified
>> by a file name is one that Unix has, but not MVS.

> I believe Robert Corbett's point was that files cannot be uniquely
> identified by name on Unix, at least not for purposes of implementing
> INQUIRE. Because many links with different names may point to the same
> file, the runtime system must map the name to a devno/inode pair, and
> ask itself whether any logical unit is connected with that pair.

On unix, different names may point to the same file. There
are times that is important, such as not opening a file that is
already opened, but otherwise you get what you ask for.

For MVS, the same name can represent different files, on different
disk volumes. That is true for many other systems, though.

-- glen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: execution times for Open64 Fortran 95 compiler
Next: data types inside interface