HDTenEightyP/NetNews huggingface dataset:
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Turning VAX FORTRAN IOSTAT returns into VMS status codes?
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Thu, 12 Nov 1992 15:06:39 GMT


In article <2b022ab8.3aaa@lhn.gns.cri.nz>, mdlcpgs@lhn.gns.cri.nz writes:
|>Hi. I wonder if anyone can tell me how to turn a VAX FORTRAN
|>IOSTAT status return value into a VMS status for signalling
|>by LIB$SIGNAL?  I cant in this application use ERRSNS because
|>the error of interest may not be the last io transaction on
|>the file at the time when I want to signal.

Here's a function that does it.  It's a bit wordier than I might have hacked
up on my own but I wanted it to be understandable.  The key notion is that
the IOSTAT value is just the "message number" part of a VMS condition code
using the FOR$ (FORTRAN Run-Time Library) facility.  Note that you can't
recover the severity of the original error except by using knowledge of how
it was assigned, which I have done here.

	INTEGER*4 FUNCTION IOSTAT_TO_STATUS (IOSTAT)
C+
C 
C FUNCTIONAL DESCRIPTION:
C 
C     Converts FORTRAN IOSTAT value to a VMS condition code suitable for
C     use by LIB$SIGNAL
C 
C FORMAL PARAMETERS:
C  
C     IOSTAT:
C	  The IOSTAT value to be converted, INTEGER*4
C   
C FUNCTION VALUE:
C 
C     The VMS condition code equivalent of the IOSTAT value argument.
C 
C-
	IMPLICIT NONE
	INTEGER*4 IOSTAT
	INCLUDE '($FORDEF)' ! FORTRAN RTL error message codes
	INCLUDE '($FORIOSDEF)'	! IOSTAT definitions
	INCLUDE '($STSDEF)' ! VMS condition code format
	INCLUDE '($SSDEF)'  ! VMS statuses

	! Define base message code value
	!
	INTEGER*4 FORMSG_BASE
	PARAMETER (FORMSG_BASE =
	1  ISHFT(FOR$_FACILITY,STS$V_FAC_NO) +    ! FOR$ facility code
	2  STS$M_FAC_SP)			    ! Facility specific

	! IOSTAT of zero means success
	!
	IF (IOSTAT .EQ. 0) THEN
	    IOSTAT_TO_STATUS = SS$_NORMAL
	!
	! Negative IOSTAT means end of file
	!
	ELSE IF (IOSTAT .LT. 0) THEN
	    IOSTAT_TO_STATUS = FOR$_ENDDURREA
	!
	! Otherwise IOSTAT is MSG_NO part of message with F severity
	! (except for OUTCONERR which is E severity)
	!
	ELSE
	    IF (IOSTAT .EQ. FOR$IOS_OUTCONERR) THEN
	      IOSTAT_TO_STATUS = FOR$_OUTCONERR
	    ELSE
	      IOSTAT_TO_STATUS = FORMSG_BASE +
	1       ISHFT(IOSTAT,STS$V_MSG_NO) + STS$K_SEVERE
	    END IF
	END IF
	RETURN
	END

--

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: dafnioti@cae.wisc.edu (Petros Dafniotis)
Subject: Re: VAX FORTRAN COMMON block problem
Organization: U of Wisconsin-Madison College of Engineering
Date: 4 Nov 92 23:10:00 CST

In article <1992Nov4.215456.9045@Princeton.EDU> mfterman@phoenix.Princeton.EDU (Mutant for Hire) writes:
>Here's the problem. I have the following set of lines in my code. This
>is the only common block in the entire program. These lines are repeated
>verbatim in every subroutine and in the main code.
>
>      real t0,ts,c1,c2
>      real e(-ks:ks,-ks:ks,-ks:ks)
>      real ei(-ks:ks,-ks:ks,-ks:ks)
>      real qqi(-ks:ks,-ks:ks,-ks:ks)
>      complex y(0:iter,-ks:ks,-ks:ks,-ks:ks,1:dimf)
>      common t0,ts,c1,c2,e,ei,qqi,y

