[comp.os.vms] Problems setting term when setting host to VAX from PDP 11/44 via

SUE@RITA.ACS.WASHINGTON.EDU (07/05/88)

  Hello.  Pardon me if I may sound a bit naive in posing this question but
I am not a systems person.  Our department had recently bought a VAX 8250
which we linked to 2 pdp11/44's via DECNET. We had noticed this problem:
when we use SET HOST to the VAX from the PDP's, we are unable to spawn
subprocess or set many terminal characteristics we could odinarily do when
we connect directly to a VAX port. The terminal comes up set as "hardcopy".

    When we try to spawn a subprocess, as from within mail, for example,
we get something like:

  - mail-e-editproc. error creating or executing edit subprocess
  - rms-f-dev, error in devname or inappropriate device type


    When we try to do set term/xxx, about the only thing it will let us set
is /dev=, the other qualifiers gives us:

  -set-w-notset, error modifiying RTA1:
  -system-f-badparam, bad parameter value

   The in-house programmer responsible for setting this up is not really
familiar with the vax and is learning as he goes from the supplied manuals.
He has some vague notions of what may be wrong, but no real idea if it is
possible to fix.

   Could anybody shed some light into this problem and how or if it is possbile
to fix up?? Could it be simply an incorrect setup problem?

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

	Our department had recently bought a VAX 8250 which we linked to 2
	pdp11/44's via DECNET. We had noticed this problem:  when we use SET
	HOST to the VAX from the PDP's, we are unable to spawn subprocess or
	set many terminal characteristics we could odinarily do when we
	connect directly to a VAX port. The terminal comes up set as
	"hardcopy".

	When we try to spawn a subprocess, as from within mail, for example,
	we get something like:

	  - mail-e-editproc. error creating or executing edit subprocess
	  - rms-f-dev, error in devname or inappropriate device type

	When we try to do set term/xxx, about the only thing it will let us
	set is /dev=, the other qualifiers gives us:

	  -set-w-notset, error modifiying RTA1:
	  -system-f-badparam, bad parameter value

	The in-house programmer responsible for setting this up is not really
	familiar with the vax and is learning as he goes from the supplied
	manuals.  He has some vague notions of what may be wrong, but no real
	idea if it is possible to fix.

	Could anybody shed some light into this problem and how or if it is
	possbile to fix up?? Could it be simply an incorrect setup problem?

PDP-11's run a large variety of operating systems.  Among those supporting
DECnet, there are AT LEAST:  RT-11, RSX-11M, RSX-11M+ and RSTS.  There are
also multiple versions of each of these OS's.

You may wonder why the OS running on the remote system should have anything
to do with setting up terminals on the VAX.  Well, it does:  The DECnet
SET HOST protocols - the current one is CTERM, but there have been several
others in the past, and if you are running an older version of one of the
-11 OS's, you may be using one of them - produce what is in effect a split
driver:  When a program on the VAX tries to set up terminal charactertics,
nothing much really happens locally.  Instead, the requested setup is
packaged up into a form defined by the protocol and sent over to the remote
system.  The remote system then (tries to) act on the request (by applying
as much of it as makes sense to the physical terminal line you are really
talking to) and sends back a response indicating what actions it could or
could not take.  As a result, the only terminal attributes you can set are
those common to both the VAX and the -11:  If the attribute isn't known on
the VAX, there is no way to specify the request; if it isn't known on the -11,
there is no way to act on it.  (Except that the remote session starts out
with the terminal set up pretty much as it was before the SET HOST was done;
so it's possible to set termnal attributes locally before SET HOST'ing that
mean nothing to the remote system.)

This phenomenon is not limited to SET TERM.  Line editing, for example, is
done by the system running SET HOST - NOT the system SET HOST to:  The remote
system just packages up an input request.  If your local system doesn't
support line editing, you can't use it on the remote system.  On the other
hand, if your local system DOES support it and it is enabled before you
SET HOST, you can (usually) use it even though the remote system doesn't
understand it.

I didn't really answer your question here, because you didn't provide enough
information.  However, I hope I've provide YOU with the information you need
to figure out what your system is up to.
							-- Jerry