[Info-vax] disabling a CTRL/Y ast
VAXman- at SendSpamHere.ORG
VAXman- at SendSpamHere.ORG
Fri Jan 8 10:30:58 EST 2016
In article <0b21c383-9454-4868-8a59-ca4db34feaf5 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
>On Friday, January 8, 2016 at 10:06:17 AM UTC-5, VAXman- wrote:
>> In article <81b88a19-35af-4ca5-83eb-3c795c01c219 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
>> >On Friday, January 8, 2016 at 9:42:40 AM UTC-5, VAXman- wrote:
>> >> In article <1467ade2-ca54-4282-adf6-685268571cbd at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
>> >> >On Thursday, January 7, 2016 at 11:21:27 AM UTC-5, VAXman- wrote:
>> >> >> In article <3a583568-e33e-446e-9805-6ea94f9ebf71 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
>> >> >> >On Wednesday, January 6, 2016 at 12:22:06 PM UTC-5, Stephen Hoffman wrote:
>> >> >> >> On 2016-01-06 16:46:32 +0000, Tom Adams said:
>> >> >> >>
>> >> >> >> > I want to turn ctrl/y into a noop in certain regions of code and turn
>> >> >> >> > ctrl/y into an exit in other regions of code.
>> >> >> >>
>> >> >> >> Some background: I've posted more than a few replies here in the
>> >> >> >> comp.os.vms newsgroup, specifically discussing the particular
>> >> >> >> application in question and its general design, and an unfortunate
>> >> >> >> aggregation of the UI and the more critical code paths, and your
>> >> >> >> understandable preference to avoid restructuring the application code
>> >> >> >> through reworking the existing design to block ^Y from arriving within
>> >> >> >> the most critical sections of the code.
>> >> >> >>
>> >> >> >> > I do find that it is necessary to run lib$disable_ctrl at the beginning
>> >> >> >> > of the program and lib$enable_ctrl at the end of the program to restore
>> >> >> >> > the previous CLI state, but I need to run asts to do the rest.
>> >> >> >>
>> >> >> >> If you want ASTs in some parts of the code and not in others, then
>> >> >> >> you're going to have to wrap those sections appropriately. That's if
>> >> >> >> you don't decide to migrate those critical code sections into another
>> >> >> >> process context, or related steps. Because beyond the potential for ^Y
>> >> >> >> in these sections and the associated issues you're having with the
>> >> >> >> image rundown processing in the absence of an EXIT command, other sorts
>> >> >> >> of generic application failures ("bugs") or any arriving $forcex calls
>> >> >> >> or such activities can potentially still leave the application in an
>> >> >> >> indeterminate state.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Pure Personal Opinion | HoffmanLabs LLC
>> >> >> >
>> >> >> >Here's an example of what I am trying to do that seems to work OK.
>> >> >> >I guess a forced exit from a bug could leave the CTRL\Y in
>> >> >> >the disabled state at the CLI instead of the original state.
>> >> >> >
>> >> >> >Also, it's possible that someone could define TT to be some terminal
>> >> >> >other than the login terminal. VMS leaves all the built-in process
>> >> >> >logicals that refer to the login terminal vulnerable to redefinition.
>> >> >> >It may be possible to roll your own safe (executive, no_alias) logical
>> >> >> >name via a call in syslogin.
>> >> >> >
>> >> >> >Also, I still need to cover the cases where this code runs in a context
>> >> >> >where TT is not defined.
>> >> >>
>> >> >> PROGRAM MY_TERMINAL
>> >> >> IMPLICIT NONE
>> >> >>
>> >> >> INCLUDE '($DSCDEF)'
>> >> >> INCLUDE '($JPIDEF)'
>> >> >> INCLUDE '(LIB$ROUTINES)'
>> >> >>
>> >> >> INTEGER*4 STATUS
>> >> >>
>> >> >> RECORD /DSCDEF1/ TERMINAL
>> >> >>
>> >> >> TERMINAL.DSC$W_MAXSTRLEN = 0
>> >> >> TERMINAL.DSC$B_DTYPE = DSC$K_DTYPE_T
>> >> >> TERMINAL.DSC$B_CLASS = DSC$K_CLASS_D
>> >> >> TERMINAL.DSC$A_POINTER = 0
>> >> >>
>> >> >> STATUS = LIB$GETJPI(JPI$_TERMINAL,,,,TERMINAL,)
>> >> >> IF (STATUS.AND.1) THEN
>> >> >> STATUS = LIB$PUT_OUTPUT(TERMINAL)
>> >> >> ENDIF
>> >> >>
>> >> >> CALL SYS$EXIT(%VAL(STATUS))
>> >> >> END
>> >> >>
>> >> >> --
>> >> >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
>> >> >>
>> >> >> I speak to machines with the voice of humanity.
>> >> >
>> >> >There is an issue.
>> >> >
>> >> >MY TERMINAL returns a blank string when you spawn it off the CLI:
>> >> >
>> >> >SPAWN RUN MY_TERMINAL
>> >>
>> >> No there's not. There's not terminal associated with the spawned subprocess;
>> >> there's a mailbox used instead.
>> >>
>> >>
>> >>
>> >> >But (oddly enough) the TT logical name is defined in that spawned interactive process. The process has TT, SYS$COMMAND and all that but no login terminal returned by GETJPI. And, it
>> >>
>> >> >
>> >> >This user interface program I am trying to improve gets used in all sort of processes: interactive processes, spawned interactive processes, batch jobs, detached processes, processes spawned by detached processes.
>> >> >
>> >> >I think the best thing to do is for the program use the special processing for CTRL/Y in all interactive processes.
>> >> >
>> >> >But, I cannot use the login terminal from GETJPI in a spawned interactive process.
>> >> >
>> >> >I can think of some options:
>> >> >
>> >> >1. use TT
>> >> >2. use TT with a "_" added to the front
>> >> >3. do not provide the special processing in detached interactive processes. Maybe just disable CTRL/Y in that case.
>> >> >
>> >> >BTW, when you hit CTRL/Y in an image in the spawned interactive process, it kills the process, it does not suspend the image. It acts differently from a normal interactive process.
>> >> >
>> >> >Is there some way to tell if you are in a spawned interactive process other than checking with GETJPI for the lack of a login terminal name?
>> >>
>> >> Do I need to write the whole program for you? :)
>> >
>> >A least the OS calls, apparently.
>> >
>> >>
>> >> I'd first determine of the process IS a subprocess. Then, find the master PID
>> >> of that process and pass it to the LIB$GETJPI as the second argument. That'll
>> >> get you the terminal from the master/parent process.
>> >>
>> >>
>> >> PROGRAM MY_TERMINAL
>> >> IMPLICIT NONE
>> >>
>> >> INCLUDE '($DSCDEF)'
>> >> INCLUDE '($JPIDEF)'
>> >> INCLUDE '($STSDEF)'
>> >> INCLUDE '(LIB$ROUTINES)'
>> >>
>> >> INTEGER*4 STATUS, MASTER_PID
>> >> RECORD /DSCDEF1/ TERMINAL
>> >>
>> >> TERMINAL.DSC$W_MAXSTRLEN = 0
>> >> TERMINAL.DSC$B_DTYPE = DSC$K_DTYPE_T
>> >> TERMINAL.DSC$B_CLASS = DSC$K_CLASS_D
>> >> TERMINAL.DSC$A_POINTER = 0
>> >>
>> >> STATUS = LIB$GETJPI(JPI$_MASTER_PID,,,MASTER_PID,,)
>> >> IF (STATUS.AND.STS$M_SUCCESS) THEN
>> >> STATUS = LIB$GETJPI(JPI$_TT_PHYDEVNAM,MASTER_PID,,,TERMINAL,)
>> >> IF (STATUS.AND.STS$M_SUCCESS) THEN
>> >> STATUS = LIB$PUT_OUTPUT(TERMINAL)
>> >> ENDIF
>> >> ENDIF
>> >>
>> >> CALL SYS$EXIT(%VAL(STATUS))
>> >> END
>> >>
>> >> --
>> >
>> >That one even works for:
>> >
>> >SPAWN SPAWN SPAWN SPAWN RUN MY_TERMINAL
>>
>> Yup.
>>
>> For shits and giggles, I added the '_' for you too so that $ASSIGN will be
>> able to assign a channel even if there's some strange logical definiiton in
>> the process that looks like the terminal's name.
>>
>> PROGRAM MY_TERMINAL
>> IMPLICIT NONE
>>
>> INCLUDE '($DSCDEF)'
>> INCLUDE '($JPIDEF)'
>> INCLUDE '($STSDEF)'
>> INCLUDE '(LIB$ROUTINES)'
>> INCLUDE '(STR$ROUTINES)'
>>
>> INTEGER*4 STATUS, MASTER_PID
>> RECORD /DSCDEF1/ TERMINAL
>>
>> TERMINAL.DSC$W_MAXSTRLEN = 0
>> TERMINAL.DSC$B_DTYPE = DSC$K_DTYPE_T
>> TERMINAL.DSC$B_CLASS = DSC$K_CLASS_D
>> TERMINAL.DSC$A_POINTER = 0
>>
>> STATUS = LIB$GETJPI(JPI$_MASTER_PID,,,MASTER_PID,,)
>> IF (STATUS.AND.STS$M_SUCCESS) THEN
>> STATUS = LIB$GETJPI(JPI$_TT_PHYDEVNAM,MASTER_PID,,,TERMINAL,)
>> IF (STATUS.AND.STS$M_SUCCESS) THEN
>> STATUS = STR$PREFIX(TERMINAL,%DESCR('_'))
>> IF (STATUS.AND.STS$M_SUCCESS) THEN
>> STATUS = LIB$PUT_OUTPUT(TERMINAL)
>> ENDIF
>> ENDIF
>> ENDIF
>>
>> CALL SYS$EXIT(%VAL(STATUS))
>> END
>>
>> This has been fun. I haven't written much FORTRAN since my days as the chief
>> simulation guru on the Navy's HITS DATPG project at the NAEC (Naval Engineer-
>> ing Center) in Lakehurst. The only other major FORTRAN was a project called
>> EGRESS for the laboratory access control at the Myers Center (the HEXAGON) at
>> Ft. Monmouth -- now RIF to oblivion and up for sale.
>>
>> --
>
>The physical login terminal name already has a "_" at the front. So you are adding another "_".
>
>I found that one "_" is sufficient to keep SYS$ASSIGN from trying to translate
>the name.
>
>I don't think that extra "_" adds any robustness, but maybe you know of a test case that I did not try.
You're using JPI$_TT_PHYDEVNAM? In that case, no you don't need the '_'.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
More information about the Info-vax
mailing list