HDTenEightyP/NetNews huggingface dataset:
From: Benoit.St-jean@f159.n167.z1.fidonet.org (Benoit St-jean)
Newsgroups: comp.lang.modula2
Subject: MODULA-2 IN FRENCH
Date: 15 Oct 92 10:28:11 GMT
Article-I.D.: puddle.9293.2ADF2550
Organization: FidoNet node 1:167/159 - XON/XOFF Informatio, Montreal QC

YA>Hello,

YA>I am looking for a Modula-2 compiler well fit for teaching computer science
YA>high school level. I need something with documentation in french langage if
YA>possible ;-) . All suggestions are welcome.

YA>Yves Auger
YA>--- msgedsq 2.0.5
YA> * Origin: Micro-Plus,St-Jerome,Qc (514-431-1267) (1:242/116)

You should take a look at UQAM (Universit du Qubec  Montral).  They
have small "recueils de notes" and "rsum" for their basic programming
courses(in Modula-2).  This is not as complete as a book but they're
fairly good enough for an introduction.  Anyway, a good part of learning
a programming language is done by... programming!  Forgot to say, their
"books" are related to the TopSpeed Modula-2 Compiler...

I would also suggest you to take a look on the Swiss side since Modula-2
was born there!  Maybe Mr. Wirth got popular on the BBS scene and
perhaps(I hope!), good french shareware DOC. or compilers are available
out there...  Send some FidoMail and hope someone from Swiss will read
it and give you a BBS board supporting French-related Modula-2 stuff...
This is not as convenient as buying a book but if you absolutely need
it...

Finally, look at CEGEP Andr-Laurendeau for a "recueil de notes".  I do
not know if they produce one but it is possible since Modula-2 is the
language they use in "Technologies Physiques" and "Microprocesseurs"
studying programs...

Hope this helps...

P.S.  Try calling "Le Camelot" at (514)861-5019
      or fax them at (514)393-4109
Maybe they have(or know) a good Modula-2 franch book...


 * SLMR 2.1a * Encrypted tagline:KDJFGDJF DFKJH IEURQB HF ERHFIUG!!

--  
uucp: uunet!m2xenix!puddle!167!159!Benoit.St-jean
Internet: Benoit.St-jean@f159.n167.z1.fidonet.org
From: maurel@dbulm1.uucp
Newsgroups: comp.lang.modula2
Subject: Re: Modula-2 may be dead, but long live Oberon-2
Date: 6 Oct 92 15:01:48 GMT
Organization: Daimler-Benz, Institut f. Informationstechnik

In article <1992Sep18.201959.6441@glv.uucp>, andersen@reality (Robert Andersen) writes:
> ...
> What system are you using it on?  Is there a compiler for the NeXT or VAX/VMS  
> systems?
yes
for both machine take contact to
ModulaWare GmbH
Wilhelmstarsse 17
D. 8520 Erlangen
telefon: (09131)208395
fax:     (09131)28205
e-mail:  100023.2527@compuserve.com

bye

guy maurel
DaimlerBenz
Forschungzentrum
Postfach 2360
D.7900 Ulm
Tel: (0731)505-2172
fax: (0731)505-4110
email: maurel@dbulm1.uucp
Newsgroups: comp.lang.modula2
From: fujiki@isct.kyutech.ac.jp (Takeshi Fujiki)
Subject: Let me know about TopSpeed Modula-2
Organization: Information Science Center of Kyushu Inst. of Tech.
Distribution: comp
Date: Mon, 12 Oct 1992 09:27:19 GMT


One of my friend cannot post news,so he ask me to post following.
If you have answer, please send mail to him. His email address is

chackn@alsyskke.kke.co.jp

Thanks you.

----------------------------------------------------------------------
I'm an Ada programmer and also very interested in Modula-2. Recentry
my friend form U.S.A. gave me 'TopSpeed Modula-2'.

But accidentally I lost the 'User's Manual'. I only have 'VID' manual,
'TechKit' manual, and 'Language Tutorial'. But I couldn't find how to
make 'M2.RED' file in these manuals. Many times I saw the description
'see TopSpeed Modula-2 User's Manual' in those.

If anyone knows, please let me know by e-mail or fax. Because I can
not read news.
(I sent the registration card to JPI. But it takes too long time.)

