Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!husc6!purdue!i.cc.purdue.edu!j.cc.purdue.edu!tsh From: tsh@j.cc.purdue.edu (Greg Kamer) Newsgroups: comp.lang.fortran Subject: Re: F8X response (long) Message-ID: <6502@j.cc.purdue.edu> Date: 25 Feb 88 15:09:45 GMT References: <705@elxsi.UUCP> <44400017@hcx2> Organization: Purdue University Computing Center Lines: 129 Summary: more on INCLUDE .vs. MODULE > > 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