NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/fortran/3176

Internet Message Format | 1992-08-25 | 30.4 KB

From: [e-mail] (Dan Magenheimer)
Date: Tue, 25 Aug 1992 15:53:51 GMT
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Message-ID: <[e-mail]>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Path: sparky!uunet!usc!sdd.hp.com!hpscdc!hplextra!hpfcso!djm
Newsgroups: comp.lang.fortran
Lines: 668

Here's the responses I received from the message I posted 7/28/92 titled
"CALLING UNIX (PORTABLY) FROM FORTRAN".  Thanks to all who responded!
I've also included some further discussion following the responses and the
original message follows that.

If you missed the orignal posting and would still like to respond, I am
still collecting responses!


                Dan Magenheimer
                IEEE 1003.9 (ex-)Technical Editor

##############################################################################
>From idacrd!ccr-p.ida.org![e-mail] Wed Jul 29 08:10 MDT 1992
Date: Wed, 29 Jul 92 10:07:40 EDT
From: [e-mail] (David desJardins)
To: [e-mail]
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Organization: IDA Center for Communications Research, Princeton

In article <[e-mail]> you write:
>Still, we're proud that we were able to complete the standards process
>and would like to find out if and how widely it would be used.  So,
>please reply to this message (email or notes/news) with:
>
>   1) Will you use it if its available? (Optional: How? Why? When?)
>   2) Will you be encouraging your system/Fortran vendor to provide it?

Yes, I certainly intend to use it, and to encourage the vendors on
which I use Fortran (primarily Cray Research, at present) to support
it.  The most significant reason I want to use it is one that you
mention.  Fortran I/O (including Fortran 90) is completely inadequate.
Currently all of my I/O (and all of that of everyone that I know) is
sequential and non-record-based, but support for that is rather poor
and non-standard.  (For example, I don't know any good way to read
binary data from stdin.)  I definitely desire a more portable and
generic method for non-record-based I/O.

>Caveats:  As you will see if you look at the standard (and as may be pointed
>out by some who opposed the standard), the standard contains some
>compromises that may be considered less than aesthetic.  This tends to be
>true of any standard, but the reasoning for each decision is carefully
>described in the Rationale appendix to the standard. Also, some areas
>that might have proved useful to standardize were left out to increase
>consensus.  These may be standardized by future standards committees.

Of course, the strength of my support depends on these details of the
standard, which I haven't had a chance to review.

                                        David desJardins

##############################################################################
[See discussion section for further information on this response. -ed]
>From [e-mail] Mon Aug  3 22:26 MDT 1992
From: [e-mail] (Robert Corbett)
To: [e-mail]
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Organization: Sun Microsystems, Mt. View, Ca.

Is draft 11 of P1003.9 dated August 23, 1991 reasonably close to
the final standard?

                    Yours truly,
                    Robert Corbett
##############################################################################
>From [e-mail] Wed Jul 29 13:57 MDT 1992
From: Walt Howard <[e-mail]>
To: [e-mail]
Subject: Re: Fortran bindings for Posix calls

Yes, we will use them when they become available.  We will certainly
encourage our vendor to supply them.

FYI, our vendor is HP, and we do use the hooks provided in the present
HP F77 compiler to make use of HP-UX routines.

My congratulations on getting a standard out the door.

>>Walt

##############################################################################
[See discussion section for further information on this response. -ed]
>From [e-mail] Wed Jul 29 20:58 MDT 1992
From: [e-mail] (Richard Maine)
To: [e-mail] (Dan Magenheimer)
Subject: CALLING UNIX (PORTABLY) FROM FORTRAN

On Tue, 28 Jul 1992 18:13:00 GMT, [e-mail] (Dan Magenheimer) said:

Dan> WANT TO CALL UNIX PORTABLY FROM FORTRAN?  Read this:

        [...description of POSIX 1003.9...]
Dan>    1) Will you use it if its available? (Optional: How? Why? When?)
Dan>    2) Will you be encouraging your system/Fortran vendor to provide it?

