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