Re: RFCS (BIND image)

Eddie Renoux <elr0262@newsit2.mcdata.com> Thu, 07 April 1994 17:54 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10355; 7 Apr 94 13:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10351; 7 Apr 94 13:54 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa19707; 7 Apr 94 13:54 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 7185; Thu, 07 Apr 94 13:52:43 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 7183; Thu, 07 Apr 94 12:59:57 EDT
Date: Thu, 7 Apr 1994 10:57:36 -0600
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Eddie Renoux <elr0262@newsit2.mcdata.com>
Subject: Re: RFCS (BIND image)
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: <9404061538.AA21737@newsit2.mcdata.com> from "fab@FAB.MD.INTERLINK.COM" at Apr 6, 94 11:03:10 am
Message-ID: <9404071354.aa19707@CNRI.Reston.VA.US>

> > >   ...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