The answer to both quetions for me is "no."  Reasons:

1. All my Fortran programming (which is most of my programming) is now
   in Fortran 90 rather than Fortran 77.  I've been using f90 since
   October of last year, and I don't anticipate using f77 on any new
   projects.  I am encouraging all of the other users at my site to
   convert to f90 and I am encouraging vendors to support it.

   I consider the style of 1003.9 to be very foreign to even f77; many
   of the concepts seem simply lifted from C/unix with little integration
   into the style of f77 programming.  Yes, it is legal f77, but very
   cryptic and unnatural in style.  As out of place as it seems in f77,
   it seems even farther removed from reasonable f90 style.  There are
   obscure constructs to accomplish what can be done simply, naturally,
   and portably in f90.

   For one of many, many examples: suppose I want to open a file for
   readonly access (to facilitate sharing, lessen the likelihood of
   accidentally corrupting the file, etc).  There have been widely
   used f77 extensions for this for many years.  F90 standardizes this
   with the action="read" specifier in the open.  As I recall 1003.9,
   it would require me to completely abandon standard Fortran i/o on
   the file and rewrite the access to that file in terms of the 1003.9
   calls.  This is not what I call integration into reasonable
   Fortran style.

   Yes, I heard/read some of the rationale for making it an f77
   binding (and an obscure one at that); no I don't agree with it.

2. Portability.  My programs must run on many systems.  This includes
   both unix and non-unix systems.  At the moment, I don't know of
   any vendors offering 1003.9 even on unix systems.  (There may well
   be some, but presumably it isn't a significant majority or I'd have
   heard more about it).  Even if all the unix vendors universally
   decided to support 1003.9, by the time that support was widely
   available, the limittations of the f77 style of the interface would
   seem more out of place than they do now.

   And, of course, all this has no hope of applying to non-unix systems.
   The 1003.9 interface makes no attempt to abstract the concepts
   involved, but is just a straight translation of Unix system calls.
   I can't even think what some of the concepts would mean in a non-unix
   environment.

   If I used this "standard" I would actually sacrifice portability in
   some ways.  I'd have to change perfectly standard, portable f90
   constructs to calls available only on unix systems (and perhaps
   not on all of them).

3. Yes, there are things I need/want to do that aren't within the
   confines of standard, portable, f90.  My approach will continue to
   be, as it has been in the past, to isolate such system-dependent
   code to a small set of routines that I port to the various relevant
   systems.  I abstract and simplify the required interface enough that
   it should be relatively easy to write the routines for the various
   systems.

   The 1003.9 routines are far too obscure and far too tied to unix to
   be adopted as my system-dependent interface.  It is not a small set
   of routines and it is not abstracted at all.  The extent that I
   might make use of 1003.9 is that one of the system-dependent
   versions of my routines might someday call some of the 1003.9
   routines.  In this, the 1003.9 stuff would be no more than one
   other implementation of my system-dependent routines.

--
Richard Maine
[e-mail]


##############################################################################
>From aix3![e-mail] Thu Jul 30 08:02 MDT 1992
From: aix3![e-mail] (Stewart Holt)
To: netcomsv![e-mail] (Dan Magenheimer)
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Organization: Energy Management Associates

In article <[e-mail]>, you wrote:
>
> As an ex-member of the committee, I'd like to poll the user community
> to determine 1) whether you will use it, and 2) whether you will be
> encouraging your system and/or Fortran vendors to provide it.
>
Yes, we are very interrested in this. I personally support a "portability
library" for fortran which is used on about 12 different platforms.  As you
mentioned much of what you describe is exists in various forms. I am the
one who deals with those forms!

I would like to see this standard asap. Wish IEEE would post text on net. I
had rather scan with editor than use an index of a document. I will
encourage our vendors to support this.  I have been waiting for this piece
of Posix since the various standards were defined. Thanks for your
interest.

