Find the answer to your Linux question:
Results 1 to 4 of 4
Hi all, I've got an issue where I am supporting an older closed-source application written for SCO, and I am attempting to run it under linux. It runs amazingly fast ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    XDS
    XDS is offline
    Just Joined!
    Join Date
    May 2003
    Posts
    2

    Trouble with virtual terminals when supporting a SCO app


    Hi all, I've got an issue where I am supporting an older closed-source application written for SCO, and I am attempting to run it under linux.
    It runs amazingly fast under linux vs. SCO using the ICBS packages. We're talking in the order of 300-400% faster.

    We connect to the system via telnet or ssh. No serial terminals are involved.

    This application 'identifies' users within the program via their tty # (ie tty123, tty54), therefore, a single user can login to this program correctly, but once a second user telnets to the machine, the software believes the user is already connected as it only identifies the user by the controlling tty that telnetd is running on, and is not aware of virtual ttys (ie, pts/0 pts/1).

    Is there a way to force users to be mapped to a tty (like cu did in Solaris) that our application can understand? Printing is not an issue, as we use IP-based printing vs print back to tty. a hacked telnetd perhaps? A different terminal controller than mingetty? Any ideas are appreciated.

    If this is not the correct forum for this question, or if you are aware of a more approriate venue for this, please let me know.

    Thanks!

  2. #2
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    It's good that you're going from SCO to Linux in these times... =)

    I'm not sure what pty naming scheme SCO uses normally, though. I haven't used it, and especially since things look the way they do right now, I don't think I ever will. But surely, it too must support Unix98 PTYs in /dev/pts? Could you illuminate me?

  3. #3
    XDS
    XDS is offline
    Just Joined!
    Join Date
    May 2003
    Posts
    2
    SCO appears to use a naming scheme which I would consider 'classic'.
    /tty1, tty2-tty136, and so forth. Apparently they do not use mixed alpha such as ttyP1, ttyFA, etc.

    The problem isn't so much a SCO to Linux one, as it is a problem with our application, called Medical Manager. It only wants to see the 'root' controlling device aka /dev/tty06 that telnetd binds to, and is not aware of the pty-style naming scheme. The source for this application is closed, and apparently the software vendor is not willing to update the code to support a free OS. I think they make some of their money through the sale of the SCO licenses. SCO is flat out all they are willing to support.

    I might be up the creek on this one, and it would be a shame. There is so much more I can do with a linux box (clustering, high-availability, etc) that I can not do with SCO, or at least without a lot of $$$. Combine that with the fact that on two identical boxes, the linux/medical manager system absolutely annihilates the SCO box for speed on indexing/sorting.

    Again, I guess what I'm looking for is a way to present the pty sessions as the 'classic' style, true serial port TTYs to the application.

  4. #4
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    I guess that you could create some ptys using the "conventional" (how conventional it actually is compared to UNIX standards I don't really know, but anyway...) using mknod on the older BSD style PTYs, ie. the /dev/pty[a-z]? and corresponding /dev/tty[a-z]? devices. Check them out with ls -l for the device numbers that you need, and then create some slave devices there with the /dev/tty[A-Z][A-Z] names that you seem to need. Then modify the login program that you use to use those device names instead. It's not too small a job, but it shouldn't be to hard either.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •