lanceh@mot.com (DX516 Lance Hall) (05/07/91)
A while back I sent this request out but got no responses - thus I am going to try
this again with more facts included.
I have been trying to get Software Components Group's (SCG) XRAY+ functional on the
Apollo platform. For those not familiar with this product, it is a workstation based,
source level symbolic debugger that communicates with SCG's PROBE+ debugger on the
target unit via a serial connection. The XRAY+ configures the serial port correctly
and transmits 2 messages to the target but does not seemingly receive the response
message from the target as seen on the serial data analyzer. The result is that the
workstation is pretty much locked up. Ending the lockup requires a workstation power
cycle (NOT NICE) or having the target unit send junk to XRAY+.
My environment has been either an Apollo DN3000 or Apollo DN2500 running Domain OS
release 10.2. The XRAY+ product was created on a HP/Apollo Series 400 running Domain
OS release 10.3 and tested functional on this system. In addition, XRAY+ was tested
by SCG successfully on an Apollo DN3000 running Domain OS release 10.1. I can get
XRAY+ to run on my Apollo DN3000 if I come up diskless running Domain OS release
10.3 but fails as stated above when running the installed Domain Os release 10.2.
Question 1 - Does anyone else have this configuration functional? Was this product
really just created for my client company and I am the guinea pig?
Question 2 - Is there something in my configuration of the Apollo workstation that
I have overlooked? Is there something about creating a product on a newer
HP/Apollo workstation but running it on an older workstation?
Question 3 - Is there something broken with regard to SYSTEM V emulation of serial
ports (i.e., open(), ioctl(), fcntl(), read(), write(), or close()) in Domain
OS release 10.2 but not in 10.1/10.3?
- - - H E L P - - -
Reply to comp.sys.apollo or followup address.
Thanks.
------------
Lance N. Hall
lanceha@i88.isc.com
+1 708 505 9100 x387 (Interactive Systems Corp.)
+1 708 576 0560 (Current client company - Motorola Inc.)
--
Duane Binder Software Technology Center
duaneb@mot.com Motorola Communications Sector
708-576-5532 fax 708-576-3131krowitz@RICHTER.MIT.EDU (David Krowitz) (05/10/91)
I have had reports from one of the people using my SR10 print-servers of handshaking problems with serial lines configured for DTR/CTS (ie. hardware) handshaking when running on series 400 machines under *some* versions of SR10.2 and *some* versions of SR10.3. It apparently depended on which PSK's you had (or had not) installed. In the particular case that was brought to my attention, the printer would enable DTR to single the computer that it was ready for data, and the series 400 machine would refuse to transmit because it had the definition of DTR/CTS reversed. These problems did not show up on DN3xxx/4xxx machines, only on HP/Apollo 400 series machines. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (05/11/91)
In article <9105101401.AA01478@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >I have had reports from one of the people using my SR10 print-servers of >handshaking problems with serial lines configured for DTR/CTS (ie. hardware) >handshaking when running on series 400 machines under *some* versions of >SR10.2 and *some* versions of SR10.3. It apparently depended on which PSK's >you had (or had not) installed. > >These problems did not show up on DN3xxx/4xxx machines, only on HP/Apollo 400 >series machines. As of SR10.3 (plus some patches but no PSKs), the serial ports on our DN4500/fpa node do not work as tty0x (x=2,3) since DTR is never raised so the getty never sends the "login:" banner. Switching them to siox (x=2,3) fixes the problem. Tty01 always works. In fact, the problem only occurs after a power-off boot; once the ports have been used once as siox, they can be set back to tty0x, and will continue to work until the node is powered off (they will work across shut/reboots). It took several weeks for this problem to show up since we don't shut our systems off, and seldom even shut/reboot until something is so screwed up that the node is useless. Mike. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775