##############################################################################
>From metaware!metaware.com![e-mail] Thu Jul 30 09:55 MDT 1992
From: [e-mail] (Mike Ross)
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Newsgroups: comp.lang.fortran
Organization: Metaware Incorporated, Santa Cruz, CA

 I reserve judgement until I see a full copy of
 the standard. Assuming it is not too unreasonable,
 I will consider implementing it in our FORTRAN.
 I can't say when-- that would be classified :-).
         Mike


##############################################################################
[See discussion section for further information on this response. -ed]
>From [e-mail] Wed Jul 29 08:24 MDT 1992
From: [e-mail] (Alan M. McKenney)
To: [e-mail]
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Organization: Courant Institute, NYU, NY, NY, USA

    Could you perhaps tell us how to get a copy of the IEEE
1003.9 standard?


--
Alan McKenney        E-mail:  [e-mail]         (INTERNET)
Courant Institute,NYU,USA     ...!cmcl2!cims.nyu.edu!mckenney   (UUCP)

##############################################################################
##############################################################################
        ADDITIONAL DISCUSSION
##############################################################################
>From djm Tue Aug  4 15:26:26 1992
To: [e-mail]
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN

>From [e-mail] Mon Aug  3 22:26 MDT 1992
>To: [e-mail]
>Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
>Newsgroups: comp.lang.fortran
>
>Is draft 11 of P1003.9 dated August 23, 1991 reasonably close to
>the final standard?
>
>                    Yours truly,
>                    Robert Corbett

There were a few semantic clarifications after draft 11, but none of the
syntax/interfaces changed.  The final standard should be available for
purchase from IEEE in September.

            Thanks,
            Dan Magenheimer


##############################################################################
>From djm Wed Jul 29 14:01:11 1992
To: [e-mail]
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Status: R

>From [e-mail] Wed Jul 29 08:24 MDT 1992
>From: [e-mail] (Alan M. McKenney)
>Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
>Newsgroups: comp.lang.fortran
>
>    Could you perhaps tell us how to get a copy of the IEEE
>1003.9 standard?
>
>Alan McKenney        E-mail:  [e-mail]         (INTERNET)
>Courant Institute,NYU,USA     ...!cmcl2!cims.nyu.edu!mckenney   (UUCP)

Camera ready copy is in IEEE's hands.  There will undoubtedly be
a final formatting tweak or two, then it will be off to the publishers.
I'd guess 4-6 weeks before it will be available for ordering from
IEEE. I'll post the ordering details at that time.

Does this mean you are interested?  Or did the caveats scare you?

                Dan Magenheimer

##############################################################################
>From djm Thu Jul 30 09:59:44 1992
To: [e-mail]
Subject: Re:  CALLING UNIX (PORTABLY) FROM FORTRAN
Status: R

>From [e-mail] Wed Jul 29 20:58 MDT 1992
>Subject: CALLING UNIX (PORTABLY) FROM FORTRAN
>
>On Tue, 28 Jul 1992 18:13:00 GMT, [e-mail] (Dan Magenheimer) said:
>
>Dan> WANT TO CALL UNIX PORTABLY FROM FORTRAN?  Read this:
>
>        [...description of POSIX 1003.9...]
>Dan>    1) Will you use it if its available? (Optional: How? Why? When?)
>Dan>    2) Will you be encouraging your system/Fortran vendor to provide it?

Richard --

Thanks much for your thoughtful response.

>The answer to both quetions for me is "no."  Reasons:
>
>1. All my Fortran programming (which is most of my programming) is now
>   in Fortran 90 rather than Fortran 77.  I've been using f90 since
>   October of last year, and I don't anticipate using f77 on any new
>   projects.  I am encouraging all of the other users at my site to
>   convert to f90 and I am encouraging vendors to support it.

I too am fully supportive of Fortran 90 (and managed some of the HP early
investigations into it).  Still, given the large number of programmers
using F66 well into the eighties, we were certain that F77 bindings
would be useful for some time to come.

