Hi all, The Fault Tolerance Working Group will be reading the following ticket at the September 2019 meeting: Create MPI_INFO_ENV before MPI_INIT Issue #143 <https://github.com/mpi-forum/mpi-issues/issues/143> Pull Request #126 <https://github.com/mpi-forum/mpi-standard/pull/126> Add a new API function for constructing an MPI_INFO_ENV object when one might not exist (or might be wrong). This is sort of in conjunction with the Tools and Sessions working groups. We will also hold a no-no and first vote on the following ticket: Add MPI_ERR_PROC_ABORTED Issue #134 <https://github.com/mpi-forum/mpi-issues/issues/134> Pull Request #112 <https://github.com/mpi-forum/mpi-standard/pull/112> Add the MPI_ERR_PROC_ABORTED error class. No-no text is here: https://github.com/mpi-forum/mpi-standard/pull/112/commits/4872280602dcac861... <https://github.com/mpi-forum/mpi-standard/pull/112/commits/4872280602dcac8619525c945f4a6922632b6492> Finally, we will have a second vote on these two issues: Clarify what MPI_SUCCESS guarantees, and what is left undefined when MPI_ERR_XXX happens Issue #119 <https://github.com/mpi-forum/mpi-issues/issues/119> Pull Request #95 <https://github.com/mpi-forum/mpi-standard/pull/95> The definition of MPI_SUCCESS is a terse "no error returned". When we operate under the assumption that some failure (process, resource, transport, otherwise) may happen, we need to clarify in which cases MPI_SUCCESS is possible, and what it guarantees. For example an implementation may mask errors that do not have a direct consequence on the call semantic. Conversely, we need to clarify what arguments and buffers are valid or undefined after a call has raised an error. Define error/failure behavior in MPI_INIT/FINALIZE Issue #102 <https://github.com/mpi-forum/mpi-issues/issues/102> Pull Request #50 <https://github.com/mpi-forum/mpi-standard/pull/50> Errors before or during MPI_INIT may kill the entire application, which makes initializing MPI a possibly risky proposition in a mixed-mode application. Thanks, Wesley