Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!iuvax!pur-ee!j.cc.purdue.edu!mace.cc.purdue.edu!tsh From: tsh@mace.cc.purdue.edu (Greg Kamer) Newsgroups: comp.lang.fortran Subject: INCLUDE .vs. MODULE Keywords: include is useless or tiresome for some setups Message-ID: <917@mace.cc.purdue.edu> Date: 25 Oct 88 15:09:29 GMT Organization: Purdue University Lines: 137 > In article <909@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: > >I've written about this one before. MODULE is much more useful than > >INCLUDE if you are writing your code on a front-end machine and > >submitting it to a remote host. For such a setup, INCLUDE's > >have to be done with a front-end preprocessor before submitting the > >mainframe. With MODULE's you can simply prepend all of your MODULE's > >to the front of the code and send it off. > Could you clarify this a bit? It sounds as though you are saying that > all the MODULEs used in a program have to be part of the same compilation > source on the mainframe; that you can't have some MODULEs sitting there > that you just use. Is that so? > If it isn't so, how is having a module already sitting on the mainframe > and having the compiler use it any easier than having an INCLUDE file > already sitting on the mainframe and having the compiler on the mainframe > include it? (Remember COBOL's "COPY" statement, anyone? It can be done.) Think about HOW you would send stuff to another machine to compile it. 1) You would want ALL of your source code (including the stuff in MODULES) to be on your front-end machine. 2) You would want to cut down the amount of jcl required on the mainframe to obtain the source code for compilation and you would want a setup where YOU don't have to remember to upload the source code to the mainframe for a particular MODULE and/or source code routine once you have made changes. (Let's see, out of those 92 source code files and 27 INCLUDE files, which ones did I change in the last 2 days of sweeping mods. Seem familiar?) The point is that you don't want to do source code maintenence on the mainframe, thus the MODULE's would be on the front-end. Also, you need to remember that SOME operating systems (such as CDC VSOS, which is what we use on our Cyber 205) differentiate between local job files and permanent files. Thus, you must inlcude jcl to pre-attach and INCLUDE or MODULE files that you might have on the mainframe BEFORE you run the compiler. Lets say I have 4 INCLUDE files on the mainframe- then the required jcl (assuming that you have a compiler which will deal with INCLUDE files - the Cyber 205 compiler does NOT) would look something like ATTACH include-file-1 ATTACH include-file-2 ATTACH include-file-3 ATTACH include-file-4 upload-source-code-from-front-end FORTRAN,INPUT=source-code-file LOAD EXECUTE Those attaches can get pretty darned tedious for programs that have a lot of INCLUDE files (some of our programs have over 20 of 'em). Now lets see what we get if we have them all in a single MODULE file. ATTACH module-file upload-source-code-from-front-end FORTRAN,INPUT=source-code-file LOAD EXECUTE This requires less jcl, but it still means I have to remember to upload the MODULE file(s) if I have changed them. This is a real good way to get burnt! Now lets take a look at my current setup. This involves having all of the source code on the front-end, so *I* don't have to remember to upload anything when they are changed. On the front-end - concatenate and pre-process the source code to pull in INCLUDE files append this to the end of the jcl required to compile and load, telling the compiler to obtain its source from std input. submit the result to the mainframe What the mainfram sees is FORTRAN,INPUT=INPUT LOAD EXECUTE (end-of-group) pre-processed source code Note that this requires me to write or obtain a pre-processor that will pull in those include files. If the MODULE concept is enabled, we get On the front-end concatenate the MODULE files followed by the source files append this to the end of the jcl required to compile and load, this time telling the compiler to obtain its source from std input. submit the result to the mainframe What the mainframe sees is FORTRAN,INPUT=INPUT LOAD EXECUTE (end-of-group) MODULEs source code and this time no silly pre-processor is required. The main point I was trying to make is that for situations where your compiler is on a different machine the MODULE command cuts down on either the amount of jcl required to obtain the source code and/or eliminates the need for a front-end preprocessor. The disadvantages of INLCUDE .vs. MODULE are glaringly apparent to anyone who has ever worked on a system which differentiates between local job files (which are available to the executing job) and permanent files (which require jcl to make them available to the executing job). I suspect that you have never worked with such a setup- most people I talk to who have never dealt with such an environment have difficulty in understanding why the compilers on such systems don't have INCLUDE facilities. Its because using INCLUDE's on such a system would require lots of tedious jcl and better ways have been devised to deal with the facility for such operating systems, usually as part of a source code revision control system. Alas, the 205 is a miserable interactive environment, and so we don't even use the revision control system (UPDATE) available on the 205 since the facilities available on our Unix front-end put it to shame. Now if they would just add a macro facility to Fortran 88.... -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)