HDTenEightyP/NetNews huggingface dataset:
From: Spencer.Morgan@f612.n270.z1.fidonet.org (Spencer Morgan)
Newsgroups: comp.lang.modula2
Subject: JPI Modula-2
Date: Thu, 10 Dec 92 16:17:36 PDT
Organization: FidoNet node 1:270/612 - The Programmer's Pi, York PA

JPI is now Clarion in Florida.
 
JPIs BBS # is 1-305-781-3578.
 
Try 1-800-354-5444 for voice.
 
Spencer


--  
uucp: uunet!m2xenix!puddle!270!612!Spencer.Morgan
Internet: Spencer.Morgan@f612.n270.z1.fidonet.org
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.modula2
Subject: Re: GENERIC TYPE IN MODULA-2
Date: 14 Dec 92 20:53:14 GMT
Organization: Department of Computer Science, University of Manchester
In-reply-to: andrea@ESSEX.STFX.CA's message of 10 Dec 92 21:39:54 GMT

In article <00964E42.F315D220.13757@esseX.stfx.ca> andrea@ESSEX.STFX.CA (John Andrea) writes:

   TYPE
      data :ADDRESS;
      left, right :Pointer;

   Unfortunately that approach removes type checking and you can put the wrong
   data type into your tree.

Not if you create a separate module where the parameters have the
correct type and must be coerced to the above.  Granted you could get
this wrong, but if you do it once, you can use it as a template and
then just use search/replace to create a new module with the correct
type.  If the compiler is any good, it should be able to inline all
the interface procedures and so it doesn't cost you anything at
runtime.


   Yes it looks like the OO approach wins in a situation like this.

The one OO solution I've seen to this is not one I'd advocate and not
one I think comp.object readers would like either.  The classic (and
IMHO still the best) solution to this problem is parametric
polymorphism aka ``generics'' in Ada or ``templates'' in C++ (the
above solution is just a manual instantiation method).  This has
_nothing_ to do with OO.

yours against gratuitous use of OO as a panacea,

bevan
Newsgroups: comp.lang.modula2
From: ob@ifi.uib.no  (Ole-Bjorn Tuftedal)
Subject: Re: Generic stack implementation
Nntp-Software: PC/TCP NNTP
Reply-To: ob@ifi.uib.no
Organization: University of Bergen, Norway
Date: Tue, 15 Dec 1992 11:47:32

911288c@ace.acadiau.ca (HON (EDWIN) KIN CHUNG) writes

>      FOR wordcount := 0 TO size DIV TSIZE(WORD) - 1 DO
>         item[wordcount] := location^;
>         INC(location, TSIZE(WORD));
                ^^^^^^
                parameter not correct type ??

                Is this some problem ...???
                I am using TopSpeed Modular-2.

                Can anybody help ??

The code was tested in Logitech Modula-2 (now Multiscope/StonyBrook).

The type ADDRESS (from module SYSTEM) is compatible with pointers - 
it is a POINTER TO WORD.

The (first) argument to INC can a.o. be integer, cardinal, address, 
char, an enumeration type.

Good luck,
Ole-Bjorn Tuftedal
From: yeung@REED.EDU (Woodrow Yeung)
Newsgroups: comp.lang.modula2
Subject: Re: p1 Modula-2 on the Macintosh
Date: 19 Dec 92 01:44:00 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: Reed College, Portland, Oregon

Hi Marc,

May I ask if you are using p1 for your personal work or as part of a Boeing
project?

I am about to embark on a major project using the p1 compiler with MacApp 2.0
but would like to have SYM support.  I am negotiating with Elmar to either
have V4.3 support SYM or to have V5.0 support MacApp 2.0.1.  Is V5.0 stable
enough?  Thanks.

Woody Yeung
yeung@reed.edu
Newsgroups: comp.lang.modula2
From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
Subject: Address & phone no. of Clarion - wanted
Organization: University of Newcastle, AUSTRALIA
Date: Wed, 16 Dec 1992 06:06:22 GMT

