Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Re: OBSERVE.MAR Part 1 of 1
Message-ID: <8612181618.AA05718@ucbvax.Berkeley.EDU>
Date: Thu, 18-Dec-86 11:19:02 EST
Article-I.D.: ucbvax.8612181618.AA05718
Posted: Thu Dec 18 11:19:02 1986
Date-Received: Thu, 18-Dec-86 22:18:40 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: 
Organization: The ARPA Internet
Lines: 61
Approved: info-vax@sri-kl.arpa


		WARNING!!!  This program can crash your system!

OBSERVE is a clever little piece of code that interposes itself between the
port and class drivers of a target terminal and copies all outgoing characters
directly to the terminal it was run on.  For OBSERVE to work, it must under-
stand the kind of port driver being used, and further the same port driver
must be used on both the target and observing terminals.  In practice, the
program understands the DZ11 and DMF32 port drivers.  Unfortunately, it makes
a rather simple test to determine which of the two it is dealing with:  It
looks at the second byte of the terminal's device name.  If that byte is "X",
the DMF32 code is used; otherwise, the DZ11 code is used.  For example, if you
try it out using a VAXStation emulated window - device name WTAn: - you'll get
a quick crash.  (At least I did.)  I'm willing to bet that the same thing will
happen with LAT terminals (LTAn) or a DECnet remote terminal (RTAn).  I don't
know what will happen with other terminal hardware, such as the DZ32, though I
think the port drivers for the DZ32 and DZ11 are the same, so that particular
one should work.  It's also not obvious that the code will work if virtual
terminals are enabled.  Since it WON'T run on my VAXStation - which has no
"real" terminals - I can't test any of this out; I'm not willing to crash our
8600 just for the heck of it.  So, I can only guess based on a quick reading
of sparsely-commented code.

Other things to know about OBSERVE:

	- I suspect that typing CTRL/S while observing a terminal that's
		producing a lot of output can cause a crash as various buffers
		overflow.
	- It is hard-wired to assume VT100-compatible terminals, only, though
		nothing really terrible will happen on others.
	- It has hard-coded in a variety of assumptions about the inards
		of the terminal driver.  Hence, it stands a good chance of
		dying as new versions of VMS come out.  Further, given its
		nature, any time OBSERVE dies, it is almost certain to take
		the system with it.
	- Some of the coding isn't quite as defensive as it might be; there
		are some timing windows during initialization that could leave
		the system in a strange state.  Don't type CTRL/Y while the
		program is starting up!
	- The program never bothers to lock down the kernel-mode, elevated-IPL
		code it runs during initialization; a page fault in this code
		will cause a crash.  This is quite unlikely, but possible.
	- If you start it via a foreign command, it will take a single argu-
		ment, the name of the target terminal.  Otherwise, it will
		prompt you.
	- Don't bother thinking about using OBSERVE to RECORD what a terminal
		is doing, rather than just displaying it - that would involve
		a whole new approach.

Take all this as a warning to be careful.  Given its simplicity, it's probably
the case that if OBSERVE works on a particular configuration at all, it will
continue to work - i.e., if you can run it for a couple of minutes without
crashing the system you should be safe.  But don't make your test run during
production!

BTW, OBSERVE needs CMKRNL - which it will NOT enable - and must be linked
against the system symbol table.  (I'm being brief deliberately:  If you
don't know what this means, you have no business playing with this program.)

							-- Jerry
-------