<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3627" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=921271506-14012010><FONT face=Arial
color=#0000ff size=2>If JOIN stays, I don't expect IJOIN to be overly
complicated. On the other hand, if no-one uses any of that, why care? We have
enough bells and whistles in the standard already.</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpi3-ft-bounces@lists.mpi-forum.org
[mailto:mpi3-ft-bounces@lists.mpi-forum.org] <B>On Behalf Of </B>Richard
Treumann<BR><B>Sent:</B> Wednesday, January 13, 2010 10:49 PM<BR><B>To:</B> MPI
3.0 Fault Tolerance and Dynamic Process Control working Group<BR><B>Subject:</B>
Re: [Mpi3-ft] Nonblocking Process Creation and Management<BR></FONT><BR></DIV>
<DIV></DIV>
<P>If somebody implemented JOIN without first implementing a basic
ACCEPT/CONNECT I do not think they made good use of their time. JOIN requires
most of the ACCEPT/CONNECT logic anyway. Much easier to implement ACCEPT/CONNECT
and then layer JOIN on top.<BR><BR>What JOIN does is allow a form of
ACCEPT/CONNECT in an environment where PUBLISH_NAME, LOOKUP_NAME, OPEN_PORT are
not very usable.<BR><BR>Why deprecate something like JOIN that is simple to
provide, harmless to have and possibly useful? <BR><BR>You did not answer
whether it is because there is something hard about IJOIN and you want symmetry
with IACCEPT and ICONNECT. <BR><BR><BR>Dick Treumann - MPI Team <BR>IBM Systems
& Technology Group<BR>Dept X2ZA / MS P963 -- 2455 South Road --
Poughkeepsie, NY 12601<BR>Tele (845) 433-7846 Fax (845) 433-8363<BR><BR><BR><IMG
height=16
alt="Inactive hide details for "Supalov, Alexander" ---01/13/2010 04:29:55 PM---Thanks. Good points. Still, I think what you're real"
src="cid:921271506@14012010-1DCD" width=16 border=0><FONT
color=#424282>"Supalov, Alexander" ---01/13/2010 04:29:55 PM---Thanks. Good
points. Still, I think what you're really looking for is a way to say "enough"
before b</FONT><BR><BR>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR vAlign=top>
<TD width="1%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=96 border=0><BR><FONT color=#5f5f5f size=2>From:</FONT></TD>
<TD width="100%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=1 border=0><BR><FONT size=2>"Supalov, Alexander"
<alexander.supalov@intel.com></FONT></TD></TR>
<TR vAlign=top>
<TD width="1%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=96 border=0><BR><FONT color=#5f5f5f size=2>To:</FONT></TD>
<TD width="100%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=1 border=0><BR><FONT size=2>"MPI 3.0 Fault Tolerance and Dynamic
Process Control working Group"
<mpi3-ft@lists.mpi-forum.org></FONT></TD></TR>
<TR vAlign=top>
<TD width="1%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=96 border=0><BR><FONT color=#5f5f5f size=2>Date:</FONT></TD>
<TD width="100%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=1 border=0><BR><FONT size=2>01/13/2010 04:29 PM</FONT></TD></TR>
<TR vAlign=top>
<TD width="1%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=96 border=0><BR><FONT color=#5f5f5f size=2>Subject:</FONT></TD>
<TD width="100%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=1 border=0><BR><FONT size=2>Re: [Mpi3-ft] Nonblocking Process
Creation and Management</FONT></TD></TR>
<TR vAlign=top>
<TD width="1%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=96 border=0><BR><FONT color=#5f5f5f size=2>Sent by:</FONT></TD>
<TD width="100%"><IMG height=1 alt="" src="cid:921271506@14012010-1DD4"
width=1 border=0><BR><FONT
size=2>mpi3-ft-bounces@lists.mpi-forum.org</FONT></TD></TR></TBODY></TABLE>
<HR style="COLOR: #8091a5" align=left width="100%" noShade SIZE=2>
<BR><BR><BR><FONT face=Arial color=#0000ff>Thanks. Good points. Still, I think
what you're really looking for is a way to say "enough" before basically closing
something down. This is less general than the individual ability to CANCEL this
and that at will at any time: flexible, yes, but cumbersome enough to be
asserted out in one of the proposals.</FONT><BR><FONT size=4></FONT><BR><FONT
face=Arial color=#0000ff>Anyway, we may want to leave CANCEL alone for the
moment. Let's get back to JOIN. Are there any apps out there that use it still?
I think this was a hack to get around the temporary unavailability of the proper
accept/connect back then. If the hack has lived its useful life, we may want to
deprecate it now.</FONT><BR><BR>
<HR align=left width="100%" SIZE=2>
<B><FONT face=Tahoma>From:</FONT></B><FONT face=Tahoma>
mpi3-ft-bounces@lists.mpi-forum.org [</FONT><FONT face=Tahoma><A
href="mailto:mpi3-ft-bounces@lists.mpi-forum.org">mailto:mpi3-ft-bounces@lists.mpi-forum.org</A></FONT><FONT
face=Tahoma>] </FONT><B><FONT face=Tahoma>On Behalf Of </FONT></B><FONT
face=Tahoma>Richard Treumann</FONT><B><FONT
face=Tahoma><BR>Sent:</FONT></B><FONT face=Tahoma> Wednesday, January 13, 2010
10:19 PM</FONT><B><FONT face=Tahoma><BR>To:</FONT></B><FONT face=Tahoma> MPI 3.0
Fault Tolerance and Dynamic Process Control working Group</FONT><B><FONT
face=Tahoma><BR>Subject:</FONT></B><FONT face=Tahoma> Re: [Mpi3-ft] Nonblocking
Process Creation and Management</FONT><FONT size=4><BR></FONT>
<P><FONT size=4>An application that is really trying to do overlap of
communication and computation is likely to post Isends and Irecvs before
entering a computation step. If the computation step discovers the answer and
another iteration is not needed then why require all the sends and receives to
be done? The application already knows the data is useless.<BR><BR>A
master/worker application may have an outstanding MPI_Irecv at each worker with
tag 1 to pick up workload and an outstanding MPI_Irecv with tag 2 that is
looking for the "all done" message. When the "all done" shows up, the workload
MPI_Irecv needs to be completed before a disconnect can proceed. Why make the
master send a null workload to each worker just to clear those obsolete
MPI_Irecvs?<BR><BR>The standard has several points at which it states that all
outstanding sends and receives must be complete. If an Isend or Irecv has been
posted there are 2 ways to complete it: Make the matching Send or Recv happen or
call MPI_Cancel. The pair of operations MPI_Cancel; MPI_Wait will always
complete no matter what the other side does. As long as the application does not
care whether the data is delivered, this is a clean way to satisfy the
requirement that all outstanding sends and receives must be complete.<BR><BR>I
have not been following the FT stuff but it seems like MPI_Cancel would be
useful there. If I have posted an MPI_Irecv from task 9 and then learned task 9
is gone why wouldn't I want the option of doing an MPI_Cancel on the MPI_Irecv
request? That seems cleaner than any other way of getting rid of the receive
descriptor.<BR><BR><BR>Dick Treumann - MPI Team <BR>IBM Systems & Technology
Group<BR>Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY
12601<BR>Tele (845) 433-7846 Fax (845) 433-8363<BR><BR><BR></FONT><IMG height=16
alt='Inactive hide details for "Supalov, Alexander" ---01/13/2010 03:52:11 PM---Thanks. Do we know any active app that uses the JOIN'
src="cid:921271506@14012010-1DCD" width=16><FONT color=#424282 size=4>"Supalov,
Alexander" ---01/13/2010 03:52:11 PM---Thanks. Do we know any active app that
uses the JOIN still? If none, why the heck keep it afloat? I</FONT><FONT
size=4><BR></FONT>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR vAlign=top>
<TD width="15%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f><BR>From:</FONT></TD>
<TD width="85%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><BR>"Supalov, Alexander" <alexander.supalov@intel.com></TD></TR>
<TR vAlign=top>
<TD width="15%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f><BR>To:</FONT></TD>
<TD width="85%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><BR>"MPI 3.0 Fault Tolerance and Dynamic Process Control working
Group" <mpi3-ft@lists.mpi-forum.org></TD></TR>
<TR vAlign=top>
<TD width="15%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f><BR>Date:</FONT></TD>
<TD width="85%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><BR>01/13/2010 03:52 PM</TD></TR>
<TR vAlign=top>
<TD width="15%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f><BR>Subject:</FONT></TD>
<TD width="85%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><BR>Re: [Mpi3-ft] Nonblocking Process Creation and
Management</TD></TR>
<TR vAlign=top>
<TD width="15%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f><BR>Sent by:</FONT></TD>
<TD width="85%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><BR>mpi3-ft-bounces@lists.mpi-forum.org</TD></TR></TBODY></TABLE>
<HR align=left width="100%" noShade SIZE=2>
<FONT size=4><BR><BR></FONT><FONT face=Arial color=#0000ff size=4><BR>Thanks. Do
we know any active app that uses the JOIN still? If none, why the heck keep it
afloat?</FONT><FONT size=4><BR></FONT><FONT face=Arial color=#0000ff
size=4><BR>I meant CANCEL in all its varieties. Again, how many apps cannot live
without it?</FONT><FONT size=4><BR><BR></FONT>
<HR align=left width="100%" SIZE=2>
<B><FONT face=Tahoma size=4>From:</FONT></B><FONT face=Tahoma size=4>
mpi3-ft-bounces@lists.mpi-forum.org [</FONT><A
href="mailto:mpi3-ft-bounces@lists.mpi-forum.org"><U><FONT face=Tahoma
color=#0000ff
size=4>mailto:mpi3-ft-bounces@lists.mpi-forum.org</FONT></U></A><FONT
face=Tahoma size=4>] </FONT><B><FONT face=Tahoma size=4>On Behalf Of
</FONT></B><FONT face=Tahoma size=4>Richard Treumann</FONT><B><FONT face=Tahoma
size=4><BR>Sent:</FONT></B><FONT face=Tahoma size=4> Wednesday, January 13, 2010
9:48 PM</FONT><B><FONT face=Tahoma size=4><BR>To:</FONT></B><FONT face=Tahoma
size=4> MPI 3.0 Fault Tolerance and Dynamic Process Control working
Group</FONT><B><FONT face=Tahoma size=4><BR>Subject:</FONT></B><FONT face=Tahoma
size=4> Re: [Mpi3-ft] Nonblocking Process Creation and Management</FONT>
<P><FONT size=5>Why would JOIN be any less useful today than in the past? Why
would you want to deprecate it? It is a trivial bootstrap for the simplest form
of ACCEPT/CONNECT. It just hides the ACCEPT and CONNECT operations and lets the
user handle the complexity of identifying the two end points any way he likes.
<BR><BR>I never felt JOIN was needed very badly but it went in as a "what the
heck" decision and I do not see that anything has changed.<BR><BR>Is it because
IJOIN seems more difficult than IACCEPT and ICONNECT in some way?<BR><BR>When
you say CANCEL should be deprecated, do you mean MPI_Cancel of an outstanding
ISEND/IRECV request or something else?<BR><BR>Dick Treumann - MPI Team <BR>IBM
Systems & Technology Group<BR>Dept X2ZA / MS P963 -- 2455 South Road --
Poughkeepsie, NY 12601<BR>Tele (845) 433-7846 Fax (845)
433-8363<BR><BR></FONT><FONT size=4><BR></FONT><IMG height=16
alt='Inactive hide details for "Supalov, Alexander" ---01/13/2010 02:53:18 PM---Thanks. I meant the JOIN per se as a way of establis'
src="cid:921271506@14012010-1DCD" width=16><FONT color=#424282 size=5>"Supalov,
Alexander" ---01/13/2010 02:53:18 PM---Thanks. I meant the JOIN per se as a way
of establishing the communicator. Do we need that still? Wh</FONT>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR vAlign=top>
<TD width="13%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f size=4><BR>From:</FONT></TD>
<TD width="87%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><FONT size=4><BR>"Supalov, Alexander"
<alexander.supalov@intel.com></FONT></TD></TR>
<TR vAlign=top>
<TD width="13%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f size=4><BR>To:</FONT></TD>
<TD width="87%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><FONT size=4><BR>"MPI 3.0 Fault Tolerance and Dynamic Process
Control working Group" <mpi3-ft@lists.mpi-forum.org></FONT></TD></TR>
<TR vAlign=top>
<TD width="13%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f size=4><BR>Date:</FONT></TD>
<TD width="87%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><FONT size=4><BR>01/13/2010 02:53 PM</FONT></TD></TR>
<TR vAlign=top>
<TD width="13%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f size=4><BR>Subject:</FONT></TD>
<TD width="87%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><FONT size=4><BR>Re: [Mpi3-ft] Nonblocking Process Creation and
Management</FONT></TD></TR>
<TR vAlign=top>
<TD width="13%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=96><FONT color=#5f5f5f size=4><BR>Sent by:</FONT></TD>
<TD width="87%"><IMG height=1 src="cid:921271506@14012010-1DD4"
width=1><FONT
size=4><BR>mpi3-ft-bounces@lists.mpi-forum.org</FONT></TD></TR></TBODY></TABLE>
<HR align=left width="100%" noShade SIZE=2>
<FONT size=5><BR></FONT><TT><FONT size=5><BR><BR>Thanks. I meant the JOIN per se
as a way of establishing the communicator. Do we need that still? What
practically relevant cases can be provided to justify its continuing existence?
If there are none, we should rather deprecate the JOIN and drop the
IJOIN.<BR><BR>Good point on the CANCEL.<BR><BR>-----Original
Message-----<BR>From: mpi3-ft-bounces@lists.mpi-forum.org [</FONT></TT><A
href="mailto:mpi3-ft-bounces@lists.mpi-forum.org"><TT><U><FONT color=#0000ff
size=5>mailto:mpi3-ft-bounces@lists.mpi-forum.org</FONT></U></TT></A><TT><FONT
size=5>] On Behalf Of Josh Hursey<BR>Sent: Wednesday, January 13, 2010 8:25
PM<BR>To: MPI 3.0 Fault Tolerance and Dynamic Process Control working
Group<BR>Subject: Re: [Mpi3-ft] Nonblocking Process Creation and
Management<BR><BR>Since join() does a handshake to create the new communicator,
it <BR>should be delayed by the remote side of the protocol. A nonblocking
<BR>version would allow the application to possibly do other computation
<BR>while waiting for the remote side.<BR><BR>As far as Cancel, I have
been thinking that it might be useful for <BR>Accept and Connect. Though
with the normal problems of Cancel, I don't <BR>know how to really specify
it. I want to look into it a bit more <BR>before next week to see if
anything useful can be said of using Cancel <BR>with
Accept/Connect.<BR><BR>-- Josh<BR><BR>On Jan 13, 2010, at 2:01 PM, Supalov,
Alexander wrote:<BR><BR>> Hi,<BR>><BR>> Do we really need the IJOIN
thing? I think the JOIN itself should be <BR>> deprecated. Just as
CANCEL, by the way.<BR>><BR>> Best regards.<BR>><BR>>
Alexander<BR>><BR>> -----Original Message-----<BR>> From:
mpi3-ft-bounces@lists.mpi-forum.org [</FONT></TT><A
href="mailto:mpi3-ft-bounces@lists.mpi-forum.org"><TT><U><FONT color=#0000ff
size=5>mailto:mpi3-ft-bounces@lists.mpi-forum.org</FONT></U></TT></A><TT><FONT
size=5> <BR>> ] On Behalf Of Josh Hursey<BR>> Sent: Tuesday, January
12, 2010 11:04 PM<BR>> To: MPI 3.0 Fault Tolerance and Dynamic Process
Control working Group<BR>> Subject: [Mpi3-ft] Nonblocking Process Creation
and Management<BR>><BR>> I extended and cleaned up the Nonblocking Process
Creation and<BR>> Management proposal on the wiki:<BR>>
</FONT></TT><A
href="https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Async-proc-mgmt"><TT><U><FONT
color=#0000ff
size=5>https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Async-proc-mgmt</FONT></U></TT></A><TT><FONT
size=5><BR>><BR>> I added the rest of the nonblocking interface proposals,
and touched<BR>> up some of the language. I do not have an implementation
yet, but will<BR>> work on that next. There are a few items that I need to
refine a bit<BR>> still (e.g., MPI_Cancel, mixing of blocking and
nonblocking), but this<BR>> should give us a foundation to start
from.<BR>><BR>> I would like to talk about this next week during our
working group<BR>> slot at the MPI Forum meeting.<BR>><BR>> Let me know
what you think, and if you see any problems.<BR>><BR>> Thanks,<BR>>
Josh<BR>><BR>> _______________________________________________<BR>>
mpi3-ft mailing list<BR>> mpi3-ft@lists.mpi-forum.org<BR>> </FONT></TT><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><TT><U><FONT
color=#0000ff
size=5>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</FONT></U></TT></A><TT><FONT
size=5><BR>>
---------------------------------------------------------------------<BR>>
Intel GmbH<BR>> Dornacher Strasse 1<BR>> 85622 Feldkirchen/Muenchen
Germany<BR>> Sitz der Gesellschaft: Feldkirchen bei Muenchen<BR>>
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer<BR>>
Registergericht: Muenchen HRB 47456 Ust.-IdNr.<BR>> VAT Registration No.:
DE129385895<BR>> Citibank Frankfurt (BLZ 502 109 00)
600119052<BR>><BR>> This e-mail and any attachments may contain
confidential material for<BR>> the sole use of the intended recipient(s). Any
review or distribution<BR>> by others is strictly prohibited. If you are not
the intended<BR>> recipient, please contact the sender and delete all
copies.<BR>><BR>><BR>>
_______________________________________________<BR>> mpi3-ft mailing
list<BR>> mpi3-ft@lists.mpi-forum.org<BR>> </FONT></TT><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><TT><U><FONT
color=#0000ff
size=5>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</FONT></U></TT></A><TT><FONT
size=5><BR><BR>_______________________________________________<BR>mpi3-ft
mailing list<BR>mpi3-ft@lists.mpi-forum.org</FONT></TT><U><FONT color=#0000ff
size=4><BR></FONT></U><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><TT><U><FONT
color=#0000ff
size=5>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</FONT></U></TT></A><TT><FONT
size=5><BR>---------------------------------------------------------------------<BR>Intel
GmbH<BR>Dornacher Strasse 1<BR>85622 Feldkirchen/Muenchen Germany<BR>Sitz der
Gesellschaft: Feldkirchen bei Muenchen<BR>Geschaeftsfuehrer: Douglas Lusk, Peter
Gleissner, Hannes Schwaderer<BR>Registergericht: Muenchen HRB 47456
Ust.-IdNr.<BR>VAT Registration No.: DE129385895<BR>Citibank Frankfurt (BLZ 502
109 00) 600119052<BR><BR>This e-mail and any attachments may contain
confidential material for<BR>the sole use of the intended recipient(s). Any
review or distribution<BR>by others is strictly prohibited. If you are not the
intended<BR>recipient, please contact the sender and delete all
copies.<BR><BR><BR>_______________________________________________<BR>mpi3-ft
mailing list<BR>mpi3-ft@lists.mpi-forum.org</FONT></TT><U><FONT color=#0000ff
size=4><BR></FONT></U><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><TT><U><FONT
color=#0000ff
size=5>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</FONT></U></TT></A><FONT
size=5><BR></FONT><FONT size=4><BR></FONT><TT><FONT
size=5><BR>---------------------------------------------------------------------<BR>Intel
GmbH<BR>Dornacher Strasse 1<BR>85622 Feldkirchen/Muenchen Germany<BR>Sitz der
Gesellschaft: Feldkirchen bei Muenchen<BR>Geschaeftsfuehrer: Douglas Lusk, Peter
Gleissner, Hannes Schwaderer<BR>Registergericht: Muenchen HRB 47456
Ust.-IdNr.<BR>VAT Registration No.: DE129385895<BR>Citibank Frankfurt (BLZ 502
109 00) 600119052<BR><BR>This e-mail and any attachments may contain
confidential material for<BR>the sole use of the intended recipient(s). Any
review or distribution<BR>by others is strictly prohibited. If you are not the
intended<BR>recipient, please contact the sender and delete all
copies.</FONT></TT><TT><FONT
size=4><BR>_______________________________________________<BR>mpi3-ft mailing
list<BR>mpi3-ft@lists.mpi-forum.org</FONT></TT><TT><U><FONT color=#0000ff
size=4><BR></FONT></U></TT><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><TT><U><FONT
color=#0000ff
size=4>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</FONT></U></TT></A><FONT
size=4><BR><BR></FONT><BR><TT><FONT
size=4>---------------------------------------------------------------------<BR>Intel
GmbH<BR>Dornacher Strasse 1<BR>85622 Feldkirchen/Muenchen Germany<BR>Sitz der
Gesellschaft: Feldkirchen bei Muenchen<BR>Geschaeftsfuehrer: Douglas Lusk, Peter
Gleissner, Hannes Schwaderer<BR>Registergericht: Muenchen HRB 47456
Ust.-IdNr.<BR>VAT Registration No.: DE129385895<BR>Citibank Frankfurt (BLZ 502
109 00) 600119052<BR><BR>This e-mail and any attachments may contain
confidential material for<BR>the sole use of the intended recipient(s). Any
review or distribution<BR>by others is strictly prohibited. If you are not the
intended<BR>recipient, please contact the sender and delete all
copies.<BR></FONT></TT><TT>_______________________________________________<BR>mpi3-ft
mailing list<BR>mpi3-ft@lists.mpi-forum.org<BR></TT><TT><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</A></TT><TT><BR></TT><BR><BR><pre>---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
</pre></BODY></HTML>