OT: SCO 6.0 - MAJOR BUG!!!!!

[Fairlight]

Y'all catch dis heeyah?  J. P. Radley been jivin' 'bout like:
> 
> A further response:
> 
>         FYI, this change goes back to System V Release 4, released
>         in 1989.  It is a consequence of the adoption of SunOS VM
>         architecture in SVR4 to replace the regions VM of earlier System
>         V releases.

Sounds like a straw man to me:

[FLAdmin] [~/storage/bin] [11:25am]: cp centericq-4.20.0 testcicq
   ... Running centericq-4.20.0 on another pty on this system ...
[FLAdmin] [~/storage/bin] [11:26am]: cp testcicq  centericq-4.20.0
[FLAdmin] [~/storage/bin] [11:26am]: file centericq-4.20.0
centericq-4.20.0:       ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, stripped
[FLAdmin] [~/storage/bin] [11:27am]: ls -l centericq-4.20.0
-rwxr-xr-x   1 fladmin  iglou    7902704 Oct 24 11:26 centericq-4.20.0*
[FLAdmin] [~/storage/bin] [11:27am]: uname -X
System = SunOS
Node = shell1
Release = 5.8
KernelID = Generic_117350-25
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 2

No core dumps, no crashes, no segv's, nothing.  Just keeps on chugging.
(The cicq program is a multi-protocol IM client.)  I was talking to
someone, I kept talking to someone, and could use any part of the program.
This machine is actually pretty light on memory as well, from what the
admin told me.  I think it has less than half a gig, and it's a bit of a
workhorse.  I'd very likely expect pages to be swapped out, especially in
something that large.

Solaris 8 is -far- more SVR4 than the SVR3-ish OSR series, and has been
for years.  Actually, SCO said they were not taking OSR to SVR4, but were
taking R3 their own way.  Another back-track?  Or just a weak and invalid
excuse now?

Either way, Sun managed to make it work without issue.  Maybe SCO should
subcontract some of Sun's software engineers if the former can't figure out
a proper implementation themselves.  Which actually makes little to no
sense, as it was fine in 5.0.6 and just crept in now.  Your source is quite
ambiguous as to whether the VM code was adopted that far back, or whether
Sun released the VM that far back and SCO just managed to take one little
corner of SVR4 to implement very recently.  The date reference context is
ambiguous and can be taken either way.

I still say it's a straw man, even if it's actually Sun's code.  Funny, it
works fine in Solaris.  If SCO couldn't be bothered to either get current
code (assuming Sun had a bug to begin with way back then and it was just
put in wholesale now for SCO 6) or vet the code themselves in alpha, beta,
and gamma, then the onus is completely on SCO.

Sounds like a handful of excuses.  Very reminiscent of when SCO licensed
the termcap code for Portfolio from JSB, the product had issues, and SCO
said talk to JSB, it's their code.  JSB said talk to SCO, they licensed it.
Nobody had a solution.  It's always someone else's problem with SCO, in my
experience.  Difference being that they could afford to just discontinue
Portfolio to make the problems go away.  I doubt they can afford to do that
with OSR6.

mark->
-- 
There is no "I" in TEAM.
This would be the primary reason I've chosen not to join one.