Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!nrl-cmf!ukma!gatech!udel!princeton!rutgers!im4u!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!kvc
From: kvc@nrcvax.UUCP (Kevin Carosso)
Newsgroups: comp.os.vms
Subject: Re: re: Session Logs / Photo
Message-ID: <1355@nrcvax.UUCP>
Date: 15 Jan 88 21:05:58 GMT
References: <51rrk@byuvax.bitnet>
Reply-To: kvc@minnie.UUCP (Kevin Carosso)
Organization: Network Research Corp.  Oxnard, CA
Lines: 53

In article <51rrk@byuvax.bitnet> rrk@byuvax.bitnet writes:
>I have used the Photo program quite a bit.  Even the most recent copies
>(I think they are most recent, the one with two separate drivers and device
>types rather than odd and even pty's) can crash the system.  And device

If you have the CMU pseudo-terminal driver that I was distributing and
the last edit to the sources for the drivers was in December 1986 or later
and you think it crashes your system and you are not using the TPDRIVER
in PSI V4.1, then I'd like to know about it.  No one has reported any
system crashers to me since I fixed the problem in December 1986.

>drivers are supposed to change in a major way in 5.0.

Device drivers don't change all that much in V5.  Not much more than they
do at any major release (remember V4)?  In fact, I'm quite pleasantly
surprised at how easily (for the most part) they appear to have made
the addition of SMP on the rest of us.  I think it's quite an achievement.
At least, from information they've let out so far.

>                                                    Why not go with the
>DEC device just made for the task:  the RTAx device you see when you do
>a "$ SET HOST".  This device seems to be able to do just about anything
>that a PHOTO session might require, (except for virtual terminals, but your
>primary session should have one of those) and on any DECNET node connected
>to your system.  It is created via an RMS open on node::"objnum=" (I think
>the number was somewhere between 23 and 27) and the protocol can be derived
>by disassembling/debugging RTPAD.EXE on any VMS system, and it will probably
>survive 5.0, etc.  I just can't tolerate device drivers which crash, but would
>love a Photo program I could use.

The big problem is that the RT devices are indeed "just made for the task"
 -- the task of supporting a remote DECnet terminal session.  They just do not
appear to be general enough to be used for such purposes.  If you would like to
sit down and spend some time "disassembling/debugging RTPAD.EXE" to derive
the protocol and then let the rest of us know what it is, I'm sure we'd
appreciate it.  But seriously, the remote terminal driver functions basically
by packaging up the QIO request and sending the package over a DECnet link
to an application on the other side (RTPAD) which interprets the I/O request
package and issues an equivalent QIO to the real terminal on its end.

While I suspect that it might be possible to write a PHOTO that works
using this mechanism, it certainly seems to me to be a big waste of time
and effort.  Also, there is certain to be less of a guarantee that a major
version upgrade won't affect this (completely undocumented) protocol than
that that same upgrade won't destroy beyond reasonable hope of redemption
a user-written driver (which are meant to be supported, generally with minor,
documented modifications).


        /Kevin Carosso                     kvc@nrcvax.uucp
         Network Research Co.              kvc%nrcvax@trwind.trw.com
                                           kvc@engvax.scg.hac.com
                                           kvc@ymir.bitnet