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