JBVB@AI.AI.MIT.EDU.UUCP (05/29/87)
I inquired of a Network Solutions salesperson after one of their presentations at the conference in Monterey this past March, and he said that their DDN/MVS did not support 3270-mode telnet. Regarding an RFC: I suppose I could document what I've found while doing FTP's implementation, but I'm not a mainframe programmer, and I got the feeling during an earlier discussion here that the present state of affairs wasn't to everyone's satisfaction. Should I (or some one of the others working on TN3270) institutionalize what we've got now? If not, I'd be happy to be included in any e-mail discussion of what *ought* to be done. I definitely agree that the issue needs some work, since the number of available implementations has been growing. jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software, Inc. PS: I sent a request to be added to this list to "tcp-ip-request@sri-nic.arpa" three weeks ago, and it appears I haven't been added. Was that the wrong place to send it?
BRUCE@UMDD.BITNET (Bruce Crabill) (05/30/87)
We don't want to simply document what we have now. The current state of
affairs is not good. Most people I've talked to seem to agree that it
needs to be cleaner and more information about the type of terminal and
the features the emulator will support need to be presented. Bob Braden
made some comments a while back concerning the desirability of presenting
the control unit type as well as the terminal type, and I would like to
see some method of indicating if the emulator can handle the Yale ASCII
extensions. Maybe we can form some kind of working group on this. Currently
most of the people who would be affected by this is a fairly small group
and perhaps we could decide how it needs to be fixed and write an RFC
stating our findings. I am more than willing to work on such a project.
How many others out there are interested?
Brucemqh@batcomputer.tn.cornell.edu (Mike Hojnowski) (05/31/87)
In article <8705300729.AA11310@ucbvax.Berkeley.EDU> BRUCE@UMDD.BITNET (Bruce Crabill) writes: > Maybe we can form some kind of working group on this. Currently >most of the people who would be affected by this is a fairly small group >and perhaps we could decide how it needs to be fixed and write an RFC >stating our findings. I am more than willing to work on such a project. >How many others out there are interested? I discussed these issues with several TN3270 gurus in Monterey. The consensus seemed to be that there is indeed a need for work in this area, but that none had the time or energy to do it. I will agree that this is a relatively minor issue, but with more vendors coming out with TN3270ish programs, it's important that this be settled soon. I'm willing to be in on this. -- Mike Hojnowski (Hojo) {ihnp4,rochester}!cornell!batcomputer!mqh ICBM 042N 29 076W 27 mqh@batcomputer.tn.cornell.edu "With friends like that, who needs enemas?" - Max Headroom
braden@ISI.EDU (Bob Braden) (06/01/87)
I inquired of a Network Solutions salesperson after one of their presentations at the conference in Monterey this past March, and he said that their DDN/MVS did not support 3270-mode telnet. There must have been some misunderstanding about the question or the answer. DDN/MVS is based on the UCLA MVS code, which certainly does support 3270-mode Telnet, and always has. I have a tn3270 icon on my Sun screen, which I occasionally open to log into TSO on the UCLA 3090 and use PDF in full-screen. Now that the ARPANET is back from the dead, it works quite snappily, too. Bob Braden
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (06/02/87)
I inquired of a Network Solutions salesperson ... and
he said that their DDN/MVS did not support 3270-mode telnet.
There must have been some misunderstanding about the question or the
answer. DDN/MVS is based on the UCLA MVS code, which certainly does
support 3270-mode Telnet, and always has....
Bob Braden
This is what I get for answering my mail while far from my references.
I know that one of the mainframe packages doesn't have TN3270. Is it
C.I.S.C.O. (not the Bay area gateway people) that doesn't?
jbvb
BTW: I'm still not on the list. Has there been any further discussion of
the RFC issue? Also, am I simply not aware of an official MIT redistribution
point? If so, could someone inform me whom to contact?ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (06/02/87)
The Maryland CISCO, is a hardware implementation. It is a box that plugs into your MVS machine's channel and plugs into ethernet/DDN on the other side. While I've received glossy literature on these things in the past, I've never heard of someone that had one. Does anybody have one of these things? -Ron
LYNCH@A.ISI.EDU.UUCP (06/02/87)
Oh yeah, Bob, you brought up a point that I have ignored lately: the Arpanet is back from the dead lately. Why? Was something wonderful discovered or done? Or did some evil packet sprayer die in silence? Dan -------
braden@ISI.EDU.UUCP (06/02/87)
Nothing wonderful. Just good old BBN grunt work ("tuning") plus some
criminally-delayed line upgrades.
Bob
fserr@ALEXANDER.BBN.COM.UUCP (06/03/87)
The ARPANET had severe performance problems last October, and again during late January and February. In both cases we think the major culprit was oversubscribed network trunks. The network routing algorithm started thrashing about, looking for less congested routes. This sometimes led to less efficient use of the existing bandwidth, compounding the performance problems. Last fall the problems were triggered by trunk rehomings that were done in the wrong order. The most important "fix" was simply getting all the rehomings done, restoring the bandwidth that had been there before. The congestion in February was alleviated by adjustments to the parameters used in the network routing calculations. We lessened the ability of the network to route around congestion, but made it more stable in the face of limited bandwidth on important routes. Upgrading several key nodes to a more powerful hardware version may have had a small role in keeping performance at acceptable levels. Though things seem OK now, the network is still sensitive to increased traffic on key paths. (Transcontinental bandwidth seems to be the critical resource here.) Sometime very soon (perhaps this week), a new link will be added to the ARPANET between New England and northern California. This new cross-country trunk should improve performance still further, and start to provide some room for expansion beyond current traffic levels. Fred Serr Network Analysis Department BBN Communications
YAKOV@IBM.COM.UUCP (06/03/87)
We (group of people at T.J. Watson Research Center, IBM Corp.) are working on a draft proposal which will attempt to standardize 3270 emulation over the Telnet. Any ideas/comments/suggestions are welcomed. Jacob Rekhter (yakov@ibm.com).
narten@PURDUE.EDU (06/03/87)
>Though things seem OK now, the network is still sensitive to increased >traffic on key paths. (Transcontinental bandwidth seems to be the >critical resource here.) Has anyone ever looked into the way EGP traffic (and the "extra hop" problem that goes with it) effects this? For instance, on the ARPANET, there are only 3 EGP servers sites publicly available. They are presumably located on the east coast (10.7.0.63 bnnet2-arpanet-gw.arpa), midwest (10.2.0.37 purdue-cs-gw.arpa), and on the west coast (10.3.0.27 gateway.isi.edu). Does anyone have any information on numbers and locations of sites peering with each server? Would it help to skew the peering so that sites on the east peered with bbnnet2, and so on, even if it means that the percentages of the total sites each server peers with is unequal? In looking at routing tables gotten via EGP from purdue-cs-gw.arpa, only a handful (less than 40 out of 240) of the routes actually go through those gateways. The rest go to specific (and presumably correct) gateways. Is this because everyone else peers with Purdue (and hence its EGP updates have the correct info) or because the "extra hop" problem really isn't a problem since ICMP redirects get things straightened out? Thomas
minshall@OPAL.BERKELEY.EDU (06/06/87)
Jacob, Needless to say, a standard would be very welcome. It should be planned to be released as an RFC. Many people have asked about 3279, 3179, etc. I think the point is that the standard needs to address "3270 over telnet", where all of the above are in the class "3270". Peter is right that in general the 3179 G graphics are nice; but sometimes programmed symbols are nice. The point is we should allow "everything". I think the model (continues to be) how the IBM "PVM" (IBM's telnet-style program for VM systems) does it. I think that someone with PVM devleopment experience (and thus an IBMer) would be very useful in this endeavour. Anyway, I'm very interested in contributing to such a standard. Greg
jimbys@tybalt.caltech.edu (James V. Bys) (01/09/88)
Expires: Sender: Followup-To: Distribution: Keywords: A while ago there was posted (I hope in this newsgroup) the location of a tn3270 package available via anonymous ftp. I have misplaced this location. Could someone remind me of it? Thanks! James V. Bys California Institute of Technology Internet address: jimbys@iago.caltech.edu
LDW@MVSA.USC.EDU (Leonard D Woren) (01/12/88)
The original message on how to get tn3270 was posted before I
subscribed to tcp-ip, but I have a copy that was forwarded to me when
I was trying to get tn3270. The original posting was from Greg
Minshall on 17 Aug 87. The specifics are:
host - arpa.berkeley.edu (10.0.0.78) I was unable to get this to
work, but ucbarpa.berkeley.edu did work.
directory - pub
file - tn3270.tar (>700K)
- compress(1) version in tn3270.tar.Z (>300K)
It can also be obtained on a diskette, but I can't find the info on
that right now.
/Leonardminshall@VIOLET.BERKELEY.EDU (01/13/88)
Jim,
You *can* ftp tn3270, but I would suggest buying it by mail.
It is a fairly large body of code (something like 350Kbytes compressed);
additionally, it is useful for the University to have some idea of
tn3270 usage in the world (for when the University makes future development
plans).
The following is a canned message on how to acquire tn3270
via the mail:
-----
New versions of the tn3270 and mset commands, used to logon to CMS from
unix, has been available since the late summer of 1987.
New features are:
o Error messages, in English, overlay a portion of the
screen when the user types an erroneous entry (invalid
control sequence, attempt to enter data in an "input
disallowed" field, etc.).
o Ability to "escape to shell". This, by itself, is
mostly useful in an MS-DOS (or non-BSD) system.
o An Application Programming Interface (API). This allows
programs, running under Unix or MS-DOS, to read and
write the 3270 screen, and to send keystrokes (3270)
to tn3270. This makes use of the "escape to shell"
feature. Included in the (beta) distribution is a
program which uses the API to receive files sent from
the IBM host (we don't supply the IBM side at this point,
and the rather stupid protocol is likely to change in
the future).
o Yale ASCII/7171/4994 "transparent" mode should now
be fully implemented. SAS-Graph, for example,
supports doing graphics to TEK terminals over
this interface. Locally, we use the X windowing
system terminal emulator (xterm), which provides
some TEK emulation, to display SAS-Graph graphics
on our workstations.
o Mset now prints out program function (PF) keys in
numerical order.
o Various bugs have been fixed.
To obtain the source for tn3270, send a check for $100.00 (US) payable
to "Regents of the University of California" to:
Campus Software Office
295 Evans Hall
UC Berkeley, CA 94720
USA
Specify that you are ordering tn3270.
This version will run under MS-DOS if the PC has the Ungermann-Bass
smart TCP board (NIU).
This version will compile under MS-DOS if you have: 512K of memory;
Microsoft C version 4.0; Microsoft MASM 4.0; the Ungermann-Bass "socket
emulation library"; and Polymake from Polytron (Hillsboro, Oregon).
Greg Minshallnasa@ms.uky.edu (Eric T. Freeman) (02/28/88)
Could someone send me the address of any place I can ftp the newest version of tn3270? Thanks. Eric Freeman University of Kentucky Computer Science nasa@g.ms.uky.edu
minshall@VIOLET.BERKELEY.EDU (12/14/88)
At long last, a new version of tn3270 is being released.
The preferred method of retrieval (see below) is by mail from the University.
However, the file is available on host ucbarpa.berkeley.edu as
pub/tn3270.tar.Z (binary mode transfers only, please).
This version should work on Ultrix, SunOS, etc.
With this version we are dropping support (possibly temporarily) for the
MS-DOS environment. The basic hooks are still there, but I haven't had
the time to actually get it to work.
This new version consists entirely of bug fixes (ie: no new functionality).
However, there have been enough bugs accumulating over the last year or
so that getting the fixes out should improve things considerably.
Bugs to me. Sorry this has taken so long ("so little and so late").
Greg Minshall
minshall@berkeley.edu
---------------
New versions of the tn3270 and mset commands, used to logon to CMS from
unix, are now available.
The following bugs have been fixed in version 4.1:
o This version corrects an earlier bug in tn3270 (telnet,
actually) which prevented tn3270 from running on a
Sun 4.
o This version corrects for a bug on some SunOS 4.0 systems
(running on Sun 3's is where this has been noticed) which
causes screen corruption when making extensive use of
highlighting (which tn3270 does and "man", for some reason,
doesn't).
o This version corrects a bug which caused unformatted
screens to behave incorrectly (the so-called CICS bug).
o This version works correctly with VM/XA.
o Various bugs have been fixed.
The previous version of tn3270 supported an MS-DOS environment; this
version doesn't. See tn3270/README for some alternatives.
Features include:
o Error messages, in English, overlay a portion of the
screen when the user types an erroneous entry (invalid
control sequence, attempt to enter data in an "input
disallowed" field, etc.).
o Ability to "escape to shell". This, by itself, is
mostly useful in a non-BSD system.
o An Application Programming Interface (API). This allows
programs, running under Unix, to read and
write the 3270 screen, and to send keystrokes (3270)
to tn3270. This makes use of the "escape to shell"
feature. Included in the (beta) distribution is a
program which uses the API to receive files sent from
the IBM host (we don't supply the IBM side at this point,
and the rather stupid protocol is likely to change in
the future).
o Yale ASCII/7171/4994 "transparent" mode should now
be fully implemented. SAS-Graph, for example,
supports doing graphics to TEK terminals over
this interface. Locally, we use the X windowing
system terminal emulator (xterm), which provides
some TEK emulation, to display SAS-Graph graphics
on our workstations.
o Mset now prints out program function (PF) keys in
numerical order.
To obtain the source for tn3270, send a check for $100.00 (US) payable
to "Regents of the University of California" to:
Campus Software Office
295 Evans Hall
UC Berkeley, CA 94720
USA
Specify that you are ordering tn3270.stewarta@sco.COM (Stewart I. Alpert) (01/05/89)
Does anyone know where I can get the sources to tn3270? thanks, stewarta@sco.COM ...!uunet!sco!stewarta @ucscc.ucsc.edu:stewarta@sco.COM
tmac@SOL.ENGIN.UMICH.EDU (01/06/89)
From uunet.uu.net!stewarta%sco.uucp Thu Jan 5 16:00:19 1989 From: stewarta%sco.uucp@uunet.uu.net Sender: tcp-ip-relay@sri-nic.arpa To: tcp-ip@sri-nic.arpa Date: 4 Jan 89 20:05:47 GMT Organization: The Santa Cruz Operation, Inc. Message-Id: <1243@viscous> Subject: tn3270 Does anyone know where I can get the sources to tn3270? thanks, stewarta@sco.COM ...!uunet!sco!stewarta @ucscc.ucsc.edu:stewarta@sco.COM I think you can anonymous ftp them from devvax.tn.cornell.edu Tom McLeary -------------------------------------------- Thomas McLeary tmac@caen.engin.umich.edu Univ. of Michigan Computer Aided Engineering Network UUCP: tmac%caen%mailrus.uucp --------------------------------------------
bin@primate.wisc.edu (Brain in Neutral) (01/10/89)
> Does anyone know where I can get the sources to tn3270? > > I think you can anonymous ftp them from devvax.tn.cornell.edu Or ucbarpa.berkeley.edu, in pub/tn3270.tar.Z. If you want to make it run under Ultrix, you need to do some tweaking. Paul DuBois dubois@primate.wisc.edu bin@primate.wisc.edu
minshall@VIOLET.BERKELEY.EDU (02/07/89)
There is a new "bug fix" version of tn3270 - 4.1.1. This supercedes version 4.1 (released December, 1988). The files are on ucbarpa.berkeley.edu in the directory pub/tn3270. The file 4.1TO4.1.1diffs.Z contains a set of diff's which will bring a 4.1 release up to a 4.1.1 system (at least in all important aspects). This includes three new versions of the man pages and a newer version of /etc/map3270. The file tn3270.4.1.1.tar.Z is the new release. The main fix is to telnet.c - to notice that we have negotiated out of a mode (for UCLA-based MVS systems mostly - but also for protocol correctness). Other changes include some more byte ordering considerations, eliminating some unused macros from screen.h, checking the parameters to the 3270 orders RA and EUA (and bailing out if the parameters are bad - 3270 programmers beware!), tolerating the Gould C compiler, and making sure that debugging information actually gets out (even if the programs dumps core or goes into a loop). A note to "by mail" customers: I apologize to those who have ordered their system in the last month and a half from the Campus Software Office. I have not supplied the SW office with a new master and they have thus been unable to satisfy your order. I hope to provide a new master (of 4.1.1) within the next two weeks. Thanks to all those providing such early bug reporting to my 4.1 release (and for bearing with it all). Greg Minshall
COINS@A.ISI.EDU (09/25/89)
HELP
LOOKING FOR TN3270 SOURCE CODE WHICH WILL RUN ON A VAX
OR A PDP1170, HOW ABOUT ANYTHING IN "C".
THANK YOU
LYNN
-------mw@beach.cis.ufl.edu (Michael Wohlgemuth) (02/15/90)
I am having some trouble with TN3270 and was told that I might not have the latest version. What is the latest version and where can I get it? Thanks Mike
COINS@A.ISI.EDU (06/28/90)
I am looking for an implementation of a tn3270 server for non-ibm hosts, preferably UNIX-based. Does anyone know where I might find such a beast or how I might acquire it? Barring that, does anyone know where I might find specifications for a TN3270 server? Thank you Lynn -------
asbjorns@uit.no (05/04/91)
Is there a public domain/shareware version of tn3270 for Unix System V available out there somewhere? Asbjoern Saetran, asbjorns@stud.cs.uit.no
LIANE%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU (05/22/91)
I would like to ask the help of someone in order to get information on tn3270. I know about RFC 1041 but I would like to find more about real use of this option: examples of topologies using this kind of terminal emulation, equipments used, implementations, software available, limitations etc.. I will compile all the responses received and present a result report to the list. Thanks in advance Liane Tarouco University Federal of Rio Grande do Sul Institute of Informatics Porto Alegre - Rs - Brazil liane@sbu.ufrgs.anrs.br