As you're aware, F77 is a subset (well, close enough) of F90 so 1003.9
works for F90 as well.

>   I consider the style of 1003.9 to be very foreign to even f77; many
>   of the concepts seem simply lifted from C/unix with little integration
>   into the style of f77 programming.  Yes, it is legal f77, but very
>   cryptic and unnatural in style.  As out of place as it seems in f77,
>   it seems even farther removed from reasonable f90 style.  There are
>   obscure constructs to accomplish what can be done simply, naturally,
>   and portably in f90.

That's why we didn't call it an F90 binding as well, even though it could
be.  Michael Hannah is chairing a committee to do a F90 binding.

I'd still be interested in your answers to the original questions, as
they apply to a "future F90 binding"?  Would you use it?  Would you
encourage vendors to provide it?

As for "C/unix-ness", we had a very difficult task bridging the cultural
gap between Fortran and C/Unix.  We thought that, if anything, we leaned
more in the direction of Fortran than C/Unix.  Much of the cryptic/unnatural
style was imposed by the constraint of sticking to the F77 standard
and common Fortran coding conventions (e.g. subroutines).

>   For one of many, many examples: suppose I want to open a file for
>   readonly access (to facilitate sharing, lessen the likelihood of
>   accidentally corrupting the file, etc).  There have been widely
>   used f77 extensions for this for many years.  F90 standardizes this
>   with the action="read" specifier in the open.  As I recall 1003.9,
>   it would require me to completely abandon standard Fortran i/o on
>   the file and rewrite the access to that file in terms of the 1003.9
>   calls.  This is not what I call integration into reasonable
>   Fortran style.

Yes, another constraint we lived with was not specifying language extensions
though there were many we would have liked to do.  This limited the style
integration available to us.

>   Yes, I heard/read some of the rationale for making it an f77
>   binding (and an obscure one at that); no I don't agree with it.

Obscure?

>2. Portability.  My programs must run on many systems.  This includes
>   both unix and non-unix systems.  At the moment, I don't know of
>   any vendors offering 1003.9 even on unix systems.  (There may well
>   be some, but presumably it isn't a significant majority or I'd have
>   heard more about it).  Even if all the unix vendors universally
>   decided to support 1003.9, by the time that support was widely
>   available, the limittations of the f77 style of the interface would
>   seem more out of place than they do now.

For forward looking users such as yourself, this is probably true.

No, no vendors are providing 1003.9 yet as far as I know.  Several vendors
are providing similar mechanisms which were used as bases for the standard.

>   And, of course, all this has no hope of applying to non-unix systems.
>   The 1003.9 interface makes no attempt to abstract the concepts
>   involved, but is just a straight translation of Unix system calls.
>   I can't even think what some of the concepts would mean in a non-unix
>   environment.

True, but an increasing number of vendors are providing 1003.1 compliance
even on their proprietary systems (e.g. "OpenVMS", MPE/ix, Windows NT)
as it makes it easier to sell to the government.  A 1003.1 implementation
makes a 1003.9 implementation very straightforward (almost entirely a
library layer on top of 1003.1).

>   If I used this "standard" I would actually sacrifice portability in
>   some ways.  I'd have to change perfectly standard, portable f90
>   constructs to calls available only on unix systems (and perhaps
>   not on all of them).

No.  You use F90 for everything that you can do with it and use 1003.9
only for those things you can't.

>3. Yes, there are things I need/want to do that aren't within the
>   confines of standard, portable, f90.  My approach will continue to
>   be, as it has been in the past, to isolate such system-dependent
>   code to a small set of routines that I port to the various relevant
>   systems.  I abstract and simplify the required interface enough that
>   it should be relatively easy to write the routines for the various
>   systems.
>
>   The 1003.9 routines are far too obscure and far too tied to unix to
>   be adopted as my system-dependent interface.  It is not a small set
>   of routines and it is not abstracted at all.  The extent that I
>   might make use of 1003.9 is that one of the system-dependent
>   versions of my routines might someday call some of the 1003.9
>   routines.  In this, the 1003.9 stuff would be no more than one
>   other implementation of my system-dependent routines.

