Conference bulova::decw_jan-89_to_nov-90

DECW$CLIENT is a tool that helps you start DECwindows applications running on
a VAX/VMS system (aka compute server), with the output displayed on your
workstation, running VAX/VMS or ULTRIX.

COMPUTE SERVER SETUP
--------------------

Most of the installation work takes place on the VAX/VMS system. The following
commands will prepare the compute server by putting the command procedure in
the correct location, and setting up the DECnet object database.

Note that proxy access to the compute server is required to use DECW$CLIENT. 
uSE WITHOUT PROXIES, OR PROXIES OTHER THAN TO USER INDIVIDUAL ACCOUNTS, IS
STRONGLY DISCOURAGED.

The first thing you need to do is install the internal utility CHILD on the
compute server. This can be obtained from the Software Tools Clearinghouse, or
from PRNSYS""::RELEASED_TOOLS:[CHILD]*.* (ref BULOVA::DECWINDOWS note 111.1).
Follow the installation instructions to install CHILD on your VAX/VMS system
(not the workstation) before proceeding.

Then, on the compute issue the following commands:

$ SET DEFAULT SYS$COMMON:[SYSEXE]
$ COPY /LOG DECWET::SYS$PUBLIC:DECW$CLIENT.COM *
$ COPY /LOG DECWET::SYS$PUBLIC:DECW$CLIENT-SET-DISPLAY.COM *
$ COPY /LOG DECWET::SYS$PUBLIC:DECW$CLIENT-TERMINAL-WINDOW.STARTUP *
$ SET FILE /OWNER=SYSTEM /PROT=(S=RWED,O=RWED,G=E,W=E) DECW$CLIENT*.*
$ NCP = "$NCP"
$ NCP SET OBJECT DECW$CLIENT NUMBER 222 FILE SYS$SYSTEM:DECW$CLIENT.COM PROXY BOTH
$ NCP DEF OBJECT DECW$CLIENT NUMBER 222 FILE SYS$SYSTEM:DECW$CLIENT.COM PROXY BOTH

  NOTE: If you need to change the DECW$CLIENT object number, you'll have
        to edit decw-client.c (ULTRIX workstations only) and DWAPP.COM
	(VAX/VMS workstations)

  NOTE: If the compute server is a VAXcluster, you'll need to issue a
	$ NCP SET OBJECT DECW$CLIENT ALL
	on all the other nodes of the VAXcluster now.


Two simple workstation interfaces are provided to demonstrate access to
DECW$CLIENT, one for VAX/VMS and one for ULTRIX.  These simple interfaces are
provided to demonstrate the access technique.  No claims are made as to their
overall usability or innovation.

VAX/VMS WORKSTATION SETUP
-------------------------

$ NCP SET OBJECT DECW$CLIENT NUMBER 222 PROXY OUT
$ NCP DEF OBJECT DECW$CLIENT NUMBER 222 PROXY OUT

The procedure DWAPP.COM can be executed on a VAX/VMS workstation running
DECwindows to start up applications on the compute server. For instance, on a
VAX/VMS workstation you could use the procedure DECWET::SYS$PUBLIC:DWAPP.COM.
You'll need to edit it and change the string XYZ to your initials.

If the procedure is invoked as:

$ @DWAPP DECWET
Application: bookreader
Application:
$

This procedure starts up the specified applications (in this case, just the
bookreader) on DECWET.  The display will be on the VAX/VMS workstation.


ULTRIX WORKSTATION SETUP
------------------------
The program decw-client.c can be compiled on an ULTRIX system running
DECwindows and executed to start up applications on the application
execution system.  On the ULTRIX workstation:

#
# To create decw-client
#
% dcp decwet::'sys$public:decw-client.c' decw-client.c
% cc decw-client.c -o decw-client -ldnet

    OR

% dcp -i decwet::'sys$public:decw-client' decw-client
   
    THEN

% su
# recommend that you move it to /usr/local
% chmod u+s+r+x,g+r+x,o+r+x decw-client
% chown root decw-client

