Conference noted::hackers_v1

	There was a change in MAIL between VMS V3 and V4 which makes
    MAIL not usable with a command string. Instead you can send mail
    directly from DCL by talking MAIL-11 protocol. The following is
    a fragment that does this, and that I have used with no problems.
    
    		Dave
    
$ user = "MONAHAN     "
$ node = "52354::"
$ object = "''node'""27="""
$ on error then goto exit
$ open /read /write link 'object'
$ write link "''f$getjpi("", "USERNAME")'"
$ write link user
$ read link status
$ v = 0
$ v[0,8] = 'f$cvui(0, 8, status)
$ v[8,8] = 'f$cvui(8, 8, status)
$ v[16,8] = 'f$cvui(16, 8, status)
$ v[24,8] = 'f$cvui(24, 8, status)
$ if v .ne. 1 then goto error
$ eot = " "
$ eot[0,7] = 0
$ write link eot
$ write link "security manager"
$ write link "%%AUDPACK ''f$logical(""SYS$NODE"")'"
$ copy 1.1 link
$ write link eot
$ read link status
$ v = 0
$ v[0,8] = 'f$cvui(0, 8, status)
$ v[8,8] = 'f$cvui(8, 8, status)
$ v[16,8] = 'f$cvui(16, 8, status)
$ v[24,8] = 'f$cvui(24, 8, status)
$ if v .ne. 1 then goto error
$exit:
$ set noon
$ delete 1.1;*
$ delete 1.2;*
$ close link
$ exit
$error:
$ read link message
$ if 'f$len(message) .eq. 1 then goto exit
$ goto error

    OK, the example I used is taking us away from the root problem. I was
    MAILing to myself in order to prove to myself that the remote procedure
    ran to completion.  I'll change that (to just print a file or
    something) to circumvent the MAIL problem, which doesn't concern me
    right now. 
    
    I'll be back with status.

    I found the problem.  I have to compare f$mode with "NETWORK", not
    "network".

    re: .0
    
    It sounds like you are in the infamous "transparent network protocol"
    traps. one of the ways you can get relatively instantaneous information
    is by doing the following sort of thing:
    
    ("telling" node)
    
    $ TYPE OTHER"user password"::"TASK=DO_SOMETHING"
    
    
    ("OTHER")
    
    [DO_SOMETHING.COM]
    
    $ ASSIGN SYS$NET SYS$OUTPUT
    $ ! whatever you want to do
    $ EXIT (or LOGOUT)
    
    	the main point of this exercise is to open a transparent link
    back to the calling node from the other. You'll notice this sort
    of thing in the "TELL" procedures. This allows you to see what causes
    the "network process exited" errors, which are telling you that
    your command procedure died on the remote node for "some reason".
    
    	I did something like this in a hack that checked my mail machine's
    MAIL file from all of my other assorted accounts. What I wanted
    to do was to spawn a subprocess  (/NOWAIT) on whatever machine I
    was on, and run a remote network task on the mail machine to spawn
    MAIL, output any "You have ## new messages" to a file, and type
    the file back over the network to tell me if I got mail. Yes, it
    works, but I had to SPAWN the MAIL command with output and input
    command files. Overall it's a bit hacky, but hey, it works. And
    the TYPE command from the issuing node automatically gives you the
    output from the other node providing you assign SYS$NET to SYS$OUTPUT
    on the other node.
    
    Hope this is a pointer you can use...
    
    -pjh
    

    I want to have the remote process both read and write from the network.
    DCL can do this by using OPEN/READ/WRITE, READ, and WRITE.  But I
    haven't been able to get it to pass this capability on to images run
    from DCL.
    
    Does anyone know how I can get this to work?  Is it specific to the
    particular interactive programs I have been using in my testing? 

    (node A, file callit.com)

    $ open/read/write net b::"0=doit"
    $loop:
    $! various commands including both
    $ read net line
    $! and
    $ write net line
    $! it will know enough about the program run on node B so that it
    $! knows when to read and when to write so it doesn't get jammed.
    $ ...
    $ close net
    $ exit

    (node B, file doit.com)

    $ open/read/write net sys$net
    $ define/user sys$input net
    $ define/user sys$output net
    $ mail	! (or any other interactive program)
    $ write net "All done."
    $ close net
    $ exit

    My experiments indicate that the program (mail in the example) is,
    in fact running interactively, but it is not reading from sys$net.

	:Karl.

    <*whew*>  Wish I could offer some encouraging words...
    
    With transparent DECNET, you MUST have matching sets of reads and
    writes from your "co-operating" processes.  It is very difficult
    to predict whether or not MAIL will READ or WRITE to SYS$whatever
    at any given instant, and how many times it will do one or the other
    in a row.  It is not possible to detect which it is doing from the
    remote process using transparent mode...
    
    I would say that creatively redefining SYS$OUTPUT: and SYS$INPUT:
    directly to SYS$NET: should produce desireable results in most cases,
    at least initially,  but you must be very careful to READ every
    time the remote process intends to WRITE, and WRITE every time the
    remote process intends to READ.  If you miss even once, you're HUNG.
    
    						Brian
    

re .5: (using MAIL in network jobs)

Read the extracted notes in .0 about using MAIL for your test network program.

-Mike

    I've gotten things other than mail to work (like
    analyze/rms/interactive and elf) but I can't get spawn to work (taking
    input/output from/to the network connection), no matter what I tell the
    spawn to do.  It always says

%DCL-W-INVFILSPE, input or output file specification too long - shorten

    My original problem is solved, anyway.  I discovered that the program
    I was trying to get to work (FTP) wanted to see a linefeed character
    (not simply end-of-record) before it would process the input command
    line.