Port Server II Driver issue

Realport
1

I’m using a Portserver II / Port 16/em combination to emulate multiple serial console ports in a lan to lan test environment.

(Workstation LAN -> Digi PortserverII/Digi EM16 -> test station Management processor LAN)

We use HP Unix workstations as the test server to monitor the lan console on the test station. It’s a lan out and lan in from the workstation to the test chassis but the test software sees the console as a serial connection using the digi drivers. Due to firmware upgrades on the test chassis management processor I started seeing erratic behavior when connecting to the console. I updated the Digi drivers to the latest available and this fixed the console connection handshaking between the Digi Port Server and the management processor on the test station, but now the test software which runs on HPUX CDE won’t spawn the graphics based software components until the connection is established. It appears that no connection is established untill there is an existing STDOUT. In other words, If I establish a terminal connection FIRST (using the cu -l command) then the test software can start up the graphic window session but will not otherwise. It appears to be a case of the test program won’t run without a connection and the connection can’t be established without an existing output. Catch 22 situation. My question then is: is there a way to set the drivers or the Digi box configuration to extablish a connection without an existing STDOUT so that the test software creates a connection BEFORE creating the STDOUT?
Any ideas welcome. Thanks.

2

If I understand you correctly, it appears this worked fine until the test server had firmware upgrades applied. Has this been reported to the manufacturer who provdided the firmware updates?

Meanwhile, the only thing that comes to mind is the possibility of a blocking versus non-blocing issue. Be sure to use the /dev/cux## device (non-blocking).

3

Sorry, not sure what you mean by blocking? I’m using /dev/ttyExx. On the old version of the drpadmin I specified “e” for the port identifier and it would create a /dev/cuexx and with the new software it created them as “ttyExx”.

The new drivers definately fixed any issues I had communicating with the target device that originally resulted from the firmware upgrade. The problem I’m having now seems to be a conflict of port connection without a previously created STDOUT. Everything works fine if I’m working from a terminal but if the connection is attempted as a background process without a display then it is indeed “blocked”.