pete@octopus.UUCP (Pete Holzmann) (08/22/86)
I grabbed a copy of ProComm 2.3 several days ago. It seems like a very nice
program, but also rather buggy. It has a *very* annoying tendency to lock
up completely, and has trouble with terminal emulations. Has anybody else
had and/or solved these problems?
- Alt-S (setup) locks up an AT every time (IBM and clone. A second
clone didn't have trouble)
- Kermit transfers tend to get locked up
- It frequently locks up when you aren't receiving anything (goes
into a receive loop at the wrong time?)
- TVI 925/950 emulation locks up often when things like 'sysline'
try to write to the status line
- TVI 950 isn't worth beans in vi.
- TVI 925 locks up immediately when initialized with the standard
termcap init string in the berkeley termcap file
I'd love to use this program, if only it worked!
--
OOO __| ___ Peter Holzmann, Octopus Enterprises
OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
OOOOO \___/ UUCP: {hplabs!hpdsd,pyramid}!octopus!pete
___| \_____ Phone: 408/996-7746john@moncol.UUCP (John Ruschmeyer) (08/24/86)
In article <216@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: >I grabbed a copy of ProComm 2.3 several days ago. It seems like a very nice >program, but also rather buggy. It has a *very* annoying tendency to lock >up completely, and has trouble with terminal emulations. Has anybody else >had and/or solved these problems? > > - TVI 925/950 emulation locks up often when things like 'sysline' > try to write to the status line > - TVI 950 isn't worth beans in vi. There are two major problems with the Televideo emulations that I have found: 1) The Home Cursor character (Control-^) is not supported (really odd since they did set it up for the HOME key to send that character). For me a quick fix was to set up a seperate termcap entry for the PROCOMM emulation which just used the standard one, but with the 'ho' attribute left undefined. 2) There seems to be a bug in how the status line is updated. If it is already enabled (via an ESC-g) and then updated (via an ESC-f), the new contents are *not* shown until the status line is disable and then re-enabled. Hope this is of help. -- Name: John Ruschmeyer US Mail: Monmouth College, W. Long Branch, NJ 07764 Phone: (201) 571-3451 UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john ...!pesnta!moncol!john NOMAD: ... a mass of conflicting impulses. Absorbing it unsettled me. SPOCK: That unit was Rich Rosen. from "Rosen Trek"
rick@sdcsvax.UUCP (Rick Randall) (08/25/86)
In article <216@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: >I grabbed a copy of ProComm 2.3 several days ago. It seems like a very nice >program, but also rather buggy. It has a *very* annoying tendency to lock >up completely, and has trouble with terminal emulations. Has anybody else >had and/or solved these problems? > > - Alt-S (setup) locks up an AT every time (IBM and clone. A second > clone didn't have trouble) > - Kermit transfers tend to get locked up > - It frequently locks up when you aren't receiving anything (goes > into a receive loop at the wrong time?) > ... Never had any of these problems on my PC or on my Orchid 286e expansion board (like an AT on the PC). Procomm 2.3 has worked beautifully by and large -- definitely the best PD comm program I've found. Sorry about your problems -- and I can't suggest remedies; perhaps you should register and then ask for support from the author(s). Rick Randall EECS Department University of California, San Diego decvax\ rick@sdcsvax.ucsd.edu ihnp4 >---> sdcsvax ---> rick ucbvax/ rick@sdcsvax.uucp
adamsd@crash.UUCP (Adams Douglas) (08/25/86)
Be sure that you haven't left packages like SuperKey or ProKey running when you invoke Procomm. SuperKey can be left running, but be sure to clear the macros. Also, there are many more obscure resident packages that can interfere w/ProComm. Try deleting all resident software. If that doesn't work, you might also try changing the setup so it operates through BIOS calls (this may not make a difference, but it's worth a try). Don't exclude the possiblility that your copy of ProComm may have been corrupted. It happens. -- ============================================================ Adams Douglas ARPA:crash!adamsd@nosc.ARPA Jet Propulsion Lab/NASA UUCP:adamsd@crash.UUCP (818)354-3076 These opinions are my own and not necessarily those of JPL or NASA. "Did I do something wrong today, or has the world always been like this and I've been too wrapped up in myself to notice?" -- Arthur Dent
jsm@vax1.ccs.cornell.edu (Jonathan Meltzer) (08/26/86)
In article <2012@sdcsvax.UUCP> rick@sdcsvax.UUCP (Rick Randall) writes: >In article <216@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: >>I grabbed a copy of ProComm 2.3 several days ago. It seems like a very nice >>program, but also rather buggy. It has a *very* annoying tendency to lock >>up completely, and has trouble with terminal emulations. Has anybody else >>had and/or solved these problems? >> >> - Alt-S (setup) locks up an AT every time (IBM and clone. A second >> clone didn't have trouble) >> - Kermit transfers tend to get locked up >> - It frequently locks up when you aren't receiving anything (goes >> into a receive loop at the wrong time?) >> ... > >Never had any of these problems on my PC or on my Orchid 286e >expansion board (like an AT on the PC). Procomm 2.3 has worked >beautifully by and large -- definitely the best PD comm program >I've found. Sorry about your problems -- and I can't suggest >remedies; perhaps you should register and then ask for support >from the author(s). The only Procomm problem I've encountered is the inability to Kermit to/from Vax UNIX. Anyone know the correct parameters? Jon Meltzer Dept. of Modern Languages and Linguistics, Cornell University ------------------------------------------------------------------------ "Disclaimer" is a trademark of Bell Laboratories.
myxm@lanl.ARPA (Mike Mitchell) (08/27/86)
> In article <216@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: > >I grabbed a copy of ProComm 2.3 several days ago. It seems like a very nice > >program, but also rather buggy. It has a *very* annoying tendency to lock > >up completely, and has trouble with terminal emulations. Has anybody else > >had and/or solved these problems? > > > Never had any of these problems on my PC or on my Orchid 286e > expansion board (like an AT on the PC). Procomm 2.3 has worked > beautifully by and large -- definitely the best PD comm program > I've found. Sorry about your problems -- and I can't suggest > remedies; perhaps you should register and then ask for support > from the author(s). I'll have to agree about Procomm. It is one of the nicest pieces of software that has come through public domain. The problems you are experiencing could either be related to some background software that you are loading at boot or since you say it is a compatible, you might even want to suspect the BIOS. I don't know how dependant Procomm is on the BIOS, but I have had it hang on me when I had background serial port monitor running and start Procomm up. Mike Mitchell myxm@lanl.ARPA
jcm@ORNL-MSR.arpa (James A. Mullens) (08/28/86)
I missed the beginning of this discussion on ProComm problems, but I'll contribute a suggestion which is at least interesting if not helpful. I decided to take a look at ProComm recently, and found it wouldn't work correctly until I set the date of the executable file (procomm.exe) up to last June instead of its earlier creation date. Perhaps the authors built in an expiration date?! I found annoying problems in the vt100 emulation when used with the UN*X vi editor on BSD 4.2, so I decided not to use it... My apologies if this finds it way to net.micro ... I'm on the arpanet side of the fence and I seem to have no way to discriminate between net.micro and net.micro.pc. (All constructive suggestions greatly appreciated). Has anyone else seen this ProComm phenomenon, or did I just imagine it? jim mullens / oak ridge national lab
fac@burdvax.UUCP (Frank Cooley) (08/29/86)
> Xref: burdvax net.micro:7058 net.micro.pc:9229 > > In article <2012@sdcsvax.UUCP> rick@sdcsvax.UUCP (Rick Randall) writes: >>In article <216@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: >>>I grabbed a copy of ProComm 2.3 several days ago. It seems like a very nice >>>program, but also rather buggy. It has a *very* annoying tendency to lock >>>up completely, and has trouble with terminal emulations. Has anybody else >>>had and/or solved these problems? >>> >>> - Alt-S (setup) locks up an AT every time (IBM and clone. A second >>> clone didn't have trouble) >>> - Kermit transfers tend to get locked up >>> - It frequently locks up when you aren't receiving anything (goes >>> into a receive loop at the wrong time?) >>> ... >> >>Never had any of these problems on my PC or on my Orchid 286e >>expansion board (like an AT on the PC). Procomm 2.3 has worked >>beautifully by and large -- definitely the best PD comm program >>I've found. Sorry about your problems -- and I can't suggest >>remedies; perhaps you should register and then ask for support >>from the author(s). > > The only Procomm problem I've encountered is the inability to Kermit to/from > Vax UNIX. Anyone know the correct parameters? > > > > Jon Meltzer > Dept. of Modern Languages and Linguistics, Cornell University > ------------------------------------------------------------------------ > "Disclaimer" is a trademark of Bell Laboratories. You have to set the kermit type parameter correctly to either binary or text. If you do this you should have no trouble, I have scripts which call up kermit and set the type depending on what type of file I want to download and this works fine. Frank Cooley
broman@cod.UUCP (Vincent P. Broman) (09/02/86)
<>
Two suggestions for unixoid procomm users:
The vt100 emulation gave me problems until I made the wrapmargin option
in procomm match the expected value in the vt100 termcap entry. Check
yours. No guarantees this is the only stumblingblock.
My kermit transfers didn't work until I set the program parameters to
transmit 8 bits at a time when I start the transfer. I didn't find
a setup that I could use for terminal emulation AND file transfer,
because the terminal displayed "funny" chars when my unix system
sent characters with the 8th bit set.
Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA
Phone: +1 619 225 2365 {seismo,caip,ihnp4,ucbvax}!\\\\\\\
Arpa: broman@bugs.nosc.mil Uucp: {floyd,moss,bang,hp-sdd,sdcsvax}!noscvax!broman