Conference noted::hackers_v1

As you have probably gathered from the manuals, for VMS systems all task inter-
facing is done via objects.  The non-privileged object for general task and
command file processing is the zero, or TASK, object.  The illustrations in the
"Guide to Networking on VAX/VMS" are Fortran examples designed for use through
a command file, but that does not mean you cannot call up the executable image
directly.

When you use TASK=AAA for example, you are (by default) looking for a command
file called AAA.COM in the directory of the node and account you designated.
However, if you state TASK=AAA.EXE then Decnet realizes you want to call an
image directly, (using NETSERVER capabilities).  Actually, doing this does
not really gain you anything in your application, but does simplify the
interfacing...

Now, where must AAA.EXE reside ?  In your application, since you wish not to
bother the system manager then it will have to be in the default Decnet account
for that system.  It is reachable (if the system manager allows it) by using
NODE""::  for the nodename.  If you leave off the "":: then you better assume
that the system has no PROXY login for the account you are running your sending
task from or it will look at the proxy account instead.  Using "":: forces the
default Decnet account.  The receiving task needs to be in the default account,
and then the sending task can talk to it...

All this assumes that the host computer has not disabled the TASK= object.  If
it has, all the above won't help you a bit, since that disables this kind of
communication altogether, and now you MUST ask help from the system manager.
Why?  Because he must ASSIGN you an object number and place your file in the
proper directory.  You must then use THAT number to communicate "128=" etc.

I have included in this response two files, one for the sending system, and
the other to place into the default Decnet account on the receiving system.
I tested it on a system that did not disable "TASK=" and it worked fine.

Now for the problem of two independant tasks talking to each other...
You may have to have two copies of the receiver task going, talking to each
other via temporary mailbox.  They each can talk to the sending tasks by
network mailbox.  You have 4 tasks going then, one pair for one user, one
pair for the other user.  Programming shouldn't be that difficult, as it only
means adding the hooks for temporary mailbox creation (and if the mailbox is
already created, and if created correctly, the second task will automatically
use the same temporary mailbox as the first task).  Obviously some handshaking
will have to occur here for all this to work, but it SHOULD give you the
solution you are looking for.

Here are the programs I mentioned earlier:

RECEIVER.PAS  (.EXE goes on host system's default Decnet account, I copied it
               there by doing COPY RECEIVER.EXE NODENAME""::* )
--------------------------------------------------------------------------------
PROGRAM RECEIVER;

VAR
  I : INTEGER;
  BUFFER1, BUFFER2 : VARYING [80] OF CHAR;
  NETFILE : TEXT;

BEGIN
  BUFFER2 := '';
  OPEN (NETFILE, 'SYS$NET', NEW);
  RESET (NETFILE);
  READLN (NETFILE, BUFFER1);
  FOR I := LENGTH(BUFFER1) DOWNTO 1 DO
    BUFFER2 := BUFFER2 + BUFFER1[I];
  REWRITE (NETFILE);
  WRITELN (NETFILE, BUFFER2);
  CLOSE (NETFILE)
END.
--------------------------------------------------------------------------------

FILE SENDER.PAS  (I do the following to run the program and connect to the
                  other system:
                  DEFINE TASK "NODENAME""""::""TASK=RECEIVER.EXE"""
                  RUN SENDER )
--------------------------------------------------------------------------------
PROGRAM SENDER (INPUT, OUTPUT);

VAR
  BUFFER1, BUFFER2 : VARYING [80] OF CHAR;
  NETFILE : TEXT;

BEGIN
  WRITELN ('Line to send to net task :');
  READLN (BUFFER1);
  OPEN (NETFILE, 'TASK', NEW);
  REWRITE (NETFILE);
  WRITELN (NETFILE, BUFFER1);
  RESET (NETFILE);
  READLN (NETFILE, BUFFER2);
  CLOSE (NETFILE);
  WRITELN ('Received line: ');
  WRITELN (BUFFER2)
END.
--------------------------------------------------------------------------------

It is not that trivial, but it isn't that hard either.  Hope this gives you
the clues and the information you need...

