Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: mod.computers.vax
Subject: Re: redirecting regis output
Message-ID: <8605110330.AA01925@ucbvax.Berkeley.EDU>
Date: Sat, 10-May-86 23:31:10 EDT
Article-I.D.: ucbvax.8605110330.AA01925
Posted: Sat May 10 23:31:10 1986
Date-Received: Mon, 12-May-86 21:35:51 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Organization: The ARPA Internet
Lines: 37
Approved: info-vax@sri-kl.arpa


    I've been compiling and running some ISSCO/DISSPLA programs using the
    CALL REGIS(3,1) subroutine which sends the graphics output (REGIS) to
    my vt241 terminal. 

    I would like to capture these regis commands.

    [The author then indicates various methods he's tried to do this, of
	which only a SET HOST 0/LOG succeeded; otherwise, all the output
	kept ending up at the terminal.]
The terminal has a number of standard names.  The most common are SYS$OUTPUT:
and TT:.  However, others are possible, including SYS$ERROR:, FOR006 in
FORTRAN programs, and many, many more.  Programs have been known to use
SYS$COMMAND and even SYS$INPUT - neither of which is a good idea if you expect
to do output, though they do work.  The problem you've got is to determine
which of the many different names ISSCO/DISSPLA has used.  You've already
eliminated a couple - FOR006, SYS$OUTPUT, and TT, for example.  However, there
are many others to try.  You might want to try overriding ALL the various SYS$
logicals that normally point to the terminal, just to determine quickly if any
of them is relevant.  Or, try stepping through your program with the debugger
- catch calls to REGIS, then step along until something interesting happens.
Alternatively, build as small an EXE file that does REGIS output as you can -
it need not work - and look at it with an editor - the file name strings are
in there SOMEWHERE.

All of this may fail.  The program could be using a GETJPI call to determine
its controlling terminal's name, then opening that terminal.  If so, you could
set up a translation for the actual terminal name - try both the virtual and
physical names (VTAnnn or TTcnnn).  Even that may fail if the subroutine does
the open with translation inhibited.  In that case, you may have no alterna-
tive but to use SET HOST 0.

Another thing to try:  Run the program in BATCH.  If it works, fine; other-
wise, the error messages you get may provide a clue.

							-- Jerry
-------