Good enough.  Note that (assuming vendors implement the standard of course)
your layer on top of 1003.9 will work on all POSIX 1003.9 compliant systems,
thus limiting the number of system-dependent layered interfaces you would
need to implement.

>Richard Maine
>[e-mail]

Thanks again for your feedback!

                Dan Magenheimer

##############################################################################
>From [e-mail] Thu Jul 30 11:38 MDT 1992
From: [e-mail] (Richard Maine)
To: [e-mail]
Cc: [e-mail]
Subject:  CALLING UNIX (PORTABLY) FROM FORTRAN

On Thu, 30 Jul 92 09:59:45 -0600, Dan Magenheimer <[e-mail]> said:

Dan> I too am fully supportive of Fortran 90 (and managed some of the HP early
Dan> investigations into it).  Still, given the large number of programmers
Dan> using F66 well into the eighties, we were certain that F77 bindings
Dan> would be useful for some time to come.

Almost certainly true for some people.  I wasn't trying to claim that my
reponse was typical of "most" users.  I'll leave that kind of unsupported
statements to the politicians.  I was just answering for me.

Dan> I'd still be interested in your answers to the original questions, as
Dan> they apply to a "future F90 binding"?  Would you use it?  Would you
Dan> encourage vendors to provide it?

Probably yes on both counts.  I hadn't realized that your question was
meant to cover the "future f90 binding" as well.  It is hard to say for
sure without seeing yet even a rough outline of what it would be like,
but my guess would be that yes, I would use an f90 binding.

Dan> As for "C/unix-ness", we had a very difficult task bridging the
Dan> cultural gap between Fortran and C/Unix.  We thought that, if
Dan> anything, we leaned more in the direction of Fortran than C/Unix.
Dan> Much of the cryptic/unnatural style was imposed by the constraint
Dan> of sticking to the F77 standard and common Fortran coding
Dan> conventions (e.g. subroutines).

