My first install of OSR5.0.5 was at the end of September (1998) for a customer upgrading from a Xenix system. This was a 16 user system running on a 486-100, with the main applications being a Filepro database (written and maintained by someone else) and RealWorld accounting software. I've supported this client on OS issues for 8 years or so.
It was Year 2000 compliance that forced the upgrade. That's often the case nowadays, but this was hastened a bit by the failure of their tape drive.
After much discussion of clones vs. brand names, the client settled on an HP E50 server with a 4 gig drive (10 times their present capacity), 64 meg of memory, and an HP Surestore DAT. This is a nice low-end server, well configured and reasonably priced.
HP does a nice job with these. Just as a small example, it's often quite a challenge even to figure out how to get a new machine open, because it is not immediately obvious anymore. The E50 is no exception, but HP has a nice diagram right on the front of the machine that shows you what to do (hint: push down hard and pull back).
Both to save the client some money and to give me a chance to thoroughly burn in the system, we decided to do the initial install and set up at my offices and then do a final data transfer after delivery.
As it happened, the machine, the OS and the customer's backup tape all arrived on a Friday afternoon. The tape was over a week old (because of their tape drive failure), but this let me get started and I can worry about final data transfer on site. The DAT drive and Filepro didn't show, but I didn't need them to begin work.
I had ordered 5.0.5 Enterprise even though there is no network now. It's foolish not to have this available, because the network will come. The documentation is pretty much the same as always; a few extra pieces of paper but no radical changes. The media is now packaged like Unixware: all the CD's in sleeves in one box.
The release notes are worth reading. While this is just an interim release which primarily just catches up 5.0.4 to all the required patches, there are some new features, including notes about a new notebook kernel image (it's a smaller memory kernel) , and some Dos tools (floppycp) to create images and btld's.
The required disk space for installation has gone up; it always does. Enterprise now requires at least 400MB. By the way, this now includes a copy of Skunkware 98: if you wanted to install all of that, there's another 500MB.
Network installation is supported, though only with a short list of specific nics. The models are listed in the release notes this time; in the 5.0.4 they were not. New models include Intel Etherexpress Pro100 (e100b) and 3Com 3c905 and 3c900.
According to the release notes, up to four (4) disks are recognized and can be configured during installation.
There's a new scoansi terminal type. The old ansi is still there, and the docs say that it should be used when logging into previous releases, and to use scoansi for Unixware 7.
You'd expect this to cause a problem when you rlogin from 5.0.5 to older systems, and indeed it does. There's already a TA on it: https://aplawrence.com/cgi-bin/ta.pl?arg=109521
This is now included (free) with the OS. Communicator includes such niceties as web page editing and publishing, Netscape Conference and Netscape Netcaster.
Sendmail is now version 8.8.8
There's an imapd (Imap 4) daemon installed by default.
Bind (named, version 8.1.1) now uses /etc/named.conf.
It's more than a name change: the new named has new features. The extent of the changes is too much to describe here; I expect the 5.0.5 On-Line Man Pages will be online at SCO soon; check named.conf when they are.
There is mention of how to edit /etc/conf/pack.d/fd/space.c to support higher speed machines. This was a Pentium 300; I couldn't create any floppy problems. However, I felt there was no harm in making the change anyway, so I decided to do that. Strangely, the expected variables were not in the space.c file (they are present on 5.0.4 systems).
There is also a note that warns that you can't format /dev/rfd0; that you have to specify the full device name like /dev/rfd0135ds18. That was true on 5.0.4, also, though I don't think the Release Notes mentioned it. Of course, most of us just type format which works fine unless you have two floppies and need to be specific.
The initial install went beautifully. The E50 bootable cdrom booted the SCO CD, and although the install program guessed wrong about the EIDE CDROM configuration (doesn't it always?), it did immediately recognize the Ethernet card and chose VESA SVGA by default for the video card. Later, when I ran mkdev graphics, it correctly identified the actual card installed, but VESA was a good default choice.
I had an interesting experience with the CDROM later while installing the tape drive. I somehow (klutzy fingers) managed to knock the CD power cable loose. Interestingly, the machine wouldn't boot either hard drive or floppy with that cable off. Apparently the BIOS does a very early check for that device, and hangs if it doesn't find it. It may have eventually timed out if I had left it alone, I don't know.
The release notes mention a new bootstring, Srom.ten that can be used if an EIDE CDROM doesn't support 6 byte SCSI read commands. I didn't need this, and have been lucky enough never to have had such a device in the past, but this might be good to know someday.
There's also scsi.noscan which was in 5.0.4 (but not in the bootstring man page). This prevents scanning for additional hard drives. I had need of this once on a 5.0.4 install, but not here.
The install screens are the same as usual for 5.0.4, except for a new one that tells how to install products (particularly Visionfs) from the Optional Services CD. I missed that one, but SCO people tell me it is there.
On later installs, I watched more carefully for this, and found that it comes at the very end, just before rebooting. I'm frankly disappointed with that: I see too many installs with no Visionfs and I suspect it's just because the installers don't notice it or don't understand what it is for. This tiny blurb doesn't help much.
Frankly the whole Optional Services CD is confusing. The readme file points out that some of the services might be bundled with your OS, but it doesn't give a matrix of what is. As far as I know right now, the only thing bundled with Enterprise is Visionfs.
Another confusing part is the Patches and Supplements directory, which includes things like oss449f!
I've heard that SCO will soon be putting up a web page for Late Breaking News about 5.0.5. I hope they make it less confusing.
I did a thorough scan just to see how well the controller/drive performed. The entire drive took 44 minutes, which is a bit faster than the 6 Mbytes/min estimate. That's sarcasm, of course: I don't know any modern machines that are even close to being that slow.
I took 128000 blocks for swap and 30000 for boot but did not make a /u. The silliness about entering a mount point for /dev/swap is still present, and you still end up with a /swap directory in your root filesystem.
The install started 1:45 PM. The first thing I checked was that Alt-F3 installation shell is still there (it is). The bar graph popped up 2 minutes later, it reached the 5% at 1:49 , was at 63% by 2:10 and 100% at 2:33. Finally it installed UDKcompat patch and the whole thing was done at 2:36
Generally, the machine is pretty quick for its price range. It outperformed a similarly equipped clone I have here, and by a quite noticeable amount. Of course, it does cost almost 50% more, so it should.
On the first boot, I was pleased to note that the wd.delay no longer necessary even though the CD is IDE. No long hang at wdinit.
Later installs on different hardware have still required this, though. I'm not sure why this machine did not.
The GUI came up a mess. I played with it a bit; got nowhere, so I backed it off to 640x480 and moved on to other things. I noticed later that there is a boot option in the E50 startup for viewing hardware; it looks like it's trying to do a graphic screen, but this was also messed up. I realized a few days later that the monitor I was using was an older plain VGA model; when I switched to a new 17 inch SVGA, I was immedially able to configure the higher resolutions, and use the actual video card that mkdev graphics saw rather than the generic vesa. I'll undoubtedly have to back this off for the customer; they intend to use one of their older monitors.
Which we did, for a few minutes, anyway. The old monitor from the Xenix box lasted about an hour, and then died. I don't know if that was just coincidence or it was overtaxed by the new video card, but we had to put up a new monitor.
The Desktop looks pretty much the same, except that Account Manager and Software Manager were out on the Desktop rather than within System Administration.
The first thing I noticed in "scoadmin" was a new "ISA PnP" manager.
I also noticed that a UW7 related TA ( https://aplawrence.com/cgi-bin/ta.pl?arg=109441 ) has been updated to include reference to 5.0.5, and it gives suggestions for using ISA PnP cards with this manager.
I had an ISA PnP Nic hanging about, so I threw it in, but the PnP manager insisted that no PnP cards were to be found. So much for testing that!
There is also a new DHCP manager; conceptually it looks very much like its counterpart in NT: you define pools of addresses with the Address Allocation Manager and parcel them out to subnets or individual clients. I didn't bother to reconfigure any of my Windows machines to test this; dhcp is pretty simple and I doubt it could be screwed up very badly.
Netscape communicator installed by default. This doesn't seem quite so demanding of high resolution as Navigator was, but I still couldn't configure it at 640x480. After switching to the newer monitor, I had 1024 x 768, and could.
As would be expected, if you are upgrading, Communicator would not install over what you have, and would need to be explicitly installed from custom.
Although the nic card had been recognized at install, it wasn't in netconfig, nor did it find it automagically. I've seen this before on 5.0.4; if you add a bogus card and then remove it, it then will find the PCI card. That same trick worked here.
Just choose any card from the list and configure TCP/IP on it as though you were really installing it. Leave the Netconfig manager, and immediately come back in. Remove the non-existent card, choose Add New, and the "invisible" PCI card will pop up (assuming, of course, that you already have the right software for that card installed).
Interestingly, when I entered an IP address of 10.1.1.1, the netmask defaulted to class 255.255.255.0, a class C mask. The old default would have been 255.0.0.0 as would be "normal" for network 10. I don't know if this was deliberate or not, but since most intranets using network 10 DO want a class C subnet, it does save a second or two of editing.
Both serial ports were configured by default; that's a change from 5.0.x. No parallel ports, as before.
Sar is still not enabled by default. This seems dumb to me, and I always turn it on: /usr/lib/sa.sar_enable -y. Sar reports take very little space; the default interval of 20 minute samples represents almost no effect on the machine's performance, and when you start having problems, it is real nice to have the default month's worth of history to look back on.
I added the 10 user license, which gives them 15 users. This annoys some customers that happen to have and need 16 users, but these folks can live with 15. I let it tune for the additional 10 users; no obvious differences from 5.0.4. But there are minor differences in /etc/conf/cf.d/mtune; I haven't checked exactly what changed and why.
I checked the system crontabs (always a good idea on a new release) and noticed nothing changed from 5.0.4.
The Xenix machine used a 250 MB QIC drive. I have an old Wangtek tape and controller that I keep around for these jobs. It's a full length card, so sometimes it's a bother to install, but it works. Fortunately "mkdev tape" still has those old cards as options, so the driver installation was quick and easy. I had no mounting hardware to put the tape in, so as usual the restore (relative to /xstuff) was done with the drive outside of the machine propped up by my checkbook and a couple of tape boxes. After the restore I moved over the user directories (using the scripts from /Unixart/upgrades.html) and the user executables, the /appl directory (Filepro), /u/rwc (RealWorld) and /u/wp51 (Wordperfect).
I added a "mapchan -n" to /etc/profile to take care of expected screen drawing problems, but forgot to check if I needed to. As it turned out, I didn't need to, at least not for the apps I have here.
After copying over /etc/default/ffppath, the old Filepro popped up working, and so did RealWorld (Version 6.5), which surprised me because I really didn't expect that to work. Several RealWorld types had led me to believe that it wouldn't, but so far this seems to. The customer does need to upgrade that for Y2K problems, but they are evaluating other software so it is good that this appears to be working.
The new Filepro has a "century mark" capability that lets you specify that two digit year dates before that mark are to be sorted and treated as being after 2000. This will help, but I've written too much Filepro to think that will solve all the issues. Fortunately for me, that's someone else's headache.
Filepro keeps its own termcap for extended features; I had to modify that so that it would recognize the new scoansi terminal, but that was just adding another alias for ansi.
As the Filepro upgrade hadn't arrived yet I couldn't do much more there.
Wordperfect (5.1) came up after making a link of scocons.trs to scoansi.trs. This was not necessary; the customer says they seldom if ever use it anymore, but it doesn't hurt that it works. WP5.1 works (though not well) on 5.0.4; I expect it will be just as good or bad here. I know that there is a problem here if someone shuts off their terminal without exiting WP; this causes a wp process attached to a psuedo tty to start gobbling up memory like candy. I'll warn them of this just in case they do decide to use it.
There is a Megaport card in the Xenix machine; this will be transferred at the final cutover, so I have put off printers until then. Xenix printers will need to be transferred over, but this is fairly quick and easy on site. I don't know yet how old the Megaport is, but the docs on Equinox's latest drivers seem to indicate they can support even the older models. We'll see. I have brought these cards up from older systems on other jobs, but I'm not sure they were as old as this one is. That could be a major hangup on site; but we can revert back to Xenix for a few days if we have to.
The HP has a feature for identifying ISA resources in the BIOS; I got the Megaport addresses out of /xstuff/usr/adm/messages and reserved them in the setup BIOS. I then installed new Megaprt drivers ( https://www.equinox.com ), linked them in, and rebooted. I didn't have the board yet, but this gives me the device files, so now I could transfer printers, and edit /etc/ttytype. The only thing I can't do here is enable the ports that were enabled; that will have to wait until I'm on site.
THe old Megaport did pretty well: it had 4 dead ports before the transfer and 7 after. Unfortunately, that was too many, so we had to rush order a replacement. Equinox makes a current card that can use the old Megaport pods (the external DB25 hookup pads), but they insist upon using a different tty naming scheme. That wasn't too hard to get around, though there were many places that hardcoded tty ports to do such things as offering different default printers depending upon what terminal you logged in in; these took a while to track down and fix.
The most annoying thing was the install itself. I'm sure that either something went wrong or it is documented somewhere, but after first installing the new drivers, nothing worked. The documentation I had said to run ssdiag, but that just bombed out complaining about a missing database. I called Equinox for support, but all the techs were in a meeting, so I started poking around, and found something called ssmknm (or something like that) and, since I had nothing working and nothing to lose, I ran it. Fortunately, this completed the configuration, ssdiag now worked, and we were able to continue.
I transferred the printers using the script from /Unixart/upgrades.html#xprin
Users were extracted by editing /xstuff/etc/passwd to remove the system accounts and then running
addxusers -f -v /xstuff/etc/passwd
The release notes warn that the installation breaks several symbolic links, including /etc/passwd, so I deliberately did not run the Software verification until after adding in the Xenix users, just to see if the "you should do this immediately" warning in the Release Notes had any teeth in it. As I expected, the verify fixed the symlinks correctly, without losing my new users.
I installed Visionfs and had the usual problems getting it licensed; netbios running, a mismatched "hostname" vs /etc/hosts, but nothing very serious: See: /Unixart/visionfs.html
I'm a little surprised that it is still possible to get the hostname business screwed up just by changing names in netconfig, but it is no big deal if you are expecting it and know what to look for.
The HP Surestore arrived Saturday, so I took the Wangtek out of the kernel, added this in, and then added back in the Wangtek so that the HP will be the first tape. That will make it easier to remove the Wangtek when I'm done with it on site.
The physical installation was a breeze, because HP really is a class act. The SureStore kit includes rails for both their E series and L series servers, extra screws, extra jumpers, a power extender, and their SCSI cable already had one 50 pin adapter on it. Furthermore, the set up instructions included Sun and SCO, and even gave the correct responses for "mkdev tape".
Strangely (I've never noticed this before), the "mkdev tape" insisted that the old Wangtek had to be the default drive for it to work properly. I don't recall that being true in the past, but I may just have never had this installed in conjunction with a SCSI drive before.
Microlite added a new indexed, fast-find restore a little while back, but I hadn't had a chance to play with it until now. Setting this up involves running their edge.resmgr to identify the tape device and determine how well it can be fast positioned. I found this a little confusing, but fortunately there are crystal-clear examples in the supplemental manual, and those made it all perfectly sensible. Part of this configuration involves setting the Locate Threshold. If you don't know what that threshold is, the FFA (Fast File Access) test will determine this for you. It does take significant time to test a drive (which is why I never did it before now: I've always been on site and left it for the customer to do without having to pay me for watching a tape run), so be aware of that.
After getting this set up, I made the first set of Emergency Boot disks, printed the Edge configuration report, and stuffed those into the Edge product box. I always show the customer how to do this (and these folks had been running Ctar on Xenix so they already know), but I like to tuck away a set whose location I know. This can be a great help when I get the 4:00 PM Friday afternoon phone call from a very panicky person who has just lost their hard drive.
After making the first Master Backup, and before setting the cron scripts, you next run edge.emx (it is an X program, so obviously you must be in the GUI), and create an index of the tape. This also takes a fair bit of time, but you will be able to set the Automatic Backups to create the index during the Verify phase, so normally this is nothing to be concerned about.
After the index has been made, you get a point and click interface to work with. Again, I found this slightly less than perfectly intuitive, but a minute in the manual set me straight. I deliberately chose a file near the end of the backup to test; the restore was impressively quick: approximately a minute to get to the end of a 550 MB tape and read back the file.
According to the release notes, the online help has been improved. Of course, that's the exact text that was in the 5.0.4 documentation, so who knows? There certainly are some changes: the Netscape section now refers to Communicator rather than Netscape Gold, etc, but I don't have the time or patience to go through it exhaustively right now.
The question for 5.0.4 folks is whether it is worth the cost and trouble to upgrade. For some, of course, the new features are certainly worth it, and I would think this is particularly true if you are pre-5.0.4.
But really this doesn't offer a lot over 5.0.4. Personally, I don't need Communicator or DHCP in my office setup, and I'm planning to move to UW7 soon anyway, so I'll probably skip this release.
Other folks have different needs and desires, of
If you have an old app and need a Filepro programmer, or assistance with SCO Unix, I can help.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2012-07-14 Tony Lawrence