ZRPLIB3@DTUZDV5A.BITNET (Christoph D. Gatzka) (05/10/86)
I am interested in making a detached process appear to be an interactive process that is visible via $ show user. That process then should receive messages sent to him using sys$brkthru. Is that possible and has somebody already written a routine modifying it? And how, on the other hand can an interactive process be made detached, whereas in reality it is still connected to a terminal with a user? Christoph Gatzka <ZRPLIB3@DTUZDV5A> in Bitnet Zentrum fuer Datenverarbeitung Aussenstelle Morgenstelle Universitaet Tuebingen D - 7400 Tuebingen
LEICHTER-JERRY@YALE.ARPA (05/13/86)
I am interested in making a detached process appear to be an interactive
process that is visible via $ show user. That process then should receive
messages sent to him using sys$brkthru. Is that possible and has somebody
already written a routine modifying it?
And how, on the other hand can an interactive process be made detached,
whereas in reality it is still connected to a terminal with a user?
Christoph Gatzka <ZRPLIB3@DTUZDV5A> in Bitnet
First off, I don't understand what you mean by a "detached process". In VMS
usage, a detached process is one that is not a subprocess. When you log in,
your top level process is detached. You may be referring to a disconnected
process, but that doesn't make much sense either.
Disconnected processes show up on a SHOW USERS; they are still INTERACTIVE.
The property of being or not being INTERACTIVE is assigned at process creation
and can't be changed; it is not affected by disconnection. It would be
easy to write a kernel-mode program that plugged the appropriate bits in
the process header to change a non-INTERACTIVE program to INTERACTIVE, or
make other changes - but this seems both excessive and dangerous. Just what
is it you are trying to accomplish? It would be easier to write your own
SHOW USERS utility - it just uses GETJPI to find all the processes and ignores
those that aren't interactive.
As for receive broadcast/breakthru writes: Those are implemented in the
terminal driver. If the program isn't connected to a terminal, there is no
way for it to receive broadcast messages.
I don't understand what "detached whereas in reality it is still connected to
a terminal with a user" is supposed to mean.
-- Jerry
-------daemon@ucbvax.UUCP (05/14/86)
A detached process is the VMS equivalent of a UN*X "daemon", and is created by using the RUN command with either the /UIC or /DETACHED commands. Look in the DCL Dictionary under RUN (Process) on page DCL-493 in the v4.3 doc set. Hmm, I still don't know how to solve the original problem, though... --Bob Sutterfield OCES VAX System Manager IRCC Facilities Management The Ohio State University bob%osuag.uucp@ohio-state.arpa
eriks@yetti.UUCP (Eriks Rugelis) (05/23/86)
> I am interested in making a detached process appear to be an interactive > process that is visible via $ show user. That process then should receive > messages sent to him using sys$brkthru. Is that possible and has somebody > already written a routine modifying it? > And how, on the other hand can an interactive process be made detached, whereas > in reality it is still connected to a terminal with a user? > > Christoph Gatzka <ZRPLIB3@DTUZDV5A> in Bitnet here at york, we have been working on at least part of what you want... in our case, i need a process that is not attached to a physical terminal thus does not waste a terminal port but is still capable of responding in some intelligent fashion to broadcast messages we've been experimenting with kevin carosso's ptydriver (pseudo-terminal) with some success... we're just trying to get opcom to recognize a pty as a legitimate terminal so that we can trap and react to opcom messages it isn't working quite yet but i fully expect that it will in the very near future if you are interested in the final result send me mail and i'll send you a copy of the finished hack p.s. the ptydriver is a really neat piece of code and was submitted to at least two u.s. decus tapes.. it still works under vms 4.3.. take that as a good omen Voice: Eriks Rugelis Ma Bell: 416/736-5257 x.2688 Electronic: {allegra|decvax|ihnp4|linus}!utzoo!yetti!eriks.UUCP or eriks@yulibra.BITNET
jso@edison.UUCP.UUCP (05/23/86)
> First off, I don't understand what you mean by a "detached process". In VMS > usage, a detached process is one that is not a subprocess. When you log in, > your top level process is detached. You may be referring to a disconnected > process, but that doesn't make much sense either. Probably "Detached processes that are not interactive", i.e., those that are created by a RUN/misc-qualifiers. They certainly wouldn't return INTERACTIVE from f$mode; probably BATCH or OTHER.... > As for receive broadcast/breakthru writes: Those are implemented in the > terminal driver. If the program isn't connected to a terminal, there is no > way for it to receive broadcast messages. Exactly. Broadcast messages are sent to a terminal, not a process.... John Owens edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]