Thank you.

--
/ Yoshimi FUJII           e-mail: chackn@alsyskke.kke.co.jp   /
/ Alsys KKE co. ltd.  TEL 81 45 451 2412 FAX 81 45 451 2419   /
/ Techno-wave 100 16F, 1-1-25, Kanagawa-shin-machi, Yokohama, /
/       J A P A N                                             /
----------------------------------------------------------------------



--
$@F#LZ(J $@7r;N(J (Takeshi FUJIKI)         $@6e=#9)6HBg3X(J  $@>pJs2J3X%;%s%?!<(J
       Information Science Center Kyushu Institute of Technology 
                         E-mail : fujiki@isct.kyutech.ac.jp
From: narti@mintir.new-orleans.la.us (Narti Kitiyakara)
Newsgroups: comp.lang.modula2
Subject: Modula-2 & Windows
Date: Wed, 07 Oct 92 07:53:58 CDT
Organization: Minas Tirith BBS (Public Access Usenet for New Orleans)

>Can anybody tell me if it is possible to write Windows programmes with
>modula-2? And if so, how to go about doing so?

        The Logitech and JPI (I think) compliers are both capable
of Windows programming, but you'll need a resource complier (as
found, for example, in the Microsoft SDK).  I've not been finding
Windows programming as difficult as I expected, but the Windows'
API needs a better cross-reference.

                                        - Narti
From: tchannon@black.demon.co.uk (Tim Channon)
Newsgroups: comp.lang.modula2
Subject: Re: multiple implementations
Date: 11 Oct 92 17:37:12 GMT
Organization: null
ReplyTo: tchannon@black.demon.co.uk
X-Mailer: cppnews $Revision: 1.18 $

> Does anyone know of any good techniques for managing multiple implementation
> modules?  A trivial example is for a Stack to have an array implementation
> and a linked list implementation.   How do you name your files and how do

Pragmas?

  TC. 
    E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
                                
Newsgroups: comp.lang.fortran
From: dafnioti@cae.wisc.edu (Petros Dafniotis)
Subject: MicroWay NDP486 CLEARVIEW debugger problem
Organization: U of Wisconsin-Madison College of Engineering
Distribution: comp.lang.fortran
Date: 8 Oct 92 10:05:52 CDT
Summary: I cannot have EMM386 and debugger working! 

System: 486 PC
Compiler: MicroWay NDP486 with the Ergo extender
Problem: The ClearView debugger does not load (giving the error:
         "Error while altering program segment size"). I have
         found that the problem is caused by the EMM386 expand memory
         manager (I use the one coming with the MS-Windows v3.1).

Did anybody experience this problem? Workarounds? Manuals say nothing.
Thanks in advance,

					Petros Dafniotis
					UW-Madison
From: spxsjm@thor.cf.ac.uk (Mr S J Morris 92)
Newsgroups: comp.lang.fortran
Subject: Re: Problems printing numbers in SUN Fortran
Summary: My problem, not theirs.
Date: 14 Oct 92 08:18:22 GMT
Organization: University of Wales College at Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway


Last week I posted a message to this group describing some problems that
I had with numerical output from a SUN Fortran program. Because the
problem didn't occur when running on a VAX, I suspected that there may
have been a bug in the compiler.

I'm just posting this note to set the record straight: the bug was in my
program, not in the SUN compiler. Granted it was a subtle bug, which
escaped all the normal compile and runtime checks, but nevertheless a
bug. 

Thank you to everybody who replied to my first posting. Full marks to
SUN, two of whose staff were among the first to offer assistance,
including inspection of the source code. Even fuller marks to Melvin
Klassen of University of Victoria, BC, Canada, who also offered to look
at the source code and managed to track down the problem.

Steve Morris.
Department of Physics, University of Wales College of Cardiff.
From: zkdc05@trc.amoco.com (Kelly D. Crawford)
Newsgroups: comp.lang.fortran
Subject: Re: Adjustable arrays
Date: 8 Oct 92 22:22:14 GMT
Organization: Amoco Production Company, Tulsa Research
Originator: zkdc05@church


In article <533@rama.UUCP>, bcs@rama.UUCP (Brian Spollen) writes:
> In article <1992Oct5.171833.16706@magnus.acs.ohio-state.edu>, cpaulse@magnus.acs.ohio-state.edu (Chris D Paulse) writes:
>   Fortran, in its infinite, uh, flexibility, typically allows accessing of 
>   arrays beyond what the declaration indicates, so the array may, in fact,
>   not be adjustable at all.  Hence, declaring the array with a * may not
>   be appropriate (only if the variable involved is an argument to the 
>   subroutine).

You are correct, but don't blame this on Fortran's infinite flexibility.  Many
procedural languages allow it.  Run time bounds checking is expensive.
This is what compiler options and analysis tools are for.

>   For example, the following code will compile (on the Sun and VAX):
> 
>       PROGRAM TEST
>       INTEGER IDUM(1)
>       IDUM(3) = IDUM(1) + IDUM(2)
>       STOP
>       END

The following code also compiles on the Sun:

#include <stdio.h>
void main() {
int *idum;
idum[3] = idum[1] + idum[2];
}

Sorry...just couldn't resist...

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 *** <<<
Newsgroups: comp.lang.fortran
From: steve@agropyron.forests (Steve)
Subject: need help, f77 --> linker problem
Date: Fri, 16 Oct 1992 22:43:25 GMT
Reply-To: steve@agropyron.forests
Organization: Sun Microsystems, Inc.

Hope I'm looking in the right places.

I'm compiling/linking a biological model on a sun sparc ipx.
The code is fortran, using a few of the vms extensions.
compilation goes fine, then linking kicks in. A trace shows it
"accepting" all of my modules and several libraries, then it
complains of the following and dies.

-lF77:
        /usr/lang/SC1.0/libF77.sa.1.4
-lm:
        /usr/lang/SC1.0/cg87/libm.a
-lc:
        /usr/lib/libc.sa.1.6
ld: /l.outa00301: Permission denied 
ld: /l.outa00301: output write error: Bad file number 
Compilation failed
*** Error code 2
make: Fatal error: Command failed for target 

The number in l.outaXXXXX is the process id.
disk space "shouldn't" be a problem.

The linker is being invoked from a makefile via f77 using the following lines:

${MODEL_DIR}/treegro: ${OBJECTS}
        f77 ${OBJECTS} -C -g -u -xl -Qoption ld -t -o ${MODEL_dir}/treegro


any ideas?

-steve

p.s. ignore the reply-to, I live at : steve@agropyron.cfnr.colostate.edu

Thanks!!!

Newsgroups: comp.lang.fortran
From: john@aquarius.unm.edu (John Prentice)
Subject: Re: The Cray YMP fails paranoia arthmetic test?!
Date: Tue, 13 Oct 92 04:51:03 GMT
Organization: Dept. of Physics & Astro, University of New Mexico, Albuquerque
Distribution: usa

In article <1992Oct12.230317.22480@craycos.com> jrbd@craycos.com (James Davies) writes:
>Not to defend Cray arithmetic, but I'd be a little bit leery of a Monte 
>Carlo program that got widely varying results from different random number 
>sequences (or that required that they be non-random, as you seem to be 
>saying ;-)

You would be surprised how common this kind of thing is however.  In the
mid-70's, I worked on porting a bunch of nuclear reactor safety codes 
between machines.  The codes modeled various reactor accidents based on
first principle physics and tried to predict when fuel rods would fail.
One shocking thing was that the same code, run on the same type of CDC computer
but at different installations, would give very different results.  Different
to the extent that with one compiler, you would see rod failure, with another,
you wouldn't.  The source of the discepencies was that different installations
had set different compiler defaults for how to handle rounding.  Kinda spooky.
Whether this was all due to poor numerics that let the errors grow unreasonably
fast or something physical about the nature of reactor fuel rod failure (i.e.,
chaos), I haven't a clue.  I would certainly first consider just bad numerics,
but I can also cite very simple physical systems which would exhibit the same 
behavior due to chaos.  Either way however, these are good examples of the need 
to consider error propagation and growth in numerical methods and to be 
concerned about computer arithmetic.

