T.R | Title | User | Personal Name | Date | Lines |
---|
623.1 | May be worth a try | SQM::HALLYB | Khan or bust! | Mon Dec 07 1987 17:09 | 2 |
| Check the subprocess' PSL bits 24:25. If ^B10, then DCL.
(PSL is in PHD$L_PSL).
|
623.2 | Is there a less-priv'ed way? | 32288::MEAGHER | Too good to be true | Sun Dec 20 1987 16:32 | 4 |
| Thanks, but is there any way to do this without CMKRNL (or any other
god-like) privilege?
b
|
623.3 | | PSW::WINALSKI | Paul S. Winalski | Sun Dec 20 1987 16:51 | 9 |
| RE: .2
No, there is not.
Note also that the mode field in the PSL won't let you distinguish DCL trying
to read a command ("$" state) from DCL reading on behalf of a user command
procedure ("$ READ SYS$INPUT FOO", "$ INQUIRE").
--PSW
|
623.4 | Oh well... | 32288::MEAGHER | Too good to be true | Mon Dec 21 1987 07:09 | 12 |
| Well, thanks for trying...
I wonder how ALL-IN-1 is able to know when its subprocess is in a "$"
state, particularly when the user presses RETURN. At that point,
ALL-IN-1 assumes control of the terminal again. ALL-IN-1 does not, I
believe, need to be run with CMKRNL privilege. Does anyone know how
that mechanism works, offhand?
If not, I guess I'll post this question in the ALL-IN-1 notes file.
Or read the fiche, if I can get 'em.
b
|
623.5 | How its done... | CHOVAX::YOUNG | Back from the Shadows Again, | Mon Dec 21 1987 09:01 | 23 |
| Well as I recall from having written some ALL-IN-1 applications
during its V1 days, it does it pretty much the same way that the
infamous TELL.COM does it.
Both TELL and ALL-IN-1 take no chances when they do this, they use
a command procedure in the slave process to explicitly prompt for
input. Thus, ALL-IN-1 creates a subprocess with output, say,
A1_MBX_OUT, and input A1_MBX_IN, and error A1_MBX_ERR (I forget
how it actually goes so I am improvising). The first command it
puts in A1_MBX_IN is "@A1_SUB_CTRL.COM".
This subprocess would then do something like this:
$ LOOP:
$ Write sys$input "~WAITING FOR INPUT$"
$ Read sys$input COMMAND_STRING
$ COMMAND_STRING
$ goto LOOP
Whenever the Master process saw the string "~WAITING FOR INPUT$"
it knew that it could send another command.
-- Barry
|
623.6 | | PSW::WINALSKI | Paul S. Winalski | Tue Jan 05 1988 16:32 | 9 |
| RE: .5, .4
Yup, .5 has it more or less right. This is how SCOPE tool cooperation did it,
and how MMS does it, as well. You send a command down SYS$INPUT to the
subprocess that does a DCL WRITE of a known string to SYS$OUTPUT, then you
know that once you see your string back again, DCL is ready for another
command.
--PSW
|
623.7 | Thanx! | JENEVR::MEAGHER | Comfortably Numb | Wed Jan 06 1988 08:28 | 8 |
| Thanks, all.
I got spoiled early on by RSTS pseudo-keyboards, which could
tell the controlling program whether the process was in a system
command wait state. I was hoping for a similar or equivalent
mechanism to be hidden somewhere in VMS. Oh well...
bob
|
623.8 | | CHOVAX::YOUNG | Back from the Shadows Again, | Thu Jan 07 1988 23:32 | 6 |
| Re .7:
Yeah, Bob. That's what we get for leaving a sophisticated
Operating System like RSTS/E for something primitive like VMS.
-- Barry
|