rrk@byuvax.bitnet (01/07/88)
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
drivers are supposed to change in a major way in 5.0. 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.
Ray Whitmer
AMMON::RAYhydrovax@nmtsun.nmt.edu (M. Warner Losh) (01/15/88)
In article <51rrk@byuvax.bitnet>, rrk@byuvax.bitnet writes: > [photo is great but crashes system, use set host instead] Well, I just tried the following command on my system (that DOESN'T have DECnet: $ SET HOST 0/log=foo and it said : %RMS-F-DEV, error in device name or inappropriate device type for operation What is it that I'm doing wrong? I don't start DECnet in the start-up, since we don't have a license for it. (btw, it keep the mail from anybody problem out, since the same error occurs when we tried to run the .COM file that was posted a few months ago). Is there some way that I we can use this w/o having DECnet-VMS installed? -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.
kvc@nrcvax.UUCP (Kevin Carosso) (01/16/88)
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