HDTenEightyP/NetNews huggingface dataset:
From: iott@rtsg.mot.com (Joel K. Iott)
Subject: Z'hexno' gives compilation errors
Organization: Motorola Inc.
Date: Thu, 5 Nov 1992 16:37:55 GMT


I am trying to compile the following file on an Apollo workstation:

      SUBROUTINE VT100 (CURSOR, LCURSOR)
C
C     CURSOR CONTROL CHARACTERS FOR A VT100 TERMINAL
C
      INTEGER ZERO, SEMI, H
C
      INTEGER*4 CURSOR(10,22), LCURSOR(22), CDATA(22), LCDATA(22),
     1 BUFFER4(2)
C
      LOGICAL CURRADDR
C
      DATA ZERO/Z'30'/, SEMI/Z'3B'/, H/Z'48'/
      DATA CDATA/
     1 Z'1B5B4800',Z'1B5B4100',Z'1B5B4200',Z'1B5B4400',Z'1B5B4300',
     2 Z'1B5B0000',Z'1B5B3652',Z'1B5B324A',Z'00000000',Z'1B5B304B',
     3 Z'1B5B304A',Z'00000000',Z'00000000',Z'00000000',Z'00000000',
     4 Z'00000000',Z'00000000',Z'00000000',Z'07000000',Z'09000000',
     5 Z'0D000000',Z'0A000000'/
      DATA LCDATA/3,3,3,3,3, 2,4,4,0,4, 4,0,0,0,0, 0,0,0,1,1, 1,1/

...etc.

and get the following errors.  Any help would be appreciated.


f77   -c vt100.f
vt100.f:
(00012)       DATA ZERO/Z'30'/, SEMI/Z'3B'/, H/Z'48'/
**** Error #224 on Line 12: [DATA ZERO/@Z] symbolic name of constant expected
(00018)      5 Z'0D000000',Z'0A000000'/
**** Error #224 on Line 18: [          @Z] symbolic name of constant expected

Thanks
Joel
From: fairfield@slacvx.slac.stanford.edu
Newsgroups: comp.lang.fortran
Subject: Re: Whats the difference between STATIC variables and SAVE variables?
Date: 10 Nov 92 07:03:08 GMT
Article-I.D.: slacvx.1992Nov9.230308.1
Organization: Stanford Linear Accelerator Center

In article <BxHG3I.M8r@ux1.cso.uiuc.edu>, ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
> In article <davidm.721341404@voltaire>, davidm@voltaire.Rational.COM (David Moore) writes:
> |>
> |>[ ... good reasons for using SAVE rather than the compilation flag. ]
> |>
> |>REMARKS:
> |>
> |>I have seen programs which assume that parameters passed once will remain
> |>bound on subsequent calls to entry statements which lack those parameters.
> |>For example, this is sometimes used to allocate memory dynamically. When you
> |>find such a program, locate the original card deck, drop from the top of a tall
> |>building, and see if you can erase all the disk copies before the deck hits
> |>the ground (hint; remove the rubber bands)
> 
> if you use SAVE, what's wrong with this technique ?
> you can do poor man's "packages".  i find them very useful when you
> have data that you do not want to expose to the whole world, and you want
> to act on them in many ways.  example:
> 
> 	call histogram_initialize(n,xmin,xmax)
> 	...
> 	do i=...
> 	    ...
> 	    call histogram_accumulate(x(i))
> 	    ...
> 	enddo
> 	call histogram_output
> 		
> and the histogram array (SAVEd, of course) is local to the 'histogram' 
> package, which is a single routine with three entry points.

    Sorry, you've missed the point (reread David M.'s paragraph): 
The problem is NOT with having different arguments (and numbers of them)
for different entry points, nor with SAVE'ng and sharing _local_ variables
between the entry points.  The problem is with SAVE'ng the argument itself.
Your example is perfectly fine but does not address the objection...

		Cheers, Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
