Let's see if we can reason this out...
MPI_FILE_OPEN just *radiates* wrongness. There is no FILE object yet, so how
can we possibly perform an OPEN action on it? At the very least, the name
should be MPI_OPEN_FILE, which is at least consistent with the "assumed" object
rule from MPI-1. (Whether you prefer to think of that implicit object as a
communicator or as the global object is entirely up to you, which is one nice
feature of this particular name.)
Since we do have a FILE object when we close, it would appear that
MPI_FILE_CLOSE is correct. However, we have now broken a symmetry that everyone
and their dog would expect to be there.
Thankfully, J&E now comes to our rescue yet again. Because we are allowed to
leave out teh subsets if they are not needed, MPI_OPEN_FILE can legitimately be
shortened to MPI_OPEN since we currently do not allow OPEN to operate on
anything other than a file. Ditto for CLOSE.
So, at the end of the day, we are left with MPI_OPEN and MPI_CLOSE for the
Fortran and C bindings, and 99% of the MPI world is happy because the names are
both short and (from their perspective) obvious. For C++, we use the
communicator as the base object and now the other 1% is happy because the names
are both long and (from their perspective) obvious.
Now let's talk about all of the MPI constants that need fixing! :-P
-- Eric Salo Silicon Graphics salo@sgi.com