SCO 5.0.7V

Although many an old SCO box has been replaced by Linux or (shudder) Windows, many others still chug along in server rooms across the country. Sometimes the server remains alive because of stubbornness, sometimes it is just rank ignorance, but more often it's simply that any replacement is economically difficult. The SCO server is kept alive because the company using it can't afford any alternative.

I have a number of resources here about converting or maintaining SCO systems.

Most of these old systems run on SCO's 3.2v5 operating systems. These date from 1995 (3.2v5.0.0) to 2003 (3.2v5.0.7), so the newest of them is seven years old and are often running on hardware of the same age. Never mind security, operability or anything else: it's downright scary to be running on hardware that old. Unfortunately, installing SCO on anything current can be difficult or even impossible as driver support melts away.

As of this writing, it is still possible to install SCO 5.0.7 on generic hardware but when you start getting into RAID systems it can be very hard to find drivers and even network cards can cause some difficulty - it's all become nasty enough that I refuse to do any such work on anything but a flat time and materials basis with no guarantees of success. If the system is older than 5.0.6 and can't be upgraded to at least 5.0.7, I may refuse it anyway - it's just too unpleasant. Life sucks for old SCO owners.

SCO has made things a bit easier by providing SCO 3.2v5.0.7V, which is a VMware image - that is, it's not an operating system installation disk, it's an image of an already installed (partially unconfigured) SCO 5.0.7 system. That's important because it means you don't "install" the OS within VMware, you "import" or (depending upon your flavor of VMware) "deploy" it. After VMware is done bringing it in, you boot it and it asks for the system configuration info needed - see all this at the 5.0.7V for VMware Getting Started Guide.

I was involved with one of these earlier this week. The customer had an old Compaq running a Synergy DBL system under SCO 5.05. I was simply contracted to install the SCO (their VMware vendor had attempted part of that but didn't realize that the CD was a VM image) and to transfer data.

This was a fairly easy process. I transferred users using "ap" (see SCO Unix Upgrades for more on that and other upgrade issues), tarred up their home directories and transferred them with "rcp" after establishing user equivalence.. I suppose I could have taken the trouble to install ssh on the old system, but why look for trouble? The old "rcp" works.

To establish user equivalence, the simplest thing is to login to the new server from the old. Do a "w -x" to see the source of your login - it will either be an ip address or a name. Whatever it is, put that in /.rhosts and chmod 600 /.rhosts. You'll then be able to rcp from the old to the new.

We added a second drive which was actually a NAS. VMware abstracts that as scsi id 1, so SCO doesn't know that this is actually a network device. However..

While transferring data, I observed WRITE_10 errors. Specifically:

Mon Feb 15 15:47:11 2010 WARNING:  "WRITE_10" command timed out 12
seconds after its start on ha=0 id=1 lun=0 Request=C102F6A0
WARNING:  "WRITE_10" command timed out 12 seconds after its start on ha=0
 id=1 lun=0 Request=C1035B80

The VMware consultant expressed no interest whatsoever except to observe that we were hammering heavily transferring data and that he was trying to install Exchange on the same NAS concurrently.

OK - color me naive, but if you can't transfer data to one VM while installing another, is this really usable? I would think not, but what do I know?

After the Exchange install finished, we didn't see any more problems. Until two days later, that is:

Wed Feb 17 09:19:13 2010
WARNING:  "WRITE_10" command timed out 12 seconds after its start on ha=0
 id=1 lun=0 Request=C102F100

That upset me. but it turned out that the VMware folks had needed to take the NAS down at about that time. You'd think they would have realized that no operating system likes its drives disappearing, but they did not mention this until I sent email to the customer's IT person warning about the error. I'm left HOPING everything is in fact as it should be - I'm not completely confident.

But - maybe there WAS something misconfigured, maybe that's why they bounced it, maybe I'm worried for nothing. I left instructions for checking /usr/asdm/messages and with luck they won't see that again.

We did have a minor issue with Synergy. On the old system, all that stuff was installed under /usr/asa/synergy. Apparently new binaries were needed to transfer to 5.0.7, and these were all installed in /usr/asa/synergyde. As there were an unknown number of scripts referring to the old paths, I created a symlink: ln -s /usr/asa/synergyde /usr/asa/synergy to fix that.

Printers were easy as these were all netcat printers. I simply rcp'd the interface scripts to /usr/spool/lp/model and than ran lpadmin for each printer:

for i in printer1 printer2 printer3
/usr/lib/admin -p $i -m $i -v /dev/null
/usr/lib/accept $i
enable $i

I transferred the mmdf information and was able to send mail. There were some cron entries I extracted from "crontab -l" and added them to the new machine. That was about it for me. I headed home and sent them my bill.

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> SCO Unix 5.0.7v on VMware


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Sat Feb 20 18:47:02 2010: 8101   SteveSmith


Hi Tony,

Thanks for the timely article. I've got a potential customer with a similar situation, but I've been a bit reluctant to dive in.

The thing about Vmware is that so many people expect hardware level performance when in reality it's the hardware layer plus a software abstraction layer. I'm not surprised when things slow down a bit.

As I understand it, the SCO VM instance is licensed on a yearly basis through SCO. I'm curious if your customer had any issues with that? I would imagine that they owned their previous version.

Sat Feb 20 18:56:21 2010: 8102   TonyLawrence


As these systems are often running on older hardware, the VMware can actually be an improvement. It was here - reports that formerly took 20 minutes to run now complete in 13 minutes.

As to the licensing, no, that wasn't an issue. It's reasonably priced.

Wed Jun 9 12:32:31 2010: 8673   Skully


So now we are faced with the job of making backups to store offsite.
It is my understanding that tape drives are not supported with 5.0.7V.
Are we to make backups to files and FTP them for storage?
BTW, thanks for the great info, you've saved countless lives and systems with this website!

Wed Jun 9 13:35:57 2010: 8674   TonyLawrence


I strongly recommend using Microlite BackupEdge to backup to FTP servers.

You can download a fully functional demo from (link) and when you are ready to buy, I can save you money on the purchase.

Tue Jan 4 15:42:54 2011: 9200   LindaR


Thanks for a great article. We have a client entertaining the idea of moving 2 existing 5.0.7 servers to VMware. Possibly a naive question, but I've been unable to find this answered anywhere. Will 5.0.7 executables run under 5.0.7v?

Tue Jan 4 15:57:09 2011: 9201   TonyLawrence


Yes, 5.0.7v is 5.0.7 as far as apps are concerned.

Kerio Samepage

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

A computer once beat me at chess, but it was no match for me at kick boxing. (Emo Philips)

This post tagged: