macmillan%wnre.aecl.cdn%ubc.CSNET@RELAY.CS.NET.UUCP (12/04/86)
We are running the HASP+ communications "package" between our VAX cluster and
a remote CDC system. It allows users to submit jobs to be executed on the
CDC and receive the output from the jobs on a VAX printer or to the user's
directory.
I am trying to come up with a simple mechanism that would allow CDC users to
submit jobs to the VAX batch queues and automatically receive output on the
CDC.
The plan is:
1. CDC user prepares a VAX job for input to a card reader (ie. $job, $password,
etc.)
2. The user routes the job to the remote (ie the VAX) punch queue.
The job has an additional parameter containing the CDC userid and password
which will be used to route the job back to the CDC. Somthing like
/CDCID=(aaaaa,bbbbb). This information is then stripped off the $job card.
3. A /NOPRINT and /LOG_FILE=filename is appended to the $job card. The job is
then submitted to the card reader input symbiont.
$ MCR INPSMB
filename
$
4. A follow up job, synchronized to run immediately after the first, routes the
job to the CDC. Actually, it submits a file to the CDC, with the printout
of the job from step 3, appended to it.
The purpose of a follow-up job is to ensure that something gets back to the
CDC. An alternative is to add on the DCL, but suppose the job failed for
cputime, DCL error, or anything else? Something HAS to be returned, or the
CDC user will have no record of what happened.
$ SYNCHRONIZE/ENTRY=number/QUEUE=name
The Problem:
The only hitch in the plan is in the follow-up job. It needs to know the entry
number of the job in the batch queue. (The queue name can be extracted from
the $job card beforehand.) But INPSMB does not return the entry number (or
anything else) to the terminal.
Note: The followup job will have a different user name than the first job.
Is there a simple solution? Maybe a simple
$ ON ERROR GOTO ROUTEBACK
.
.
.
$ ROUTEBACK: !comes here if error or not
$ SUBMIT FOLLOWUP
I want to keep things as simple as possible, and write a program that calls
on the input symbiont, only as a last resort.
John MacMillan
Atomic Energy of Canada
Whiteshell Nuclear Research Establishment
Pinawa, Manitoba, Canada R0E 1L0
(204) 753-2311 x2539LEICHTER-JERRY@YALE.ARPA (12/09/86)
[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 <whatever> $ <inform CDC system> 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 -------