#
# To use decw-client
#
% decw-client remote-system-name
wsname,prefix
application1
application2
^D

Also see the short scripts on DECWET::SYS$PUBLIC:

xvms	Creates a logged-in terminal window
yvms	Creates a terminal window at the Username: prompt

Miscellaneous notes:  If you modify the scripts xvms or yvms to start
other applications, and the application name contains a "$" (decw$mail,
for instance), you must quote the "$" with a backslash (decw\$mail, for
instance).


TERMINAL WINDOWS
----------------

The defaults for terminal windows are:

- Use the defaults for your account (whatever you have saved, or the
  system defaults)

- Process name is xyz_nodename (BLS_UMBRLA, for instance).  Subsequent
  terminals are created with a digit appended.

- The window and icon name is the node name.  If the process name has
  a digit appended, so will the window and icon name.

To run an application using DECW$CLIENT, you specify the application
name.  The application name for terminal windows is

terminal-window

You can specify some options on the terminal window line by following
the application name with a "/".  There are 5 options, and they are
position-dependent.

The options are:

P1 - No auto login flag.  0=autologin, 1=prompt for username.  Default
     is to autologin to the user's account.
P2 - DECterm setup file name. If not specified, the default is used.
P3 - Process name.  If not specified, the string xyz_nodename is
     used.
P4 - String for the window title and icon name.  If not specified, the
     current nodename is used (it may be modified by ";n" if there
     are multiple terminal windows for the same user on the node)
P5 - Wait for child flag.  Default is 0.  You probably don't care. 
     See text of DECW$CLIENT-TERMINAL-WINDOW.STARTUP for details if
     you think you do.

Examples:

These lines of text are entered as lines of input to the DWAPP.COM command
procedure on VAX/VMS workstations, or to decw-client on ULTRIX workstations.

Create a logged-in terminal window

	terminal-window

Create a terminal window at the username prompt

	terminal-window/1

Create a logged-in terminal window with a special DECterm defaults file

	terminal-window//real-big-window.decterm/

ADDITIONAL NOTES
----------------

The first time you use DECW$CLIENT from either a VAX/VMS or ULTRIX
workstation, it will create a directory in your account on the compute server,
SYS$LOGIN:[.DECW$APPS] (Note: you can't use that string to access the
directory, it's for explanatory purposes only), and set the directory version
limit to 10.  This directory is used for storing the startup and output files. 
If you are having problems with an application, check the application output
file in this directory (application.output).

To start DECwindows NOTES, create the file NOTES.STARTUP in your
[.DECW$APPS] directory with the following contents:

	$ set display/create/node=yourws
	$ notes /display=decwindows

DECW$CLIENT looks for the application name as specified. If that is not
found, it will prepend the application name with DECW$ and try again. 
This means that you either must specify DECW$MAIL as the application
name, or create a MAIL.STARTUP with the following contents:

	$ set display/create/node=univax/transport=decnet
	$ run sys$system:decw$mail
    

    Thank you. It was mighty kind of you to make this available.
    It works like a charm.
    
    Note, however, that the proxy must be set up on the compute
    server side with the /DEFAULT qualifier; i.e.
    
    	UAF> ADD/PROXY remote-node::remote-user local-user/DEFAULT
    
    Had to spend some time until I realized that.
    
    Now, tho only question is:
    
    	What shall we do when the first customers start asking for
    	these nifty utilities; e.g. CHILD & DECW$CLIENT*.*?
    
    
    Thanks again,
    ...Petri

Why did you feel it was necessary to choose an object number other than 0?

James

re .-1

	Correct compliance with DNA!	:-)

	The "names" of type 0 objects have system-specific semantics.
	DNA doesn't guarantee that a name required by operating system
	X can necessarily be expressed by operating system Y.

NOTE:  A problem was identified (thank you Dave Porter) with the use of
the SET DISPLAY command, due to it's CREATE rather than CREATE-IF semantics.
This results in hundreds of orphaned WSAn devices, eating system memory
and slowing down application startup (I sure hope this gets fixed in the
next version!!!).