Yes, I recognize the f77 subroutine interface as being the source of
some of the obscurity, but some of it is "pure" unix.  Things like the
whole security system.  For instance the use of 3 digit octal numbers
to set modes.  Yukk!  That's cryptic and obscure by any standard I'm
used to; even the terminology of it is obscure.  I'd have never
thought to look for something called anything close to chmod (or
whatever the 1003.9 equivalent name is - I forget) to set security.
Oh, "mode" means security?  (I'm not really asking.  I know the
answer, but most Fortran programmers I talk to don't.)  This is the
kind of thing I mean by referring to the interface as obscure and
C/unix style.

A subroutine name like set_security would make a lot more sense.  (You
did say that you allowed long variable names - take out the underscore
if you want to otherwise stay f77 standard).  And make the arguments
something more meaningful than an octal number.  (No, I haven't sat
down to actually design such an interface myself.  I am well aware
that it is far from trivial).

>   If I used this "standard" I would actually sacrifice portability in
>   some ways.  I'd have to change perfectly standard, portable f90
>   constructs to calls available only on unix systems (and perhaps
>   not on all of them).

Dan> No.  You use F90 for everything that you can do with it and use 1003.9
Dan> only for those things you can't.

I was alluding to things like the i/o, where I have to abandon all
standard Fortran i/o on a file to get a single non-Fortran feature in
the open.  There I have to actually sacrifice portability to use the
1003.9 approach.  It is more portable to find the system-dependent
way of diddling the Fortran open than to abandon the Fortran i/o.

Yes, I know, I hadn't stated this clearly.  I was trying to avoid my
(usual) tendency to be overly wordy.  In the process, I left out a
few too many of the needed words.

>   of routines and it is not abstracted at all.  The extent that I
>   might make use of 1003.9 is that one of the system-dependent
>   versions of my routines might someday call some of the 1003.9
>   routines.  In this, the 1003.9 stuff would be no more than one
>   other implementation of my system-dependent routines.

Dan> Good enough.  Note that (assuming vendors implement the standard
Dan> of course) your layer on top of 1003.9 will work on all POSIX
Dan> 1003.9 compliant systems, thus limiting the number of
Dan> system-dependent layered interfaces you would need to implement.

Yes, that would be a help.  And if it turns out that vendors implement
the 1003.9 stuff, I probably will do one of my system-dependent
"wrappers" for it.  I'm not likely to push them for it though.
I'd be more likely to push them for a more natural f90 binding,
possibly one compliant with the POSIC f90 binding standard if one
comes out (even in draft form).

--
Richard Maine
[e-mail]

##############################################################################
>From djm Thu Jul 30 12:45:44 1992
To: [e-mail]
Subject: Re:  CALLING UNIX (PORTABLY) FROM FORTRAN

>>From [e-mail] Thu Jul 30 11:38 MDT 1992
>Subject:  CALLING UNIX (PORTABLY) FROM FORTRAN
>
>Dan> No.  You use F90 for everything that you can do with it and use 1003.9
>Dan> only for those things you can't.
>
>I was alluding to things like the i/o, where I have to abandon all
>standard Fortran i/o on a file to get a single non-Fortran feature in
>the open.  There I have to actually sacrifice portability to use the
>1003.9 approach.  It is more portable to find the system-dependent
>way of diddling the Fortran open than to abandon the Fortran i/o.

I'm not much of an expert on this area, but my recollection and interpretation
is that this is not the case.  Mixing the I/O models is allowed if
the file is opened when the POSIX I/O flag is set.  Of course, then
all FORTRAN I/O is "layered" on top of POSIX I/O, which will probably
result in lower performance on some machines.  And sequential formatted
files are newline-delimited.  But other than these restrictions, I think
you're OK.  (This was a late change to the standard.  Do you have an
older draft?)

>Dan> As for "C/unix-ness", we had a very difficult task bridging the
>Dan> cultural gap between Fortran and C/Unix.  We thought that, if
>Dan> anything, we leaned more in the direction of Fortran than C/Unix.
>Dan> Much of the cryptic/unnatural style was imposed by the constraint
>Dan> of sticking to the F77 standard and common Fortran coding
>Dan> conventions (e.g. subroutines).
>
>Yes, I recognize the f77 subroutine interface as being the source of
>some of the obscurity, but some of it is "pure" unix.  Things like the
>whole security system.  For instance the use of 3 digit octal numbers
>to set modes.  Yukk!  That's cryptic and obscure by any standard I'm
>thought to look for something called anything close to chmod (or
>whatever the 1003.9 equivalent name is - I forget) to set security.
>Oh, "mode" means security?  (I'm not really asking.  I know the
>answer, but most Fortran programmers I talk to don't.)  This is the
>kind of thing I mean by referring to the interface as obscure and
>C/unix style.
>
>A subroutine name like set_security would make a lot more sense.  (You
>did say that you allowed long variable names - take out the underscore
>if you want to otherwise stay f77 standard).  And make the arguments
>something more meaningful than an octal number.  (No, I haven't sat
>down to actually design such an interface myself.  I am well aware
>that it is far from trivial).

After the way the naming ended up, I might be inclined to agree with you.
On the other hand, having a link to the Unix culture has its advantages
to.  E.g. if you tell your local Unix expert that you need to make
a file readonly, he/she'll tell you to use "chmod".  With our naming
model, the Fortran programmer just adds a prefix and looks it up.  Yes,
I know that a good cross-reference table shoots that argument in the foot
but that was probably the main reason it ended up that way.

By the way, I assume you don't mind if I post your responses?

                Dan

##############################################################################
>From [e-mail] Thu Jul 30 13:15 MDT 1992
From: [e-mail] (Richard Maine)
Subject:  CALLING UNIX (PORTABLY) FROM FORTRAN

On Thu, 30 Jul 92 12:45:45 -0600, Dan Magenheimer <[e-mail]> said:

Dan> But other than these restrictions, I think
Dan> you're OK.  (This was a late change to the standard.  Do you have an
Dan> older draft?)