Could someone please mail me the address of Clarion (the new owners
of JPI TopSpeed)?  I know it's been posted here before, but I seem to
have lost my copy.

Phone and fax numbers would be even more useful.

I know an Australian distributor, but that's not what I'm after now.
What I'm looking for is the head office.
-- 
Peter Moylan                      eepjm@wombat.newcastle.edu.au
From: randy@psg.com (Randy Bush)
Newsgroups: comp.lang.modula2
Subject: Re: Generic stack implementation
Date: 14 Dec 92 19:39:01 GMT
Article-I.D.: psg.1992Dec14.193901.28257
Organization: Pacific Systems Group, Portland Oregon, US

eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:

> TopSpeed Modula-2 won't let you do arithmetic on addresses.  And a
> good thing, too, in my opinion.  Address arithmetic is one of the
> most non-portable things you can do, and I'm a little shocked to
> see an example of it in a textbook.

Hmmm.  As one of M2's stated design goals was to be able to write the entire
operating system in M2.  Hence, one wants to write storage [de]allocators,
device drivers for devices that use multiple addresses, ...

So, the issue is what is a reasonable zero-cost safety to put around the
mechanism so it is not accidentally misused?

randy
-- 
randy@psg.com   ...!uunet!m2xenix!randy
From: martino@ALSENG.BOEING.COM
Newsgroups: comp.lang.modula2
Subject: Re: p1 Modula-2 on the Macintosh
Date: 19 Dec 92 03:47:35 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: The Internet

Woody Yeung writes:

>May I ask if you are using p1 for your personal work or as part of a Boeing
>project?

Hi Woody,

I am using p1 Modula-2 at work to port some Modula-2 programs on the VAX to
the Mac.  The programs are definitely non-trivial, with individual module
sizes approaching 10,000 lines each.

>I am about to embark on a major project using the p1 compiler with MacApp 2.0
>but would like to have SYM support.  I am negotiating with Elmar to either
>have V4.3 support SYM or to have V5.0 support MacApp 2.0.1.
>Is V5.0 stable enough?

I cannot offer any comparison of the stability of V4.3 versus V5.0, as I
have never used V4.3 because of it's restriction on the code size of an
individual module (32 Kbytes, or around 2500 lines).

I have found and reported a few bugs in the beta release V5.0b4.  Many of
these bugs were fairly obscure, and were apparently in V4.3 as well.  Some
of the bugs that were V5.0 specific were related to the ISO I/O Libraries,
so I am currenty using the MODUS I/O Libraries instead.  However, p1's
technical assistance (via e-mail) has been excellent.  They have helped me
find temporary workarounds for each bug, and tell me that all of these bugs
have now been fixed.  I notice that you are using V5.0b8, so your version
probably has my bug fixes in them!

If you are about to embark on a major project, I would recommend using V5.0
over V4.3 because of the many improvements that they have described in
their release notes.  I wouldn't worry too much about finding bugs in this
major new release, because p1 is so good about getting your problem solved
and the compiler fixed.

----
Marc Martin
Boeing Space & Defense Group, Seattle, WA, USA
martino@alseng.boeing.com
Xref: sparky comp.lang.modula2:1559 comp.sys.mac.programmer:19779
From: amc01@rrz.Uni-Koeln.DE (Sebastian Hagedorn)
Newsgroups: comp.lang.modula2,comp.sys.mac.programmer
Subject: Syntax checker for Modula-2
Date: 14 Dec 1992 13:22:05 GMT
Organization: Regional Computing Center, University of Cologne
Distribution: world
NNTP-Posting-Host: rs1.rrz.uni-koeln.de


I guess my question points into the direction of the "GENERIC TYPE"
discussion that has been led here. We are looking for a way to implicitly
cast arguments in certain situations. Our idea to handle that problem
is to use a pre-processor that should make a list of all variables and type
dependencies, applying a cast if necessary, in order to get rid of
incompatibilities.
Now, we don't really want to code that beast from scratch. Does anybody
out there have source for a syntax checker or anything else that creates
a list like that?
Any help is greatly appreciated, also other alternatives to solve that problem.
Thanks!
-----------------------------------------------------------------------
Sebastian Hagedorn			"Keep passing the open windows"
Linguistic Data Processing
Cologne University
Germany