In any event, there is a new version of DECW$CLIENT.COM,
and DECW$CLIENT-TERMINAL-WINDOW.STARTUP as of 3:00pm EST today.  If you
have copied these files before that time, I strongly suggest that you copy
and install the new versions.  Also note that you no longer need to do
anything special for NOTES or MAIL startup, DECW$CLIENT handles these
correctly now.  DECW$CLIENT also outputs more information to the
NETSERVER.LOG, which will be useful in diagnosing startup problems.

(updated copy of .1 follows)

DECW$CLIENT is a tool that helps you start DECwindows applications running on
a VAX/VMS system (aka compute server), with the output displayed on your
workstation, running VAX/VMS or ULTRIX.

COMPUTE SERVER SETUP
--------------------

Most of the installation work takes place on the VAX/VMS system. The following
commands will prepare the compute server by putting the command procedure in
the correct location, and setting up the DECnet object database.

Note that proxy access to the compute server is required to use DECW$CLIENT. 
USE WITHOUT PROXIES, OR PROXIES OTHER THAN TO USER INDIVIDUAL ACCOUNTS, IS
STRONGLY DISCOURAGED.

The first thing you need to do is install the internal utility CHILD on the
compute server. This can be obtained from the Software Tools Clearinghouse, or
from PRNSYS""::RELEASED_TOOLS:[CHILD]*.* (ref BULOVA::DECWINDOWS note 111.1).
Follow the installation instructions to install CHILD on your VAX/VMS system
(not the workstation) before proceeding.

Then, on the compute issue the following commands:

$ SET DEFAULT SYS$COMMON:[SYSEXE]
$ COPY /LOG DECWET::SYS$PUBLIC:DECW$CLIENT.COM *
$ COPY /LOG DECWET::SYS$PUBLIC:DECW$CLIENT-SET-DISPLAY.COM *
$ COPY /LOG DECWET::SYS$PUBLIC:DECW$CLIENT-TERMINAL-WINDOW.STARTUP *
$ SET FILE /OWNER=SYSTEM /PROT=(S=RWED,O=RWED,G=E,W=E) DECW$CLIENT*.*
$ NCP = "$NCP"
$ NCP SET OBJECT DECW$CLIENT NUMBER 222 FILE SYS$SYSTEM:DECW$CLIENT.COM PROXY BOTH
$ NCP DEF OBJECT DECW$CLIENT NUMBER 222 FILE SYS$SYSTEM:DECW$CLIENT.COM PROXY BOTH

  NOTE: If you need to change the DECW$CLIENT object number, you'll have
        to edit decw-client.c (ULTRIX workstations only) and DWAPP.COM
	(VAX/VMS workstations)

  NOTE: If the compute server is a VAXcluster, you'll need to issue a
	$ NCP SET OBJECT DECW$CLIENT ALL
	on all the other nodes of the VAXcluster now.


Two simple workstation interfaces are provided to demonstrate access to
DECW$CLIENT, one for VAX/VMS and one for ULTRIX.  These simple interfaces are
provided to demonstrate the access technique.  No claims are made as to their
overall usability or innovation.

VAX/VMS WORKSTATION SETUP
-------------------------

$ NCP SET OBJECT DECW$CLIENT NUMBER 222 PROXY OUT
$ NCP DEF OBJECT DECW$CLIENT NUMBER 222 PROXY OUT

The procedure DWAPP.COM can be executed on a VAX/VMS workstation running
DECwindows to start up applications on the compute server. For instance, on a
VAX/VMS workstation you could use the procedure DECWET::SYS$PUBLIC:DWAPP.COM.
You'll need to edit it and change the string XYZ to your initials.

If the procedure is invoked as:

$ @DWAPP DECWET
Application: bookreader
Application:
$

This procedure starts up the specified applications (in this case, just the
bookreader) on DECWET.  The display will be on the VAX/VMS workstation.


ULTRIX WORKSTATION SETUP
------------------------
The program decw-client.c can be compiled on an ULTRIX system running
DECwindows and executed to start up applications on the application
execution system.  On the ULTRIX workstation:

#
# To create decw-client
#
% dcp decwet::'sys$public:decw-client.c' decw-client.c
% cc decw-client.c -o decw-client -ldnet

    OR

% dcp -i decwet::'sys$public:decw-client' decw-client
   
    THEN

% su
# recommend that you move it to /usr/local
% chmod u+s+r+x,g+r+x,o+r+x decw-client
% chown root decw-client

#
# To use decw-client
#
% decw-client remote-system-name
wsname,prefix
application1
application2
^D

Also see the short scripts on DECWET::SYS$PUBLIC:

xvms.	Creates a logged-in terminal window
yvms.	Creates a terminal window at the Username: prompt

Miscellaneous notes:  If you modify the scripts xvms or yvms to start
other applications, and the application name contains a "$" (vue$master,
for instance), you must quote the "$" with a backslash (vue\$master, for
instance).


TERMINAL WINDOWS
----------------

The defaults for terminal windows are:

- Use the defaults for your account (whatever you have saved, or the
  system defaults)

- Process name is xyz_nodename (BLS_UMBRLA, for instance).  Subsequent
  terminals are created with a digit appended.

- The window and icon name is the node name.  If the process name has
  a digit appended, so will the window and icon name.

To run an application using DECW$CLIENT, you specify the application
name.  The application name for terminal windows is

terminal-window

You can specify some options on the terminal window line by following
the application name with a "/".  There are 5 options, and they are
position-dependent.

The options are:

P1 - No auto login flag.  0=autologin, 1=prompt for username.  Default
     is to autologin to the user's account.
P2 - DECterm setup file name. If not specified, the default is used.
P3 - Process name.  If not specified, the string xyz_nodename is
     used.
P4 - String for the window title and icon name.  If not specified, the
     current nodename is used (it may be modified by ";n" if there
     are multiple terminal windows for the same user on the node)
P5 - Wait for child flag.  Default is 0.  You probably don't care. 
     See text of DECW$CLIENT-TERMINAL-WINDOW.STARTUP for details if
     you think you do.

Examples:

These lines of text are entered as lines of input to the DWAPP.COM command
procedure on VAX/VMS workstations, or to decw-client on ULTRIX workstations.

Create a logged-in terminal window

	terminal-window

Create a terminal window at the username prompt

	terminal-window/1

Create a logged-in terminal window with a special DECterm defaults file

	terminal-window//real-big-window.decterm/

ADDITIONAL NOTES
----------------

The first time you use DECW$CLIENT from either a VAX/VMS or ULTRIX
workstation, it will create a directory in your account on the compute server,
SYS$LOGIN:[.DECW$APPS] (Note: you can't use that string to access the
directory, it's for explanatory purposes only), and set the directory version
limit to 10.  This directory is used for storing the startup and output files. 
If you are having problems with an application, check the application output
file in this directory (application.output), as well as SYS$LOGIN:NETSERVER.LOG

I have been having the following problems with DECW$CLIENT. I suspect it
has something to do with the default priv's of the target account but I'm
having problems pinning it down:

	1. When using DWAPP.COM from the workstation, when I specify
	no param on the specification of the TERMINAL-WINDOW appli-
	cation name, ie TERMINAL-WINDOW as opposed to 
	TERMINAL-WINDOW/1, I still get a terminal window that is NOT
	logged in.

	2. When specifying applications other than DECW$application-name
	they are not invoked, ie TPU or NOTES.

I've installed the most recent version of DECW$CLIENT per 305.5 and the
associated files and have defined the PROXY in UAF to be DEFAULT.

1) I've seen this caused by strange things in LOGIN.COM.  I've asked Steve
to send me his.

2) NOTES should work correctly with the latest DECW$CLIENT.  TPU does not,
but I've got a fix in hand that makes it easy to add additional client
applications that are started by their own DCL commands (as NOTES and
TPU are), rather than via the RUN command...coming soon.

