Re: RFCS

[[e-mail]]

> On Wed, 30 Mar 1994, Tom Butts wrote:
>
> > Section 10.3
> >
> >   "When establishing an SNA session on behalf of a client, the
> >    server will receive a Bind RU from the host application.  It
> >    will also receive a Start Data Traffic RU.  Once both of these
> >    have been responded to positively by the server, it must then
> >    inform the client of the presence of this session by sending it
> >    a data message with the DATA-TYPE flag set to BIND-IMAGE.  The
> >    data portion of this message must contain the bind image exactly
> >    as it was received in the Bind RU that the server accepted on
> >    behalf of the client."
> >
> >   Why not allow the client to see the BIND-IMAGE and respond to it
> >   (positively or negatively)?
>
> Doesn't that just add a level of complication though?  In either case,
> the server is going to have to examine the Bind to make sure that it's
> acceptable (RU sizes, LU type, etc.).  Is there anything gained by having
> the client also examine the Bind, and then having the client and server
> negotiate to come to agreement on whether to accept or reject the Bind?

I agree that this adds another level of complexity which we do not want nor
 need.
This was discussed early in TN3270E discussions and rejected.  Refer to the
archives.

>
> >   ...Also why require the server to keep
> >   a BIND-IMAGE around for each session -- just send it when the server
> >   is going to positively respond to the BIND.
>
> I'm not sure I understand what you're getting at here.  By "keep a
> BIND-IMAGE around for each session" do you mean for the entire life of a
> given session?  The draft simply says that the server must send a copy of
> the Bind image to the client as soon as an SNA session is established;
> whether or not the server hangs on to a given session's associated Bind
> image after that is, I suppose, up to the server.  Or am I missing your
> point?
>
> Thanks,
> Bill

I think his point was that you have to hold the BIND-IMAGE around until the
Start-Data-Traffic flows.  I suppose it means that the client cannot send
data traffic to the server until the server can send that data to Vtam.  It
is a tradeoff of whether to buffer the data traffic or to buffer the BIND-IMAGE.
At least the BIND-IMAGE is of a known, finite size, compared to data traffic.

Is that right Tom?

Fred