Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!hao!husc6!mailrus!umix!metavax!chris
From: chris@metavax.UUCP ( PSA)
Newsgroups: comp.lang.fortran
Subject: Re: F8X response (long)
Message-ID: <2989@metavax.UUCP>
Date: 26 Feb 88 13:35:21 GMT
References: <705@elxsi.UUCP> <44400017@hcx2> <2337@s.cc.purdue.edu>
Reply-To: chris@metavax.UUCP (Chris Collins)
Organization: Meta Systems, Ltd. -- Ann Arbor, MI
Lines: 22

In article <2337@s.cc.purdue.edu> ags@s.cc.purdue.edu.UUCP (Dave Seaman) writes:
 
>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.

We have a way to issue FILEDEF's from within a program on VM/CMS.  However,
it uses an Assembler routine to send the command to the operating system.

I don't think this is really that bad.  If I'm running a program which 
uses data from a file, and I don't want it to prompt me for the file name, 
then I must tell the operating system or the program or both that 
the file to use is "thisfile".  Sometimes it's better to have the capability
to be able to tell both the OS and the program, and sometimes not.
Particularly if this allows a level of indirection on the file name.

Chris Collins