-- Benn

$!++
$! P1  = target node
$![P2] = username there
$![P3] = processname prefix
$!--
$ server = p1
$get_server:
$ if server .nes. "" then goto have_server
$ inquire server /nopunct "Server: "
$ goto get_server
$have_server:
$ if p2 .eqs. "" 
$ then
$   user = f$edit(f$getjpi(0,"username"),"trim")
$ else
$   user = p2
$ endif
$
$ If P3 .eqs. "" Then P3 = f$trnlnm ("Sys$Node")
$
$ set term/noecho
$ read sys$command password/end=nopass/prompt="Password: "
$ set term/echo
$ write sys$output ""
$ open /read /write /error=open_problem -
	f1 -
	'server'"''user' ''password'"::"222="
$ this_node = f$trnlnm ("SYS$NODE") - "_" - "::"
$ write f1 f$fao ("!AS,!AS", this_node, P3)
$get_application:
$ read /prompt="Application: " /end=app_done sys$command app
$ if app .eqs. "" then goto app_done
$ write f1 app
$ goto get_application
$app_done:
$ close f1
$ exit 1
$open_problem:
$ sts = $status
$ write sys$output "% Error connecting with ''server'"
$ write sys$output f$message (sts)
$ exit sts+%X10000000
$ nopass:
$ set term/echo
$ exit 

I've been using decw-client on an Ultrix system (thanks!), and have
made a few modifications that I think people may find useful.  The updated
decw-client.c is appended to this message.

The thing that I didn't like about decw-client was that it required you
to give the name of the display node and applications on stdin, rather
then on the command line.  The new command line syntax is:

decw-client remote-node [-n display-system-name [-p prefix]] [progname...]

The remote-node is the VMS system on which you want to start a job.
The display-system-name is where you want the display to go.  The prefix is
the optional prefix to put on the VMS process names.  The prognames are
the names of the applications you want to start.

If you don't specify the -n option, you must specify the display-system-name
on the first line of the standard input:

decw-client remote-node application1 application2
display-system-name,prefix
^D

The ",prefix" is optional.

If no prognames are given on the command line, they are given on the standard
input:

decw-client remote-node -n display-system-name
terminal-window
mail
^D


Examples:

	alias pbsvax decw-client pbsvax -n `hostname` terminal-window
	(alias to start a DECterm on pbsvax)
	
	decw-client pbsvax -n `hostname` mail notes
	(start mail and notes on pbsvax)

	decw-client pbsvax -n `hostname`
	terminal-window
	mail
	^D
	(start a DECterm and mail on pbsvax)

I find the ability to not hard-code the display system's name into shell
scripts handy (OK, I know you don't really have to hard-code it, but I bet
most people do).  This way I can set up a bunch of aliases that are the
same for the several Ultrix systems I use (I can share the same .cshrc files).

	- Karl

---------------------------------------------------------------------------
/* decw-client.c
    This program is used to create remote processes on the cluster from your
    Ultrix workstation.  These processes usually are meant to run either 
    DECwindows-based applications or to run within a DECterm terminal emulator 
    window.

    decw-client is invoked with one argument -- the name of the node to connect
    to.  This could be `decwet', `ltning', etc.

    The first line of input to decw-client has the following format:
        Xserver,prefix,transport
    where
        Xserver    is the nodename of your workstation
        prefix     is the string prefixed to the name of created processes
                   (for example, XYZ$MAIL).  This string is usually your 
                   initials. It may be omitted, in which case your cluster
                   username is used.
        transport  is the name of the X transport to use.  Omit this.

    The remaining lines of input to decw-client each start a remote process.
    You can use `mail' to start DECwindows Mail, `calendar' or
    `decw$calendar' to start the Calendar, and so on.  You can use
    `terminal-window' to create a process running in a terminal emulator window.

    Alternatively, you can invoke decw-client as:

	decw-client remote-node [-n Xserver [-p prefix]] [remote-process ...]

    To compile this program, use the following command:

        % cc decw-client.c -o decw-client -ldnet
        % chmod u+s decw-client
	% su
        % chown root decw-client

    (You must be root to do the last command.)
*/

