Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags
From: ags@s.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: F8X response (long)
Message-ID: <2337@s.cc.purdue.edu>
Date: 25 Feb 88 19:27:14 GMT
References: <705@elxsi.UUCP> <44400017@hcx2>
Reply-To: ags@s.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 28

In article <44400017@hcx2> bill@hcx2.SSD.HARRIS.COM writes:
>Anyway, if what you say is really true, then how could a FORTRAN program
>OPEN a file?  It must be able to do this if it conforms to FORTRAN 77,
>and according to my Cyber FTN200 manual, it can.  I further believe that,
>if there is any operating system in use today that cannot "dynamically"
>open and access files by name, they will either quickly acquire the
>capability or they will not long survive.  Technology marches on.

FTN200 can open a file by name if the file is local to the job.  If the
file is a permanent file or pool file that is not attached to the job, then
it is still possible to access the file, but you must issue a system call
to make the file local before you can open it.  It is possible to issue the
system call from within the executing program, but of course this is not
standard FORTRAN.

Does this sound rather backward to you?  It does to me, too.  But before
you dismiss the VSOS operating system completely, consider IBM's VM/CMS
and their current FORTVS2 compiler.  In that environment you cannot open
files by name at all, in any way that I know of.  You can open files only
by "ddname", which means that you must remember to issue a "filedef" to
tell the system what ddname to assign to the file before you execute the
program.  It is not possible to issue filedefs from within an executing
program in any way that I know of, and even if there is a way, this only
means that VM is no worse than VSOS when it comes to opening files.

Dave Seaman
-- 
Dave Seaman	  					
ags@j.cc.purdue.edu