romwa@gpu.utcs.toronto.edu (Royal Ontario Museum) (03/26/89)
With reference to a posting last week about problems with linking HDB uucp and "old" uucp Xenix, I think the problem is due to a brain damaged Computone Intelliport card. This cluster controller works fine with standard dumb terminals on it, but fails miserably with uucp and kermit file transfers between the Xenix box and a PC. Seems like it cannot handle steady streams of data. Computone knows about the problems and they said they are working on it. How can they release serial boards that can't do uucp???? Don't they test anything down there? Also, I cannot get a standard Hayes 2400 modem to work consistently on this board. The modem correctly picks up the line on dial in but there is no carrier as the Computone board seems not to be communicating with the modem. Occasionally, after a disable/enable sequence the modem will work correctly for one call, then the line goes into outer space again, until some fortuitous sequence of events such as a reboot or dis/enable sets things right. Any help on the modem part of these problems would be appreciated. How about posting the register and parameter settings for a 2400 baud Hayes modem that is working on a Computone board? Thanks in advance. Mark T. Dornfeld Royal Ontario Museum 100 Queens Park Toronto, Ontario, CANADA M5S 2C6 mark@utgpu!rom - or - romwa@utgpu
steve@jack.UUCP (Steven Harrison) (03/29/89)
In article <1989Mar26.091015.1214@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Royal Ontario Museum) writes: >With reference to a posting last week about problems with >linking HDB uucp and "old" uucp Xenix, I think the problem is >due to a brain damaged Computone Intelliport card. This >cluster controller works fine with standard dumb terminals on >it, but fails miserably with uucp and kermit file transfers >between the Xenix box and a PC. Seems like it cannot handle >steady streams of data. > I do not know who you have talked to at Computone nor am I sure if you really believe what you are saying but let me say this. We have been using their boards for about five years now on a number of different machines, and a variety of modems. This includes a 300 Hayes modem and most recently a Telebit Trailblazer. By the way we have used a number of UUCp's including System 5.3 HDB and all have worked just fine! I would suggest that you look at your configurations in /atx/attype and verify that you understand how these work. All of this is, of course based on the fact that you really are having trouble. >Computone knows about the problems and they said they are >working on it. How can they release serial boards that can't >do uucp???? Don't they test anything down there? > You are right how could they release something that doesn't work????? Problem seems to be on the other end not in Georgia. Again I recommend you look closely at configurations in the file mentioned above and maybe even your own hardware. We certainly have not sold every possible combination that there is on the market today. >Also, I cannot get a standard Hayes 2400 modem to work >consistently on this board. The modem correctly picks up the >line on dial in but there is no carrier as the Computone board seems >not to be communicating with the modem. Occasionally, after a >disable/enable sequence the modem will work correctly for one >call, then the line goes into outer space again, until some >fortuitous sequence of events such as a reboot or dis/enable >sets things right. > Let's face it Hayes modems are not the best modems in the world to use for bi-directional UUCP traffic. I would suggest that you set your dialers scripts such that &D2 and &C0 are set for dialing out, and &D2 and &C1 are set for dialing in. Make sure you reset the modem at the beginning of the dialer script also, so that you can be assured of some known state. ----- J. Steven Harrison Systems'n'Software 1624 Brookes Ave. San Diego, California 92103-5111 (619) 542-0608 UUCP: ucsd!jack!steve ARPA: ucsd!jack!steve@sdcsvax.ucsd.edu
romwa@gpu.utcs.toronto.edu (Royal Ontario Museum) (03/29/89)
In article <774@jack.UUCP> steve@jack.UUCP (Steven Harrison) writes: >In article <1989Mar26.091015.1214@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Royal Ontario Museum) writes: >>With reference to a posting last week about problems with >>linking HDB uucp and "old" uucp Xenix, I think the problem is >>due to a brain damaged Computone Intelliport card. This >>cluster controller works fine with standard dumb terminals on >>it, but fails miserably with uucp and kermit file transfers >>between the Xenix box and a PC. Seems like it cannot handle >>steady streams of data. >> >I do not know who you have talked to at Computone nor am I sure if you really >believe what you are saying but let me say this. We have been using their >boards for about five years now on a number of different machines, and >a variety of modems. This includes a 300 Hayes modem and most recently a >Telebit Trailblazer. By the way we have used a number of UUCp's including >System 5.3 HDB and all have worked just fine! > >I would suggest that you look at your configurations in /atx/attype and verify ^^^^^^^^^ Steve, I really am having problems with this board. I can see from the above file reference that you do not have their latest products. I, too, have successfully used their older boards for the last 4 years. Their new "Intelliport" cluster controller is based on a NEC V50 cluster controller chip. It is on a single board with four multiplexed high speed serial connectors. Up to four 16 port cluster boxes can be attached as far away as 2000'. (We are limiting our cable runs to a couple hundred feet.) This cabling scheme keeps our false ceilings a bit tidier and the cabling costs down. It seems to me they must have a polling or time slicing scheme running that does not give a uucp port enough time to get large chunks of data through. That it failed with a simple PC to Xenix kermit transfer also says there is something wrong. When I called, they admitted the problem and were "working on it". In the long run, they'll fix it, I hope. > >>Also, I cannot get a standard Hayes 2400 modem to work >>consistently on this board. The modem correctly picks up the >>line on dial in but there is no carrier as the Computone board seems >>not to be communicating with the modem. Occasionally, after a >>disable/enable sequence the modem will work correctly for one >>call, then the line goes into outer space again, until some >>fortuitous sequence of events such as a reboot or dis/enable >>sets things right. >> >Let's face it Hayes modems are not the best modems in the world to use >for bi-directional UUCP traffic. I would suggest that you set your >dialers scripts such that &D2 and &C0 are set for dialing out, and &D2 and &C1 are set for dialing in. Make sure you reset the modem at the beginning >of the dialer script also, so that you can be assured of some known >state. Looks like I learned the hard way. Each time I cu to the modem to work on the set up and then try to enable the line, it doesn't come up. All that it needed was a hardware reset. > >----- >J. Steven Harrison >Systems'n'Software Mark T. Dornfeld Royal Ontario Museum 100 Queens Park Toronto, Ontario, CANADA M5S 2C6 mark@utgpu!rom - or - romwa@utgpu
gillisb@mist.cs.orst.edu (Brian Gillis) (03/29/89)
In article <1989Mar28.235134.4956@gpu.utcs.toronto.edu> romwa@gpu.utcs.UUCP (Royal Ontario Museum) writes: >In article <774@jack.UUCP> steve@jack.UUCP (Steven Harrison) writes: >>In article <1989Mar26.091015.1214@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Royal Ontario Museum) writes: >>>With reference to a posting last week about problems with >>>linking HDB uucp and "old" uucp Xenix, I think the problem is >>>due to a brain damaged Computone Intelliport card. This >>>cluster controller works fine with standard dumb terminals on >>>it, but fails miserably with uucp and kermit file transfers >>>between the Xenix box and a PC. Seems like it cannot handle >>>steady streams of data. >>> I too have had this problem with computone's AT16 product. I was very amazed that it could not handle 9600bps cu connection with another Xenix system without a loss of data. However, I was able to overcome the problem by increasing the CPU time spent on the important ports. You might try this method if your Computone product allows it. Brian gillisb@gsd.UUCP