E-mail: hgd@spinfo.Uni-Koeln.DE
Newsgroups: comp.lang.fortran
From: wws@craywr.cray.com (Walter Spector)
Subject: Re: Uglifier (was Re: Real Programmers)
Organization: Cray Research, Inc.
Date: 18 Dec 92 20:11:41 CST

In article<1992Dec18.233525.19273@nsisrv.gsfc.nasa.gov>,knox@spruce.gsfc.nasa.gov (Robert Knox) writes:
> Re. output from Mortran:
>
> On my first largish Fortran projects I used a pre-processor 
> call FLECS, for CDC 170 series machines.

Mortran actually lived on in the Cray world disguised as
SKOL in the old COS operating system.  At one time, several
significant pieces of COS were coded in it, including CSP
(the control statement processor - COS's shell), and some of
the original debugging tools.  Over time, these were rewritten
in raw Fortran, CAL (assembler), and Pascal (this was long before
C became all the rage).

There was even an undocumented extension in the old CFT Fortran
compiler called 'IMPLICIT SKOL' which did something magical with
variables starting with I00.  But this is all dusty history and
I don't remember what it did.

No, we didn't port SKOL to Unicos.  :-)

Walt
----
Walt Spector
(wws@renaissance.cray.com)
Sunnyvale, California
_._ _._ _.... _. ._.
From: dodd@mycenae.cchem.berkeley.edu (Lawrence R. Dodd)
Newsgroups: comp.lang.fortran
Subject: Re: Real Programmers
Date: 15 Dec 92 14:27:37
Organization: Dept of Chemical Engineering, Polytechnic Univ, NY, USA
	<1992Dec14.235245.2307@ultb.isc.rit.edu>
	<DODD.92Dec15053719@mycenae.cchem.berkeley.edu>
	<1992Dec15.170343.10342@craycos.com>
Reply-To: dodd@roebling.poly.edu
NNTP-Posting-Host: mycenae.cchem.berkeley.edu
In-reply-to: jrbd@craycos.com's message of 15 Dec 92 17:03:43 GMT


>>>>> "James" == James Davies <jrbd@craycos.com> writes:

  James> In article <DODD.92Dec15053719@mycenae.cchem.berkeley.edu> dodd@roebling.poly.edu writes:
>
>>>>>> "Doctor" == Doctor FORTRAN <jsvrc@rc.rit.edu> writes:
>
>  Doctor>   101 Format (100 (' :-)'), /, ' For the Humor-impared.')
>  Doctor>       Write (Kout, 101)
>
> line 2: Error: attempt to use undefined variable "kout"
> line 2: Error: bad unit specifier type in write statement
> Compilation failed

  James> Real FORTRAN programmers always write to unit 6, and then bitch about
  James> the compiler being broken when it doesn't work.  write(*,101) is for
  James> sissies :-)

Real FORTRAN programmers don't use lowercase letters, no excess space, no
commas unless the compiler complains, and no unit number that can be
remembered. so

 85367 FORMAT(100(':-)')/'FOR THE HUMOR-IMPARED.')
       WRITE(6,85367)
       
Newsgroups: comp.lang.fortran
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: function name as an argument
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Mon, 14 Dec 1992 15:24:01 GMT