From: ritley@uimrl7.mrl.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: is there a PD s/w library for IMSL-like routinesin F77??
Date: 11 Nov 92 15:10:48 GMT
Reply-To: ritley@uiucmrl.bitnet ()
Organization: Materials Research Lab


Actually there is quite a bit of matrix manipulation software available
from NETLIB.  You can send theo one-line mail message "send index"
to NETLIB@RESEARCH.ATT.COM" for more information.

Statistical software is similarly available from STATLIB , 
STATLIB@TEMPER.STAT.CMU.EDU
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: unformatted output: << SUMMARY >>
Organization: Los Alamos National Laboratory
Date: Fri, 6 Nov 1992 21:07:29 GMT

In article <1992Nov4.160112.26525@chpc.utexas.edu>, michael@chpc.utexas.edu (Michael Lemke) writes:
|> [...]
|> Doesn't have the record *number* to be stored at some place as well?  
|> Nothing stops you from doing
|> 
|>          open( ,.... access='direct', .... )
|>          write( ..., rec=777 ) data
|>          write( ..., rec=32 ) mode_data
|>          close( ... )
|> 
|> which gives you just two records of data and lots of `holes'.  Or am I
|> missing something?

The standard doesn't actually *say* whether writing a file this way
is legal or not.  That is, if you write a record number which is 
well beyond the present file length, what happens.  The standard
it silent on this question.  *MOST* implementations will simply
extend the file as necessary and leave the intermediate record
positions unchanged (that is, containing whatever the system
patterns the disk with when you extend a file - if the system
does this important operation!).

-- 
J. Giles
From: JRowe@cen.ex.ac.uk (J.Rowe)
Newsgroups: comp.lang.fortran
Subject: Re: flushing output in f77
Date: 13 Nov 92 13:07:16 GMT
Organization: Computer Unit. - University of Exeter. UK

In article <141324@lll-winken.LLNL.GOV> sterne@dublin.llnl.gov (Philip Sterne) writes:

>   Is there a clean standard-conforming way of emptying the write
>   buffer for a unit in f77?  

Standard conforming? No. But what we do here in the Physics Department at
Exeter is to have a tiny c routine:

#include <stdio.h>
void flushout()
{
  fflush(NULL);
}

which we can compile to an object file and then link to our fortran.
It seems to work fine under SunOS, ConvexOS, AIX and HP-UX.  Some OSs
demand an underscore to be added to the routine name in the c source,
I can't remember whether it goes on the beginning of the name or the
end.

John.
Newsgroups: comp.lang.fortran
From: pfennige@scsun.unige.ch (PFENNIGER Daniel)
Subject: Re: ALGAMA function, optimization question
Organization: University of Geneva, Switzerland
Date: Fri, 13 Nov 1992 08:17:50 GMT

In article <92317.150302HDK@psuvm.psu.edu>, H. D. Knoble <HDK@psuvm.psu.edu>
sends subroutines about the DGAMMA/DLOGAM functions.

The DLGM function reads:

>       DOUBLE PRECISION FUNCTION DLGM(W)
> C===Companion function for DGAMMA and DLOGAM.
>       DOUBLE PRECISION C(20), W,W2,PRESUM,CONST,DEN,SUM
>       INTEGER I
>       C(1)=1.D0/12.D0
>       C(2)=-1.D0/360.D0
>       C(3)=1.D0/1260.D0
>       C(4)=-1.D0/1680.D0
>       C(5)=1.D0/1188.D0
>       C(6)=-691.D0/360360.D0
>       C(7)=1.D0/156.D0
>       C(8)=-3617.D0/122400.D0
>       C(9)=43867.D0/244188.D0
>       C(10)=-174611.D0/125400.D0
>       C(11)=77683.D0/5796.D0
>       C(12)=-236364091.D0/1506960.D0
>       C(13)=657931.D0/300.D0
>       C(14)=-3392780147.D0/93960.D0
>       C(15)=1723168255201.D0/2492028.D0
>       C(16)=-7709321041217.D0/505920.D0
>       C(17)=1516286977551.D0/396.D0
>       C(18)=-26315271553053477373.D0/2418179400.D0
>       C(19)=1542102059911661.D0/444.D0
>       C(20)=-261082718496449122051.D0/21106800.D0
>       CONST=.91893853320467274178032973640561763986139747363778D0
> C---CONST=DLOG(SQRT(2*PI))
>       DEN=W
>       W2=W*W
>       PRESUM=(W-.5D0)*DLOG(W)-W+CONST
>       DO 1 I=1,20
>         SUM=PRESUM+C(I)/DEN
>         IF(SUM.EQ.PRESUM) GOTO 2
>         DEN=DEN*W2
> 1     PRESUM=SUM
> 2     DLGM=SUM
>       RETURN
>       END

My question to experts in optimization is: 
What is the better way to initialize such an array C of constants
1) DATA statement
2) PARAMETER statement
3) the above example as an optimizing compiler anyway detects that 
   C and CONST are constant. 

	Daniel Pfenniger
Organization: Ryerson Polytechnical Institute
Distribution: na
Date: Wednesday, 4 Nov 1992 18:35:38 EST
From: <ACPS7188@RyeVm.Ryerson.Ca>
Newsgroups: comp.lang.fortran
Subject: Looking for software to run Fortran in P.C

  Hello all!
 I'm looking for a software to run Fortran in my P.C, which is IBM compatible
and has 4 MB RAM.  If anyone has it for sale, please let me know the price.
In the case that you don't want to sale it, would you kind copy it for me..
I'll pay all the expense.. or I can send my disks to you..  Just let me know
in details such as: how many disks, what kind of disks, how much RAM required
for running it..
 Please mail to me at ACPS7188@RyeVm.Ryerson.Ca.   Thanx in advance!!
Newsgroups: comp.lang.fortran,comp.lang.c
From: pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl)
Subject: Re: Need Fortran->C converter!
Organization: Technical University of Munich, Germany
Date: Sat, 7 Nov 1992 08:25:26 GMT

chrism@col.hp.com (Chris Magnuson) writes:

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

There is one in AENEAS.MIT.EDU (18.71.0.38) in the dir /pub/gnu
(I believe).

Peter Loibl
pal@regent.e-technik.tu-muenchen.de
Newsgroups: comp.lang.fortran
From: jdavis@wam.umd.edu (Joel H. Davis)
Subject: ALGAMA function
Organization: University of Maryland, College Park
Date: Wed, 11 Nov 1992 04:35:58 GMT


	A friend of mine has recently transferred some Fortran code from a
mainframe to a PC to be run under MS FORTRAN.  When he tries to compile it,
however, he gets an unresolved external reference error (or some such message,
the error was reported to me thirdhand) for the ALGAMA (A log[gamma]) function.
Apparently it was available using the compiler on the mainframe, but MS FORTRAN
does not support it.  
 
	Anyway, I was wondering if it would be possible to find the source for
this function or just get it as part of a separate library.  The program ran
and was used extensively on the mainframe he had, so it seems that this 
missing function is the only problem.


Joel.


Newsgroups: comp.lang.fortran
From: mazzucch@ghost.dsi.unimi.it (massimo mazzucchi)
Subject: FortranTOc
Keywords: info
Organization: Computer Science Dep. - Milan University
Date: Wed, 11 Nov 1992 17:36:54 GMT


Hi 

i am Max from Milan

i will know if exist a traslator (for pc or unix machine)

fortran to c your name and price

Thanks for your help



--------------------------------------------------------------------------------
!  Massimo Mazzucchi                         address    e-mail                !
!  University of State                       mazzucch@ghost.dsi.unimi.it      !
!  Departement of Computer Science                                            ! 
!  Via Comelico, 41 -  20133 MILAN ITALY                                      !
 -------------------------------------------------------------------------------
From: dtm@castle.ed.ac.uk (D Muxworthy)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 Standard document
Date: 6 Nov 92 13:45:25 GMT
Organization: Edinburgh University

In article <KHB.92Nov5191219@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM
(Keith Bierman fpgoup) writes:
>
>From the comp.lang.fortran.faq
>
>Q1) Where can I get a copy of the Fortran 90 Standard?

[list of addresses and info on prices deleted]

The official ISO price from their Geneva office is indeed SFR 125.  Readers
in the UK, before ordering it through BSI, might like to know that the BSI
price for exactly the same document is #186.40.  Repeated requests to BSI
Publications Department to explain the reasons for the difference have
failed to produce anything approaching a satisfactory answer.
David Muxworthy
(BSI Fortran convenor)
From: sterne@dublin.llnl.gov (Philip Sterne)
Newsgroups: comp.lang.fortran
Subject: flushing output in f77
Keywords: flush,i/o
Date: 12 Nov 92 22:10:39 GMT
Reply-To: sterne@dublin.llnl.gov (Philip Sterne)
Organization: Lawrence Livermore National Laboratory

Is there a clean standard-conforming way of emptying the write
buffer for a unit in f77?  

Problem:  Iterative procedure acting on a large vector.  Time
	  per iteration can be as long as a day or so.  
	  Currently only write the converged vector at the
	  end of the job.

Need:	  Transportable way of writing the vector to disk at
	  intermediate steps so I can restart the calculation
	  and not lose completed iterations.  Ideally write
	  out the vector to disk, rewind, overwrite with 
	  the next vector on completion of the next iteration, 
	  and so on.  I need some way of flushing the write 
	  buffer so the file contains the entire vector.

I could use flush, but that appears to be architecture dependent.

At the moment, the best (portable) plan I can come up is to open, 
write and close some file for each iteration.  

Is there a better way?  For example, does a REWIND force a flush?
Or is this vendor dependent?  The standard doesn't seem to address 
this question.  

Thanking you in anticipation,
				Phil

--
Philip Sterne 				|    sterne@dublin.llnl.gov
Lawrence Livermore National Laboratory	|    Phone   (510) 422-2510
Livermore,  CA 94550			|    Fax     (510) 422-7300
From: tim@ksr.com (Tim Peters)
Newsgroups: comp.lang.fortran
Subject: Re: unformatted output
Date: 6 Nov 92 16:00:32 EST
Organization: Kendall Square Research Corp.

In article <KHB.92Nov3190132@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes:
>In article <Bx5s1u.C0J@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
> > IEEE standard guarantees that binary->decimal->binary is the identity
> > if at least as many significant digits as specified the standard are
> > written out.  I believe it is 17 digits for double and 9 digits for
> > single.
>
> Actually, a close reading of the standard reveals that an
> implementation is free to do relatively poor rounding for large
> numbers; this destroys the identity.

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:

	When rounding to nearest, conversion from binary to decimal and
	back to binary shall be the identity as long as the decimal
	string is carried to the maximum precision specified in Table 2,
	namely, 9 digits for single and 17 digits for double.

Print fewer than that many decimal digits, and the identity won't hold in
some cases even if all conversions are rounded perfectly; print at least
that many decimal digits, and perfect rounding isn't needed to make the
identity hold for all cases.

sometimes-compromise-just-increases-confusion-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
tim@ksr.com,         ksr!tim@uunet.uu.net
From: napier@cs.ucsd.edu (Jim Napier)
Newsgroups: comp.lang.fortran
Subject: IEEE standards
Date: 11 Nov 92 16:42:30 GMT
Article-I.D.: network.1drd5mINN143
Distribution: world
Organization: AMES Dept., UC San Diego
NNTP-Posting-Host: sierra.ucsd.edu


I work for the mechanical engineering department at UCSD where the bulk of
our graduate level programming is in Fortran. We have an network of Suns
running the latest rev of Sun's Fortran compiler. This compiler conforms
to IEEE standards supposedly. I have 2 problems-

1) Many grads have spent years working on other systems that didn't support
   IEEE and don't know how to deal with the exceptions. Programming methods
   and old programs that have worked for them previously generate IEEE errors
   when compiled and run on the Suns. 

2) Not being a Fortran progammer myself I have been unable to help them much
    except to point to man pages or hardcopy documentation that discusses
    IEEE standards and exceptions. Unfortunately none of the documentation does
   a sufficient job of presenting a proper beginner's overview.

Can anyone point me to references regarding how to write Fortran programs that
avoid IEEE errors or in general discuss what the IEEE requirements are and
exactly what some of the errors mean? Any personal experiences and caveats
are welcome also.

Thanks for any help.

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Jim Napier
Systems Administration
Applied Mechanics & Engineering Sciences Dept.
UC San Diego
(619)534-5414
napier@ames.ucsd.edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Weird HP compiler warning
Organization: University of Jyvaskyla, Finland
Date: Wed, 11 Nov 1992 13:32:05 GMT

In article <1992Nov10.193635.2736@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
> ...
>	  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.

No, the argument is NOT an intrinsic, but the result returned
from the call of an intrinsic function.
Thus the compiler is really badly off the track.
Perhaps prepending '+' before 'sqrt' would eliminate the annoying message?

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.fortran,comp.sys.hp
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Weird HP compiler warning
Followup-To: comp.sys.hp
Organization: Department of Chemistry, University of Toronto
Date: Wed, 11 Nov 1992 02:27:06 GMT

In article <1992Nov10.190621@helix.nih.gov> rvenable@helix.nih.gov
(Richard M. Venable) writes:
>In article <1992Nov10.193635.2736@alchemy.chem.utoronto.ca>,
>mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
>|> Warning on line 5 of weird.f: Argument has same name as INTRINSIC
>function
>
>Hmmm.  I tried the above code on an HP/Apollo workstation and on an
>HP9000/750
>and didn't get the above error message on either system.

     Do you use the +ppu option?  I wonder if this is an unintended
side-effect of that?

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca

P.S.:  Note that I have redirected followups to comp.sys.hp since this
       is becoming very HP specific.
Newsgroups: comp.lang.fortran
From: dafnioti@cae.wisc.edu (Petros Dafniotis)
Subject: Re: Lahey fortran
Organization: U of Wisconsin-Madison College of Engineering
Date: 9 Nov 92 23:19:40 CST

In article <1992Nov9.234221.11019@ms.uky.edu> bud@ms.uky.edu (William K Glunt) writes:
> I'm interested in getting a fortran compiler for a DOS machine
>that can use more than 640K of ram.  Anyone know the current status
>of the Lahey offerings? How about educational discounts?  Any information
>will be appreciated.

  LAHEY EM/32 fortran is -I guess- the product you want. I have only used the
Lahey F77L v4.0 compiler (this one has the 640Kb limit) and I only have
*EXCELLENT* comments/opinions for it. What was really *AMAZING* was that
it was shipped with a bunch of the best utilities, written from other companies
who were specialized in these systems. For example, if you have used the
MS-FORTRAN v5.x you know how slow is the linker; well, Lahey was shipped with
OPTLINK a professional linker whose link times were dazzling (closer to Turbo
Pascal speed of linking, and you know how fast is TP).

  Now, as for the EM/32, it contains - as the Lahey people have told me-
(i) all possible utilities,
(ii) PharLap extender; this is the *BEST* DOS extender; the only "extender"
     for PCs which is better is OS/2 v2.0 (which is of course a real OS, not
     a toy). Anyhow PharLap is DPMI and VCPI comliant; hence, you can run
     Lahey executables under Windows (due to DPMI).
(iii) educational price (Lahey+Extender) was 2 months ago: $750
      (quite expensive).

  Street price (e.g. Programmer's shop) was around $1100. Lahey asks you
for an acknowledgment in your PhD/Master thesis for the educational price.
You could also consider Watcom 386 compiler (it is much cheaper); see FAQ
for more info.

					Petros Dafniotis
					Chem Engr Dept, UW-Madison
				e-mail: dafniotis@chera6.che.wisc.edu
Newsgroups: comp.lang.fortran
From: KARGL@rzmain.rz.uni-ulm.de (ComRam)
Subject: Problem using $GETUAI
Organization: Chaos Computer Club Ulm
Date: Thu, 5 Nov 1992 18:42:35 GMT
X-News-Reader: VMS NEWS 1.24

Starting with the problem of finding the Real Name to a given Account I
first wrote a little C program which does the job and works quite fine.
Then I started to do the same thing in FORTRAN (Just for fun:-) and this
one refuses to work. The SYS$GETUAI returns a SS$_BADCONTEXT. Can anyone
tell me whats wrong with this thing?

--------------------------------------------------------------------------

* FINDREAL.FOR --- Find Owner Name --- (C) 1992 by ComRam

	PROGRAM Findreal

	IMPLICIT NONE
	
	INCLUDE '($JPIDEF)'
	INCLUDE '($UAIDEF)'

	CHARACTER*12   Username
	CHARACTER*32   Owner

	INTEGER Usernamelen,
	1	Ownerlen,
	2	Status,
	3	I

	INTEGER SYS$GETJPI,
	1	SYS$GETUAI

	STRUCTURE /ITMLST/
	   INTEGER*2 BUFLEN,
	1            CODE
	   INTEGER*4 BUFADR,
	1            RETLENADR
	END STRUCTURE
	
	RECORD /ITMLST/ JPI_LIST,
	1		UAI_LIST
	
	JPI_LIST.BUFLEN       = 12
	JPI_LIST.CODE         = JPI$_USERNAME
	JPI_LIST.BUFADR       = %LOC (Username)
	JPI_LIST.RETLENADR    = %LOC (Usernamelen)

	Status = SYS$GETJPI (,,,JPI_LIST,,,)
	
	WRITE (*,*) '*',Username(1:Usernamelen),'*'

	DO I=Usernamelen,1,-1
	   IF (Username(I:I) .NE. ' ') GOTO 10
	ENDDO
10	CONTINUE

	WRITE (*,*) 'I : ',I,'  Username : *',Username(1:I),'*'
	
	UAI_LIST.BUFLEN       = 32
	UAI_LIST.CODE         = UAI$_OWNER
	UAI_LIST.BUFADR       = %LOC (Owner)
	UAI_LIST.RETLENADR    = %LOC (Ownerlen)

	Status = SYS$GETUAI (0,0,%DESCR(Username(1:I)),UAI_LIST,0,0,0)

	WRITE (*,*) 'Status : ',Status,'  Owner : ',Owner

	STOP
	END

------------------------------------------------------------------------------



------------------------------------------------------------------------------
 ComRam  (in real life : Frank Kargl)    Student consultant for programming
 IP            : COMRAM@RZ.UNI-ULM.DE    University of Ulm          Germany
 DECnet(Belwue) : 50186::KARGL           All statements posted above are
 Bitnet       : KARGL@DULRUU51.BITNET    my personal oppinion ONLY !
------------------------------------------------------------------------------
    God created INTEGERS ... everything else was defined by mathematicians
From: dbs900@anusf.anu.edu.au (David Singleton)
Newsgroups: comp.lang.fortran
Subject: Fortran 90 Standard document
Date: 5 Nov 1992 22:06:38 GMT
Organization: ANU Supercomputer Facility
Distribution: world
NNTP-Posting-Host: 150.203.5.6
Originator: dbs900@eliptix



Could someone please post the details of where to order a copy
of the Fortran 90 standard from and the cost of same?

Thanks,
David
-- 
----------------------------------------------------------------------------
Dr David Singleton               ANU Supercomputer Facility
D.Singleton@anu.edu.au           Australian National University   
Work Phone: +61 6 249 4389       Canberra, ACT, 2601, Australia