#include <stdio.h>
#include <string.h>

#define BUFSIZE 1024        /* size of buffer for read/write */

static char *usage =
	"usage: %s nodename [-n xserver [-p prefix]] [process ...]\n";
 
static char *comma = ",\0";
static char *version = "V2.0\0";
static char *ok = "DECW$CLIENT--OK";

void send_line();

main(argc, argv)
int argc;
char *argv[];
{
    int sock;             /* socket for connection */
    int length;           /* length of data        */
    char buff[BUFSIZE];   /* buffer for data       */
    int quit	= 0;
    char *s;
    int count;
    char	*remote_node	= NULL;
    char	*xserver	= NULL;
    char	*prefix		= NULL;
    char	*progname;


    /*
     * Make sure the node name was given on the command line
     */
    progname = argv[0];
    if( argc < 2 ) {
        fprintf(stderr, usage, progname);
        exit(1);
    }

    remote_node = argv[1];
    argc = argc - 2;
    argv = argv + 2;

	/* now look for options to process:  [-n node [-p prefix] */

    for (; argc > 0; --argc, ++argv)  {
	if (argv[0][0] != '-')
	    break;
	switch (argv[0][1])  {
	    case 'n':	/* node name follows */
		if (argc < 2)  {
		    fprintf(stderr, "missing node name following -n\n");
		    fprintf(stderr, usage, progname);
		    exit(1);
		}
		xserver = argv[1];
		argc --; ++argv;
		break;
	    case 'p':	/* prefix */
		if (argc < 2)  {
		    fprintf(stderr, "missing prefix following -p\n");
		    fprintf(stderr, usage, progname);
		    exit(1);
		}
		prefix = argv[1];
		--argc; ++argv;
		break;
	    default:
		fprintf(stderr, "Bad option %s\n", argv[0]);
		fprintf(stderr, usage, progname);
		exit(1);
		break;
	}
    }

    if (prefix != NULL)  {	/* -p option requires -n option */
	if (xserver == NULL)  {
	    fprintf(stderr, "-p option requires -n\n");
	    fprintf(stderr, usage, progname);
	    exit(1);
	}
    }


#ifdef DEBUG
    sock = 1;
    puts("debugging\n");
#else
    /*
     * connect to our partner "dnet_echo1d" on the specified node
     */
    sock = dnet_conn(remote_node, "#222", 0, 0, 0, 0, 0);
    if( sock < 0 )
    {
        /* print DECnet specific connect error */
        nerror (argv[0]);
                exit(1);
    }
#endif

    /*puts("Connected!");*/

    /* send Xerver,prefix,xport,version info over network */

    /* info may have come from command line or from stdin */

    if (xserver != NULL)  {	/* from command line */
	if (prefix == NULL)
	    prefix = "";
	strcpy(buff, xserver);	/* node */
	strcat(buff, comma);	/* node, */
	strcat(buff, prefix);	/* node,prefix */
	strcat(buff, comma);	/* node,prefix, */
	strcat(buff, comma);	/* node,prefix,, */
	strcat(buff, version);	/* node,prefix,,version */
    }
    else  {	/* read info from stdin */
        if (gets(buff) != NULL)  {
            s = buff;
            count = 1;
            while (1) {
                if (!(s = strchr(s,',')))
                    break;
                else {
                    count++;
                    s++;
                }
            }
            switch (count) {	/* NOTE fall-thrus!! */
                case 1: strcat(buff,comma);
                case 2: strcat(buff,comma);
                case 3: strcat(buff,comma);
                        strcat(buff,version);
                        break;
                default:
                    fprintf(stderr,
			"Too many elements on node,user,xport line\n");
		    quit = 1;
                    break;
            }
        }
        else
	    quit = 1;
    }

    /* now send the data, if no error */
    if (!quit)
	send_line(buff, sock, 0);


    /*
     * read lines from standard input, send them over the network,
     * then read and print the echo'ed line from our partner
     */
    if (!quit)  {
	if (argc > 0)  {	/* take commands from command line */
	    for (; argc > 0; --argc, ++argv)
		send_line(*argv, sock, 1);
	}
	else  {		/* take commands from stdin */
	    while (gets(buff) != NULL)
		send_line(buff, sock, 1);
	}
    }

    /*
     * finished - close network connection and exit
     */
    /*puts("Exiting...");*/
    close(sock);
}

void
send_line(buff, sock, await_response)
char	*buff;
int	sock;
int	await_response;
{
	/* send buff (if non-zero length), and possibly await a resonse */

    int	length;
    char	rbuff[BUFSIZE];

    /*puts(buff);*/
    length = strlen(buff);
    
    /* Only send non-empty lines */
    if( length > 0 ) {
        if( write(sock, buff, length) < 0 ) {
	    perror("couldn't send line over network");
        }

#ifndef DEBUG
    
        while( await_response ) {
    	    /*puts("Waiting for response");*/
    	    if( (length = read(sock, rbuff, BUFSIZE)) < 0 ) {
		perror("couldn't read line over network");
		break;
    	    }
	    else if (length == 0) {
		fprintf(stderr, "Unexpected eof on network link");
		break;
	    }
	    rbuff[length] = '\0';
	    if ((length == strlen(ok)) &&
			(!strncmp(ok,rbuff,length)))
		break;
	    puts(buff);
	}
#endif
    }
}

            Hello

    DECW$CLIENT works fine with default resource files. Helps me a lot!!!!

    Now I like to change the loction of "main window" in DECW$BOOKREADER
    and its size but Bookreader always use defaults size and location.

    "Local Bookreader" works as I defined.

    Please help me. Where is correct place for recourse files?????

        Thanks in advance,
            Kari
    

	
	me again

	I found that DECWINDOWS V2 FT1 Bookreader works correctly with my 
	sys$login:decw$bookreader.dat.

	
		--Kari

I have encountered a small problem using the DECW$CLIENT utility.
The problem is specific to the creation of remote DECterm sessions.

My workstation is running VMS V5.3 and DECwindows V2.0 and the server is
running VMS V5.2 and DECwindows V2.0.

The command that I am using to invoke the DECterm is:

	@DWAPP WHELIN terminal-window		(WHELIN is my SERVER)

This should give me a logged-in window on my workstation, but instead it
creates two processes which remain in LEF state indefinitely.

The first is the CHILD process and the second is the DECW$TERMINAL process.

I have included the extracts from the TERMINAL.STARTUP, TERMINAL.OUTPUT and
NETSERVER.LOG files, (at least these are being created).

Any and all help would be greatly appreciated.

Regards,

Andrew

P.S.  The utility works as described for other DECwindows applications
      such as Mail and Notes, so I do think that it's related to the
      command procedure.

=========================================================================
TERMINAL.STARTUP Extract

$ !DECW$CLIENT V1.3 
$ @sys$system:decw$client-set-display DWJNES::0.0 DECNET
$ define exedir sys$system:,decw$examples:,USER5:[DAVIS.DECW$APPS]
$ run exedir:decw$TERMINAL

This appears normal.
=========================================================================

=========================================================================
TERMINAL.OUTPUT Extract

Using existing display device - WSA2

DECterm version X2.0-15 now at your service...

To create DECterms, use the Session Manager or call the
DECwTermPort() routine from another process.

*** However, this appears incorrect; it seems to indicate some problem,
*** but I'm not sure what.
=========================================================================

=========================================================================
NETSERVER.LOG Extract (I included this in case it was relevant).

        --------------------------------------------------------

        Connect request received at  9-NOV-1989 13:49:24.22
            from remote process DWJNES::"0=DAVIS"
            for object "SYS$COMMON:[SYSEXE]DECW$CLIENT.COM"

        --------------------------------------------------------

