dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (03/21/89)
In posting <8903201633.AA03974@umix.cc.umich.edu>, Marcus asks: > Can anyone tell me if there is an apollo kermit available that handles > wild-carding (for multiple sends) and/or VT100 emulation in a window? I have a new version of the Pascal Kermit for Aegis that provides both capabilities. It is based upon the Pascal Kermit that was in the ADUS library, but massively revised. It uses the Aegis "CL" command line parser and thus recognises all the standard Aegis wild-card constructs. Its connect mode module is modeled after /com/emt and uses the same code logic. Thus it understands DM windows, vt100 windows, CRP windows and uses similar function key definitions. It correctly implements the standard Kermit protocol and provides many optional Kermit features. It provides a wide variety of the Kermit server features, both as a server mode Kermit and as a Kermit client speaking to a server. It was developed under sr9.6 & sr9.7 but I am just finishing up a version that will work under sr10. It is avaliable from the ADUS library or from me. Pease send me a floppy or ctape and SASE for a copy. I can E-mail the source code but it is large (500k+), so be sure that your mailer will accept large files. Dave Funk
MARCUS@STOAT.PCL.AC.UK (03/21/89)
Can anyone tell me if there is an apollo kermit available that handles
wild-carding (for multiple sends) and/or VT100 emulation in a window?
- m a r c u s -lnz@LUCID.COM (Leonard N. Zubkoff) (03/21/89)
The standard C Kermit distributed by Columbia works fine on SR9.7. For SR10.1, I had to delete the Apollo conditionalization as the Apollo then is essentially 4.3. As for vt100 emulation, C Kermit does not provide a terminal emulator, but the command "vt100 kermit" works fine to invoke kermit under the vt100 emulator. Leonard
rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (11/30/89)
I would like to get kermit running on my DN10000. I am running BSD4.3 under Domain. Where can I get the kermit source and makefiles? Has anybody done a port to Domain (if needed?).
rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (12/04/89)
Following various suggestions I received on getting Kermit running on my DN10000 running BSD 4.3 under SR10.1, I got the apollo-kermit distribution from labrea.stanford.edu. I can't get it to work. It builds fine on the 10000, using "make bsd", and I get the C-kermit prompt, and the response to help queries, etc. looks OK. It won't transfer files though. When I tell it to Receive, I get the prompt to escape back to local mode and send the file, but when I do this on my Mac using Kermit under Versaterm pro, nothing happens. The file transfer never gets initiated. Same happens with Send. The Macintosh kermit I am using works fine with the C-kermit built on tank (an ELXSI running BSD 4.x), and the comm settings revealed by "show" on tank are the same as for my apollo-kermit, except that the maximum packet length on apollo kermit is listed as 32768 for send or receive (vs 1024 and 2048 on tank). Any idea of what is going on? It seems like somehow the DN10000 is never getting the message from my Mac kermit that the file transfer is ready to go. Has anybody successfully used this kermit on a DN10000 under 10.1?
rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (12/05/89)
In article <6534@tank.uchicago.edu>, rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: > Following various suggestions I received on getting Kermit running on > my DN10000 running BSD 4.3 under SR10.1, I got the apollo-kermit > distribution from labrea.stanford.edu. I can't get it to work. It > builds fine on the 10000, using "make bsd", and I get the C-kermit > prompt, and the response to help queries, etc. looks OK. It won't > transfer files though. When I tell it to Receive, I get the prompt > to escape back to local mode and send the file, but when I do this > on my Mac using Kermit under Versaterm pro, nothing happens. The > (etc.) After reading the .bwr file, and some experimentation, I found that the problem was that I was dialling in to my Apollo through a tcp/ip based terminal-access system that assumed 7 data bits, even parity. Kermit couldn't put this in "raw mode" since it is out of its control. The .bwr file suggests some scary hacking with telnetd, but fortunately, this system allows you to reset the parity and data bits even if you use telnet. I suppose rlogin -8 would also work. Once I did this, everything worked fine.
rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (12/05/89)
There is still a curious anomaly regarding my fix of my kermit problem. Namely, when I built kermit on tank (a bsd4.3 ELXSI), and accessed it through the SAME incorrectly set terminal server, it worked just fine. Now is that weird or what?
rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (12/06/89)
In article <6561@tank.uchicago.edu>, rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: > There is still a curious anomaly regarding my fix of my kermit > problem. Namely, when I built kermit on tank (a bsd4.3 ELXSI), > and accessed it through the SAME incorrectly set terminal server, > it worked just fine. Now is that weird or what? This must look mysterious, but what happened was that my report of my kermit fix got bounced by the mailer. The text of the original message follows: After reading the .bwr file, and some experimentation, I found that the problem was that I was dialling in to my Apollo through a tcp/ip based terminal-access system that assumed 7 data bits, even parity. Kermit couldn't put this in "raw mode" since it is out of its control. The .bwr file suggests some scary hacking with telnetd, but fortunately, this system allows you to reset the parity and data bits even if you use telnet. I suppose rlogin -8 would also work. Once I did this, everything worked fine. Actually, just setting parity, stopbits and 8bits wasn't enough. I also had to specify "term download" to this telnet-based system, which must have something to do with the way carriage returns and line feeds are handled. 1
rchrd@well.UUCP (Richard Friedman) (12/08/89)
check that the assumed parity is thesame between the two systems
over kermit. I have had problems like this when dialing into
a system where the server was set for no parity and the dialin
was set with even. They could never get talking.
--
/s/ rchrd <=> Richard Friedman <=> rchrd@well
rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd
[Pacific-Sierra Research / Berkeley CA] (415) 540-5216
(The usual disclaimers apply - I speak only for myself!)