I am in favor of adding Adam's rationale.

> Rationale:
> All MPI tool information interface functions must return error classes,
> because applications cannot portably call MPI_ERROR_CLASS before
> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error
> class.

Kathryn

> -----Original Message-----
> From: [email protected] [mailto:mpi-forum-
> [email protected]] On Behalf Of Adam T. Moody
> Sent: Tuesday, July 24, 2012 11:23 AM
> To: Main MPI Forum mailing list
> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
>
> I think we are all converging, but there is one point that I wanted to
> bring up:
>
>     Can one call ERROR_CLASS/STRING before MPI_INIT?
>
> The current standard doesn't allow this, since ERROR_CLASS/STRING are
> not in the list of functions that one can call before INIT.  However,
> Rolf pointed out that the previous standard didn't need to allow this,
> because there is no way to replace the default error handler (which is
> that errors are fatal) until after INIT.  Thus, if one of these
> functions throws an error before INIT, it triggers the ERRORS_ARE_FATAL
> handler and never returns.
>
> However, since MPI_T_ errors do not kick off the error handlers, now we
> have the case where error codes can be returned before MPI_INIT.
> However, again, since ERROR_CLASS/STRING are not in the list of
> functions that one can call before INIT, it is implied that users cannot
> call these functions until after MPI_INIT.  It would be nice to add a
> rationale statement along these lines to the latest proposed text, e.g.:
>
>
> All return codes with the prefix MPI_T_ are error codes. They must be
> unique values and cannot overlap with any other error codes or error
> classes returned by the MPI implementation. Further, they shall be
> treated as MPI error classes as defined in Chapter 8.4 and follow
> the same rules and restrictions. In particular, they must satisfy:
>
> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>
> Rationale:
> All MPI tool information interface functions must return error classes,
> because applications cannot portably call MPI_ERROR_CLASS before
> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error
> class.
>
>
> Note the above is more restrictive than it needs to be, since it seems
> that we could allow MPI_T to return arbitrary error codes *after*
> MPI_INIT.  However, it seems we're already imposing the restriction that
> they always return error classes.
> -Adam
>
>
>
> Mohror, Kathryn wrote:
>
> >I see the meaning of classes and codes now. I was a bit confused by the
> wording in 8.4. I still think it's a bit weird that everywhere else in the standard,
> the codes returned need to be converted to classes to get a portable
> understanding of the error, but in MPI_T we will return classes, so the meaning
> is already known without conversion.
> >
> >However, that said, Bronis' wording of Rolf's suggested change seems to
> make that distinction clearer. I am okay with Bronis' text:
> >
> >
> >
> >>All return codes with the prefix MPI_T_ are error codes. They must be
> >>    unique values and cannot overlap with any other error codes or error
> >>    classes returned by the MPI implementation. Further, they shall be
> >>    treated as MPI error classes as defined in Chapter 8.4 and follow
> >>    the same rules and restrictions. In particular, they must satisfy:
> >>
> >>       0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>
> >>
> >
> >Kathryn
> >
> >
> >
> >>-----Original Message-----
> >>From: [email protected] [mailto:mpi-forum-
> >>[email protected]] On Behalf Of William Gropp
> >>Sent: Tuesday, July 24, 2012 8:31 AM
> >>To: Main MPI Forum mailing list
> >>Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
> >>
> >>MPI error codes, combined with MPI_Error_string, permit an MPI
> >>implementation to return a instance-specific and detailed error message.
> Error
> >>classes, like Unix error codes, have only slightly more information that
> >>"something went wrong".
> >>
> >>Because MPI error classes are error codes, its possible to return the error
> class;
> >>this can be used before Init and after Finalize now.  But between Init and
> >>Finalize, codes permit but do not require an implementation to return more
> >>helpful information.  I see no reason to require the MPI_T interface to be
> less
> >>user-friendly than the rest of the MPI interface.  However, leaving this for
> 3.1
> >>might make sense.
> >>
> >>Bill
> >>
> >>William Gropp
> >>Director, Parallel Computing Institute
> >>Deputy Director for Research
> >>Institute for Advanced Computing Applications and Technologies
> >>Paul and Cynthia Saylor Professor of Computer Science
> >>University of Illinois Urbana-Champaign
> >>
> >>
> >>
> >>On Jul 23, 2012, at 3:05 PM, Mohror, Kathryn wrote:
> >>
> >>
> >>
> >>>I have some concerns over this.
> >>>
> >>>
> >>>
> >>>>The topic about user-callability of MPI_ERROR_CLASS and
> >>>>
> >>>>
> >>MPI_ERROR_STRING
> >>
> >>
> >>>>outside of the initialized MPI should be revisited in MPI-3.1.
> >>>>This is not evident for the tools' developers because they know
> >>>>the meaning of their MPI_T_ERR... classes and only classes are returned.
> >>>>
> >>>>
> >>>If we are going to treat MPI_T error codes the same way they are in the rest
> of
> >>>
> >>>
> >>the standard, does it make sense to say that "only classes are returned" by
> >>MPI_T calls? I think that MPI calls return codes and the codes are translated
> to
> >>classes by the MPI_ERROR_CLASS function.
> >>
> >>
> >>>If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available before
> >>>
> >>>
> >>MPI_Init, then this may be a hardship on tools. I imagine many tools doing a
> >>significant amount of set up before MPI_Init to avoid overhead. However, if
> >>there is no information about what the return codes mean, then tools may
> have
> >>difficulty.
> >>
> >>
> >>>Possibly it makes more sense to treat MPI_T return values differently than
> >>>
> >>>
> >>MPI calls? Could the MPI_T return values be a set of defined codes instead?
> >>
> >>
> >>>Does anyone have different insight on error codes vs classes?
> >>>
> >>>Kathryn
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [email protected] [mailto:mpi-forum-
> >>>>[email protected]] On Behalf Of Bronis R. de Supinski
> >>>>Sent: Monday, July 23, 2012 10:37 AM
> >>>>To: Main MPI Forum mailing list
> >>>>Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
> >>>>
> >>>>
> >>>>OK by me.
> >>>>
> >>>>On Mon, 23 Jul 2012, Dave Goodell wrote:
> >>>>
> >>>>
> >>>>
> >>>>>I agree, we should make these changes.
> >>>>>
> >>>>>-Dave
> >>>>>
> >>>>>On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi Rolf, all,
> >>>>>>
> >>>>>>I agree with your suggestions and I am in favor of making these
> changes.
> >>>>>>
> >>>>>>
> >>>>Bronis (as well as Kathryn and Dave as the remaining members in the
> >>>>
> >>>>
> >>chapter
> >>
> >>
> >>>>committee for tools) should concur, though.
> >>>>
> >>>>
> >>>>>>Anybody else have any concerns over these changes?
> >>>>>>
> >>>>>>As for the callability of the error functions, I also agree - let's target
> those
> >>>>>>
> >>>>>>
> >>in
> >>
> >>
> >>>>3.1. This change is not vital and bit too big for final edits.
> >>>>
> >>>>
> >>>>>>Thanks,
> >>>>>>
> >>>>>>Martin
> >>>>>>
> >>>>>>
> >>>>>>On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Martin et al.,
> >>>>>>>
> >>>>>>>Consistently with your proposal, I would recommend:
> >>>>>>>
> >>>>>>>1) Sect 14.3.9 "Return Codes for the MPI tool information interface"
> >>>>>>>last sentence reads
> >>>>>>>
> >>>>>>> All return codes with the prefix MPI_T_ must be unique values and
> >>>>>>> cannot overlap with any other return values returned by the MPI
> >>>>>>> implementation.
> >>>>>>>
> >>>>>>>but should read
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>All return codes with the prefix MPI_T_ must be unique values and
> >>>>>>>>cannot overlap with any other
> >>>>>>>>
> >>>>>>>>
> >>>>>>> error codes and error classes
> >>>>>>>
> >>>>>>>
> >>>>>>>>returned by the MPI
> >>>>>>>>implementation. Further, they shall be treated as MPI error classes
> as
> >>>>>>>>defined in Chapter 8.4 and follow the same rules and restrictions,
> >>>>>>>>
> >>>>>>>>
> >>>>>>> especially they must satisfy
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>2) A.1.1 the first three tables are headed by
> >>>>>>>
> >>>>>>>Error classes
> >>>>>>>Error classes (continued)
> >>>>>>>Return Codes for the MPI tool information interface
> >>>>>>>
> >>>>>>>and these lines should read
> >>>>>>>
> >>>>>>>Error classes
> >>>>>>>Error classes (continued)
> >>>>>>>Error classes (continued)
> >>>>>>>
> >>>>>>>3) The last line of A.1.1, 2nd table
> >>>>>>>
> >>>>>>>MPI_ERR_LASTCODE
> >>>>>>>
> >>>>>>>should move after the last MPI_T_ERR_... code in the 3rd table.
> >>>>>>>
> >>>>>>>Okay?
> >>>>>>>
> >>>>>>>The topic about user-callability of MPI_ERROR_CLASS and
> >>>>>>>
> >>>>>>>
> >>>>MPI_ERROR_STRING
> >>>>
> >>>>
> >>>>>>>outside of the initialized MPI should be revisited in MPI-3.1.
> >>>>>>>This is not evident for the tools' developers because they know
> >>>>>>>the meaning of their MPI_T_ERR... classes and only classes are
> returned.
> >>>>>>>
> >>>>>>>I would like to have a final "okay" before I execute
> >>>>>>>the changes in chap-appLang.
> >>>>>>>
> >>>>>>>Best regards
> >>>>>>>Rolf
> >>>>>>>
> >>>>>>>----- Original Message -----
> >>>>>>>
> >>>>>>>
> >>>>>>>>From: "Martin Schulz" <[email protected]>
> >>>>>>>>To: "Main MPI Forum mailing list" <[email protected]>
> >>>>>>>>Sent: Monday, July 23, 2012 1:23:40 AM
> >>>>>>>>Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
> >>>>>>>>
> >>>>>>>>
> >>>>MPI_ERR_LASTCODE
> >>>>
> >>>>
> >>>>>>>>Hi Rolf, all,
> >>>>>>>>
> >>>>>>>>I thought we had discussed the error semantics of MPI_T in several
> >>>>>>>>meetings/readings and nobody objected, but I generally agree with
> >>>>>>>>
> >>>>>>>>
> >>your
> >>
> >>
> >>>>>>>>comments below. However, they are not really error classes (at least
> >>>>>>>>in the tools group we/I never thought about them this way), but just
> >>>>>>>>well defined return codes. Nevertheless, they fit the model and
> >>>>>>>>semantics of classes and hence should integrated into the same rules
> >>>>>>>>for consistency. I also agree with Bronis, though, that larger
> >>>>>>>>feedback on this would be good to avoid errors because of rushing it.
> >>>>>>>>
> >>>>>>>>To keep changes minimal, I would suggest that we only change the
> >>>>>>>>following sentence, which IMHO is sufficient (and would essentially
> >>>>>>>>follow option b):
> >>>>>>>>
> >>>>>>>>All return codes with the prefix MPI_T_ must be unique values and
> >>>>>>>>cannot overlap with any other return values returned by the MPI
> >>>>>>>>implementation. Further, they shall be treated as MPI error classes
> as
> >>>>>>>>defined in Chapter 8.4 and follow the same rules and restrictions.
> >>>>>>>>
> >>>>>>>>This would also make changes in the appendix unnecessary.
> >>>>>>>>
> >>>>>>>>As for making MPI_ERROR_CLASS and MPI_ERROR_STRING
> callable
> >>>>>>>>
> >>>>>>>>
> >>>>before
> >>>>
> >>>>
> >>>>>>>>Init (and then also after finalize), yes that would be very useful,
> >>>>>>>>but is a general issue not only related to MPI_T. If we decide this is
> >>>>>>>>too invasive at this point, I would like to see this at least in 3.1.
> >>>>>>>>
> >>>>>>>>Martin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>On Jul 22, 2012, at 1:46 PM, Rolf Rabenseifner wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>About 1. question:
> >>>>>>>>>
> >>>>>>>>>I changed the headers of the three error code tables in the Annex
> >>>>>>>>>according to Tables 8.1 and 8.2 from "Return codes"
> >>>>>>>>>into "Error classes".
> >>>>>>>>>
> >>>>>>>>>svn r1505: I used also "Error classes" for the tools table
> >>>>>>>>>svn r1507: I went back to the official ticket 266 text "Return
> >>>>>>>>>codes"
> >>>>>>>>>
> >>>>>>>>>The Tools group should decide whether
> >>>>>>>>>a. they want to stay with special return codes that are not
> >>>>>>>>>part of the rule in Set. 8.4
> >>>>>>>>>
> >>>>>>>>>0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE
> >>>>>>>>>
> >>>>>>>>>In this case they should change "return code"
> >>>>>>>>>into "error codes are returned" plus noting that
> >>>>>>>>>the routine MPI_ERROR_STRING can be applied
> >>>>>>>>>with the open question, whether MPI_EEROR_STRING
> >>>>>>>>>can be applied before a call to MPI_INIT.
> >>>>>>>>>
> >>>>>>>>>Similar problem with failed MPI_INIT and analysing its
> >>>>>>>>>returned error code:
> >>>>>>>>>One needs at least MPI_ERROR_CLASS and MPI_ERROR_STRING
> >>>>>>>>>callable before MPI_INIT.
> >>>>>>>>>
> >>>>>>>>>b. or you may use the same terminology as in Sect. 8.4,
> >>>>>>>>>then new table 14.5 must show "Error classes".
> >>>>>>>>>
> >>>>>>>>>In this case you should integrate the MPI_T_ERR_...
> >>>>>>>>>into the MPI_ERR_LASTCODE rule.
> >>>>>>>>>
> >>>>>>>>>You need at least MPI_ERROR_CLASS and MPI_ERROR_STRING
> >>>>>>>>>callable before MPI_INIT.
> >>>>>>>>>
> >>>>>>>>>I would prefer solution b together combined with the
> >>>>>>>>>minimal solution for failed MPI_INIT, i.e.,
> >>>>>>>>>adding MPI_ERROR_CLASS and MPI_ERROR_STRING to
> >>>>>>>>>the list of routines callable outside of MPI's
> >>>>>>>>>initialization.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>About 2. question: MPI_T_ERR_CANTINIT -_>
> >>>>>>>>>
> >>>>>>>>>
> >>>>MPI_T_ERR_CANNOTINIT
> >>>>
> >>>>
> >>>>>>>>>svn r1506: done by Bronis in chap-tools/mpit.tex
> >>>>>>>>>svn r1508: done by Rolf in chap-appLang/appLang-Const.tex
> >>>>>>>>>
> >>>>>>>>>Rolf
> >>>>>>>>>
> >>>>>>>>>----- Original Message -----
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>From: "Bronis R. de Supinski" <[email protected]>
> >>>>>>>>>>To: "Main MPI Forum mailing list" <[email protected]
> >>>>>>>>>>
> >>>>>>>>>>
> >>forum.org>
> >>
> >>
> >>>>>>>>>>Cc: "Rolf Rabenseifner" <[email protected]>
> >>>>>>>>>>Sent: Sunday, July 22, 2012 10:03:44 PM
> >>>>>>>>>>Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>MPI_ERR_LASTCODE
> >>>>
> >>>>
> >>>>>>>>>>Rolf:
> >>>>>>>>>>
> >>>>>>>>>>OK, I am changing MPI_T_ERR_CANTINIT to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>MPI_T_ERR_CANNOTINIT.
> >>>>
> >>>>
> >>>>>>>>>>As said before, we need more opinions on the first question.
> >>>>>>>>>>
> >>>>>>>>>>Bronis
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>On Sun, 22 Jul 2012, Bronis R. de Supinski wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Rolf:
> >>>>>>>>>>>
> >>>>>>>>>>>Re:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>Dear Bronis, Martin, Dave, and Kathryn,
> >>>>>>>>>>>>(Profiling/Tools chapter responsibles)
> >>>>>>>>>>>>
> >>>>>>>>>>>>(you may forward this to the tools list - I'm not on that list)
> >>>>>>>>>>>>
> >>>>>>>>>>>>Two important questions:
> >>>>>>>>>>>>
> >>>>>>>>>>>>1. Alexander Supalov detected that we did it wrong:
> >>>>>>>>>>>>The MPI_T_ERR_... list must be part of the total error
> >>>>>>>>>>>>list and sorted in before MPI_ERR_LASTCODE.
> >>>>>>>>>>>>
> >>>>>>>>>>>>I will change this in chap-appLang/appLang-Const.tex
> >>>>>>>>>>>>
> >>>>>>>>>>>>Please look, if there must be some additional wording on this.
> >>>>>>>>>>>>For example, the last sentence of Section 14.3.9
> >>>>>>>>>>>>
> >>>>>>>>>>>>"All return codes with the prefix MPI_T_ must be unique values
> >>>>>>>>>>>>and
> >>>>>>>>>>>>cannot overlap with any other return values returned by the
> MPI
> >>>>>>>>>>>>implementation."
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>The above wording clearly states that the return values
> >>>>>>>>>>>should be consistent with MPI_ERR_* return values. So,
> >>>>>>>>>>>either the above wording needs to change (I do not see
> >>>>>>>>>>>why MPI_T_* return values need to be distinct from
> >>>>>>>>>>>MPI_ERR_* return values since the user should know that
> >>>>>>>>>>>they were using an MPI_T_* function) or we need to adopt
> >>>>>>>>>>>something like what you suggest.
> >>>>>>>>>>>
> >>>>>>>>>>>I think we need broader opinions to make the decision.
> >>>>>>>>>>>
> >>>>>>>>>>>I am concerned that wrapping up the document for MPI 3.0
> >>>>>>>>>>>has led to a fast and loose attitude about making broader
> >>>>>>>>>>>changes "in order to get it done." This attitude can
> >>>>>>>>>>>easily lead to suboptimal solutions.
> >>>>>>>>>>>
> >>>>>>>>>>>Bronis
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>may be modified into
> >>>>>>>>>>>>
> >>>>>>>>>>>>"All return codes with the prefix MPI_T_ must be unique values
> >>>>>>>>>>>>and
> >>>>>>>>>>>>cannot overlap with any other return values returned by the
> MPI
> >>>>>>>>>>>>implementation and satisfy
> >>>>>>>>>>>>
> >>>>>>>>>>>>0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. "
> >>>>>>>>>>>>
> >>>>>>>>>>>>or
> >>>>>>>>>>>>0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <=
> >>>>>>>>>>>>MPI_ERR_LASTCODE.
> >>>>>>>>>>>>
> >>>>>>>>>>>>or
> >>>>>>>>>>>>0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE <
> >>>>>>>>>>>>MPI_T_ERR_... <= MPI_T_ERR_LASTCODE.
> >>>>>>>>>>>>
> >>>>>>>>>>>>and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>may
> >>
> >>
> >>>>be also
> >>>>
> >>>>
> >>>>>>>>>>>>repeated
> >>>>>>>>>>>>in Table 14.5 as last entry, as done for the first value
> >>>>>>>>>>>>MPI_SUCCESS.
> >>>>>>>>>>>>
> >>>>>>>>>>>>This proposal is based on Section 8.4, the sentence
> >>>>>>>>>>>>
> >>>>>>>>>>>>"The error codes satisfy,
> >>>>>>>>>>>>0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: "
> >>>>>>>>>>>>
> >>>>>>>>>>>>Please confirm, that Alexander is right,
> >>>>>>>>>>>>please include me in your discussion and
> >>>>>>>>>>>>please tell me your result
> >>>>>>>>>>>>that I can do the correct changes in chap-appLang
> >>>>>>>>>>>>and you in chap-tools.
> >>>>>>>>>>>>
> >>>>>>>>>>>>2. Qeustion is less important; it is about naming:
> >>>>>>>>>>>>Alexander also noticed that your names do not fit to the names
> >>>>>>>>>>>>used in the past:
> >>>>>>>>>>>>
> >>>>>>>>>>>>MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do
> not
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>use
> >>
> >>
> >>>>>>>>>>>>abbrevations)
> >>>>>>>>>>>>
> >>>>>>>>>>>>or
> >>>>>>>>>>>>
> >>>>>>>>>>>>MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do
> not
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>use
> >>>>
> >>>>
> >>>>>>>>>>>>abbrevations)
> >>>>>>>>>>>>
> >>>>>>>>>>>>In most cases, we do not combine words without underscore.
> >>>>>>>>>>>>
> >>>>>>>>>>>>As far as I see, you can do the underscores.
> >>>>>>>>>>>>Be sure to stay at maximum with 30 characters.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Current longest MPI_T constants:
> >>>>>>>>>>>>
> >>>>>>>>>>>>123456789012345678901234567890
> >>>>>>>>>>>>MPI_T_PVAR_CLASS_HIGHWATERMARK
> >>>>>>>>>>>>MPI_T_PVAR_CLASS_LOWWATERMARK
> >>>>>>>>>>>>MPI_T_VERBOSITY_MPIDEV_DETAIL
> >>>>>>>>>>>>
> >>>>>>>>>>>>Based on this, I would stay with you names based on your MPI_T
> >>>>>>>>>>>>rule:
> >>>>>>>>>>>>MPI_T_<structual-areas-with-underscores>_<final-name-
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>without-
> >>
> >>
> >>>>underscores>
> >>>>
> >>>>
> >>>>>>>>>>>>i.e., I would only change
> >>>>>>>>>>>>
> >>>>>>>>>>>>MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT
> >>>>>>>>>>>>
> >>>>>>>>>>>>Please tell me also your decision
> >>>>>>>>>>>>that I can do the correct changes in chap-appLang
> >>>>>>>>>>>>and you in chap-tools.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Best regards
> >>>>>>>>>>>>Rolf
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>--
> >>>>>>>>>>>>Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>>>>>>>>>>>[email protected]
> >>>>>>>>>>>>High Performance Computing Center (HLRS) . phone
> >>>>>>>>>>>>++49(0)711/685-65530
> >>>>>>>>>>>>University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
> >>>>>>>>>>>>685-65832
> >>>>>>>>>>>>Head of Dpmt Parallel Computing . . .
> >>>>>>>>>>>>www.hlrs.de/people/rabenseifner
> >>>>>>>>>>>>Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring
> >>>>>>>>>>>>30)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>_______________________________________________
> >>>>>>>>>>>mpi-forum mailing list
> >>>>>>>>>>>[email protected]
> >>>>>>>>>>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>--
> >>>>>>>>>Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>>>>>>>>[email protected]
> >>>>>>>>>High Performance Computing Center (HLRS) . phone
> >>>>>>>>>++49(0)711/685-65530
> >>>>>>>>>University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
> >>>>>>>>>685-65832
> >>>>>>>>>Head of Dpmt Parallel Computing . . .
> >>>>>>>>>www.hlrs.de/people/rabenseifner
> >>>>>>>>>Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> >>>>>>>>>_______________________________________________
> >>>>>>>>>mpi-forum mailing list
> >>>>>>>>>[email protected]
> >>>>>>>>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>____________________________________________________________________
> __
> >>
> >>
> >>>>__
> >>>>
> >>>>
> >>>>>>>>Martin Schulz, [email protected], http://people.llnl.gov/schulzm
> >>>>>>>>CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>_______________________________________________
> >>>>>>>>mpi-forum mailing list
> >>>>>>>>[email protected]
> >>>>>>>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>
> >>>>>>>>
> >>>>>>>--
> >>>>>>>Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected]
> >>>>>>>High Performance Computing Center (HLRS) . phone ++49(0)711/685-
> >>>>>>>
> >>>>>>>
> >>>>65530
> >>>>
> >>>>
> >>>>>>>University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> >>>>>>>Head of Dpmt Parallel Computing . . .
> www.hlrs.de/people/rabenseifner
> >>>>>>>Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>____________________________________________________________________
> __
> >>
> >>
> >>>>__
> >>>>
> >>>>
> >>>>>>Martin Schulz, [email protected], http://people.llnl.gov/schulzm
> >>>>>>CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>mpi-forum mailing list
> >>>>>>[email protected]
> >>>>>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>
> >>>>>>
> >>>>>_______________________________________________
> >>>>>mpi-forum mailing list
> >>>>>[email protected]
> >>>>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>
> >>>>>
> >>>>>
> >>>>_______________________________________________
> >>>>mpi-forum mailing list
> >>>>[email protected]
> >>>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>
> >>>>
> >>>_______________________________________________
> >>>mpi-forum mailing list
> >>>[email protected]
> >>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>
> >>>
> >>_______________________________________________
> >>mpi-forum mailing list
> >>[email protected]
> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>
> >>
> >
> >_______________________________________________
> >mpi-forum mailing list
> >[email protected]
> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >
> >
>
> _______________________________________________
> mpi-forum mailing list
> [email protected]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum