Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!chiba!khb From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) Newsgroups: comp.lang.fortran Subject: Re: INCLUDE .vs. MODULE Message-ID: <74560@sun.uucp> Date: 25 Oct 88 20:48:39 GMT Article-I.D.: sun.74560 References: <917@mace.cc.purdue.edu> Sender: news@sun.uucp Lines: 44 In-reply-to: tsh@mace.cc.purdue.edu's message of 25 Oct 88 15:09:29 GMT In article <917@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: stuff removed... 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. More Cyber stuff ... I agree that MODULE is very useful. But the issue of distributed source can be handled at the distributed OS level quite nicely. (* sun plug follows *) NFS + automounter + yellow pages + NSE. (all sun products, many of which exist on other vendors platforms, thanks to licesening agreements) (* end sun plug *) Naturally this does not help those working with machines whose vendors haven't climbed onto the bandwagon! :>>> My points are: 1) MODULE has other good features. It should be implemented. 2) Source code control/network stuff can/should be done at the OS level. btw: > "...macro-processor in f88" This got lost very early in the comittee. To make a long story short, the committee felt under pressure to keep the proposed standard fairly short. So macro-processing we left out. I would have preferred it be included; but it is too late for f88. Let's ordain f88, and work on implementing it. Then in five years we can start discussing f9x, or f20xx. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus