Path: utzoo!attcan!uunet!husc6!mailrus!iuvax!bsu-cs!cfchiesa
From: cfchiesa@bsu-cs.UUCP (Christopher Chiesa)
Newsgroups: comp.os.vms
Subject: Re: (none)
Summary: Broadcasts might solve your problem...
Message-ID: <3378@bsu-cs.UUCP>
Date: 5 Jul 88 18:55:05 GMT
References: <8807021206.AA20905@ucbvax.Berkeley.EDU>
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 42

In article <8807021206.AA20905@ucbvax.Berkeley.EDU>, MIC@STAR.ARM.QUB.AC.UK writes:

> ...what I need to know is how to :
> 
>    Sit at one terminal inputting commands to and receiving information from a
> fortran program running on a microvax (VMS 4.6) while it sends/receives
> numerical strings to/from another terminal.
> 
>    A method which sends a load of guff before or after the numerical string will
> probably not be of much use as the motor controller won't handle this. I have
> tried using sys$assign, and sys$qio routine without success as yet

Well, it would take a bit of programming work, but the way I'd do it (in 
a totally non-privileged VMS 4.7 environment) would be to use "broadcasts."

I would have code in the FORTRAN program to transmit its status (or whatever
you are having it return) information via a $BRKTHRU call, and receive your
commands through a write-attention-AST service routine on a mailbox asso-
ciated with its terminal channel.   Your "control" program on the "other"
terminal would then do the "same thing only backwards" - i.e. use $BRKTHRU
to send COMMANDS TO the FORTRAN program, and use the write-attn-AST (i.e.
we are talking "broadcast trapping") routine to RECEIVE the "reports" FROM
the FORTRAN program.

If you have the "command" program send $BRKTHRU messages with broadcast
requester class USER1, and disable it from receiving all classes except
USER2, then do the opposite in the FORTRAN program, you can have two 
separate one-way "channels" between the programs.

I've done this in limited applications and it has worked fairly well,
but be sure to specify a non-zero "timeout" value in the $BRKTHRU calls
if you are going to be sending a lot of data (i.e. lines of a file at
full-tilt speed) through them.  I neglected to do that once and got my
process hung permanently in RWAST state.  It sat there for three weeks
until the next system reboot.

Chris Chiesa


-- 
UUCP: !{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa 
cfchiesa@bsu-cs.UUCP