SCO's "custom" problems
Some material is very old and may be incorrect today
© December 2003 Tony Lawrence
Link: SCO TA 125188
SCO's custom is amazingly bad software. Today I was configuring a system for a client, and after adding a driver for a Stallion card, going back into "custom" rewarded me with:
"Unable to start software manager. Possibly because it is already in use"
How nice. I thought there might be a lock, so I tried removing that (see below), but no, same message. That's when I went looking and came across the above TA. The only hope it offers is to restore from backup - too bad this is a new install, in the process of being configured: no backup yet. As to finding a system that "has the same set of software and patches installed", well, that was pretty unlikely too.
Well, nothing much to lose, right? I figured that the problem had to have come from the Stallion install, so, using the example "find" commands from the TA, I tracked it down and simply removed it: "rm -f". I then downloaded a fresh copy of Stallion, put it on a new floppy, and custom happily installed it. I then went on to put in the 3Com driver that I had been thwarted on.
My question is, why do people design software that craps out when it runs into ONE corrupt file in everything it is looking at? I certainly don't: just skip the stupid thing, report an error and move on. Every other "stanza" (I just love the high falutin terminology - especially when it's used in the context of inferior software!) was fine, so why not just work with what you have? Why make the user guess where the problem is? It's not like these things are related: they are separate items.
True, "custom" can't remove something it couldn't get a good read on, but so what? Is that worth crippling everything by refusing to run? Sure, it MIGHT be something very important, indespensable, life threatening and all that, but why not just hope for the best and proceed? You can explain the problem, give all the caveats, make 'em press "Y" thirty times if you must, but why bail out? It's just plain stupid.
Well, I have no idea if it's OK to do this as a general procedure. It worked here, and it's worth tucking away in the back of your mind if push comes to shove somewhere else.
"Fatal error: (vTcl interp) Server cannot open Display ega"
The "Custom" (and any Scoadmin manager written in Visual TCL) could also die because of the CHARM environment variable. That should be set to FALSE if running in the GUI and TRUE if in a character terminal (DISPLAY should be unset for the latter). You might see "Fatal error: (vTcl interp) Server cannot open Display ega" if CHARM or DISPLAY isn't right.
not in current context- custom backend binary died
Fatal Error: The custom+ binary (backend) process has died. Error Stack: Message id "INSTALL_ALREADY_NOT_APPLIED_PATCH" not in the current context
You might see that when trying to install a patch. This means that one of the dependencies of thepatch has not been installed - you may not have read the directions carefully!> Fatal Error: > The custom+ binary (backend) process has died. > Error Stack: > Message id "INSTALL_ALREADY_NOT_APPLIED_PATCH" not in the current context
Is it possible to have more than one instance of SCO Unix custom running ?
John Boland posted the following a while ago (please change the reference to SCO OS 5.0.2 (5.0.2Dp) with the one related to the 5.0.x version you're using) :
=== cut here === The lock file is: /var/opt/K/SCO/Unix/5.0.2Dp/custom/client.lock Move this file aside and you can run as many Software Managers (custom) as you like. === cut here ===
Contributed by Roberto Zini
More recent versions put the file in a different place, but just do a "find / -name client.lock".
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
More Articles by Tony Lawrence © 2013-08-09 Tony Lawrence