SCO Unix 3.2.4.2 networking/licensing - SCO

This is a discussion on SCO Unix 3.2.4.2 networking/licensing - SCO ; Hi All, It's been a long time since I've worked with SCO 3.2.4.2 and I've encountered a remote system that I need to migrate off of and networking is essential to the plan. The system doesn't have networking installed and ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: SCO Unix 3.2.4.2 networking/licensing

  1. SCO Unix 3.2.4.2 networking/licensing

    Hi All,

    It's been a long time since I've worked with SCO 3.2.4.2 and I've
    encountered a remote system that I need to migrate off of and
    networking is essential to the plan.

    The system doesn't have networking installed and I'm worried that they
    may not be licensed for it. I recall that some of what we would
    consider to be standard options were extra licensed options back
    then.

    Does anyone remember if 3.2.4.2 included TCP/IP networking in the base
    license?

    I just hope I this customer has the original disks.

    Thanks,

  2. Re: SCO Unix 3.2.4.2 networking/licensing

    > It's been a long time since I've worked with SCO 3.2.4.2 and I've
    > encountered a remote system that I need to migrate off of and
    > networking is essential to the plan.
    >
    > The system doesn't have networking installed and I'm worried that they
    > may not be licensed for it. I recall that some of what we would
    > consider to be standard options were extra licensed options back
    > then.
    >
    > Does anyone remember if 3.2.4.2 included TCP/IP networking in the base
    > license?
    >
    > I just hope I this customer has the original disks.


    Products at that time included (among others) SCO Unix 3.2v4.2 and SCO
    Open Desktop 3.0 / SCO Open Server 3.0. If someone bought the
    standalone Unix package then they could buy TCP/IP as an addon (it would
    have been SCO TCP/IP for Unix, version 1.2.1). Chances are, if they
    have a TCP-less install, they bought the plain Unix package and did not
    buy TCP/IP. If they bought Open Desktop / Open Server, I think it was
    technically possible to run through an install of those and end up
    without TCP/IP, if you told it you wanted full control over what was
    installed and then deliberately omitted TCP/IP and all the things that
    would have pulled it in; but it's very unlikely a user would have done
    that. Why pay thousands of dollars more and then install it in a manner
    which omits the extra cost options?

    Why is networking essential to the plan? You could hook it up with a
    serial cable to a Linux / etc. box next to it and use serial line UUCP;
    you could do a hard disk transplant; you could back up to whatever tape
    device they have (hopefully they have...) and then pull it in on a Linux
    system -- you don't need two controllers/drives because Linux will
    probably have drivers for the existing one. You could also probably
    find someone to sell you a SCO TCP/IP 1.2.1 license (careful that you
    get the Unix, not Xenix, version). Without knowing your reason that
    networking is essential, I can't evaluate the relative merits of these
    approaches...

    >Bela<


  3. Re: SCO Unix 3.2.4.2 networking/licensing

    On Feb 7, 1:46 pm, Bela Lubkin wrote:
    > Products at that time included (among others) SCO Unix 3.2v4.2 and SCO
    > Open Desktop 3.0 / SCO Open Server 3.0. If someone bought the
    > standalone Unix package then they could buy TCP/IP as an addon (it would
    > have been SCO TCP/IP for Unix, version 1.2.1). Chances are, if they
    > have a TCP-less install, they bought the plain Unix package and did not
    > buy TCP/IP.


    I'm pretty sure that's it.

    > If they bought Open Desktop / Open Server, I think it was
    > technically possible to run through an install of those and end up
    > without TCP/IP, if you told it you wanted full control over what was
    > installed and then deliberately omitted TCP/IP and all the things that
    > would have pulled it in; but it's very unlikely a user would have done
    > that. Why pay thousands of dollars more and then install it in a manner
    > which omits the extra cost options?


    uname -X says: Release = 3.2v4.2. I assume it would be different for
    ODT despite a similar kernel. Is that true.

    > Why is networking essential to the plan?


    The customer is remote (8 hour drive away) so we want to do only one
    visit. We want to run a parallel system for a week for testing
    purposes. The on-site time is for putting in place all the new
    equipment which includes migrating the printers to Jet Directs and
    serial terminals to thin clients. Without network access we can't
    share printers or replace terminals. That would mean extra equipment
    (their existing serial terminals use standard monitors and keyboards
    which are not being replaced) and/or an extra visit. This is something
    that's not in the budget.

    > You could hook it up with a
    > serial cable to a Linux / etc. box next to it and use serial line UUCP;


    We could do that to transfer data. It's 150MB of data which probably
    compresses to 40MB then uuencodes back up. A PPP connection could run
    all the terminals and print jobs through it.

    > you could do a hard disk transplant; you could back up to whatever tape
    > device they have (hopefully they have...) and then pull it in on a Linux
    > system -- you don't need two controllers/drives because Linux will
    > probably have drivers for the existing one.


    They are moving to Linux and I know that we could effect a one-off
    transfer while on-site. Doing it remotely wouldn't be possible if it
    involved moving hard disks.

    I had thought that VMWare might work for us as well. I would still
    need networking though.

    > You could also probably
    > find someone to sell you a SCO TCP/IP 1.2.1 license (careful that you
    > get the Unix, not Xenix, version).


    It looks like that might be the easiest answer. If I could find one,
    there are still obstacles in my way. The system is old ( 10 years, I'm
    told) and it's not clear whether it's has PCI slots (uname -X says:
    BusType = ISA) Finding an ISA device with drivers is going to be more
    time.

    > Without knowing your reason that
    > networking is essential, I can't evaluate the relative merits of these
    > approaches...


    It's really a matter of hitting our budget. Our constraints are: one
    on-site visit, minimal extra purchases, and no on-site IT talent.

  4. Re: SCO Unix 3.2.4.2 networking/licensing

    >> You could hook it up with a
    >> serial cable to a Linux / etc. box next to it and use serial line UUCP;

    >
    > We could do that to transfer data. It's 150MB of data which probably
    > compresses to 40MB then uuencodes back up. A PPP connection could run
    > all the terminals and print jobs through it.


    No ppp.
    No networking means really, no networking.
    Thats why Bela said things like uucp. You could do a serial transfer via uucp, kermit, zmodem, .. not ppp. In the case of kermit or zmodem you'd have to download binaries to floppy when you got there too, not already installed.
    If you do find a copy of tcp, you'll gain ppp, but then won't need it.

    Since they have serial terminals, that means they have some kind of multiport serial card.
    Be sure to use one of the ports on that card for the transfer since they can probably go to 115200 and they can probably use hardware flow control, otherwise....

    I don't think you are going to run parallel without a 2nd visit without tcp.
    I think it's possible, just not practical.

    Here's how you could probably do it, with one big assumption that might be wishful thinking:

    big assumption: You could probably set up the sco box to submit print jobs via uucp to the linux box.
    Assuming that, the rest isn't too difficult:
    * set up the printers on linux and reconfigure them on sco to submit to linux via uucp.
    * configure the new pc's or thin terminals to have both serial and network connections to run both systems at once.
    * connect an extra serial connection between the sco & linux boxes not used by the print spooler. enable that serial port for login on sco.
    * at some later time when you want to refresh the data and stop using sco, you ssh in to the linux box and use kermit or minicom or cu to log in to the sco box and perform a serial data transfer.

    But I would just try to find a copy of tcp and bring one each isa and a pci nics.
    Probably any old 3com will be supported and easy to find, if you have time to find a copy of tcp, then you have the same time to find old nics on ebay and double check the 3com and/or sco sites to make sure the drivers support that model on that version of sco.
    If all else fails I have such cards myself but I only _know_ they work on 5.0.4 & up. Have to check if the same drivers support the older versions of sco or if some other old driver support that card.
    You can doo that google scutwork as well as me or anyone else so, since it's your job...


    hw |pg might show the bus type more accurately, or might show something like a model or version number you can google up specs on. If the box is a compaq or other proprietary name brand, you can probably just have them read you the name/number on the front and google the specs.
    It's probably really pci but I'd try to find an isa card just in case if the on-site is such a big deal.

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  5. Re: SCO Unix 3.2.4.2 networking/licensing

    On Feb 7, 3:20 pm, "Brian K. White" wrote:
    > No ppp.
    > No networking means really, no networking.


    Arrghh!

    > Thats why Bela said things like uucp. You could do a serial transfer via uucp, kermit, zmodem, .. not ppp. In the case of kermit or zmodem you'd have to download binaries to floppy when you got there too, not already installed.
    > If you do find a copy of tcp, you'll gain ppp, but then won't need it.
    >
    > Since they have serial terminals, that means they have some kind of multiport serial card.
    > Be sure to use one of the ports on that card for the transfer since they can probably go to 115200 and they can probably use hardware flow control, otherwise....


    Good idea.

    > I don't think you are going to run parallel without a 2nd visit without tcp.
    > I think it's possible, just not practical.
    >
    > Here's how you could probably do it, with one big assumption that might be wishful thinking:
    >
    > big assumption: You could probably set up the sco box to submit print jobs via uucp to the linux box.


    Another good idea.

    > Assuming that, the rest isn't too difficult:
    > * set up the printers on linux and reconfigure them on sco to submit to linux via uucp.
    > * configure the new pc's or thin terminals to have both serial and network connections to run both systems at once.


    Hadn't thought of that. The new thin clients do have a serial port. I
    would have to share the CAT5 though.

    > * connect an extra serial connection between the sco & linux boxes not used by the print spooler. enable that serial port for login on sco.


    I don't think I have an extra serial port on the new server. I can
    remote control a thin client though.

    > * at some later time when you want to refresh the data and stop using sco, you ssh in to the linux box and use kermit or minicom or cu to log in to the sco box and perform a serial data transfer.


    For 40MB (uuencoded to about 60MB) would take less than 2 hours.
    That's possible.

    > But I would just try to find a copy of tcp and bring one each isa and a pci nics.


    It's looking like that's a good path. Ebay comes up with nothing. I'll
    post here in another post.

    > hw |pg might show the bus type more accurately, or might show something like a model or version number you can google up specs on. If the box is a compaq or other proprietary name brand, you can probably just have them read you the name/number on the front and google the specs.
    > It's probably really pci but I'd try to find an isa card just in case if the on-site is such a big deal.


    Thanks for the command, I don't recall using hw before.

    I am also investigating borrowing a dev SCO 5.0.6 box and using it for
    a rip 'n replace and paralleling with that. It's not perfect, but I
    think the developer may agree.

    Has anyone run 5.0.6 on VMWare, or Xen?

  6. Re: SCO Unix 3.2.4.2 networking/licensing

    On Feb 7, 3:15*pm, John Van Ostrand
    wrote:
    > On Feb 7, 3:20 pm, "Brian K. White" wrote:
    >
    > > No ppp.
    > > No networking means really, no networking.

    >
    > Arrghh!
    >
    > > Thats why Bela said things like uucp. You could do a serial transfer viauucp, kermit, zmodem, .. not ppp. In the case of kermit or zmodem you'd have to download binaries to floppy when you got there too, not already installed.
    > > If you do find a copy of tcp, you'll gain ppp, but then won't need it.

    >
    > > Since they have serial terminals, that means they have some kind of multiport serial card.
    > > Be sure to use one of the ports on that card for the transfer since theycan probably go to 115200 and they can probably use hardware flow control, otherwise....

    >
    > Good idea.
    >
    > > I don't think you are going to run parallel without a 2nd visit without tcp.
    > > I think it's possible, just not practical.

    >
    > > Here's how you could probably do it, with one big assumption that might be wishful thinking:

    >
    > > big assumption: You could probably set up the sco box to submit print jobs via uucp to the linux box.

    >
    > Another good idea.
    >
    > > Assuming that, the rest isn't too difficult:
    > > * set up the printers on linux and reconfigure them on sco to submit to linux via uucp.
    > > * configure the new pc's or thin terminals to have both serial and network connections to run both systems at once.

    >
    > Hadn't thought of that. The new thin clients do have a serial port. I
    > would have to share the CAT5 though.
    >
    > > * connect an extra serial connection between the sco & linux boxes not used by the print spooler. enable that serial port for login on sco.

    >
    > I don't think I have an extra serial port on the new server. I can
    > remote control a thin client though.
    >
    > > * at some later time when you want to refresh the data and stop using sco, you ssh in to the linux box and use kermit or minicom or cu to log in to the sco box and perform a serial data transfer.

    >
    > For 40MB (uuencoded to about 60MB) would take less than 2 hours.
    > That's possible.
    >
    > > But I would just try to find a copy of tcp and bring one each isa and a pci nics.

    >
    > It's looking like that's a good path. Ebay comes up with nothing. I'll
    > post here in another post.
    >
    > > hw |pg *might show the bus type more accurately, or might show something like a model or version number you can google up specs on. If the box is a compaq or other proprietary name brand, you can probably just have them read you the name/number on the front and google the specs.
    > > It's probably really pci but I'd try to find an isa card just in case ifthe on-site is such a big deal.

    >
    > Thanks for the command, I don't recall using hw before.
    >
    > I am also investigating borrowing a dev SCO 5.0.6 box and using it for
    > a rip 'n replace and paralleling with that. It's not perfect, but I
    > think the developer may agree.
    >
    > Has anyone run 5.0.6 on VMWare, or Xen?


    I may have TCP/IP package for Rel 3.2v 4.2 please contact me directly
    (akhan@att.net).

  7. Re: SCO Unix 3.2.4.2 networking/licensing


    ----- Original Message -----
    From: "John Van Ostrand"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Thursday, February 07, 2008 4:15 PM
    Subject: Re: SCO Unix 3.2.4.2 networking/licensing


    > On Feb 7, 3:20 pm, "Brian K. White" wrote:
    >> No ppp.
    >> No networking means really, no networking.

    >
    > Arrghh!
    >
    >> Thats why Bela said things like uucp. You could do a serial transfer via uucp, kermit, zmodem, .. not ppp. In the case of kermit or zmodem you'd have to download binaries to floppy when you got there too, not already installed.
    >> If you do find a copy of tcp, you'll gain ppp, but then won't need it.
    >>
    >> Since they have serial terminals, that means they have some kind of multiport serial card.
    >> Be sure to use one of the ports on that card for the transfer since they can probably go to 115200 and they can probably use hardware flow control, otherwise....

    >
    > Good idea.
    >
    >> I don't think you are going to run parallel without a 2nd visit without tcp.
    >> I think it's possible, just not practical.
    >>
    >> Here's how you could probably do it, with one big assumption that might be wishful thinking:
    >>
    >> big assumption: You could probably set up the sco box to submit print jobs via uucp to the linux box.

    >
    > Another good idea.
    >
    >> Assuming that, the rest isn't too difficult:
    >> * set up the printers on linux and reconfigure them on sco to submit to linux via uucp.
    >> * configure the new pc's or thin terminals to have both serial and network connections to run both systems at once.

    >
    > Hadn't thought of that. The new thin clients do have a serial port. I
    > would have to share the CAT5 though.


    I presumed there was already serial wiring in place to the old terminals, just plug them into the new clients same as they were in the old ones. And the tcp network would use seperate unrelated, probably new, cat5.


    >> * connect an extra serial connection between the sco & linux boxes not used by the print spooler. enable that serial port for login on sco.

    >
    > I don't think I have an extra serial port on the new server. I can
    > remote control a thin client though.


    On linux, $20 usb/serial dongles work fine and automagically.

    Remote gui access in stead of text ssh, then remote desktop or vnc to a desktop.. yeah it's an option but I'd call it a fallback option because of the speed and increased complexity.

    I'm really unsure about the ease of getting the sco box to submit print jobs to linux via serial anyways so swapping in a 506 box sounds like a great answer. Easy, as long as you think you know all there is to know about the application and the site-specific host config (users, printers, cron jobs, misc scripts and things) . If you do that, then serial ports become moot.

    The app will run the same with no or extremely little fuss, printers and users will be easier to transfer than to linux since, 506 uses the same printer spooling system, you can just look and mimic settings exactly, including copying hand edited interface scripts, instead of having to figure out how to get cups on linux to behave the same, or adjust the app to cups's behaviour. Similarly, users can be copied in one shot with the ap command, and users profiles can just be copied over without translating if it turns out the app vendor has placed settings in peoples profiles. Lots of things are simple that way.

    And with the old server being so small, you can pop the drive in the 506 box and just copy the whole drive so that later when you're away and discover some issue, you can poke through the copy of the old drive and find the old config file or script or whatever you are hit with.

    >> * at some later time when you want to refresh the data and stop using sco, you ssh in to the linux box and use kermit or minicom or cu to log in to the sco box and perform a serial data transfer.

    >
    > For 40MB (uuencoded to about 60MB) would take less than 2 hours.
    > That's possible.


    Don't uuencode. Only way I see you need that is when you do a plain cu %put or %take
    I wouldn't trust the data from a plain cu transfer even on a local hard serial line in perfect condition with full properly working hardware flow control. Especially not 40M worth (read, especialy not solid hours worth).

    Let kermit or zmodem handle it. kermit and rz/sz binaries exist for your version of sco. They will transfer 8 bit binary data directly and do error correction on the fly without aborting or corrupting and they can abort & resume cleanly & reliably and you can vastly more safely trust the resulting copy. I suppose you could do a simple checksum after the cu/uuencode copy to verify it's clean, but I wouldn't want to risk wasting hours to have it burp in the middle or fail the checksum at the end.

    But, hopefully you won't have to worry about serial anyways.


    > I am also investigating borrowing a dev SCO 5.0.6 box and using it for
    > a rip 'n replace and paralleling with that. It's not perfect, but I
    > think the developer may agree.
    >
    > Has anyone run 5.0.6 on VMWare, or Xen?


    At least vmware is known to work, with a bit of hammering & filing, but I haven't done it myself so if you find someone to lay out the hints & gotchas, that would be a good way.

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  8. Re: SCO Unix 3.2.4.2 networking/licensing

    John Van Ostrand wrote:

    > uname -X says: Release = 3.2v4.2. I assume it would be different for
    > ODT despite a similar kernel. Is that true.


    That output would be the same for ODT 3.0 and Unix 3.2v4.2, I'm afraid.
    Run `custom` and see what top level product is installed. But it's sure
    to be TCP-less Unix.

    > > You could also probably
    > > find someone to sell you a SCO TCP/IP 1.2.1 license (careful that

    you
    > > get the Unix, not Xenix, version).

    >
    > It looks like that might be the easiest answer. If I could find one,
    > there are still obstacles in my way. The system is old ( 10 years, I'm
    > told) and it's not clear whether it's has PCI slots (uname -X says:
    > BusType = ISA) Finding an ISA device with drivers is going to be more
    > time.


    BusType enumerates all the way from ISA to MicroChannel; EISA, PCI and
    anything newer does not show up in `uname -X`. OSR5 shows "%pci" at
    boot time on PCI machines, I forget whether that dates back as far as
    3.2v4.2. But I will also hazard a guess that this is a PCI system.

    Run `hwconfig -h` and look what NIC and HBA drivers are in use. Most of
    them are bus-specific so if you see e.g. a 2940 or Intel Pro/100 driver,
    you know it's PCI.

    > Has anyone run 5.0.6 on VMWare, or Xen?


    Many people have on VMware, I don't know about Xen (I imagine a
    major case of philosophical allergy ;-) I have used OSR5 VMs on ESX,
    Workstation and Server. 5.0.7 is considerably easier to deal with than
    5.0.6 (you avoid the worst hassles if you copy a hard disk image into
    VMware instead of trying to install inside the VM). Showstopper issue
    for 506 is inability to boot the ISO because /boot gets confused about
    the geometry of the El Torito boot image. For both 506 & 507 you need a
    BusLogic BTLD from SCO, then you need to patch it if you want to be able
    to do warm reboots. Google Groups (USENET search engine FKA dejanews)
    has all the info.

    >Bela<


+ Reply to Thread