Conference noted::hackers_v1

470.0. "Doing MAIL/EXTRACT in a DECnet Object" by MOSAIC::LICHTENBERG () Tue May 12 1987 00:46

I'm not much of a DCL (or VMS) wizard, so bear with me...
I am trying to define a DECnet object which, when you connect to it will:

	$ SET DEF [.MAIL]		!in the user's home directory
	$ RUN SYS$SYSTEM:MAIL
	EXTRACT/ALL/MAIL MAIL.NEW
	EXIT
	$ WRITE SYS$OUTPUT "done"

(the exact code I am using, quilted from the remote CMS hack, is below)

I'm trying to get it to do that when I open a connection
to something like NODE::"0=MAILSTUFF"  (using proxy for LOGIN) it will
do the MAIL/EXTRACT, leave the mail.new file, and send a message back
to the task that opened the connection.  Well, I can't get it to take
the input for MAIL.  It just says "DCL-W-mumble-ignoring lines that don't
start with dollar signs" or whatever... and never creates the file.

I get the feeling that since the same image (MAIL.EXE) is installed both
as the user program and the server program, that when it is run from
a DECnet connection you can't feed commands to it (perhaps it thinks
its input is incoming mail?)

Any ideas?

/Mitch.

Here's the first part: install via:
	NCP SET OBJECT MAILSTUFF NUMBER 0 FILE disk:[dir]MAILSTUFF.COM

$! MAILSTUFF.COM -- DCL DECnet "Object" to extract mail messages
$!	eb augustine, 30 may 1986
$!	mitch lichtenberg 05/11/87 - hacked into mailstuff.com
$!
$!
$! To run mailstuff, user must have a proxy on the local machine.  Without 
$! one, the user is logged into the default decnet account. So check the
$! username; if it's "DECNET", then exit (which closes the link).  Send no
$! information back about why the link is being dropped.
$!
$	if f$edit(f$getjpi("", "USERNAME"), "COLLAPSE") .EQS. "DECNET" then exit
$!
$!    The local procedure redirects output to the network link, sending any
$!    messages to the remote procedure.  It then executes the MAIL command.
$!
$!	$	set verify	! causes output to be displayed remotely
$!
$	done_message	= "DONE"		!   between tasks
$	put     	= "write sys$output"
$!
$	on warning then goto problem
$	open/read/write/error=problem remote sys$net	! Open the remote link
$!
$!
$! 1) read and execute a set of DCL commands from the remote procedure.
$!
$ define sys$output remote		! redirect output
$!
$ SET VERIFY			! echo junk back through net (debugging!)
$!
$ SET DEF SYS$LOGIN		! must be defined in user's mailfile
$ SET DEF [.MAIL]
$ RUN SYS$SYSTEM:MAIL
SELECT MAIL
EXTRACT/MAIL/ALL MAIL.INP
EXIT
$ PUT DONE_MESSAGE
$ EXIT
$	
$PROBLEM:	!Error occurred, so write a message, clean up, and exit
$	put "Remote MAIL encountered an error.  Please try again." 
$	goto close_link
$!
$!	
$!
$! 3) After sending the done message, wait for a message that may or may not
$!    arrive. If it comes, or if the link goes down while waiting, resume
$!    processing at the continue_close_link label.
$!
$CLOSE_LINK:
$	put done_message
$	deassign sys$output
$	read/error=continue_close_link remote msg	
$!
$CONTINUE_CLOSE_LINK:
$	on warning then continue
$	close remote				! close if open
$	set noverify
$	exit


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Here's the second part - a little test DCL program to poke the object.
(yes, yes, I know... I should make a variable for the node name...)

$! MSGET.COM - tester for MAILSTUFF object
$
$ done_message = "DONE"
$ put :== write sys$output
$!
$	on warning then goto error_bad_link
$	open/read/write/error=error_bad_link remote foul::"0=MAILSTUFF"
$!
$READ_REMOTE_LOOP:
$	read remote msg
$	if msg .EQS. done_message then goto done_task
$	put "  ", msg		
$	goto read_remote_loop			! loop some more
$
$!
$! 3) Send the done_message back to the remote process
$!
$DONE_TASK:
$	close remote
$!
$CLEAN_UP_AND_EXIT:
$	exit
$!
$!
$ERROR_BAD_LINK:
$	put ""
$	put "Problem with network link. Exiting..."
$! close link if still open
$	if f$logical("REMOTE") .NES. "" then close remote   
$	goto clean_up_and_exit

    I'm sure this has been discussed many times before.
    When MAIL is run in a network process it assumes that it is intended
    to receive a message via the network. Thus it ignores any commands
    on SYS$INPUT.
    The are several ways to get round this. The most obvious one I can
    remember is to run mail in a subprocess (via SPAWN).
    
    Andrew Palka