In article <1992Dec12.010450.23241@draco.macsch.com>, 
dnl@convex.is.macsch.com (David Lombard) writes:
|>In article <1992Dec10.155427.2271@e2big.mko.dec.com> lionel@quark.enet.dec.com (Steve Lionel) writes:
|>>                                     Indeed, the standard says:
|>>
|>>	If a character function is referenced in a program unit,
|>>	the function length specified in the program unit must be
|>>	an integer constant expression.
|>>
|>>			ANSI X3.9-1978, section 15.2, p15-2, lines 5-7
|>>
|>>Because VAX FORTRAN supports the usage above, we always pass character
|>>functions by descriptor, which includes the length.  But a standard-conforming
|>>program can't do this thus a compiler which chooses not to support this
|>>extension can get away without passing the length of character function
|>>arguments.  (When the function is actually called, the length of the function
|>>result does have to be passed, but that's another story.)
|>>
|>
|>If you're going to quote the standard, make sure you're right.

Sage advice. I believe I followed it in this case.

|>
|>See section 8.4.2 CHARACTER Type-Statement, line 46-:
|>
|>	If a dummy argument has a len of (*) declared, the dummy
|>	argument assumes the length of the associated actual
|>	argument for each reference of the subroutine or function.
|>
|>Thus, in a function or subroutine,
|>
|>	CHARACTER FRED*(*)
|>
|>is correct (IMHO the _proper_ declaration!).
|>

Your own advice is probably appropriate here.  A careful reading of the
paragraph you quote reveals that these lines only tell you what happens *IF*
the dummy argument has a len of (*); it doesn't say that such a len is legal
in this case.  If you keep reading to lines 5-10 on page 8-7, you'll see the
additional rule that if the program unit references the function, the length
must NOT be (*) but rather be an integer constant expression which "must
agree with the length specified" in the actual function specification. (It
was a restatement of the first part of this which also appeared in chapter
15 and which I quoted in the previous posting.) A length of (*) is legal, as 
others have mentioned, only if the function is not referenced in the program 
unit; perhaps it is passed as an argument to another routine. 

The Fortran language standard is not as explicitly written as that for some
other languages (notably Ada), and there are times when the reader has to be
familiar with the standard as a whole, fitting together pieces mentioned in
diverse sections.  Even after many years of study, there are traps for the
unwary and not a small number of ambiguities.   I've been in the Fortran
business for over 14 years now, and I still find little surprises between
the lines.  Don't feel too bad if it trips you up from time to time.

--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.lang.fortran
From: syswtr@iowasp.physics.uiowa.edu
Subject: Re: Real Programmers
Organization: Department of Physics and Astronomy, University of Iowa
Date: Wed, 16 Dec 1992 20:45:58 GMT

