Jeff and Fab, I would say that the content is fine, but it would also be as same as good when you combine and shorten some entries, to reduce the total number to 2 entries, and I would add a simple sentence about compatibility in the last one: 2. Sections 2.5.8, 3.2.2, 3.3 on pages 16, 29, 31, Sections 4.1.5, 4.1.7, 4.1.8, 4.1.11, 5.9.2 on pages 97, 99, 101, 105, 172, Section 12.3 on page 412, and Appendix A.1.1 on page 545. New inquiry functions, MPI_TYPE_SIZE_X, MPI_TYPE_GET_EXTENT_X, MPI_TYPE_GET_TRUE_EXTENT_X, and MPI_GET_ELEMENTS_X, return their results as an MPI_Count value, which is a new type large enough to represent element counts in memory, file views, etc. A new function, MPI_STATUS_SET_ELEMENTS_X, modifies the opaque part of MPI_STATUS so that a call to MPI_GET_ELEMENTS_X returns the provided MPI_Count value. 3. Sections 3.2.5, 4.1.5, 4.1.11, 4.2 on pages 34, 97, 105, and 127. The functions MPI_GET_COUNT, MPI_TYPE_SIZE, MPI_GET_ELEMENTS, and MPI_PACK_SIZE are now defined to set the count, resp. size parameter to MPI_UNDEFINED when that parameter would overflows. In all other MPI-2.2 routines, the type and semantics of the count arguments are kept unchanged, i.e., int or INTEGER. ----- With this all locations are mentioned, all new functionality is mentioned, and that's what is needed for both users and implementors. Details can be taken from the cited sections. I'm sorry for the late answer - first I've overseen the mail (therefore I now added "Ticket 265" in the Subject) - and second, I'm still on Easter break. Best regards Rolf ----- Original Message -----

From: "Jeff Squyres" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> Sent: Friday, April 22, 2011 5:11:26 PM Subject: Re: [Mpi-forum] Changelog question Rolf -- How's this? (see attached; the rendered text didn't copy-n-paste well into a plain-text email)

I honestly don't have too much of an opinion here -- Fab and I put together what we think Rolf wanted, but it *does* seem like a little overkill.

The only think I have a slight reservation about is that this sets a high bar for all other MPI-3 proposals -- e.g., will the one-sided chapter need to have changelog entries for every new function (because they're interleaved; it's not like NBC or MPI_T that just added whole new sections).

Or should we have a single new changelog entry, perhaps with a table or list of all the new functions?

(I see that Rolf made 13 new changelog entries for the Fortran 08 stuff -- https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/ticket/229/mpi-r...)

On Apr 21, 2011, at 7:15 AM, Rolf Rabenseifner wrote:

...

Yes, of course, but I thought that the MPI_Count ticket has only about 6 new routines, similar to the two entries 17 and 18 on MPI-2.2 pages 594 and 595 about the MPI_DIST_GRAPH_... routines.

If a whole new main chapter is added, then typically only one ticket is added, without mentioning 20 routines.

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ 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)