[Info-vax] An old program I found, a hack allowing for using recall /input from within a login script

[Hans Bachner]

Stephen Tyree schrieb am 22.10.2021 um 00:26:
> On Thursday, October 21, 2021 at 5:35:44 PM UTC-4, Hans Bachner wrote:
>> Stephen Tyree schrieb am 21.10.2021 um 18:41:
>>> Folks,
>>>
>>> I was looking through some old code of mine, and I found a program I had written that allowed you to leverage recall/input from a login script... by way of mucking with the program's process level using executive mode privileges. See for yourself:
>>>
>>> https://pastebin.com/PTFseGkz
>>>
>>> You would compile it with an mmk file such as:
>>>
>>> !
>>> ! Flags for controlling compilation/linking
>>> !
>>> CXX = CXX
>>> CXXFLAGS = /model=ansi/reentrancy=multi/exceptions/standard=strict/switch="const_string_literals"-
>>> /nopure_cname/ansi_alias/assume=(stdnew,trusted_short_alignment,nopointers_to_globals)-
>>> /float=ieee/ieee_mode=fast/architecture=HOST/opt=(LEVEL=5,TUNE=HOST)-
>>> /pointer_size=64=argv/rtti/warn=(disable=(dollarid))
>>> LINK = LINK
>>> LINKFLAGS = /sysexe/notraceback
>>> OBJECTS = RECALL_INPUT.OBJ
>>>
>>> !
>>> ! One rule to rule them all
>>> !
>>> RECALL_INPUT.EXE : $(OBJECTS)
>>> $(LINK)/EXECUTABLE=$(MMS$TARGET) $(LINKFLAGS) $(MMS$SOURCE_LIST)
>>>
>>> ..CXX.OBJ
>>> $(CXX) $(MMS$SOURCE) $(CXXFLAGS)
>>>
>>> Then you need to install it with executive-mode privileges. BUT, if you did all of that, you could override the behavior of log*out to write out the recall buffer, change your login script to call this monstrosity of a program, and voila, your command history (well, about 50 commands worth at least) is saved across sessions.
>>>
>>> It worked very well for me (and some others at my company), but I take no responsibility for its behavior on your systems :). Enjoy!
>>>
>>> Thanks,
>>> Stephen Tyree
>> You did not explain what the program does - is it different from
>> RECALL/OUTPUT=xxx and RECALL/INPUT=xxx ?
>>
>> Hans.
> 
> Apologies if the program's function wasn't clear. If you try to run recall/input from any DCL script, such as your login script, recall exits with an error. The condition that leads to this error is recall explicitly checking the program's "process level", a value stored in a low-level process header that indicates essentially how many scripts/program "deep" you are, looking to see if recall is being run at the command-line (process level 0). This behavior is a nuisance, as it means you can't automatically pull in your command history within a login script, for instance.
> 
> This programs behavior is to defeat this check by mucking with the program's process level. A high-level summary of the program's function is:
> 
>   - Check to see if the file passed in exists, exiting with error if it doesn't.
>   - Setting the process level of the current process to 0, capturing the old process level
>   - Create an executive-mode logical of a specific name for reasons that may be clear eventually
>   - Run pipe recall/input=<the filename>;  mcr <this program> <the old process level>
> 
> Mucking with the process level makes it so recall/input happily runs without issue within a login script. However, if you don't set the process level back to its old value, DCL gets pretty unhappy. We tested this and observed that if the process level is left at 0, when the program exits, you're logged out of your shell (which makes a certain sort of sense). We also observed that if you call any other system call except lib$do_command, the process level is overwritten. So, we needed a way within lib$do_command to put the old process level back, which is where the pipe comes in. We execute recall/input, then we call this program again, passing in the old process level.. We detect this case and, if the executive-mode logical from earlier is set, we set the process level back to the old value, leaving the shell none the wiser. We added this executive level logical so that people could not run the program just to mess with the process level.
> 
> Hope that clears it up.

Sure, thanks for all the details! I use RECALL /INPUT occasionally, and 
always manually, so I wasn't aware of the limitation that the procedure 
depth needs to be 0.

Thanks & regards,
Hans.