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 -------