ags@s.cc.purdue.edu (Dave Seaman) (02/29/88)
In article <707@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <2355@s.cc.purdue.edu>, ags@s.cc.purdue.edu (Dave Seaman) writes: >: The comparison is perfectly valid. CMS users cannot normally open >: files by name unless they remember to issue a FILEDEF before running >: the program. > >I loathe and detest CMS, but this simply isn't true. Look, this isn't an argument! An argument isn't simply gainsaying everything your adversary says! (Apologies to Monty Python) In case you want to make this a real argument by explaining WHY my statement "simply isn't true," allow me to point out that my statement was not "CMS users cannot EVER open files by name...". I said that "CMS users cannot NORMALLY open files by name...", and then I went on to explain that there is an exception, but you left out that part when you posted your followup. I might also point out that I was discussing FORTRAN, not other languages under CMS. It shouldn't be necessary to say that, since this is comp.lang.fortran, but if I don't say it, you'll probably point out that other languages can open files by name under CMS, even though there is no provision for this in FORTRAN. -- Dave Seaman ags@j.cc.purdue.edu
ok@quintus.UUCP (Richard A. O'Keefe) (03/01/88)
In response to article <2359@s.cc.purdue.edu>, by ags@s.cc.purdue.edu (Dave Seaman): The original context was INCLUDE statements in Fortran, and the claim was that INCLUDE statements should not be part of the Fortran standard because there are ***OPERATING SYSTEMS*** which do not support dynamically named files well. The fact that some languages, such as C, have no such difficulty under CMS *is* relevant to Fortran in this context, because it means that whatever difficulty Fortran may or may not experience is an artefact of the Fortran compiler and run-time system, not an intrinsic property of the operating system. Were a Fortran compiler to be written in C, for example, it would have no difficulty whatsoever with INCLUDE statements, regardless of whether Fortran programs were able to open dynamically named files (which feature *is* a part of Fortran 77). Note that Dave Seaman did not say "Fortran programs cannot easily open files by name under CMS", he said > CMS users cannot normally open files by name unless they remember ********* > to issue a FILEDEF before running the program. In CMS, there are two sorts of "file names": DSnames and DDnames. DSnames are what's out there in the file system. DDnames are basically pointers, a wee bit like symbolic links or environment variables, but with extra string. If you think of them as an MVS compatibility feature, you won't be far wrong. Now the giveaway is that the Fortran compiler is the VS Fortran Version 2 ** compiler, that is, it is basically an MVS product. To repeat, I loathe and detest CMS, but the difficulties of using Fortran under CMS have nothing to do with CMS as such, nor, for that matter, with Fortran as such. If a UNIX Fortran compiler were to insist that all file names be supplied through environment variables, would we blame UNIX, or Fortran, or would we blame the compiler vendor? Would we use such a restriction as an argument for what Fortran should be allowed to do?
ags@s.cc.purdue.edu (Dave Seaman) (03/01/88)
In article <713@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >The original context was INCLUDE statements in Fortran, >and the claim was that INCLUDE statements should not be part of >the Fortran standard because there are ***OPERATING SYSTEMS*** >which do not support dynamically named files well. You are confusing the original context of the discussion with the original context of my first posting in the discussion. I repeat that context here, exactly as I first quoted it in my posting that you responded to: 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. There is no mention of INCLUDE statements here. Therefore you simply misunderstood the context of my remarks. My original posting made two points: 1. It IS possible to access files "dynamically" in FTN200 under VSOS, but only by resorting to nonstandard system calls. 2. It would be preferable to provide for dynamic file access within standard FORTRAN, but FTN200 is not the only environment that has this problem. It is shared, for example, by FORTVS2 under CMS. -- Dave Seaman ags@j.cc.purdue.edu
jlg@a.UUCP (Jim Giles) (03/02/88)
Sounds to me like your I/O library support is the weak link. There is no
reason why the I/O library can't make any special system calls necessary
to make a file available dynamically. Consider the following:
OPEN(5,file='testfile',status='old')
The semantics of this COULD be: A) see if the file exists locally, if so -
open it; B) if the file doesn't exist locally, do the special system call
(whatever it is) to attach the any file by that name which may be in the
non-local name space - then open it; C) if the file still wasn't found,
the OPEN statement fails because STATUS='OLD' couldn't be satisfied.
This interpretation does not contradict the present standard.
I don't use any IBM operating systems, but I assume that there is some
way to dynamically attach files to the local job stream. This upgrade
of the OPEN statement would certainly work on CDC systems.
Finally, there is no reason that this same mechanism couldn't be used for
INCLUDE files or MODULES. The only reason to blame the operating
system is if the non-local files cannot be attached by any method (even
assembly code) - but I would call this an unacceptable system anyway.
J. Giles
Los Alamosok@quintus.UUCP (Richard A. O'Keefe) (03/02/88)
In article <2380@s.cc.purdue.edu>, ags@s.cc.purdue.edu (Dave Seaman) writes: > You are confusing the original context of the discussion with the original Nope, just sticking to the topic. > 1. It IS possible to access files "dynamically" in FTN200 under > VSOS, but only by resorting to nonstandard system calls. It's not clear what you mean by "nonstandard". Since system calls are outside the scope of the Fortran standard, I took this to mean that there was thought to be some extra-hairy about the system calls qua system calls, such as being undocumented. If that was not the intention "system calls" would have sufficed. The system calls you need under CMS are perfectly ordinary CMS system calls. > 2. It would be preferable to provide for dynamic file access > within standard FORTRAN, but FTN200 is not the only environment > that has this problem. It is shared, for example, by FORTVS2 > under CMS. It is surely of interest that the problem is not CMS, but the fact that FORTVS2 is basically an MVS program, and its run-time library is basically an MVS run-time library, which CMS more-or-less emulates. I repeat that someone could provide a Fortran compiler for UNIX which didn't support UNIX file names, but we'd hardly take *that* to be evidence that dynamic file access should not be part of standard Fortran, and an MVS Fortran compiler running under CMS doesn't provide any better evidence. If you want to argue that FORTVS2 + MVS is evidence for this position, that's another argument! The Fortran standard *does* provide for dynamic file access, the only trouble is that the implementation gets to define what this means. dpANS C has all the usual C stuff for opening files, and #include directives, and all. In an MVS C compiler, these names would be ddnames (or #include names would be members of libraries). Again, it looks like dynamic file access, but the implementation gets to define what that means.