John
-- 
Dr. John K. Prentice                      
Partner, Quetzal Computational Associates    
3200 Carlisle N.E., Albuquerque, NM   87110-1664
Phone: 505-889-4543  E-mail: john@aquarius.unm.edu -or- jkprent@cs.sandia.gov
From: ljeung@sfsuvax1.sfsu.edu (Lawrence Jeung)
Newsgroups: comp.lang.fortran
Subject: IEEE floating-point arithmetic exceptions
Date: 13 Oct 92 12:19:05 GMT
Organization: San Francisco State University
Originator: ljeung@sfsuvax1.sfsu.edu

I've recently begun running a hydrodynamics code on a Sun Sparcstation, 
But each time I run it, I keep getting the following message:

	Note: the following IEEE floating-point arithmetic exceptions
	occurred and were never cleared; see ieee_flags(3M):
	Inexact; Underflow;
	Sun's implementation of IEEE arithmetic is discussed in the
	Numerical Computation Guide.

I've read the man pages on ieee_flags and the Numerical Computation
Guide, and learned enough to use ieee_flags to clear the exceptions and
even ieee_handler to trap signals (SIGFPE?).  I've also run the code in
the dbx debugger and used the command "catch FPE".  But for some reason,
these techniques work some of the time and are sometimes mutually 
exclusive.  What is happening?  Or what am I doing wrong?

I've also been keeping up with the interesting "paranoia over Cray 
arithmetic".  It seems to me my problem may be related.  One of my
colleagues says most programmers using Suns ignore messages like the
ones I get.  However, in light of the issue over Cray arithmetic, I 
rather not ignore them.  I'm also reserved about my friend's advice,
since he doesn't know much about IEEE arithmetic and doesn't seem to 
mind about the different arithmetic implementations on different 
machines.  Am I worrying too much?

Lawrence Jeung
Newsgroups: comp.lang.fortran
From: rvenable@helix.nih.gov (Richard M. Venable)
Subject: Re: home directory in unix
Keywords: getenv getarg
Reply-To: rvenable@helix.nih.gov (Richard M. Venable)
Organization: National Institutes of Health
Date: Fri, 9 Oct 1992 00:09:15 GMT

The construct ~/dir/file.ext should be resolved properly if you
pass it as a command line argument, and fetch it using the standard
Unix 'getarg' call.

% program  ~/dir/file.ext

	CHARACTER*80 fnam
		:
	CALL GETARG(1,fnam)
	OPEN(20,FILE=fnam, [other options] )

However, if you are getting the filename from UNIT 5 (stdin) or
a script, or as an explicit string, it won't work.  The simplest
solution is to parse the filename, checking for '~' as the first
character, and substitute the text of the enviroment variable HOME
for '~'.

	CHARACTER*80 fnam,tmp
		:
	IF (fnam(1:1).EQ.'~') THEN
	  CALL GETENV('HOME',tmp)
          DO I=1,80
            IF (tmp(I:I).EQ.' ') GOTO 150
          ENDDO
  150	  I=I-1
          fnam = tmp(1:I)//fnam
 	ENDIF

A similar construct may be used to obtain the value (as a string) of
ANY environment variable, by checking for $ as the first char of a
filename.  You usually need to include the f77 option   -lU77   to
search the Unix libraries during the link step for this to work.
From: bcs@rama.UUCP (Brian Spollen)
Newsgroups: comp.lang.fortran
Subject: Re: Adjustable arrays
Summary: non-adjustable arrays
Date: 8 Oct 92 12:25:58 GMT
Organization: Harris Scientific Calculations, Fishers, NY

In article <1992Oct5.171833.16706@magnus.acs.ohio-state.edu>, cpaulse@magnus.acs.ohio-state.edu (Chris D Paulse) writes:
> 
> In some code I'm trying to modify, there are declarations within subroutines
> for arrays of size 1, for instance
> 
>       dimension v(1)
> 
> These arrays seem to be ajustable, as elements with indices greater than 1
  [remainder of original deleted]

  A possibility previously unexpressed here:

  Fortran, in its infinite, uh, flexibility, typically allows accessing of 
  arrays beyond what the declaration indicates, so the array may, in fact,
  not be adjustable at all.  Hence, declaring the array with a * may not
  be appropriate (only if the variable involved is an argument to the 
  subroutine).

  For example, the following code will compile (on the Sun and VAX):

      PROGRAM TEST
      INTEGER IDUM(1)
      IDUM(3) = IDUM(1) + IDUM(2)
      STOP
      END

  Note that IDUM is not an argument.  Also note that this will produce
  very unreliable results when executed, and I advise always matching
  the dimension of a local variable to its possible uses, unless you 
  deliberately intend to give someone else maintenance nightmares in the
  future.
