Re[2]: RFCS (BIND image)

Bill Kwan <crossc!kwan%ccmail.crosscomm.com@uunet.uu.net> Fri, 08 April 1994 12:18 UTC

Date: Thu, 07 Apr 1994 19:36:17 -0500
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kwan <crossc!kwan%ccmail.crosscomm.com@uunet.uu.net>
Subject: Re[2]: RFCS (BIND image)
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9404080818.aa05575@CNRI.Reston.VA.US>

     No, for 3270, either side can send first. If both side send at the
     same time, the secondary LU wins (i.e., contention winner/first
     speaker). To avoid contention, the primary LU usually bid (using a
     BID request) for the right to send.

     But neither side are allowed to send data before SDT processing is
     complete.


     Regards
     Bill Kwan
     kwan@crosscomm.com

______________________________ Reply Separator _________________________________
Subject: Re: RFCS (BIND image)
Author:  uunet!NEWSIT2.MCDATA.COM!elr0262@crossc.crosscomm.com at inet
Date:    4/7/94 10:57 AM


> > >   ...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
>
I see no reason why the BIND cannot be sent to the client as soon as the server
 has decided it is acceptable.  In PU 2.0 it is my understanding that the
 Primary
LU is the first speaker.  Thus the Secondary LU (client) cannot send anything to
the host until it has rec'd the first message (and Change Direction) from the
host.  (I have been wrong before.)
Eddie Renoux    elr@mcdata.com

Re: RFCS (BIND image) Eddie Renoux
Re[2]: RFCS (BIND image) Bill Kwan