Martin,
  I cannot find (at first glance) anything wrong with your code; so I only
have three suggestions:
1) you might mess up the values of ks or dimf in the places where you
   use the COMMON block (e.g. in one routine you may use ks=10 and in
   another ks=20).
2) you might (even without realizing it) pass as a dummy argument to this
   or another function that contains the same COMMON, one of the arguments
   of the common block, thereby introducing side effects (that are of course
   illegal).
3) you might want to use the debugger and set a watch point for your y
   variable that you know is messed up
4) you might have in a part of your program another blank COMMON block
   that messes you up.

  Now, two advices before posting:
1) present a small as possible though complete fragment of your code that
   most reasonably represents your problem. This way we can check than
   imagining what might go wrong.
2) use a FORTRAN checker for spotting syntactical/program errors. FTNCHEK
   is a free (and quite good) tool that I use; FLINT is a commercial and
   extremely flexible tool. I use both. See FAQ list for locations/companies
   and other information. Believe me, you will see BIG differences, especially
   with big codes.

  I really hope that these are of any usefulness.

				Petros Dafniotis
				Chem Engr Dept, UW-Madison
			e-mail: dafnioti@cae.wisc.edu
From: corbett@lupa.Eng.Sun.COM (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 Standard document
Date: 6 Nov 1992 03:25:25 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Distribution: world
NNTP-Posting-Host: lupa

In article <1dc5teINNbj9@manuel.anu.edu.au> dbs900@anusf.anu.edu.au (David Singleton) writes:
>
>Could someone please post the details of where to order a copy
>of the Fortran 90 standard from and the cost of same?

At present, the best source for the Fortran 90 Standard is ISO/IEC.
ANSI prints copies of ISO/IEC 1539-1991(E), but they use inferior
paper and charge more.  The address of ISO/IEC is

	ISO/IEC
	Case postale 56
	CH-1211 Genve 20
	Switzerland

When I last checked, they charged about 125 USD.  The price is
likely to have changed because of exchange rate fluctuations.

					Yours truly,
					Robert Corbett
Newsgroups: comp.lang.fortran
From: jsvrc@rc.rit.edu (J A Stephen Viggiano)
Subject: Re: Fortran Forever?
Organization: RIT Research Corp
Date: Tue, 10 Nov 1992 21:26:43 GMT

In article <5698@sumax.seattleu.edu> davej@sumax.seattleu.edu (Dave Jenner) writes:
>I remember a saying something like: "Fortran will be around forever, we
>just don't know what the language will look like in the future" or something
>like that.  Can someone remember what the saying is, who said it, and
>even give a reference to it?

That great sage, Doctor FORTRAN, has remarked on numerous occasions:

	FORTRAN was FORTRAN when C was a pup,
	FORTRAN will be FORTRAN when C's time is up.

It is widely conceded that he first publicly made this remark at a meeting of
the Lilac Hill Mob, though I forget the date.
Newsgroups: comp.lang.fortran,comp.lang.c
From: chrism@col.hp.com (Chris Magnuson)
Subject: Need Fortran->C converter!
Date: Fri, 6 Nov 1992 04:45:25 GMT
Organization: HP Colorado Springs Division

 I hope this is not a FAQ...I need a fortran to C converter.  I used to
 have one called f2c.  Can anyone help me find it again?

 Thanks!
 chrism@col.hp.com
Newsgroups: comp.lang.fortran
From: zkdc05@trc.amoco.com (Kelly D. Crawford)
Subject: Re: Fortran Forever?
Originator: zkdc05@church
Organization: Amoco Production Company, Tulsa Research
Date: Wed, 11 Nov 1992 18:33:52 GMT


In article <1992Nov11.171337.18547@draco.macsch.com>, dnl@convex.is.macsch.com (David Lombard) writes:
> In article <27366@oasys.dt.navy.mil> ruckman@oasys.dt.navy.mil (Christopher Ruckman) writes:
> >
> >In Scientific American, July 1991, p. 112, Paul Wallich's article entitled
> >"FORTRAN Forever:  Is it still the language of choice for science?"
> >contains the quote but not its origin.  According to the article, Guy
> >L. Steele of Thinking Machines quotes an unknown scientist as saying
> >"I don't know what the computer language of the year 2000 will look
> >like, but I know that it will be called FORTRAN."
> 
> 
> *Legend* attributes it to Seymour Cray.
> 

I heard the same legend just today (but attributed to *oral tradition*.)  That's two
votes for Seymour.

Speaking of great Fortran quotes, Rex Page (a functional programming guru that has
been active in the standardization effort of Fortran 90) says:

"Fortran was a mistake of ignorance and naivete.  C was created by people that should
have known better."

and

"Procedural programming is a monumental waste of human effort."

(quotes used by permission, all rights reserved, close cover before flaming)

Kelly
-- 
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 *** <<<
From: ritley@uimrl7.mrl.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: ALGAMA function
Date: 11 Nov 92 15:07:46 GMT
Reply-To: ritley@uiucmrl.bitnet ()
Organization: Materials Research Lab


I noticed there were several routines for gamma, log(gamma), etc.
located in the NETLIB public domain software scollection.

You can send the one line mail message "send index" to
NETLIB@RESEARCH.ATT.COM for more details.  You might also
send the one line mail message "send index from fn"
--- fn is the special function collection, wherein I spotted
the gamma function, log(gamma), etc.

There is also public domain statistical software available in the
same way from "statlib@temper.stat.cmu.edu".  

Good luck!
Newsgroups: comp.lang.fortran
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: Porting from CRAY to IBM
Keywords: IBM, conversion, syntax, annoyance, fustration, pocopotapital
Organization: The University of Texas System - CHPC
Date: Mon, 9 Nov 92 06:39:34 GMT

In article <8NOV199215380328@vtcc1.cc.vt.edu> millnerrl@vtcc1.cc.vt.edu (CALLABLE_TPU) writes:
>
[has trouble with]
>	program pargraf (tty,input=tty)
>and
>	program parmela (tty,input,tape10=input,output)
[when proting from Cray to PC]

These are some relicts from old Cyber times when Fortran 77 had not
been invented yet.  They are substitues for OPEN statements with
TAPE10=INPUT meaning Fortran channel 10 to be the input stream, e.g.,
card reader.  I am not absolutely sure what these statements do in your
case.  Except from channel 10 to be stdin, it looks like channel 5 to
be connected to /dev/tty and stdin (parmela).  Most likely you can
ignore these statements and somehow make sure that channel 10 gets
connected to your input, eg., OPEN( 10, FILE =
'something_that''s_your_keyboard' ) (would be SYS$INPUT in VMS, don't
know PCs.)  Hope this gets you started.
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: olaf@alnitak.usc.edu (Olaf Meeuwissen)
Newsgroups: comp.lang.fortran
Subject: Multiple includes
Date: 10 Nov 1992 10:02:18 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: alnitak.usc.edu

Hello,

I have a question concerning include files.  Whenever I include a file twice in
the same subroutine my compiler complains,  understandably.  However,  I really
would like to do this.  Is there a way to include files conditionally?  I mean,
only include it if it is not included already.

The reason  for this is  that I want to put all  the maximum dimensions for the
arrays used in the program in one single file,  so the user knows where to find
them if they have to be changed. Let's call this file `dim.h'. Now I have other
header files, say `lib.h' and `sys.h', that both contain some arrays, so I want
to include `dim.h'.  Then, if I have to include both `lib.h' and `sys.h' in one
subroutine, yes, the compiler starts complaining!  Of course, I get similar re-
sults if I want to include `dim.h' and any of the other header files.

For the moment I'm circumventing this by commenting out the include for `dim.h'
in the other header files and explicitly including it in every subroutine,  but
I find this highly inelegant.  Does someone have any suggestions on how to pro-
gram a conditional include? They are more than welcome at olaf@alnitak.usc.edu.

Thanx,
     ____               ___
    / __ \ /\          / __\  Olaf Meeuwissen   (e-mail: olaf@alnitak.usc.edu)
   / / / // /____    _/ /     Dept. of Chemistry, Univ. of Southern California
  / / / // // __ \  /  _/     ------------------------------------------------
 / /_/ // // /_/ /  / /       Predestination was doomed from the start.
 \____//_/ \_____\ /_/                                                 -- N.N.
Newsgroups: comp.lang.fortran,comp.lang.pascal
From: kraska@fmsrl7.srl.ford.com (Marvin P. Kraska)
Subject: Re: Pascal to FORTRAN translator needed (NOT)
Summary: cross link modules under VMS
Keywords: pascal, fortran, converter, translator
Organization: Ford Motor Company Research Labs, Dearborn, MI
Date: Wed, 11 Nov 1992 21:43:19 GMT



    Thanks to all who responded - cross-linkage of modules compiled
under different VAX languages is supported directly.  (Unfortunately,
the Pascal code is not _true_ VAX Pascal, but close enough for this
application.) Sorry about wasting bandwidth - and many thanks to all 
who pointed out the simple solution. 

	Marv
-- 
#include <std/disclaimer.h>-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#  Marvin P. Kraska #
# Ford Motor Research Laboratory                   kraska@fmsrl7.srl.ford.com #
# Powertrain Systems & Controls Engineering                    (313) 337-5348 #
#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- My SHO Played in Peoria! #
From: ctrbdo@iapa.uucp%mailhost.ecn.uoknor.edu (bryan d oakley)
Newsgroups: comp.lang.fortran
Subject: Re: Correction! Re: Fortran Forever?
Date: 12 Nov 92 22:55:56 GMT
Organization: FAA / Mike Monroney Aeronautical Center

Deja Vu!  Just a few moments ago in comp.lang.c someone asked the
merits of C vs. FORTRAN.  I'm not going to go over THAT again...

I'm a FORTRAN programmer at heart, but do C when the problem lends
itself to a solution in C.  I just recently got GNU c++ (g++) so I'm
checking in to it.  Object orientedness has it's place in the world,
but from what I read c++ is a poor imitation of real object oriented
programming (ask any lisp or smalltalk programmer).  My advice (you
get what you pay for...:-): Learn them all, then use the one best
suited for the problem.  Gotta write a math library?  Use FORTRAN.
Deal with system level stuff?  C is great.  Windows?  C or C++.  Don't
use a hammer when the job requires a screwdriver.  

People who swear C should be used for all tasks reminds me of the
quote (and I paraphrase) "to a child with a hammer, everything looks
like a nail".

-- 
----------------------------------------------------------------------
Instrument Approach Procedures Automation              DOT/FAA/AMI-230
----------------------------------------------------------------------
Bryan D. Oakley                    ctrbdo%iapa@mailhost.ecn.uoknor.edu
Newsgroups: comp.lang.fortran,comp.sys.hp
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Weird HP compiler warning
Organization: Department of Chemistry, University of Toronto
Date: Tue, 10 Nov 1992 19:36:35 GMT

     I usually like my compilers to give me a lot of warnings, even when
they are most likely useless.  In this case however, I have run across
one warning whose meaning I cannot fathom.  Consider the following short
program:

	  double precision h,nexth,err,d2fex
	  h = 1.d0
	  err = 10.d0
	  d2fex = 123.d0
          nexth = min(h,sqrt(12.d0*err/d2fex))
	  write(*,*)nexth
	  END

For this piece of code, the compiler produces the warning

Warning on line 5 of weird.f: Argument has same name as INTRINSIC function

Of course the argument has the same name as an intrinsic!  The argument
IS an intrinsic!  Am I going to get this silly warning every time I put
one intrinsic inside another?  My only comfort is that the program
executes correctly despite a warning which, to me at least, seems to
suggest that the compiler didn't get it.
     If anyone on HP's compiler team is reading this, I would very much
like to know what the rationale behind this strange warning is.  If
anyone else can actually think of a reason why such a warning should be
issued, I would very much like to hear it.
     HP's compiler produces plenty of other warnings which no other sane
compiler does, but at least I can see some sort of warped logic
to most of the others I've seen so far.  (There's an EXTERNAL warning
which annoys me, but I think I understand why it's issued.)  This one
baffles me.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: unformatted output
Organization: Los Alamos National Laboratory
Date: Tue, 10 Nov 1992 19:27:36 GMT

In article <18290@ksr.com>, tim@ksr.com (Tim Peters) writes:
|> [...]
|> Agree that an implementation is free to do less-than-perfect I/O
|> conversions for large numbers, but the conversions have to be accurate
|> enough in every case so that read(write(x)).eq.x always holds under round-
|> to-nearest.  From section 5.6 (Binary <-> Decimal Conversion) of 754-
|> 1985: [...]

All correct.  Unfortunately, the Fortran standard does not conform to
IEEE (in fact, it conflicts with it in some places - like with regard
to negative zero).  And the Fortran standard does not require the same
conversion accuracy as the IEEE floating point standard.  I raised
this very point about conversion in my public review comments and
the response was that such issues were beyond the scope of the
committee.  In other words, you're at the mercy of the implementor.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: hugunin@augustus.mit.edu (James Hugunin)
Subject: Fortran 90 Compiler for Sparc
Reply-To: hugunin@mtl.mit.edu
Organization: Massachvsetts Institvte of Technology
Date: Sat, 7 Nov 1992 19:44:44 GMT


Does anyone out there know where I could purchase (or ftp) a Fortran 90  
compiler for Sun Sparcs?

Please reply via email to hugunin@mtl.mit.edu

Thanks for your help.
Newsgroups: comp.lang.fortran
From: jchauvin@netcom.com (John H. Chauvin)
Subject: Whats the difference between STATIC variables and SAVE variables?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 7 Nov 1992 16:18:30 GMT

Is there a difference between variables defined as STATIC and those defined
with the save statement? How can I tell if a program requires the compiler
option STATIC? How does the STATIC option effect program execution speed?
Should I try and avoid using it?

Thanks,

jchauvin@netcom.com
-- 
John H. Chauvin jchauvin@netcom.COM
Netcom - Online Communication Services San Jose, CA
From: millnerrl@vtcc1.cc.vt.edu (CALLABLE_TPU)
Newsgroups: comp.lang.fortran
Subject: Porting from CRAY to IBM
Keywords: IBM, conversion, syntax, annoyance, fustration, pocopotapital
Date: 8 Nov 92 20:38:00 GMT
Organization: Virginia Tech, Blacksburg, Virginia
News-Software: VAX/VMS VNEWS 1.41


	Greetings.  I am porting a rather large program from a cray to an IBM
486 pc for transportability.  Fortunately, thanks to the skill of the origional
programmer and the versatility of MS Fortran 98% of it goes straight in.  
Most of the errors followed the 22 rule (simple errors tend to wander off the 
line on which they actually occur by 11 in either direction, useful when you 
get syntax errors on comment cards) and were easy to fix.  There is a slight 
operating system incompatability.  The program statement in the origional body 
includes parameters which MS DOS doesn't like or give any clue as to what to do
with it.  I think that they are parameters transferred from the dos command 
line to the program or pointers for the program to access data.  They are:
	program pargraf (tty,input=tty)
and
	program parmela (tty,input,tape10=input,output)
Any help on what to do with these things would be greatly appreciated.

	Cheers!
		Robert Millner

Newsgroups: comp.lang.fortran
From: gl8f@fermi.clas.Virginia.EDU (Greg Lindahl)
Subject: Re: unformatted output: << SUMMARY >>
Organization: Department of Astronomy, University of Virginia
Date: Thu, 12 Nov 1992 00:11:06 GMT

In article <1992Nov11.130931.2171@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:

>No!  Think of a direct-access file as an array on disk.
>Indices are not _stored_ with array elements, they are just used
>to calculate their addresses.  Likewise, there is no need
>to store record numbers with the records.

This is the way most fortran implementations do it, but they don't
HAVE to do it this way. In addition, we need to watch out what we mean
by "hole" -- unixoids sometimes use this to refer to parts of a file
which can be read but don't exist anywhere on disk. You make a unix
disk hole by writing a few bytes, seeking forward for many bytes, and
writing a few more bytes.
Xref: sparky comp.lang.fortran:4225 comp.lang.c:16082
From: chrism@col.hp.com (Chris Magnuson)
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: Re: Need Fortran->C converter!
Date: 6 Nov 92 14:36:22 GMT
Article-I.D.: col.1992Nov6.143622.26392
Organization: HP Colorado Springs Division


  Never mind, I got it now!

  Thanks.
Newsgroups: comp.lang.fortran
From: rolfe@dsuvax.dsu.edu (Tim Rolfe)
Subject: Re: Fortran Forever?
Organization: Dakota State University
Date: Wed, 11 Nov 1992 19:17:12 GMT

I clipped the quote from the advertizing mailing for . . . something . . .
from W.H.Freeman (reading the back of the clipping):

"I don't know what the computer language of the year 2000 will look like,
but I know that it will be called Fortran."  --- Tony Hoare
-- 
                                              --- Tim Rolfe
                                           rolfe@dsuvax.dsu.edu
                                            ROLFE@SDNET.BITNET
Xref: sparky comp.lang.fortran:4286 comp.os.vms:17798
From: mdlcpgs@lhn.gns.cri.nz
Newsgroups: comp.lang.fortran,comp.os.vms
Subject: Turning VAX FORTRAN IOSTAT returns into VMS status codes?
Date: Wed, 11 Nov 92 21:58:16 GMT  
Organization: Institute of Gelogical & Nuclear Sciences, New Zealand.

Hi. I wonder if anyone can tell me how to turn a VAX FORTRAN
IOSTAT status return value into a VMS status for signalling
by LIB$SIGNAL?  I cant in this application use ERRSNS because
the error of interest may not be the last io transaction on
the file at the time when I want to signal.
	Thanks, Phil
From: ee161wcc@sdcc15.ucsd.edu (Biju Zachariah)
Newsgroups: comp.lang.fortran
Subject: Obscure Fortran
Keywords: Internal Libraries
Date: 10 Nov 92 07:24:25 GMT
Distribution: usa

Hello,
	Does anyone know the phone # for Language Systems Fortran?
This version of Fortran runs on the Macintosh computers. If someone
has information on this version of fortran please mail
dlau@omega.ucsd.edu. Thanks,
					David Lau
.

Newsgroups: comp.lang.fortran
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: Whats the difference between STATIC variables and SAVE variables?
Organization: MacNeal-Schwendler Corp.
Date: Wed, 11 Nov 92 17:10:06 GMT

In article <1992Nov9.190426.13544@photon.com> wmc@photon.com (Bill Cornette) writes:

...Context removed...
>
>	Obviously (at least to me), STATIC (when not required) takes extra 
>execution time.  The code must save all variables in a stack somewhere and
>reinitialize all variables whenever entering a routine.  I would avoid
>it in all home-grown programs for this reason, but as noted above, you
>may want to use it routinely for all imported codes.
>

STATIC will assign fixed locations for each variable in the routine, i.e.
stack IS NOT used.  The problem is that each routine compiled STATIC will
carve out its own chunk of memory to hold its variables during the 
life of the program.  *Reinitialization* is not done.  As a result,
if the routine is not currently active, or is not a parent of the
currently active routine, its variable space is sitting unused.

Your *understanding* of the mechanism is a little flawed.

Regards,
DNL

                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES;

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
Newsgroups: comp.lang.fortran