Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: INCLUDE .vs. MODULE
Keywords: include is useless or tiresome for some setups
Message-ID: <576@quintus.UUCP>
Date: 26 Oct 88 09:37:52 GMT
Article-I.D.: quintus.576
References: <917@mace.cc.purdue.edu>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 69

In article <917@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes:
>Think about HOW you would send stuff to another machine to compile it.

My method of choice would be NFS, actually (:-).

>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?)

Yes, it seems familiar.  That's what "make" is for.   It's an idea which
has been invented many times, and is quite easy to do.  (For UNIX, there
is even a public-domain tool to make make-files automatically.)  Why
should I care how much JCL there is as long as it is generated automatically?

>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).

So what?  Who would dream of writing that stuff by hand?  Ok, so the
mainframe may make script-writing hideously complicated, but we're already
talking about something like PWB where the source maintenance and script
generation is done automatically on a front-end machine.

Given the choice of writing a tool to generate the JCL automatically to
attach files which are already sitting on the mainframe, or having to
collect all my source files into a single giant document and transmit it,
I would much rather do the former.  (If I want to compile on a /370 from
here, we have to pay for the time it takes to transmit the sources, and
that is not especially cheap.  I really do not want to upload anything
which has not changed.)

>Now lets see what we get if we have them all in a single MODULE file.

Ahah!  So you *are* saying that the MODULE facility requires a single
great big lump of source.  Doesn't that sort of miss the point of Fortran?

>Note that this requires me to write or obtain a pre-processor that
>will pull in those include files.

So?  That's half an hour's work in UNIX+C, two hours' work in VMS+FORTRAN. 

>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.

I still don't understand this.  It does so *only* if you intend to
compile your programs on the mainframe as single large files.  This
is not the way modules work in MODULA-2 or packages work in ADA or
separately compiled classes work in SIMULA-67.  I thought the idea
of modules in F8X was to permit type-checked *separate* compilation
(but not of course to require it).

And I want to stress that if the mainframe you are using is not on-site,
you have to balance the cost of transmitting unchanged source files again
and again against the cost of renting disc space for them, and sometimes
the latter approach is cheaper.