Solution:
This document is about some unusual (to some) behavior which can occur in environments where the Realport driver is installed for use with a Portserver TS line or Digi One products.
The symptoms of this behavior are that setting changes made to the ports via the root account appear to be made, but when checked again at a later time they have changed. This is not a problem, but normal operation in a Realport environment.
In operation, the Realport driver's task is to take control of the physical ports, and then create psuedo devices to be used by the operating system (OS) hosting the RealPort driver. In a Windows environment, these appear as Com ports while in Unix, tty devices are created.
Once the RealPort driver is installed, all further port configuration is done at the OS level. Changes to things like flow control, baud rate, parity, forcedcd, altpin, etc. which are done on the com port/tty device at the OS level are actually being done to the unit as well. This is why it may seem like manual settings on the PortServer/Digi One units are changing, when in reality it is the driver changing them to match device configuration on the OS. In other words, the RealPort driver has control of the unit in all respects.
Example: A Portserver TS 16, by default, has a baud rate of 9600 baud on its physical ports, as revealed by doing the command "set line range=*". If you configure port 1 on the Portserver TS 16 with "set port range=1 dev=rp", it allows port 1 to be controlled by the RealPort driver. RealPort is then installed on an AIX server and configured to control port 1, now known to AIX as tty6. If the baud rate on tty6 is changed to 19200, doing a "set line range=1" will show that the baud rate on the TS port 1 has now changed accordingly.
In short, this behavior is not a bug, but is the way RealPort is intended to work so as to ease the task of port configuration for a sysadmin.
If the behavior seen is the opposite (i.e. the RealPort settings are not seen on the Digi unit), make sure the port is using the "RealPort" (rp) profile in the unit itself, this is required for the RealPort host to take "ownership" of the ports. This can be checked from the root prompt of the unit(s):
#> set ports
The "dev" setting should be set to "rp". If not:
#> set ports dev=rp range=*
Reboot the unit for the changes to take effect:
#> boot action=reset