brent@itm.UUCP (Brent) (05/07/85)
X
Just a note to tell of progress:
I got a 1600 bpi fix tape from Michelle Hardy at PECARES,
supposedly fixing the following Xelos problems: misc. system
hangs/crashes (apparantly Xelos didn't run too well in multiuser
mode with < 2MB of main memory); tape drives gave sudden, unexpected
interrupts; the line printed didn't print 132 col/line; and the
problem of uucp not speaking to non-Xelos systems. Unfortunately,
Michelle didn't include a 1600 bpi tape drive in the package :-).
So as soon as she sends us an 800 bpi version of the same thing,
we'll be in business.
On other fronts: we've pretty well gotten everything recompiled
under Xelos, and will try officially cutting over this next Saturday
(5/11). The biggest problem we had was with curses. The terminfo
entry for the PE1251 is brain-damaged. We tried writing our own
with limited success (i.e. ours worked worse than theirs). The
work-around is to set TERM=pe550 and make sure the 1251 had auto
new-line turned off on its setup screen. We have a couple of WY-50
tubes here also (a great tube, we're getting more). The terminfo
for the wy100 seems to work just fine on them.
Speaking of terminfo: the way it works under Xelos is you write
a terminfo description of your tube (the terminfo entry looks similar
to /etc/termcap, but supposed to be easier to read), then compile
it into an "object?" module with a program called "tic". P-E
gives you the object entries for zillions of tubes, but not the
terminfo entry itself. Apparantly this is fairly standard across
the V.2 world. This is crazy!!! Is a terminfo entry considered
proprietary source code?? and without any examples, how is one
supposed to write his own, like when one supplied on the system
is brain-damaged? i.e. the 1251.
Anyway, the other bad news: swap space. We had three tubes
logged in: one running a "make", another with an idle shell, and
another running the shell layers: "shl". (sorta like the Berkeley
control-z job control stuff. It seems to work real well). Ours is a
2 Meg system, and we allocated the standard 4,700 block swap area
(4.7 Meg). All of a sudden, the console started printing out "nearly out
of swap space, need 2048 blocks" it did this several times, then the
system hung. I called our local P-E software guys about this and
their reply was "not surprised, you need at least 9,600 blocks of swap
space under Xelos". This is crazy. Under Edition VII, we hardly
ever swap, even with 10 users logged on. Xelos swap space is going to
cost dearly in disk space. Anyone have any theories about why
Xelos is such a swap hog? Is this a bug??
More later,
Brent Laminack (pesnta!itm!brent)carl@nrcaero.UUCP (Carl P. Swail) (05/08/85)
[]
Re: ammount of swap space Xelos needs
I understand that in Xelos a number of the utility programs, editors
and compilers have the sticky bit set (very few did on Edition VII as there
were problems with sticky programs on early releases). If the stickly
bit is set then when the program is first called a copy of the task image
is stored in swap space, that copy is then loaded when the program is
needed again rather than loading from the file system.
If disc space is a real problem, then you could "chmod" the programs to
remove the sticky bit. The trade-off is that the system will run a bit
slower.
--
Carl Swail (613) 998-3408
USENET:
{pesnta,lsuc,prcrs}!nrcaero!carl
{allegra,decvax,duke,floyd,ihnp4,linus}!utzoo!dciem!nrcaero!carl