Quite possible.  (It is even more possible that I have both an older and a
newer draft and didn't study the differences in detail to notice things
like that).  I was not directly checking the draft when writing my
reply to you, but was relying on my memory of what I recalled from
reading through it earlier.

Dan> By the way, I assume you don't mind if I post your responses?

Fine.  Your original post said that you might.  A few of the things I
said were phrased in ways that might have tended to be "flame bait" if
I posted them, but that should be less of a problem if they are
incorporated into a summary.  (By the way, thanks for not taking them
that way and giving instead constructive feedback).

--
Richard Maine
[e-mail]

##############################################################################
##############################################################################
        ORIGINAL POSTING
##############################################################################
>From [e-mail] Tue Jul 28 12:13 MDT 1992
From: [e-mail] (Dan Magenheimer)
Subject: CALLING UNIX (PORTABLY) FROM FORTRAN
Newsgroups: comp.lang.fortran

WANT TO CALL UNIX PORTABLY FROM FORTRAN?  Read this:

(Since only a small percentage of Fortran programmers read notes, please
forward this message to others who might be interested.  Thanks!)

The IEEE Standards Board has recently approved IEEE Std 1003.9 aka
"Fortran Bindings for POSIX".  Published copies should be available
in a couple of months from IEEE.

As an ex-member of the committee, I'd like to poll the user community
to determine 1) whether you will use it, and 2) whether you will be
encouraging your system and/or Fortran vendors to provide it.

What is "it"?  Here's a brief description:

IEEE Std 1003.9 is/contains/standardizes:

o A portable way to call all POSIX system calls.  The standard uses
  FORTRAN 77 standard features with only one extension -- long subroutine
  names.  Examples: chmod, chdir, pipe, fork/exec, signal routines, getpid.
o Access to system constants, both static and dynamic.  Examples: LINK_MAX,
  PIPE_BUF, PATH_MAX, stat modes, open modes.
o Access to system structures, such as stat.
o A POSIX-based FORTRAN I/O layer which allows (portable) usage of files,
  pipes, and devices that do not use record-based FORTRAN conventions.
  Requirements are also defined for interactions between record-based
  FORTRAN I/O and POSIX-based FORTRAN I/O.  Also, getc/putc equivalents.
o Environment access routines (e.g. command line arguments, ENV access)
o MIL-STD-like support routines (e.g. ior, and, not)
o Extensibility.  All interfaces use a consistent set of conventions that
  can be easily applied by a vendor to non-POSIX calls.

Much of this of course already exists but differs from vendor to vendor
and is therefore not portable.  IEEE Std 1003.9 encourages portability.
Of course, portability is not obtained unless the standard is supported
by vendors, and it won't be supported by vendors unless users (YOU!)
ask for it.

Caveats:  As you will see if you look at the standard (and as may be pointed
out by some who opposed the standard), the standard contains some
compromises that may be considered less than aesthetic.  This tends to be
true of any standard, but the reasoning for each decision is carefully
described in the Rationale appendix to the standard. Also, some areas
that might have proved useful to standardize were left out to increase
consensus.  These may be standardized by future standards committees.

Still, we're proud that we were able to complete the standards process
and would like to find out if and how widely it would be used.  So,
please reply to this message (email or notes/news) with:

   1) Will you use it if its available? (Optional: How? Why? When?)
   2) Will you be encouraging your system/Fortran vendor to provide it?

I will openly post email responses.

Finally, if you are interested in participating in related POSIX/FORTRAN
standardization activities, please contact Michael Hannah, [e-mail].

                Thanks,
                Dan Magenheimer
                POSIX 1003.9 (ex-)Technical Editor
                [e-mail]
                FAX: [phone]