Greg.

      Re .1
      
      >    Using "":: forces the default Decnet account. 
      
      Actually, using "":: forces the default username for the TASK
      object at the remote node, if one was specified, else, the
      default username for the executor (the "default DECnet account").
      
      Dave C.

    Thanks for the extensive response.  The main problem I see with
    "TASK=FOO.EXE" is that this construct will initiate a process
    that is running FOO.EXE.  However, that's not what I want.  I want
    my voluntary interactive user to fire up FOO.EXE himself.
    
    Hence it sounds like I'd have to have FOO.EXE use a mailbox, as
    you said, in order to mail the data between the decnet-initiated
    process and the user's actual interactive process.  It seems
    like a shame to have to have the extra transfer.
    
    Correct me if I'm wrong, but my understanding is that IF
    the interactive user's process (or installed image) has sufficient
    privileges, it can do some sort of IO$_ACCESS qio to the net
    to identify itself.  Then, the other end can talk DIRECTLY
    to it, without intermediate mailbox ?
    
    If so, perhaps I'll go with this method, and system managers will
    merely have to install the bloody thing.  *sigh*
    
    (I have a privileged system on which to develop all of this
    anway, so at least I won't be impeded during development)
    
    /Eric

    Thanks for the help so far.  I think I've *ALMOST* got something
    working.
    
    One half of my application now runs with SYSNAM privilege on one
    node and declares itself to have a name.
    
    The other half runs on another node with normal privs (TMPMBX, NETMBX)
    and can successfully talk to the SYSNAM process.
    
    Now my problem is that when I attempt to test this by having a friend
    run the unprivileged part on a more faraway node, it just plain
    doesn't work.
    
    All my system services are coded with error checking and he's not
    getting any errors.  So I don't have any idea yet why it works from
    "closer" node but not from faraway one.  Closer node is not in a
    cluster with SYSNAM node, so I don't think that's it.
    
    One thing I wanted to try was to use NCP on the SYSNAM node and
    see if at least the faraway node was attempting contact.
    
    To this end, I was attempting to use SET LOGGING in NCP to log
    events to see if the faraway node was causing *anything* to
    happen whatsoever.
    
    However, I can't figure out how to make SET LOGGING do anything.
    The command seems to be extremely complicated.  The manual doesn't
    offer much more than the HELP command on the matter.
    
    All I want to do is use SET LOGGING in NCP to log everything to
    the terminal, all network events.  Then I want to run my application
    from the faraway node and see if anything gets logged.
    
    Can anyone tell me what SET LOGGING incantation in NCP I ought to
    try in order to turn on logging ?  Thanks.
    
    /Eric

    In the back of the NCP reference manual or the Guide to Networking
    is a list of event codes.   Do NCP SHOW KNOW LOGGING ALL to
    see if the event you are interested in is being logged.   If it
    node, do NCP SET LOGGING MONITOR EVENT x.y-z   [something like 4.0-10
    for 4.1, 4.2, etc to 4.10].   Also check that the state is on. 
    If not, do NCP SET LOGGING MONITOR STATE ON.   You will now see
    an EVL process on your system.
    
    Once logging is happening, do REPLY/ENABLE=NETWORK to enable yourself
    to receive network messages from OPCOM.
    
    	KC

Neither of the following works:

	$ ncp show know logging all
	%W, Unrecognized command verb - check validity and spelling
	\NCP\

	$ mcr ncp
	NCP>show know logging all
	%F, command syntax error
	SHOW KNOW LOGGING \ALL\

/Eric

Well, I finally figured out how to do the commands you must have meant.
However, I don't see anything being logged.  I expected that if I turn
on enough stuff, I should see some sort of even appear at my terminal
if I set host to the system on which I enabled logging.
Here's what I did:

	$ mcr ncp
	ncp> set logging monitor state on
	ncp> set logging monitor event 0.0-9
	. . .			       2.0-1
	. . .			       . . .
	ncp> show known logging
 
 
Logging Volatile Summary as of 15-OCT-1986 14:24:21
 

 Logging sink type = monitor
 
    Sink Node       Source               Events                   State Name
 
   24.321 (HANNAH)  (All sources)        0.0-9                     on
                    (All sources)        2.0-9
                    (All sources)        4.0-19
                    (All sources)        5.0-21
                    (All sources)        128.0-4
                    (All sources)        1.0-9
                    (All sources)        3.0-9
                    (All sources)        7.3-14

Then, I enabled back at dcl, with

	$ reply/enable=network

and I saw several messages, something like

	Operator Osman enabled at . . .
	%%%%%%%%%%%%%%% mumbo jumbo

so I figured I was all set.

So now I went to another system and tried setting host to HANNAH,
and looked back at HANNAH, expecting my terminal to show some sort
of logging announcement regarding the network connection.
But nothing appeared.

What else do I need ?

/Eric

    
    	You don't get messages logging network connections. Look in
    the NCP manual, and it tells you what all the events are, which
    should give you an idea about how to provoke some of them.
    
    Trev

    If I don't get messages logging network connections, perhaps
    logging won't help me solve my problem.
    
    My problem is that I have debugged a "nontransparent" network
    application that successfully talks between nodes A and B.  However,
    it fails between nodes A and C and I don't know why.
    
    Node C merely never receives a network mail message back saying
    either connected or refused.  It just sits there.
    
    However, on B it works great.
    
    Actually, node C is vms 4.3 and node B is 4.4.  Hmmm.  Anyone know
    of any wierd DECnet incompatibilities in this area ?
    
    /Eric

    
    	Have you tried using SHOW KNOWN LINKS in NCP to see what links
    get created ?
    
    Trev

    Well, this network thing is a mystery to me.
    
    I've attempted to program it according to the VMS "nontransparent
    network programming" section of the manual.
    
    The problem is, the program works from node REGINA to HANNAH but
    not between HANNAH and HANNAH.
    
    (It actually also fails from HYPER to HANNAH too, but if I can
    get HANNAH to HANNAH working, probably the other will start working
    too).
    
    The way the program is supposed to work is that the HANNAH part
    declares itself as a network object of name ADVISOR.
    
    The other part (REGINA, HYPER, or HANNAH) attempts to open
    HANNAH::"TASK=ADVISOR".  From REGINA various other nodes it all
    works.  So I know I'm close !
    
    However, from HYPER or from even HANNAH itself, the other part
    tries to do its connection (it uses IO$_ACCESS) and gets back
    the error
    
    	%F, network object is unknown at remote node
    
    But object IS known !!  And as I said, it even works if I use
    REGINA.
    
    Anyone have any hints as to what the problem might be ?  What
    set of conditions cause the above error ?
    
    Thanks.
    
    /Eric

re .12:  REGINA has the TASK object defined, while HYPER and HANNAH don't. 
Also, when using TASK, if it can't find the file it's suposed to execute,
that'll also give "Network object not found."

-Mike

    Someone told me your explanation makes no sense.  The "TASK=" is
    part of the syntax, and has nothing to do with any task that happens
    to be called "TASK".  My task happens to be called "ADVISOR".
    
    My current lead is to see if proxies have anything to do with it.
    There are proxies for various-nodes::OSMAN to local user P_OSMAN
    on node HANNAH.  I don't want this tool to depend on proxies,
    so I'm investigating that . . .
    
    /Eric

    HANNAH""::whatever will disable inbound proxy use.
    
    -- Barry

      Re .14
      
      > ... The "TASK=" is part of the syntax, and has nothing to do
      > with any task that happens to be called "TASK".  
      
      No, actually, the name to the left of the equal sign is converted
      to an object number at the requesting system.  Since HANNAH
      doesn't have the name TASK defined, you get "object unknown".
      Try using "0=" instead of "TASK=", and I'll bet it works.
      
      Dave C.

    Yes, thank you !  Now that I take a closer look, I see you are right.
    
    I always thought "TASK=FOO" was a syntax that meant to communicate
    with task called "FOO".  But it turns out that "TASK=" is more than
    syntax.  It actually looks for a task called "TASK".  So, I'm now
    having more luck with "=FOO" instead.
    
    /Eric