DECW$CLIENT serving node DWJNES user AJD via DECNET
DECW$CLIENT starting application TERMINAL-WINDOW
DECW$CLIENT creating startup file USER5:[DAVIS.DECW$APPS]TERMINAL.STARTUP
Identification of created process is 258006B1
Waiting for terminal controller to start...
Waiting for terminal controller to start...
Using existing display device - WSA2

This also appears normal.
=========================================================================

	I have started using this procedure. I would however, like to
	know how to force the request for the creation of the screen
	on the display server to use a cluster alias from the client
	node. 

	I am new to this, so be gentle...

    There are performance reasons for not doing this (messages may have to
    travel through an extra node between client and server), but if you
    really want to...
    
        NCP> SET(or DEFINE) OBJECT X$X0 ALIAS OUTGOING ENABLED
    
    ...should do it.

>    There are performance reasons for not doing this (messages may have to
>    travel through an extra node between client and server), but if you
>    really want to...
    
	Why would they have to travel through an extra node? Wouldn't the 
	on-NI bit eliminate this problem after the first message? Or isn't
	that feature available with ALIAS nodes?

>        NCP> SET(or DEFINE) OBJECT X$X0 ALIAS OUTGOING ENABLED

	Is the X$X0 object a permanent object or created only for the
	life of the system? I see it in my permanent database, but is
	this the standard?

RE: .15

	I think that when running X thru an alias, it doesn't know enough
	to go "Oh, I'm going thru 2 nodes to get to just one. I'll just
	go direct".  I dunno if this will ever be fixed.

							mike

    Re: .15
    
    The X$X0 object is created by the server using an IO$_ACPCONTROL
    function.  It shouldn't have gotten into the permanent database.

    The on-NI bit algorithm in Phase IV depends on the Ethernet controller
    having its address replaced by HiOrd+DECnet address. This way, an end
    node can send direct to the target Ethernet controller if it only knows
    the DECnet address. Also, the on-NI bit only applies to end nodes.

    The alias is a different DECnet address from that of each member node.
    It does NOT appear as a component of the address loaded in any Ethernet
    controller. Also, it is a single address which references multiple
    nodes. The "out of the cluster" node has no way of knowing which node
    in the cluster is associated with a particular connection to the alias
    - it only knows about the alias. So how could it avoid an extra hop?
    The real destination is not known until each packet reaches the alias
    (that is, a router in the alias).

    The real performance impact with alias is with large packets, since
    when you lose the on-NI bit algorithm, you also lose the "override the
    EXEC BUFFER SIZE setting and use large buffers" optimization, and the
    connection reverts to 576-byte packets (at NSP) instead of 1498-byte
    packets.

Re: .15

Are you using INSPECT and did you run its "lockdown" procedure?  One of the
things it does is blindly insist that there be permanent object definitions
for all objects declared when it is run, and it creates them if you don't
prevent it from doing so.  I understand a future version of INSPECT won't
do this.

				Steve

    Has anyone created a version of DECW$CLIENT for ultrix to allow Work
    stations to create processes on the server?
    
    bob

Do you know about rsh?
		Jeff

    Yes i know about rsh but what about launching an application from a VMS
    workstation on the ultrix server

I haven't looked at DECW$CLIENT.COM because it's protected on my client node, so
let me ask here.  Apparently the .COM always creates a startup file in
the [.decw$dwapps] subdir (even if there is already one there), 
and tries to run DECW$foo.  
DECdecision/Calc did not follow the naming convention, and their image name 
is DECISION$ECALC.
So I can't get DECW$CLIENT to start it, and I can't create my own startup
file to start it.

Any suggestions?

>DECdecision/Calc did not follow the naming convention, and their image name 
>is DECISION$ECALC.

	There is a specific check in the file for the application
	requested. If it it within the list, the command for invoking
	it is put in the .startup file. You must get the system manager
	to put in into the file in order to use the product.

I start Ultrix process from my VMS system with submit/remote node::"application"

Normally I use a shell script since I need to set the display environment
variable.

Neal