-- 
-----------------------------------------------------------------------------
Brian C. Spollen                        Internet:bcs@sc.harris.com
Harris Corporation EDA Division            PHONE:   716/924-9303 x210
Fishers, New York 14453                 "Taste makes Waist"
Newsgroups: comp.lang.fortran
From: aswx266@chpc.utexas.edu (Michael Lemke)
Subject: Re: Quickie
Organization: The University of Texas System - CHPC
Date: Sun, 11 Oct 92 00:03:35 GMT

In article <EJH.92Oct10160448@khonshu.colorado.edu> ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
>In article <28870@nntp_server.ems.cdc.com> mstemper@ems.cdc.com (Michael Stemper) writes:
>
>   In article <1992Oct8.021427.8589@ecsvax.uncecs.edu>, urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
>   |> In article <1992Oct6.134516.25053@wega.rz.uni-ulm.de>, CCC_KARG@rzmain.rz.uni-ulm.de (ComRam) writes:
>   |> > 
>   |> > How about a little ASSIGN 1 TO n
>   |> >                    WRITE(*,n)
>   |> > 		 1 FORMAT(blubb)
>   |> > 
>   |> 
>   |> There have been two other suggestions:
>   |> Store the formats in character arrays and WRITE(*,fmt(n))  and
>   |> Store the messages in arrays and write them with a common format 
>   |> WRITE(*,'(A)')msg(n). (Please check if there must be a field
>   |> width for the A format item Aw ).
>
>   If no width is specified, the width of the item (trailing blanks and
>   all) will be used.
>
>Yes, I should have done this:
>
>	write(*,*) msg(n)(:lnblnk(msg(n)))
>
>This will only print the message to the last non-blank, i.e. it won't
>print trailing blanks. In this circumstance, using '(a)' and * have
>the same effect. 

Not always.  The star will always work but with the A format the first 
character of MSG might be interpreted as a carriage control character.  
This is system dependent.

-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: smits@sci.kun.nl (JMM Smits)
Newsgroups: comp.lang.fortran
Subject: SALFORD FTN77/486: fastest access to video mem???
Summary: Wanted: fastest access to video memory using SALFORD FTN77/486
Keywords: SALFORD-FTN77/486 video-mem
Date: 12 Oct 92 13:49:04 GMT
Organization: University of Nijmegen, The Netherlands


Who can help me? I want to copy a block of data AS FAST AS POSSIBLE
to the video memory of an MSDOS-486 using the full potential of
SALFORD FTN77/486, including, if necessary, CODE ... EDOC. Undoubtedly
someone out there has solved this problem before......
 
If wanted send mail to     smits at wn3.sci.kun.nl    or
                         U625021 at hnykun11.urc.kun.nl
Newsgroups: comp.lang.fortran
From: kehcheng@netcom.com (Keh-Cheng Chu)
Subject: Re: passing arrays as parameters
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 16 Oct 1992 17:12:27 GMT

In article <16OCT92.07182890.0071@VM1.MCGILL.CA> UBCF@MUSICB.MCGILL.CA (UBCF) writes:
>
>     I've got a bit of a problem with a program I'm working on. I have
>to use some external routines (ie LINPACK) to solve a set of equations
>in a program I'm writing using the VSFORT 2.0 compiler, which implements
>the F77 standard. I'm trying to solve Ax=b, where A is a matrix and x
>and b are vectors. I have to pass A and b to the routines, which then
>solve for x. The problem is that I'm trying to write a general purpose
>routine, since the size of x can vary anywhere from 5 to 100. At the
>start of the program I tried to declare
>
>       DIMENSION A(100,100),x(100),b(100)
>
>so that all of my cases would be covered. The problem is that the
>external routine crash and burn unless A,x and b are dimensioned to
>exactly the size that they have for the current case. What I mean, is
>that if the current size is 5, everything blows up unless the
>initial declaration of the variables is A(5,5),x(5),b(5). What I don't
>understand is that the external routine also requires that you pass
>the CURRENT dimensions of the variables. So, if I initially have
>
>     dimension A(100,100),x(100),b(100)
>     .
>     .
>     {read in current value of size, N}
>     call routine (A,b,N)
>
>then the program doesn't work. What I'd like to know is is there any

