Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: mod.computers.vax
Subject: Re: card reader input symbiont
Message-ID: <8612090723.AA12489@ucbvax.Berkeley.EDU>
Date: Tue, 9-Dec-86 02:23:33 EST
Article-I.D.: ucbvax.8612090723.AA12489
Posted: Tue Dec  9 02:23:33 1986
Date-Received: Tue, 9-Dec-86 09:28:15 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: 
Organization: The ARPA Internet
Lines: 61
Approved: info-vax@sri-kl.arpa

[The original question involved taking a job passed over from a CDC host,
executing it on a VAX as a batch job, then having to be SURE of getting the
results back to the sending CDC host.]

You might do better with the following scheme:  Write the user's job to a
file, say UCOM.  Then submit, through INPSMB as you suggest, a command file
that does:

	$ on error then continue
	$ @ucom 'p1' 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
	$ on error then 
	$ 

The advantage of the extra level of indirection is that "on error" traps are
specific to each level of invokation, so any traps the user's code sets have
no effect on yours.  Further, you don't have to worry about finding all
EXIT's in the user's code, since they will EXIT right back to yours, etc.

The following problems exist with this scheme:

	- If they user's code does an explicit LOGOUT, you never regain
		control and he gets no information.  There's of course no
		reason why he should WANT to do an explicit LOGOUT, but you
		never know.  You could always re-define LOGOUT to be EXIT.
		Also watch out for EOJ, which is a rarely-used synonym for
		LOGOUT.  He can still do a STOP/ID=0, or delete his own
		process, or....
	- If the job has a time limit and runs past it, you may or may not
		gain control (depending on what error trapping the user does).
	- There are some "runaway" situations in which you won't get control
		back (though you'd never get anything back even if you were
		on the VAX directly).  For example, if a program reads from
		the SYS$INPUT but doesn't exit when it gets an EOF, it will
		run forever.  (I've had this happen with Wollongong's FTP,
		which simply re-prompts until it gets a QUIT - which the
		job controller is never going to give it.)
	- An extra level of "quote striping" of the parameters takes place in
		the code as I wrote it above.  If this is a problem, rather
		than passing p1-p8 as parameters, place them in global sym-
		bols, then at the beginning of ucom - which you are modify-
		ing anyway - move them back from the globals to local p1-p8.
	- If the user REALLY wants 16 levels of command procedure nesting,
		he'll find himself one short.  (Tough.)

Actually, for VMS V4.4 I guess you could use CALL to re-invoke the same
command procedure, so you'd only need one file.  I haven't played around
with that enough (at all) to know if it would do what you want.

As a catch-all, you might want to arrange it so that logs are written to a
known place, and start off with enough information to determine who they
belong to.  In normal end-of-job processing, you mark the log in some way -
perhaps even by renaming it to a different directory - to indicate that you
are done with it.  A job runs every, say, 15 minutes and looks for log files
that are not marked done but aren't opened by any active job.  (Off hand, the
easiest way to check is to see if you can get APPEND access to the file from
DCL - you can always get (shared) READ.)  It would then return such files to
wherever they should go.  Thus, if you somehow DID manage to screw up the
usual procedure, you'd still get your results back, though perhaps delayed a
bit.
							-- Jerry
-------