In article <1992Dec16.095723@trc.amoco.com>, zkdc05@trc.amoco.com (Kelly D. Crawford) writes:
> 
>> so are we agreed that the final version would be the following?
>> 
>> 85367 FORMAT(100(3H:-))/22HFOR THE HUMOR-IMPARED.)
>>       WRITE(6,85367)
> 
> Since we need that carriage control character, how about this:
> 
> 85367 FORMAT(10000(4H+:-)/)/24H+FOR THE HUMOR-IMPAIRED.)
>       WRITE(6,85367)
> 
> The + as a carriage control means don't skip to the next line.
> 
> Plus, since we are dealing with equipment superior to what we have today,
> then we probably will read this printout on a paper printer.  I've upped the
> number from 100 to 10000 so we can beat the printer and paper silly...
> 
> Kelly
> 
> (By the way, this compiles and runs, but my stupid old Sparc doesn't know
> that it shouldn't skip lines...)
> -- 
> Kelly D. Crawford             | Amoco Production Research | These are my own
> kcrawford@trc.amoco.com       | 4502 East 41st Street     | opinions, not
> phone: (918) 660-4043         | Tulsa, OK  74102          | Amoco's...
>           >>> *** This line intentionally left blank *** <<<
ahh, punch it in column binary...
and don't forget to lace some cards right in the middle (1009)
From: klassen@sol.UVic.CA (Melvin Klassen)
Subject: Re: How common are long variable names?
Organization: University of Victoria, Victoria, B.C. CANADA
Date: Sat, 12 Dec 92 23:15:01 GMT

Dr. Kenneth H. Fairfield <fairfield@slacvx.slac.stanford.edu> writes:
> My posting was in sympathy to J. Giles' (?) remark about compilers
> which _accept_ long names but, in essence, don't _support_ them.  

IBM's compiler fully supports 31-character names, as fully as is possible
on the specific platform (VM/CMS, MVS, AIX/370).

> My personal opinion is that it would be better for them to say, 
>   "We support long variable names, 
>    but externals still need to be limited to 7 characters".  

Page 7 (in "Chapter 1. Language") of "VS FORTRAN Version 2, Language and
Library Reference, Release 5" (SC26-4221-7) states:
     In CMS and MVS, if a global name is longer than seven characters,
     the first four and last three characters are used to form the
     external symbol.  The external symbol is then used to identify
     the global entity.  For example, ...

In the "Release 3" edition (March 1988) of this manual, 
similarly-worded text appears on page 8.

It seems clear to me!
Newsgroups: comp.lang.fortran
From: sundaram@me.uta.edu (Ravi 'Kity Bum' Sundaram)
Subject: Re: Reinventing WRITE...
Organization: none
Date: Wed, 16 Dec 1992 16:17:15 GMT

In article <29011.9212161323@thor.cf.ac.uk> spxsjm@thor.cf.ac.uk (Mr S J Morris 92) writes:


>   I want to define a subroutine which will take the same input paramters
>   as a WRITE procedure; that is, I'd like to define
>
>	 SUBROUTINE WRITELN(A,B)
>
>   in such a way that
>
>	 WRITELN (7,100) X,Y
>	 WRITELN (6,*) 'HELLO THERE'
>	 WRITELN (*,*) 'HE''S GETTING CLEVER NOW'
>
>   all work more or less the same as the corresponding WRITE statements (by
>   the way, the reason I'm doing this is to open a file, find the endfile
>   record, append a new record and then close the file again, all in a
>   single call - so that I can flush the output buffer in SUN Fortran). Is
>   there a way of doing this, or am I being hopelessly ambitious (I've been
>   doing some programming in Turbo Pascal for Windows recently, where doing
>   this would be a doddle), or is there in fact another, easier way of
>   flushing the buffer on a Sun (cf. the recent thread on how to do the
>   same on a VAX)?
>
>   Thanks in advance for any suggestions.

>
>   -- 
>
>   Steve Morris,
>   Adran Ffiseg a Seryddiaeth, Coleg Prifysgol Cymru Caerdydd.
>   (Physics and Astronomy Dept., UWC Cardiff)


1.0	I have always used
	CALL FLUSH(IUNIT_NUMBER)
	to flush the buffer. They (all the nice people of this net) told 
	me that it is non-standard. But it will work in SUN and SPARC
	All that opening, finding endfile and closing is done just to 
	flush the buffer, you can throw it all out and just add a
	CALL FLUSH after every write statement. 

2.0	The reason the thread was long on VAX but not on SUN is probably
	due to availability of CALL FLUSH in SUN.

	Ravi Sundaram
____________________________________________________________________________
From: lry1219@cfdd40.boeing.com (Larry Yeagley)
Newsgroups: comp.lang.fortran
Subject: Re: Help to flush buffer in FORTRAN.  (REPOST)
Summary: flushing buffers in FORTRAN sans CLOSEing or REWINDing
Date: 12 Dec 92 00:06:14 GMT
Organization: Boeing Computer Services, Seattle - CFD lab

In article <1992Dec8.124335.1@lure.latrobe.edu.au>, tspdlr@lure.latrobe.edu.au writes:

   [stuff deleted]

> until it finishes.  Since my program takes many hours to complete I want
> to force the buffered output data to the output file periodically to 
> ensure minimal data loss in case of a system crash/failure.
> 
> I have thought about periodically closing and re-opening the files but 
> don't really like this as a solution.
> 

Consider using the command "ENDFILE (unit)" to flush output buffer of "unit".
I have used it on several platforms and it seems to work. Typically, I use it
when I have catastrophic program crashes - those for which no error traceback
is available. Such crashes often leave data in the buffers. To insure that the
data is pushed out I insert ENDFILE after each WRITE in the suspected region.
Then, when the crash comes, I am assured that I know the last bit of data that
was written.

Note that ENDFILE does not reposition the file whereas CLOSE & REWIND do.


Larry Yeagley
lry1219@cfdd42.boeing.com
From: latypov@server.uwindsor.ca (LATYPOV A. M.            )
Newsgroups: comp.lang.fortran
Subject: OVERLAYS|FORTRAN 77|RSX(-11)|PDP-11|Russian Programmer Needs Your Help.
Date: 19 Dec 1992 04:41:05 GMT
Organization: University of Windsor, Ontario, Canada



 Dear folks, 
 
 I have a request for information from a young person, 
 working as a programmer in the town of Ufa, in Russia. 
  
 He is interested in writing a program with OVERLAYS 
 in FORTRAN 77 in RSX(-11) system. As far as his knowledge 
 goes, the info in question can be found in "PDP-11 
 FORTRAN-77 User's Guide".  
 
 However, to my regret, the local library does not have
 the mentioned manual.  
 
 In this connection, I should be most grateful to those 
 of you who could answer the following questions: 
 
 ( i) What other literature/papers can be helpful to him? 
 
 (ii) Are there any sources of information on this subject
      (overlays in FORTRAN 77 in RSX(-11)) which can be
      accesed via ftp/telnet/mailserv? 
 
 Please reply directly to my email address, as I do not
 read this newsgroup. 
 
 Thank you for your time, 
 
 Azat   
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: file redirection under unix
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Distribution: usa
Date: Tue, 15 Dec 1992 20:59:59 GMT

In article <1992Dec15.192847.12970@wl.com>, agrafiot@wl.com (Dimitris Agrafiotis) writes:
|>A trivial question: how does one redirect fortran output on a unix system?
|>(the vms equivalent would be DEFINE FOR012 file.dat). If the answer is
|>soft links, how do we take care of multiple versions of the program 
|>running in the same default directory?

in these terms there is no solution.
i use to create a directory for each execution, with something like
(in a shell script)

mkdir pgm$$
cd pgm$$
ln -s path_of_your_input_file fort.10 
pgm.x
mv fort.11 path_of_your_output_file
cd ..
rm -r pgm$$

the $$ is replaced by the process number so that each running
copy has a separate directory.
of course another solution is to put filenames in the OPENs,
which makes the programs Unix-dependent.
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: function name as an argument
Organization: Los Alamos National Laboratory
Date: Mon, 14 Dec 1992 21:53:49 GMT

In article <1992Dec14.193634.5231@newshost.lanl.gov>, jlg@cochiti.lanl.gov (J. Giles) writes:
|> [...]
|> Once again: there is no need to rely on dynamic memory to provide
|> the above functionality.  However, it appears that there *is* a
|> constraint in the Fortran 77 standard which prohibits it.  I don't
|> know why and neither does our representative to the committee.

Finally, someone who thinks rather than just reacting has sent me 
the answer to this.  The example under discussion in this thread 
did *not* require any dynamic memory allocation (or even stack).  
However, an similar example would:

      subroutine asub(func, var)
      character*(*) func, var
      ...
      var = other_fcn(func(1), func(2))
      ...
      end

Any example in which the passed-in function would be called more than
once in a single statement would require that more than one chunk of
intermediate space be reserved.  This is apparently the reason for the
constraint in the standard.  No thanks to those whose responses just
echoed the party line with no thought or explanation given.  Thanks
for the correct answer are due to Peter Montgomery of Oregon State.

Of course, a weaker constraint that allowed functions with passed-in
lengths to be used, but only if they were limited to one call per
statement, would also be possible.  It's not clear this was ever 
even considered (such a subtle constraint would probably be confusing
anyway).  

The Fortran 90 standard allows automatic and dynamic allocation and 
should have no problem eliminating the constraint altogether.  And, 
indeed, I cannot find any mention of such a constraint in the Fortran 90 
document.

Thanks once again to Peter Montgomery for setting me straight on this
issue.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: metcalf@apofort.cern.ch (Michael Metcalf )
Subject: Re: Uglifier (was Re: Real Programmers)
Organization: CERN European Lab for Particle Physics
Date: Thu, 17 Dec 1992 14:40:55 GMT

Sorry, this is of course the old source form.
                                  Mike
Newsgroups: comp.lang.fortran