bill@hcx2.SSD.HARRIS.COM (02/22/88)
/* Written 11:04 am Feb 19, 1988 by ags@j.cc.purdue.edu.UUCP */ > [note: I am posting this for a friend who maintains a very large body of > FORTRAN code -- DAS] > > Include type statements are NOT found on all compilers. The Cyber 205 > FTN200 compiler (a Fortran 77 compiler with some very, very nice > vector extensions) doesn't have such a command. The reason becomes > fairly obvious when when you look at the operating system. > > The computer is intended to be used for large scale number crunching, > and is in fact provides a terrific environment for this. However, several > peculiarities of the operating system make it an abysmal interactive > environment. (You can only have about 200 files in your area, and the > terminal interface renders implementation of a screen-oriented editor > impossible.) Furthermore, files used by programs are must be preattached > by job control language; files are not automatically available to > the program. This means that on this machine, if an "include" facility > was made part of the compiler, you would have to pre-attach them and/or > transfer each of them from the front-end as part the the compilation jcl. > This would makes the jcl pretty horrid. Hmmm. Sounds like the Cyber 205 is going to have trouble with MODULEs too. Since MODULEs can be compiled once, then USEd many times, the compiler necessarily must maintain the results of the MODULE compilation somewhere, presumably in a file. So, I think your criticism of INCLUDE vs. MODULE is somewhat spurious. Whether it is "source" or "object" or something in between that is being reused, the compiler will have to have dynamic access to named data -- which we usually think of as a file. The _only_ difference between MODULE and INCLUDE, in this respect, is that with INCLUDE, the programmer has to name the file, while with MODULE the compiler gets to choose a name. 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.
tsh@j.cc.purdue.edu (Greg Kamer) (02/25/88)
> > Include type statements are NOT found on all compilers. The Cyber 205 > > FTN200 compiler (a Fortran 77 compiler with some very, very nice > > vector extensions) doesn't have such a command. The reason becomes > > fairly obvious when when you look at the operating system. > > > > Furthermore, files used by programs are must be preattached > > by job control language; files are not automatically available to > > the program. This means that on this machine, if an "include" facility > > was made part of the compiler, you would have to pre-attach them and/or > > transfer each of them from the front-end as part the the compilation jcl. > > This would makes the jcl pretty horrid. > Hmmm. Sounds like the Cyber 205 is going to have trouble with MODULEs too. > Since MODULEs can be compiled once, then USEd many times, the compiler > necessarily must maintain the results of the MODULE compilation somewhere, > presumably in a file. So, I think your criticism of INCLUDE vs. MODULE > is somewhat spurious. Whether it is "source" or "object" or something > in between that is being reused, the compiler will have to have dynamic > access to named data -- which we usually think of as a file. The _only_ > difference between MODULE and INCLUDE, in this respect, is that with > INCLUDE, the programmer has to name the file, while with MODULE the compiler > gets to choose a name. I think we are getting fairly deep into the differences of the way operating systems deal with batch job files. On Unix and VMS, there is only 1 type of file, and in order to create temporary files that don't count against your disk quota, you must generate a UNIQUE file name in somewhere like /usr/tmp and delete it when you are through with it. On many batch-oriented number crunchers the operating systems work another way; files created as part of the batch stream simply cease to exist at the end of the batch job unless you explicitly save them. In addition, the files in your area are not available to a program unless you explicitly attach them. This has advantages and disadvantages. compare a "sample" script required to run three programs that pass some very large temporary files. Unix - # prog1 uses as input a file called 'myin'. prog1. # prog1 creates a temp file called 'temp1'. prog2. # " " 'temp2'. prog3. # prog3 creates a file you want to save called 'myout'. rm temp1 temp2 Cyber 205 jcl - attach,prog1. attach,prog2. attach,prog3. attach,myin. prog1. prog2 prog3. purge,myout. define,myout. The 205 jcl seems more verbose, and it is. It also confuses the heck out of VMS and Unix users at first who are not used to having to deal with the silly seeming jcl required to make the files accessible. However, there is something very useful about the way the operating system works. Lets say we want to run the same process 10 times CONCURRENTLY, changing only an input parameter that affects one of the calculations. Now we have a problem on Unix; the files temp1, temp2 and temp3 from the 10 jobs will conlict, and we must do something cute and (to me, annoying) like coming up with unique names for those temporary files. The alternative is waiting for each job to finish before submitting the next one. yuck; I have better things to do. On the 205, the files temp1, temp2 and temp3 are considered local to the particular batch job, and do not conflict with the local files with the same names being used in the other 9 jobs. Enough background; back to the module .vs. include problem. Lets way we maintain our code on a Unix front-end machine and want to run a program that has 3 code modules and 2 common files. For the sake of simplicity, lets assume we have a command on the 205 called 'fetch' that allows us to obtain a file from the front-end. (The real command is quite ugly) A shellscript that would send the file cyber.jcl to the 205 along with the code might look like - cat cyber.jcl *.f | submission-facility. With the use of 'include' files, the 205 jcl would have to look like - fetch,common-file1. fetch,common-file2. fortran. jcl-to-save-executable. In the case of code that uses modulues (in *.mod files) we can use a script of cat cyber-jcl *.mod *.f | submission-facility. and the 205 jcl would look like fortran. jcl-to-save-executable. In reality, since many of our programs contain in excess of 20 or 30 common files, I found I couldn't stand writing all of those silly fetch commands and ended up using a preprocessor on the Unix front-end to pull in the common files before sending the job to the 205. What we use now looks like f77pp *.f | cat cyber-jcl - | submisssion-facility The point of this is that the use of MODULE eliminates the need to do either the silly fetches or the preprocessor and is thus more useful for someone who maintains code on a different machine than that used to run the code. As for the names of the temporary files the compiler uses to deal with the modules, again, I could care less what it calls them. That's its problem, not mine. Do you know (or care about) the names of the temporary files used by Unix f77???? I suspect not... Greg Kamer
ags@s.cc.purdue.edu (Dave Seaman) (02/26/88)
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
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (02/26/88)
[talking about tedium of unique file names under unix] mktemp will make a unique file name for you and you can set it to environment local variable for your job envoking mktemp for each temporary file your process uses. It is no big deal, all you need to do is look in man pages or contact your local UNIX guru. UNIX with its utilities has much more power than you would ever dream of! Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________
chris@metavax.UUCP ( PSA) (02/26/88)
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
ravi@mcnc.org (Ravi Subrahmanyan) (02/27/88)
In article <6502@j.cc.purdue.edu> tsh@j.cc.purdue.edu (Greg Kamer) writes: > > >compare a "sample" script required to run three programs that pass >some very large temporary files. > >Unix - ># prog1 uses as input a file called 'myin'. >prog1. ># prog1 creates a temp file called 'temp1'. Instead of explicitly naming the temporary file, the "open" statement which opens the file can specify "status=scratch", and Unix will give it a file which has the process-id as part of the file name; since each process has a unique pid, the program can be run as many times as needed, concurrently, and all the temporary files will have unique names. -ravi
jerry@violet.berkeley.edu ( Jerry Berkman ) (02/27/88)
In article <2337@s.cc.purdue.edu> ags@s.cc.purdue.edu.UUCP (Dave Seaman) writes: >... 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 You can open files by name from within a program using the UOPEN subroutine in IBM's VM Fortran Utility Library (Program Number: 5798-DFH). This is non-standard, and a hassle, but it is possible. I believe I saw a notice that this problem will be alleviated in in VS FORTRAN Level 2.2.1 which is to be released soon. I hope this is the case and means CMS file identifiers will be allowed in Fortran OPEN statements; but I do not know. The comparison to CDCs VSOS is not valid. CMS users run in their own permanent files, but the Fortran OPEN can not refer to a general CMS name. In the CDC case, from what I read, the OPEN can reference all attached files, but jobs are not run in an environment with permanent user files defined. Jerry Berkman U.C. Berkeley, Central Computing Services jerry@violet.berkeley.edu (Internet) jerry at ucbviole (Bitnet) (415)642-4804
tsh@j.cc.purdue.edu (Greg Kamer) (02/27/88)
>> >>compare a "sample" script required to run three programs that pass >>some very large temporary files. >> >>Unix - >># prog1 uses as input a file called 'myin'. >>prog1. >># prog1 creates a temp file called 'temp1'. > > Instead of explicitly naming the temporary file, the "open" >statement which opens the file can specify "status=scratch", and Unix >will give it a file which has the process-id as part of the file name; >since each process has a unique pid, the program can be run as many >times as needed, concurrently, and all the temporary files will have >unique names. > >-ravi Nope. Note that the process being run uses more than one program. You can create scratch files in the 1st program using the "status=scratch" option (I use it quite often) but 1) you can't give it a name 2) it ceases to exist at the termination of program 1 and is thus not available to the 2nd program. In a related article, someone suggested the use of mktemp to generate unique file names. I'm not sure what type of Unix they are running; we are running BSD4.3 and mktemp is a C utility for which there is no f77 equivalent (try man 3f mktemp). While it would be (and indeed was...) possible to write a C routine that could be called from a f77 program and return such a file name by using an indirect call to mktemp, the original mktemp cannot be called from a f77 program, since its argument is a pointer structure, and as we all know, you can't call any of the C routines which pass structures as arguments from a fortran routine. (try it- you will get an interesting core dump...) -- Greg Kamer Purdue Macromolecular Crystallography Computer Specialist
ags@s.cc.purdue.edu (Dave Seaman) (02/28/88)
In article <7211@agate.BERKELEY.EDU> jerry@violet.berkeley.edu.UUCP ( Jerry Berkman ) writes: >The comparison to CDCs VSOS is not valid. CMS users run in their own >permanent files, but the Fortran OPEN can not refer to a general CMS name. >In the CDC case, from what I read, the OPEN can reference all attached files, >but jobs are not run in an environment with permanent user files defined. On the contrary, CDC jobs ARE run in an environment with permanent user files defined. It's just that files are not permanent unless you say that you want them to be permanent. The comparison is perfectly valid. CMS users cannot normally open files by name unless they remember to issue a FILEDEF before running the program. VSOS users cannot normally open permanent files by name unless they remember to ATTACH them before running the program. In both cases, there are exceptions. CMS users can issue FILEDEFS by making a nonstandard system call within a program. VSOS users can ATTACH files by making a nonstandard system call within a program. It's a standoff. -- Dave Seaman ags@j.cc.purdue.edu
ok@quintus.UUCP (Richard A. O'Keefe) (02/28/88)
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.zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (02/28/88)
The following worked for me (4.3BSD):
Script started on Sun Feb 28 03:10:24 1988
(csd4) !: cat m.f
character*6 t
iflnam=mn(t,6)
open(7,file=t)
write(7,*) '-file-',iflnam,' ',t
stop
end
(csd4) !: cat mm.c
/* make uniq filename */
#include <stdio.h>
#include <ctype.h>
mn_(ffn)
char *ffn;
{
char *mktemp();
char *fn= "XXXXXX";
fn = mktemp(fn);
strcpy(ffn,fn);
}
(csd4) !: f77 -o m.a mm.c mm.f
mm.c:
m.f:
MAIN:
(csd4) !: lt
[Ktotal 2828
[K-rw------- 1 zdenko 21 Feb 28 03:11 029522
[K-rwx------ 1 zdenko 33792 Feb 28 03:11 m.a
[K-rw------- 1 zdenko 885 Feb 28 03:11 m.o
[K-rw------- 1 zdenko 189 Feb 28 03:11 mm.o
[K-rw------- 1 zdenko 0 Feb 28 03:10 _r
[K-rw------- 1 zdenko 21 Feb 28 03:08 029488
[K-rw------- 1 zdenko 183 Feb 28 03:08 mm.c
[K-rw------- 1 zdenko 21 Feb 28 03:07 029461
[K-rw------- 1 zdenko 21 Feb 28 03:07 029447
[K-rw------- 1 zdenko 21 Feb 28 03:06 029439
[K-rw------- 1 zdenko 17 Feb 28 03:05 029423
[K-rw------- 1 zdenko 93 Feb 28 03:04 m.f
[K-rw------- 1 zdenko 10 Feb 28 03:02 029394
[K-rw------- 1 zdenko 10 Feb 28 03:02 a
[K-rw------- 1 zdenko 10 Feb 28 02:50
[K-rw------- 1 zdenko 10 Feb 28 02:48 027793
[K-rw------- 1 zdenko 10 Feb 28 02:46 027733
[K-rw------- 1 zdenko 10 Feb 28 02:44 027708
[K-rw------- 1 zdenko 10 Feb 28 02:43 027693
[K-rwx------ 1 zdenko 33792 Feb 28 02:36 cf.a
[K-rw------- 1 zdenko 882 Feb 28 02:36 cf.o
[K-rw------- 1 zdenko 301 Feb 28 02:36 ch.o
[K[7m[K--More--[Press space to continue, 'q' to quit.][m[J
(csd4) !: cat 029522
-file- 23616 029522
(csd4) !: x
2.0u 2.9s 1:22 6% 38+43k 177+141io 44pf+0w
Logged out Sun Feb 28 03:11:47 CST 1988. Pls turn your terminal off.
exit
script done on Sun Feb 28 03:11:47 1988
Zdenko Tomasic
UWM, Chem. Dept.
Milwaukee,WI,53201
__________________________________________________________
UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko
ARPA: zdenko@csd4.milw.wisc.edu
__________________________________________________________ssd@sugar.UUCP (Scott Denham) (03/05/88)
In article <2337@s.cc.purdue.edu>, ags@s.cc.purdue.edu (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. This was a known deficiency in IBM's VS fortran compiler - it was the result of the '77 standard being to vague as to what the 'name' was supposed to mean. In the IBM developers view, it meant the filedef/ddname in their environments. The SHARE Fortran project has convinced them of the error in their ways, and Version 2 Release 3 lets you have either syntax that makes you happy. (Incidently, in our environment, it turns out that the way they did it first is better about 80% of the time) There is nothing the "new" form gives you that you couldn't do (albeit with some user-written non-FORTRAN allocation routines) and the opposite was not true. But I'm ecstatic to have both options! > -- > Dave Seaman > ags@j.cc.purdue.edu Scott Denham Western Atlas International Of course they're my opinions, I made 'em up didn't I ???