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
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
The custom+ binary (backend) process has died.
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
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:
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".