Xref: utzoo comp.unix.xenix:2986 comp.unix.microport:1289 Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!ig!uwmcsd1!mailrus!iuvax!inuxc!att!ihnp4!ihlpl!jhh From: jhh@ihlpl.ATT.COM (Haller) Newsgroups: comp.unix.xenix,comp.unix.microport Subject: Re: Bell Tech 386 SysVr3 (really a put-down of Xenix) Summary: SVR2 IPC problems Message-ID: <6202@ihlpl.ATT.COM> Date: 11 Aug 88 14:27:26 GMT References: <25145@ucbvax.BERKELEY.EDU> <465@sp7040.UUCP> <11643@steinmetz.ge.com> <6643@conexch.UUCP> Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 13 In article <6643@conexch.UUCP>, enped@conexch.UUCP (Eric Pederson) writes: > We haven't had as much luck with SCO Xenix. I think our troubles may be due to > poor SVID IPC support in the 2.1 Xenix for the 386. There was a bug in the SVR2 IPC. I don't remember the details, but if more than 64K message queues were created and deleted, a counter overflowed, indirectly causing a reference to an invalid memory location. I saw this in a 3B-20S. After a call to AT&T Software Support (not the hotline, but the people in Lisle, IL who support people with a software support contract), they provided a fix the next day. If SCO's IPC is SVR2 based, it may have the same bug. Since the bug was found in SVR2, it was most likely fixed before SVR3 was released. John Haller