Can I Really DOUBLE My SDLC Throughput ?
What every SNA gateway owner should know...

Is SNA History Hurting YOU?

If you're responsible for SNA gateways, you have users who depend on you to
 deliver fast, reliable mainframe access. It may surprise you to find out
that  virtually every downstream SDLC device is only using half of the
bandwidth  available to it! That includes 3274 cluster controllers, 3174
establishment  controllers, and SNA gateways.

What!?! I have a full-duplex link and full-duplex modems. I even have my
SDLC  adapter set for full-duplex operation. So what's the problem?
Answer: Your SNA  gateway is still not simultaneously sending and
receiving data. To understand  why, read on and learn a little bit about
mainframe communications history.

Why Most SDLC is Half-Duplex

The original SDLC protocol requires that acknowledgments to frames are
received before more frames are sent. In practice, this means that data
can not be sent  and received at the same time. An enhancement to the
original protocol later  was made to eliminate this problem. However, by
that time, there was lots of  equipment already installed that implemented
the original version. There is a  lot of inertia in communications
standards. In fact, all IBM controllers are  still built this way. When
SNA gateways began to appear on the scene around 1986, most designers
copied the protocol used in the IBM controllers. To this  day, they
effectively waste half of the bandwidth available on full-duplex  links.
This includes the Microsoft SNA Server. But, recovering that lost 
bandwidth is much easier than you might think.

What's DATMODE=FULL (and why should I care)?

It's time to learn a little bit about your mainframe's Virtual 
Telecommunications Access Method (VTAM). It's the program on the mainframe
that controls most outside communications. The hardware that actually
implements  these connections is the Front-End Processor (FEP), running a
Network Control  Program (NCP). VTAM has lots of parameters that tell NCP
how to handle every  link to an outside device. The parameter that tells
the NCP to simultaneously  send and receive data on SDLC links is
DATMODE=FULL. If you don't specify this, the link defaults to
DATMODE=HALF. Then you get to waste up to half of the bandwidth of your
full-duplex lines. If you want to increase your throughput,  you'll have
to teach your SNA Server to speak DATMODE=FULL. And that's where  T1-SYNC
for Windows NT and T1-SYNC for NetWare for SAAcome in.

Even though you never see downstream links using DATMODE=FULL, it is
frequently used for mainframe-to-mainframe SDLC links. The presumption is
that IBM knew  from the beginning that these links would carry high-speed,
bi-directional  traffic.

So Why Do They Have DUPLEX=FULL?

Once you've looked around at a few VTAM parameters, you may also notice one
 that says DUPLEX=FULL. This is not the same thing! Actually, DUPLEX=FULL
does  two things for you. First, it eliminates the line-turnaround time
associated  with raising Request To Send (RTS) and waiting for the modem
to respond with  Clear To Send (CTS) each time you send data or an
acknowledgment. This can save up to 30 milliseconds each time you change
which end is sending. Second,  DUPLEX=FULL allows the FEP to send data to
one device on a multi-drop line  while simultaneously receiving data from
another device on the same line. This  increases the utilization of
multi-drop links, but each downstream device still  can not send and
receive at the same time unless you also specify DATMODE=FULL. 

Can I Really Double My Throughput?

Yes, according to a recent report published by The Tolly Group, formerly
known as InterLAB, and independent testing laboratory. In fact, with some
kinds of  traffic, the throughput increased as much as 114 per cent from
DATMODE=HALF to DATMODE=FULL. Obviously, applications such as file
transfers and situations  where the line is nearly saturated will benefit
most. Amazingly, even when all of the data is flowing in one direction,
throughput increases of 10 to 30  percent were measured. This is a direct
result of the fact that the required  acknowledgments can be received
while data continues to be sent without  interruption.

OK, So How Do I Supercharge My SNA Gateway?

All that is needed on the Microsoft SNA Server gateway is the Barr T1-SYNC 
adapter and the appropriate software. The SDLC link software originally
provided with each of these products does not support DATMODE=FULL, so no
other adapter  can use it. However, T1-SYNC for Windows NT includes new
SDLC link software and  drivers for the T1-SYNC adapter. In fact, the new
release of SNA Server includes the Barr drivers for T1-SYNC right out of
the box.

T1-SYNC is also the fastest SDLC adapter you can put in your gateway. It
can  handle speeds up to T1 (1.536 Mbps) and E1 (2.048 Mbps), or any
fractional T1  link. It also includes drivers and cables for RS232, V.35,
X.21, and RS530  connections. You never have to purchase additional
hardware even if you decide to upgrade your modem or CSU/DSU. The whole
package starts at just $700*. With the high cost of dial-up or dedicated
lines, it will pay for itself in just a  few months.

If you are nearing the upper limit of your SDLC links, or you just want
faster  response times and quicker file transfers, get your SNA gateway up
to speed  now, with Barr's new T1-SYNC.

Barr Systems, Inc
4131 NW 28 Lane
Gainesville, FL  32606-6681
800-BARR-SYS or 904-371-3050

 ============================================================
 From the  'New Product Information'  Electronic News Service
 on AOL (Keyword = New Products) & Delphi (GO BUSINESS PROD)
 ============================================================
 This information was processed from data provided by the
 above mentioned company. For additional details, contact 
 the company at the address or telephone number indicated.
 OmniPage Pro is now used for converting all printed input! 
 ============================================================
 All submissions for this service should be addressed to:
 BAKER ENTERPRISES,  20 Ferro Dr,  Sewell, NJ  08080  U.S.A.
 Email: RBakerPC (AOL/Delphi), rbakerpc@delphi.com (Internet)
 ============================================================