Suppose you declare A(3,3) in the main program. Then A is stored in memory
this way:

  A(1,1)A(2,1)A(3,1)A(1,2)A(2,2)A(3,2)A(1,3)A(2,3)A(3,3)

If you declare a(N,N) in routine(a,b,N) and "call routine(A,b,2)" from the
main program, what "routine" sees is a four-element array

  a(1,1)a(2,1)a(1,2)a(2,2),

starting at the same address as A in the main program.  As you can see, 
"routine" gets the wrong elements from the second column on.

>way that I can run this under the fortran 77 standard without
>manually changing the dimensions and recompiling for each case? Since
>I've got about 70 different cases that I have to test, I don't really
>want to have to run the program 70 times. Anyway, thanks in advance.

The correct way to do it is to pass the leading dimension of A, called
LDA in LINPACK, to "routine".  Thus you might have

Main:
	dimension A(100,100), b(100), ...
	LDA = 100
	...
c  handle problem of size 78
	N = 78  
	call routine(A,LDA,b,N)
	...
c  handle problem of size 95
	N = 95
	call routine(A,LDA,b,N)
	...
	end

Routine:
	subroutine routine(a,lda,b,n)
	dimension a(lda,1)  <--- a(lda,lda), a(lda,*), and a(lda,n)
	                         will also work here. a(n,n) will NOT.
	dimension b(1)      <--- or b(*), b(lda), b(n)
	...
	end

Note that "routine" needs to be compiled only once.  It will get the
correct elements of A as long as you don't pass an N that exceeds LDA.
From: urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj)
Newsgroups: comp.lang.fortran
Subject: Re: cray paranoia
Date: 11 Oct 92 01:04:32 GMT
Organization: UNC Educational Computing Service



For a little ancient history.
The older Seymor Cray designed computers CDC 6600 CDC 7600 and cousins
of that generation did not have any parity checking on their arithmetic
units (it would slow things down). So one had to believe that there
were no hardware errors during your run. Or you had to double check
preferably by an independant method.
I think that has now been changed.
Newsgroups: comp.lang.fortran
From: urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj)
Subject: Re: Quickie
Summary: What dialect of Fortran is this?
Organization: UNC Educational Computing Service
Date: Sun, 11 Oct 1992 01:18:56 GMT

In article <EJH.92Oct10160448@khonshu.colorado.edu>, ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
> In article <28870@nntp_server.ems.cdc.com> mstemper@ems.cdc.com (Michael Stemper) writes:
> 
>    In article <1992Oct8.021427.8589@ecsvax.uncecs.edu>, urjlew@ecsvax.uncecs.edu (Rostyk Lewyckyj) writes:
>    |> 
>    |> There have been two other suggestions:
>    |> Store the formats in character arrays and WRITE(*,fmt(n))  and
>    |> Store the messages in arrays and write them with a common format 
>    |> WRITE(*,'(A)')msg(n). (Please check if there must be a field
>    |> width for the A format item Aw ).
> 
>    If no width is specified, the width of the item (trailing blanks and
>    all) will be used.
> 
> Yes, I should have done this:
> 
> 	write(*,*) msg(n)(:lnblnk(msg(n)))
> 
> This will only print the message to the last non-blank, i.e. it won't
> print trailing blanks. In this circumstance, using '(a)' and * have
> the same effect. Note that if you have an implicit none satement at
> the top of you program, the function lnblnk will have to be declared
> as an integer.
> --
> Edward Hartnett			ejh@khonshu.colorado.edu
> 
   write(*,*)msg(n)(:lnblnk(msg(n)))
                   ^^^^^^^^^^^^^^^^^
What dialect of Fortran is the above construction? 


-----------------------------------------------
  Reply-To:  Rostyslaw Jarema Lewyckyj
             urjlew@unc.oit.unc.edu    (ARPA,SURA,NSF etc. internet)
          or urjlew@unc.bitnet
          or urjlew@ecsvax.UUCP 
       tel.  (919)-962-6501

Newsgroups: comp.lang.fortran