U0A61@WVNVM.WVNET.EDU ("Bryan, Jerry") (05/01/89)
A couple or three months ago I posted a question to the IBMTCP-L for
which I did not receive an answer. I now have the answer from first
hand experience, and I going going to cross-post it to the PC-IP list
and to the IBMTCP-L list as I think it would be beneficial to both
audiences.
The question was "what is it like to run the IBM TCP/IP product on your
PC for terminal emulation and file transfer?". I was coming at the
question from the point of view of one who was familiar with TCP/IP on
mainframes and minis, but not on PC's. I was also coming at the
question from the point of view of one who was familiar with what might
be called more traditional PC to mainframe connectivity products, such
as coax boards (e.g.,IBM 3270 boards and IRMA boards) and serial port
products such as KERMIT, YTERM, and PROCOMM. This is the sort of
comparison I will be making. I will not be comparing the IBM TCP/IP
product with any other TCP/IP product because IBM's product is the only
one with which I am familiar on a PC. Be forewarned that this is a
fairly long discussion, but this is the sort of information that I would
have liked to have had prior to our decision to go with TCP/IP on some
of our PC's.
TERMINAL EMULATION
First of all, IBM's TCP/IP product for the PC is not a Terminate Stay
Resident program. That is, it is not "always there" and available via a
hot key sequence. It does require that a driver for your Ethernet board
be specified in CONFIG.SYS, but the driver typically is only a few
hundred bytes long, and the driver does not contribute towards
maintaining any sense of of the program being "always there". In this
vein, it is similar to KERMIT and PROCOMM which have to be invoked for
each use, but is very different from IRMA and the IBM 3270 board and
program which are available via hot key. YTERM, by the way, is sort of
half way inbetween. It has a Terminate Stay Resident portion which is
considerably more than "just a driver", but it still is not available
via a hot key, requiring the execution of a second program instead. Most
of our staff in the computing center who have PC's have IBM's 3270
boards, and it appears that the lack of hot key invocation will be a big
obstacle to the ready acceptance of IBM's TCP/IP product for terminal
emulation.
IBM's product is invoked from the DOS prompt via the following command:
TELNET hostname
The "hostname" portion of the command is a small but vital difference
from the other products I am discussing. With the other products, no
host is specified because your are pretty much implicitly bound to a
particular host. If you have a coax card, you are bound to a particular
controller on a particular host. You may be able to get to other hosts
through the good graces of VTAM and SNA, but you you have to start with
a particular host. If you use a serial port, and your serial port is in
turn connected to a port on a host, you must start with that host in the
same way as you do with a coax card (except that it might be DECNET or
some such instead of SNA that gets you out of your host). If your serial
port is connected to a modem, your computer network is the phone system,
and your connectivity becomes whatever you can dial. If your serial port
is connected to a port on a data switch, your connectivity becomes
whatever your data switch can switch you to. Irrespective of the exact
connectivity with the other products, your connectivity is almost
certainly a master/slave relationship, with your PC being a slave to a
mainframe.
With TCP/IP, you are not bound to a particular host but instead you have
immediate peer to peer access to any host on your network which supports
TCP/IP. If you are lucky enough to be on the Internet, this might be as
many as 50,000 different hosts.
"hostname" can be an IBM or a non-IBM host. In the case of an IBM host,
the IBM product emulates a 3270 terminal. In the case of a non-IBM
host, the IBM product emulates an ASCII terminal. The version I have
emulates a Heath 19, which is not a very good ASCII terminal. I
understand that there either is now, or soon will be, a version which
supports a VT100, which will be a big improvement. Since I use both IBM
and VAX systems, and since the coax board I had before I got the
Ethernet board would not let me get into the VAX's, the Ethernet board
is a big improvement for me getting into the ASCII world.
I tend to think of the 3270 emulation as not being very good, although
this is certainly a matter of opinion and although the 3270 emulation
certainly has its strong points. Here are a number of points concerning
the emulation:
1. The default keyboard mapping is quite reasonable, and is quite easy
to change.
2. Four colors are supported. Seven colors are not supported. The
emulation is of CUT terminals rather than DFT terminals. ("CUT"
is Control Unit Terminal, or old 3270 terminals. "DFT" is
Distributed Function Terminal, or new 3270 terminals.)
The default colors are reasonable, and the defaults are quite easy
to change.
I consider the four color restriction to be a serious flaw. Just
look at OMEGAMON, for example, on a seven color terminal instead of
a four color terminal to see the difference.
In addition, I see the CUT instead of DFT support to be a serious
flaw. For example, with CUT terminals there must be a space on the
screen between fields, and colors can be changed only on a new
field. With DFT terminals, adjacent characters on the screen can be
different colors. I run into this flaw all the time using the
PROFS spelling checker. I tend to use the checker for any outbound
mail of any significant size. I have extended my spelling
dictionaries to include the userids and host names of my most
frequent correspondents. However, if I have an address of the form
userid@address and either "userid" or "address" is not in the
dictionary (but the other one is), the whole string is highlighted
and it is hard to tell which part is bad. The problem is not a
PROFS problem but a CUT terminal problem.
3. 3270 graphics are not supported. I will try to keep this entire
exposition at an entirely professional level, but I get quite
emotional about this point. This is far and away the worst
deficiency in the product. I want to run SAS/GRAPH from the
mainframe on my PC emulating a terminal, and I cannot.
In fairness to the developers of the TCP/IP product, IBM's entire
PC connectivity product line is woefully deficient concerning
mainframe graphics on a PC, so it is not just TCP/IP which has this
problem. (Correction, mainframe graphics works well on a PC3270 or
AT3270, but these machines are not "real" PC's in some sense. Also,
they have been withdrawn from marketing and there are no PS/2
equivalents, to my knowledge). Mainframe graphics on a PC is
available, but it is generally difficult to get all the pieces in
place, or expensive, or both. In particular, you cannot simply go
out and buy IBM's 3270 board and software and put it in your PC and
have graphics.
Again, trying to maintain professionalism and stay away from
emotionalism, this is an area where a Mac beats the fool out of
IBM. We have all IBM's (or clones) at the computing center, but
the Computer Science department has mostly Mac's. Computer Science
professors are rather fond of showing us TN3270 (really, MAC3270)
running glorious color SAS/GRAPH graphics from their Mac's on our
VM system, and challenging us to do the same thing on our IBM's. Of
course, we can't. I generally like IBM hardware and software, and
I really don't want a Mac on my desk. But IBM, please, please,
please fix this. And fix it not just in TCP/IP, but all across the
PC and PS/2 product line. Any PC or PS/2 product than can emulate
a terminal should do mainframe graphics.
This is off the subject I am currently on, but VT220 emulation
would be an improvement even over VT100 emulation in the ASCII
world, and should be trivial once the VT100 support is there.
However, even better (and not so trivial) would be VT340 or VT341
emulation so that I could do graphics or color graphics into a VAX.
Or maybe a good Tektronics emulation could be provided. But I would
settle for graphics into the IBM world.
4. The IBM implementation of 3270 TELNET in TCP/IP very faithfully
emulates the synchronous nature of 3270 communications. This is
second in badness only to the lack of graphics. The keyboard is
forever locking just when you don't want it locked. Users of 7171
terminal emulation (or other variations such as Series/1 or 4994)
will not like the locked keyboard and the lack of type ahead.
I use TCP/IP at work, and KERMIT (VT100 emulation) plus 7171 at
home. TCP/IP on an ethernet is generally much faster and nicer
than KERMIT at 2400 baud. However, notwithstanding the speed of
TCP/IP on an Ethernet, there are a lot of things that are a lot
faster and nicer at home, simply because of the 7171's unlocked
keyboard and type ahead. I am forever flicking a couple of PFK's
in quick sequence at work like I do at home, only to have the darn
thing beep at me. Of course, other 7171 features such as column
tabs and indent/undent are also not supported, but type ahead is
far and away the most important to me. Finally, it is slow, but if
I am willing to wait, I can run graphics (Tektronics emulation with
SAS/GRAPH) through KERMIT at home. I can't do this at all at any
speed at work.
5. The IBM implementation of 3270 TELNET in TCP/IP very faithfully
emulates the standard 3270 processing of null characters. This is
another case, like type ahead, where a 7171 does it correctly, but
a 3174 does it wrong, and TCP/IP is emulating a 3174. I think that
most of you are familiar with the phenomenon, but 3174's make a
major distinction between nulls and blanks. On the one hand, if
you prefill fields with blanks, your insert key will not work. On
the other hand, if you prefill fields with nulls, the nulls
disappear into nothingness when you hit enter, often causing the
alignment of the data you entered to be destroyed.
With real 3270 controllers and VM, there is sort of a workaround
for the problem. That is, if you set NULLS ON and FULLREAD ON,
things pretty much work correctly. In fact, there is a quite
accurate and surprisingly frank discussion of the problem in the VM
help files for FULLREAD ON. However, I am not aware of any
similar workaround on MVS. Also, FULLREAD ON can have adverse
effects on the performance of your network.
For reasons I do not entirely understand, the NULLS ON plus
FULLREAD ON trick does not work under TCP/IP. I problem is, I
think, in CP's virtual terminal support. This problem is in the
mainframe, and exists whether you are accessing the mainframe from
a PC running TCP/IP, or whether (for example) a real 3270 terminal
on one mainframe is using TCP/IP to access another IBM mainframe.
Thus, a part of the fix for the nulls problem would be in the PC
code for TCP/IP, but a part would also be in the mainframe.
6. When you are in a TELNET session with a host, you cannot terminate
TELNET without losing the session with the host. By contrast, you
can shut down KERMIT, do something else for a while, re-invoke
KERMIT, and be right back where you left off. Also, with Terminate
Stay Resident programs with a hot key, it is trivial to go back to
the PC while maintaining your mainframe session.
On the other hand, IBM's TELNET does let you enter an escape
sequence (control right-bracket, exclamation point, if anybody
cares) to invoke a second level DOS from your TELNET session. Thus,
there really is a way to maintain your session while using DOS.
Doing so is fairly expensive of memory (I am writing this at home
and do not have the exact numbers, but it is a lot). Therefore, I
often cannot do what I want to do on the PC without shutting down
the TELNET session. In addition, even when I do escape from TELNET
to a second level DOS (PUSHing in KERMIT terminology), I often find
that when I EXIT from the second level DOS back to TELNET, that my
session is gone some how or other. There is a timeout going on that
I don't understand and don't know how to get rid of.
7. When you issue "TELNET hostname" into a VM host, you find yourself
looking at a CP logo. For many (perhaps most) of you, that is
normal and what you would expect. We control our terminals
exclusively with VTAM, and the CP logo is a bit of a shock if you
are expecting to see the VTAM logo. I normally DIAL VTAM, and
UNDIAL when I am done, but I would like to see an option whereby
TELNET goes straight to VTAM.
From VTAM, I can get into our SNA network, accessing hosts which
are not running TCP/IP. For example, I run TSO and CICS all the
time through TCP/IP even though we do not run TCP/IP on MVS. This
is an excellent feature of the combination of TCP/IP with SNA.
On this subject, I know there is still a lot of residual resistance
to VTAM and SNA among VM systems programmers. I remember the first
SHARE after the announcement of the 7171, and there was a question
in a 7171 session to the effect of "why was there not an SNA
version of 7171". The question was roundly booed by the audience.
This was before there was decent SNA support for VM -- the only
support was the silly VCNA thing where you had to run VTAM under a
VS/1 guest. Whatever else you may think, IBM did VTAM for VM
right! It is an extremely solid product. There are more and more
sites with both VM and MVS, more and more systems programmers are
conversant with both systems, and even VM-only shops often have
connectivity needs that cannot be met easily without SNA. I would
urge you not to dismiss VTAM and SNA out of hand.
8. We run our TCP/IP network on thinwire Ethernet, through a BTI
controller into our VM machine. In this environment, the terminal
session seems to react much more crisply than it does using a 3270
board coax attached to a local 3274 controller. A 3174 might make
a difference, because it has a faster processor than a 3274, but
our TCP/IP is definitely faster than a local 3274.
This is a little surprising, because the 3274 is running at channel
speeds. However, the 3274 controller to 3270 terminal connection
over coax is really only running at 38.4 KB. The moral of the
story is that local 3270's are not as fast as you always thought.
This is also surprising because a PC with a 3270 board has only
VTAM between itself and CP at our shop, whereas a PC running TCP/IP
has both VTAM and TCP/IP between itself and CP. You always worry
about performance when you start adding too many layers of
software, but the TCP/IP layer has not been a problem for us.
9. When the IBM TELNET implementation "beeps" at you, it is a strange
sort of swishing sound, not a real beep. It was strange at first,
but I think I like it much better than a real beep.
10. I have found only one real bug in the software. I occasionally run
a CICS application which has multiple non-display fields. The only
time a VM programmer would normally see a non-display field would
be for entry of a password, but this particular application uses
non-display fields for other things. Anyway, the way a 3270 works,
when you type in a complete field, the cursor automatically jumps
to the next field without you having to enter the field tab key.
The IBM TELNET implementation emulates this behavior correctly in
most cases, but it does not seem to work correctly if the fields
involved are non-display. You get a beep and you have to field tab
yourself at a time when the cursor should have moved automatically.
The application works correctly on a real 3270, on a 3270 board on
a PC, and through the 7171, so the error has to be in the PC's
TCP/IP code. Other than that one error, the code seems extremely
clean and robust.
11. IBM's TCP/IP product does not support multiple host sessions. As
an example where multiple sessions are supported, a properly
configured SNA 3174 controller supports up to 128 host sessions and
up to 32 ports, with up to 4 sessions per port. You can get to the
multiple sessions with certain terminals from the 3270 family or
with a PC3270. Multiple sessions are invaluable if you use
multiple host facilities such as VM, TSO, CICS, etc. at nearly the
same time. Getting back and forth without logging off and on is a
big time saver. Putting such support into TELNET would provide the
additional advantage of being able to have multiple sessions going
to non-IBM hosts such as VAX's.
FILE TRANSFER
With all the other connectivity tools I am talking about, a file
transfer is really typing the file down the communications path at one
end and capturing the characters that come out at the other end. I am
sure that the developers of such things as KERMIT and YTERM and the IBM
3270 board would feel that I am belittling their products a little, but
if you accept a considerable oversimplification, my characterization is
fundamentally correct. The file transfer is a part and parcel of the
logged on terminal session, and the communications path itself does not
really know that there is a file transfer going on instead of terminal
traffic. In some cases, the transfer is initiated from the PC end of
the connection, and sometimes from the mainframe end. KERMIT actually
requires actions to take place at both ends. But in any case, the
paradigm of using the logged on session to carry the file transfer is
fundamentally the same.
TCP/IP file transfers are radically different. They are peer to peer
transfers that do not involve a logged on session. In fact, IBM's
implementation of TCP/IP's most functional file transfer protocol
demands that the PC not be logged on to the mainframe at all.
I most typically am logged on when I do a file transfer, so I most
typically use a low function protocol called TFTP (Trivial File Transfer
Protocol). In general, TFTP can be initiated from either end. However,
in order to operate in a logged on mode, it must be initiated from the
mainframe. You enter the command "TFTP hostname" on the mainframe,
where "hostname" is the network name of your PC. This once again is a
subtle but key point, because "hostname" could in general be any host on
the network, including somebody else's PC. In fact, the first day we
installed TCP/IP we had our name tables messed up and I got somebody
else's PC when I used my name and vice versa. Your TFTP file transfer
is simply not bound to your terminal session at all.
Having invoked TFTP, you then PUT or GET a filename, and the file is
transferred in the appropriate direction between your mainframe session
and your PC. Your mainframe session is operating as a TFTP client, and
your PC is operating as a TFTP server. The TFTP server function is
integrated into the TELNET code on the PC, which is the only reason
there is any capability at all of doing a file transfer while you are
logged on.
TFTP is a very low security protocol. While your TFTP server is
implicitly running as a part of your TELNET session, not just your
session but any TCP/IP user in your network can GET or PUT files from
your PC. You do get a chance to permit or deny any transfer, but you
are only given the name of the host requesting the transfer, not the
name of the userid. This mode of operation is called ASK mode, because
you are asked to confirm every transfer. ASK mode can get a little
tedious and irritating at times. You can turn it off, but if you do you
have no security at all.
TFTP over our Ethernet is very fast compared to serial port transfers,
and is even quite a bit faster than using a 3270 board connected via
coax to a 3270 controller. It is quite a bit slower than FTP, the more
full function TCP/IP file transfer protocol. It only supports one file
at a time (no wild cards in names), and is generally lacking a number of
very useful features that are present in FTP.
There is a TFTP program which is invocable at the DOS prompt on the PC,
in lieu of running the TELNET program. Its use is mutually exclusive
with TELNET, and basically requires that you not be logged on. It has
both a server and client mode. It is hard to imagine ever using TFTP on
the PC in client mode, because I would use the full FTP in client mode
instead whenever possible. The server mode is similar to the server
that is imbedded in TELNET, except that there is no ASK mode. That is,
the TFTP server honors all externally initiated PUT and GET requests
without further authorization. You cannot do anything else on the PC
while the TFTP server is running, but you could leave it running anytime
you wanted other people to GET or PUT files from your PC. I have
considered leaving it running at night on my PC at work, logging in to
the mainframe from home, and then up and down loading files between the
PC at work at work and the mainframe. I could then up and down load
files between the mainframe and my PC at home using KERMIT, completing
the loop between my work PC and my home PC. However, I have not quite
had the guts to leave myself so wide open to somebody tampering with my
files.
The full function protocol is called FTP (File Transfer Protocol). IBM's
implementation for the PC supports only client mode. That is, all file
transfers must be initiated from the PC end. That means that FTP can be
used to transfer between a PC and a mainframe with an FTP server, but
that FTP cannot be used for transfers between PC's since both PC's would
support FTP client but neither end would support FTP server. Direct PC
to PC transfers therefore require TFTP, because both server and client
are supported on TFTP but not on FTP. (This is the only case I can
think of where TFTP client makes any sense on the PC.)
The use of FTP requires that you not be logged on. It is invoked from
the DOS prompt via "FTP hostname". You are then asked for a userid and
password on the target host, and you undergo a pseudo-logon with respect
to authorizing your access to files. You are not really logged on, but
you can access the same files you could access if you did logon.
Having logged on, you can GET and PUT just like you can with TFTP,
except that in addition wildcards are supported so that you can "GET
*.*" or "PUT *.*" to transfer all files. You can list directories on
the target host, delete files, and rename files. Also, it is much
faster than TFTP. I don't want to get into a long discussion of exact
speeds. It depends on many factors. However, I think it is fair to say
that over our Ethernet, the transfer is faster than the PC's hard disk,
and is therefore constrained by the speed of the PC's hard disk. It is
certainly vastly faster than is a transfer with a 3270 card over a coax
and through a local 3274.
As I said, I seldom use FTP personally. I am usually already logged on
and only want to transfer one file, so TFTP is plenty good enough.
However, here is a real world example of how we do use FTP. We download
a good bit of public domain software for PC's from servers on the
Internet. Before we had TCP/IP on PC's, we would download the software
using TCP/IP on our mainframes. Then, we would download again from our
mainframes to our PC's using KERMIT. Now, we download directly from the
Internet to our PC's and the process is much faster and more robust.
I should mention that there is a certain awkwardness in using FTP into a
VM system that has nothing to do with running FTP from a PC. The
awkwardness lies in VM itself. On most operating systems in the world,
giving a userid and and password is sufficient to authorize access to
that userid's files. However, VM has these funny things called
minidisks which have passwords quite apart from the userid. In order
for VM's FTP server to work, it has to link to a minidisk which means
that it has to have the password for the minidisk. The way this works
is different depending on whether you use the native access control
facilities of VM (the directory plus usually DIRMAINT), or whether you
use another access control facility such as RACF. I don't feel qualified
to give a good description of the process because we are a VM Top Secret
shop, and Top Secret does not yet have a facility called the surrogate
facility which would allow the FTP server access to minidisks in a nice
manner. I believe that RACF already supports surrogate access, but I
don't know how it works. I know how to access minidisks on our system
with FTP, but I think that I better not get into a discussion of it for
fear that it is unlike on any other system in the world.
I have said that that you cannot use FTP while you are logged on. There
are really two reasons. One is that you cannot run FTP and TELNET at
the same time on your PC. The code simply does not multitask. I tried
pushing to a second level DOS from TELNET and running FTP. My machine
died and I had to power off my machine to recover. However, even if
(for example) I logged onto my VM userid from a real 3270 and then tried
to FTP from my PC, it still would not work because of conflicting links
to my minidisks between my logged on session and the FTP server. I
trust that the Shared File Facility, once it is supported by IBM's
TCP/IP product, will solve this problem.
For those of you who are familiar with something like VM's SENDFILE
command, but who are not familiar with FTP, I should point out that
SENDFILE (and other similar VM functions such as NOTE) work in a store
and forward fashion, but both FTP and TFTP are end to end protocols.
That is, they establish a complete virtual circuit from your machine to
the target machine, and therefore require the target machine as well as
all intermediate communications links to be up during the file transfer.
In a purely local environment, this is usually not much of a problem.
However, in the Internet, it is not uncommon for a host or for
intermediate links to be down from time to time. It is also common for
hosts to have limits on the number of simultaneous FTP's supported, and
common for these limits to be exceeded during the day. We therefore
often find ourselves downloading files from Internet servers at night
instead of during the day. This means that a human being is sitting
there performing the download. I personally prefer the store and
forward way of doing things where you can send a request to something
like a LISTSERV, and have the file arrive whenever it can. Neither your
request, nor the downloading of files, requires that the target host nor
the intermediate communications links be up, nor do they require a human
being to be sitting there in the middle of the night controlling the
file transfer. But lots of perfectly reasonable folks don't agree with
me, and that particular religious war has been fought many times before,
so no flames, please.
In the same vein, the FTP way of doing things requires that you know the
password of a userid on the far end (not a good thing), whereas the
SENDFILE and LISTSERV style of things does not. The problem is usually
finessed by having "well known" userids with "well known" passwords
provide server functions (often ANONYMOUS GUEST), and having the
password grant only read access. It works, and is really no big deal,
but I think it is ugly.
WISH LIST
My first wish is for the things I have already mentioned concerning
graphics and 7171 functionality.
My second wish is for file sharing. Before we got the TCP/IP software
for our PC's, we did not really know for sure if it supported any sort
of file sharing, or just file transfer. It is file transfer only. I
would like to see something in the vein of network virtual disks similar
to those supported by most PC LAN's. My understanding is that NFS would
take care of this wish, but the IBM product does not support NFS client
on the PC. My understanding is that NFS server is supported by IBM on a
mainframe via the VMNFS product, but that does me no good until such
time that NFS client is supported on the PC.
My third wish is to run TCP/IP on my PC at home. This one will require
a little explanation. I once saw somebody on the network make a
reference to "running TCP/IP at home". It turned out that they were
dialing into a UNIX system, and then running TN3270 to get into an IBM
system. They were just using the UNIX system as a protocol
converter.
What I want to do is literally to run the same TCP/IP software on my PC
at home as I run on my PC at work. The only difference is that I would
have a driver that would talk to my serial port and send IP packets out
over it. Then, at work I would have a server that would have modems and
serial ports on one side, and an Ethernet connection on the other. The
server would take IP packets off the serial ports and put them onto the
Ethernet and vice versa. I don't think that anything even remotely
resembling this kind of support exists anywhere in the market.
I final piece would be required to really make my third wish come true.
The PC code should support FTP server with proper security. Then, I
could leave the FTP server running when I leave work at night, and
download files from my work PC to my home PC using FTP. I see no reason
FTP server could not work. PC's running DOS usually don't have userids
and passwords, but there is no reason that an FTP server on a PC could
not support such a thing.