[comp.os.vms] Remote terminal through DECnet from application

pim@bsovax.UUCP (Pim Willemsen) (05/06/88)

Hi there,

I' looking for a way to create a remote terminal, which
emulates a hardwired terminal on a DECnet node.
So on one node I'd like to have a device called _RTAx:
which connects, through DECnet, to a terminal TTAx: on another
DECnet node.  Then I want to use the SMG$xxxx library calls
to do single character i/o on it.

In the VMS manuals, the only way that it's described is through
the DCL command SET HOST.
After using this command, a new device with the name _RTAx:
is created on the host to which I'm switching; and a DECnet
link is set up to an object called CTERM in the REMACP image.
I can't find any description of this in the VMS manuals.

I wonder, does anyone know of a way to do this kind of thing 
from within an application?

We're running VMS 4.5 on a 750, but it should also work
on a uVAX (3500).

I'd appreciate any help, by mail or through the net.

-- 
------------------------------------------------------------------------------
   Pim Willemsen           |    =========   BSO/Automation Technology
   mcvax!bsovax!pim        |    == BSO ==   POB 8052
                           |    =========   3503 RB  Utrecht, The Netherlands

rrk@byuvax.bitnet (05/09/88)

I've been posting requests for some time for this information, with no response
whatsoever.  I know of no place it is documented.  Here is the only way
I have been able to find out about it:

The following procedure makes /NOTRACEBACK images into debugable images.
If you save this procedure to DEBUG.COM and enter the command:

$ @DEBUG SYS$SYSTEM:RTPAD

it will place a debugable copy of RTPAD.EXE (the image run by $ SET HOST)
in your directory.  Then make the logical definition:

$ DEFINE RTPAD SYS$DISK:[]RTPAD

and then issue your set host command.  This will run the RTPAD in your current
directory instead of the one in SYS$SYSTEM.  You should get a debugger prompt.
You can step through and into the routines as much as you want to see about
what happens when you do a $ SET HOST.  You don't have any debugger symbols,
but you can figure out what calls are being made if you are a little familiar
with assembler code and know a few things.  You will encounter various types
of calls:

CALLS #N,@#7FFnnnnn

Is a call to a system service.  To find out what system service is being
called,

$!---------------------------cut here-----debug.com---------
$ patch/abs 'p1'
e/word 2
e \+4
dep .+4 = \
e .-8
dep .+4 = \
dep .-4 = 7ffedf68
e 20
dep . = \ or 1
update
$!----------------------cut here---end of debug.com----------------------

rrk@byuvax.bitnet (05/09/88)

Sorry, I accidentally saved in the middle of my reply.  If you want more
information (which I was in the middle of writing) on figuring out what
RTPAD.EXE does during a set host, let me know and I will post lots of hints
I use for disassembling images.  There was a program I got a copy of from
somewhere called DISM32 or some such thing which tries to be a disassembler.
The author has lots of the right ideas, but unfortunately the thing crashes
whenever I give it anything serious (such as RTPAD.EXE).  I wish I had his
source.  I'm sure I could improve it a lot.  It obviously has lots of work
in it that I wouldn't care to duplicate.  If anyone has more information
on the CTERM object protocol, or on the source code to this or any other
disassembler (or debugger, which can be rapidly converted to a disassembler)
please post the information.  Or if anyone would like the rest of the
information that belongs in the previous article, or has their own set of
helps, I think it is a very interesting topic and would like to hear from
you.

I haven't had the time to unravel RTPAD enough to get enough protocol to
use.  I plan to do this when time permits.  I probably also should look
at the FISCHE to see what comments are there, if any, but my reader is hard
on the eyes.

                                AMMON::RAY

LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (05/16/88)

	I'm looking for a way to create a remote terminal, which emulates a
	hardwired terminal on a DECnet node.  So on one node I'd like to have
	a device called _RTAx:  which connects, through DECnet, to a terminal
	TTAx: on another DECnet node.  Then I want to use the SMG$xxxx library
	calls to do single character i/o on it.

	In the VMS manuals, the only way that it's described is through the
	DCL command SET HOST.  After using this command, a new device with the
	name _RTAx:  is created on the host to which I'm switching; and a
	DECnet link is set up to an object called CTERM in the REMACP image.
	I can't find any description of this in the VMS manuals.

	I wonder, does anyone know of a way to do this kind of thing  from
	within an application?

It's not entirely clear from your description what you are trying to accomp-
lish, but going by the final question, it looks as if you want, in effect,
a "callable SET HOST" facility.

No such thing exists; you'd have to write it yourself.  I'm not sure whether
the CTERM protocol is among the published DECnet protocols; it has certainly
been implemented as part of various 3rd-party DECnet implementations for
non-DEC machines.  It's NOT a simple protocol.

The simplest approach may be to spawn a subprocess on a pseudoterminal, using
one of the various PTY drivers that have floated around the net and DECUS (and
that have finally become fairly solid and usable tools), then send through a
SET HOST command.  Ugly, but a lot less work than any alternative I can think
of.

Then again, as I said, it's not clear what you are trying to accomplish.
Perhaps you really should look at your whole application again to see if there
isn't a better approach.
							-- Jerry

pim@bsovax.UUCP (05/18/88)

	
>It's not entirely clear from your description what you are trying to accomp-
>lish, but going by the final question, it looks as if you want, in effect,
>a "callable SET HOST" facility.
>	
>No such thing exists; you'd have to write it yourself.  I'm not sure whether
>the CTERM protocol is among the published DECnet protocols; it has certainly
>been implemented as part of various 3rd-party DECnet implementations for
>non-DEC machines.  It's NOT a simple protocol.
>	
>The simplest approach may be to spawn a subprocess on a pseudoterminal, using
>one of the various PTY drivers that have floated around the net and DECUS (and
>that have finally become fairly solid and usable tools), then send through a
>SET HOST command.  Ugly, but a lot less work than any alternative I can think
>of.
>	
>Then again, as I said, it's not clear what you are trying to accomplish.
>Perhaps you really should look at your whole application again to see if there
>isn't a better approach.
	
Thanks for your reply.

I was hoping that I would only need to CREATE the remote terminal (RTAx:),
and then use normal $QIO system calls (SMG$ library calls) on it.  

The I/O manual on the terminal driver says on the first page that:

	"The Remote Command Terminal, used by the DCL command SET HOST,
	also makes use of the features and capabilities listed in Section 8.2" 

I interpreted this as meaning that the terminal driver implements
the CTERM protocol if the assigned channel is a remote terminal.

As there seems to be no easy way to use a remote terminal, 
I'll just have a process running on the remote node which reads entire
command lines and sends them to my application on the local node. 

Thanks anyway,
				Pim Willemsen

------------------------------------------------------------------------------
   Pim Willemsen           |    =========   BSO/Automation Technology
   mcvax!bsovax!pim        |    == BSO ==   POB 8052
                           |    =========   3503 RB  Utrecht, The Netherlands