Two thoughts: uvaxII+shared libraries

[BostonU SysMgr]

1. uvaxII

	It seems one of the great hopes out there is that the
	QDA-50 (or is it KDA-50?) controller will become available
	and the uvax will then support RA* series disks with their
	size and performance advantages.

	What immediately occurs to me is:

	a) We're talking minimum disk buy-in of about $27K for
	your first disk (RUA81-CA), that's a more than the system,
	maybe that's reasonable but worth a thought.

	b) More important: I think all the discussions about
	RA disks on this list point towards putting them into
	A/C machine room environments, plus they do need,
	I believe, L5-30Rs which you may not have in your office.

	I would not be surprised to hear that DEC has new RA
	disk products planned to solve some of these problems
	but until that's confirmed this picture is pretty accurate.

	(Note: I am sure there is someone out there running an
	RA81 in their steambath and has had no troubles, save
	your typing, a lot of people apparently have had troubles
	outside a machine room environment and DEC (esp. FS)
	does not love putting them into anything but machine rooms.)

2. Shared libraries

	On our 3081 we run a locally built operating system, VPS/VM,
	which normally only does full loading of libraries at RUN time.
	You *can* create fully resolved modules (like a.outs) but
	typically users create a bunch of object decks and a file
	that looks like:

	/include loader
	/include obj1
	/include obj2

		etc..

	and a very fast loader searches and resolves standard libraries
	(more libraries can be added obviously with more lines) and
	starts the program. One could imagine the same becoming a norm
	on UNIX with either a Makefile or a #!/bin/ld variant that took
	its args on the standard input, locking ld into memory would
	probably be necessary and possibly looking around to see if
	some cycles could be saved (and maybe just reserve this to fast
	systems.) This may not quite be shared libraries but I think
	it covers most of what the suggestors were after. ld would have
	to also be ld+go [P.S. I am not claiming VPS to be the only
	system with this, I think other IBM o/s's had this].
	Better would be an ld that could do it directly into memory
	and just jump to it, I believe TOPS-20 has good tools for
	this kind of approach where you can allocate a fork that
	doesn't start and then the parent can set up it's memory image
	and then start it.

	Oh well, again, just a thought. Sorta seems simpler than
	some of the other suggestions (if you don't want to load
	it till run time why don't you just not load it till run
	time...:-) I know, speed freaks will be aghast, but it's
	really not bad in our experience. And, in the UNIX tradition,
	seems very easy and non-invasive to implement experiments.

		-Barry Shein, Boston University