| 1) You will need an account on the other system.
2) From the customize menu in the session manager, use the security
option and enter the name of the node and username on the other system,
much in the way a proxy account is setup. For Example, if you have an
account, JONES, on the other node in the network, OTHER::, then allow
the user OTHER::JONES access from the security function. (Note: If the
other system is a cluster, using a cluster alias name, you will need an
entry for each node in that cluster)
3) Set host to the other node and login into your account.
4) Use the command: $SET DISPLAY/CREATE/NODE=your_wrkstatn
4) Run DECWrite.
5) Observe it displaying and taking input from your Workstation and
running on the remote system.
This is documented in chapter 8 of the VMS Decwindows User's Guide.
|
| > 4) Run DECWrite.
Thanks very much for helping this DECwrite user out, but we do ask that
the exact name be used - specifically, DECwrite (no capital 'w'). I
know this is an annoying nit, but product names are of only one form.
John
|
| I have a slightly different scenario to play out. Instead of logging into the
client VAX, I submit a remote batch job to the client VAX from my workstation.
In the remote .COM file, I presently hardcode the server node name. My
experience with DCL is pretty limited. How would I be able to obtain the node
name of the server from the batch procedure? It's probably as simple as using
one of the lexical functions. Doing it this way allows me to set up a user's
environment in such a way that they are not aware where the application runs,
just that it's available from a Fileview menu.
Thanks,
Margi LaGrotta
|