[Info-vax] disabling a CTRL/Y ast

[VAXman- at SendSpamHere.ORG]

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.