Path: utzoo!attcan!uunet!aplcen!samsung!emory!hubcap!ncrcae!sauron!wescott
From: wescott@Columbia.NCR.COM (Mike Wescott)
Newsgroups: comp.sys.ncr
Subject: Re: Tower 32/500 tty performance
Keywords: tty, binary compatibility, Tower
Message-ID: <2249@sauron.Columbia.NCR.COM>
Date: 27 Jul 90 01:16:27 GMT
References: <164@bilpin.UUCP>
Sender: news@sauron.Columbia.NCR.COM
Reply-To: wescott@micky.Columbia.NCR.COM (Mike Wescott)
Organization: E&M-Columbia, NCR Corp, W Columbia, SC
Lines: 56

In article <164@bilpin.UUCP> nick@bilpin.UUCP (nick) writes:
> The Problem:
> 	Users complained of poor cursor movement and long type ahead delay
> 	when using the Uniplex spreadsheet and wp.

[ ... ]

> 	So we have a process doing loads of sys calls but not reads,writes
> 	forks or execs. 

> 	Now for the questions :

> 	* What system calls is this run-away process making ?

Probably a read on a tty in a non-blocking mode, either with O_NDELAY
set or with VMIN and VTIME both zero.

> 	* What specifically in the STREAMS code (in os.o) was repaired ?

Heaven knows ... streams/os.o is compiled from streamio.c.  If you received
a full fledged patch there should be a release definition file along with
it.  Check out /etc/RELDEF for documentation.  The (major) bugs fixed
are listed.  But you may not be able to pin down which goes with os.o.

> 	* Is there a compatible Cobol compiler for the 32/500, and
> 	  is it any better ?

I don't know.

> 	* Just how compatible is "binary compatible" ?

Good question, impossible to answer precisely.  What it means in practice
is that we take pains not to break object compatibility where it can
be avoided. This even includes objects that are not fully linked making
it hard even to modify some of the /usr/include files.  We can't always
be successful because programmers can be too clever sometimes.  I generally
see the issue from the standpoint of what we can't change:

	+ some *.h files
	+ size, alignemnt and ordering of structures
	+ major semantics of system calls
	+ system call numbers
	+ many minor ones
	+ some errno returns
	+ filesystem layout (in some cases)

Obviously a program that depends on a bug will in turn break
when the bug is fixed.  This has happened and leads to heated
disagreement on what the proper behavior of the system should be.

We aren't always successful in maintaining backward compatibility nor
do we always get to introduce changes as soon as we would like.

--
	-Mike Wescott
	 mike.wescott@ncrcae.Columbia.NCR.COM