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

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.

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.

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.

On 10/21/2021 11:41 AM, Stephen Tyree wrote:
> 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:
>

Nice. I had written a VAX PROFESSIONAL article about a MACRO program I
wrote to do that back in 1986.

https://hunter.goatley.com/wordpress/wp-admin/post.php?post=242&action=edit

I got out of the habit of using it and never modified it for use on
Alpha and I64.

Hunter

Den 2021-10-28 kl. 05:54, skrev Hunter Goatley:
> On 10/21/2021 11:41 AM, Stephen Tyree wrote:
>> 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:
>>
>
> Nice. I had written a VAX PROFESSIONAL article about a MACRO program I
> wrote to do that back in 1986.
>
> https://hunter.goatley.com/wordpress/wp-admin/post.php?post=242&action=edit
>
> I got out of the habit of using it and never modified it for use on Alpha
> and I64.
>
> Hunter

That link needed a login...

On 10/28/2021 3:27 AM, Jan-Erik Söderholm wrote:
> Den 2021-10-28 kl. 05:54, skrev Hunter Goatley:
>> On 10/21/2021 11:41 AM, Stephen Tyree wrote:
>>> 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:
>>>
>>
>> Nice. I had written a VAX PROFESSIONAL article about a MACRO program I wrote to do that back in 1986.
>>
>> https://hunter.goatley.com/wordpress/wp-admin/post.php?post=242&action=edit
>>
>> I got out of the habit of using it and never modified it for use on Alpha and I64.
>>
>> Hunter
>
> That link needed a login...

Click on the bottom link that says

← Go to Hunter Goatley

--

-- Rob

On Thursday, October 28, 2021 at 9:37:50 AM UTC-4, Robert A. Brooks wrote:
> On 10/28/2021 3:27 AM, Jan-Erik Söderholm wrote:
> > Den 2021-10-28 kl. 05:54, skrev Hunter Goatley:
> >> On 10/21/2021 11:41 AM, Stephen Tyree wrote:
> >>> 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:
> >>>
> >>
> >> Nice. I had written a VAX PROFESSIONAL article about a MACRO program I wrote to do that back in 1986.
> >>
> >> https://hunter.goatley.com/wordpress/wp-admin/post.php?post=242&action=edit
> >>
> >> I got out of the habit of using it and never modified it for use on Alpha and I64.
> >>
> >> Hunter
> >
> > That link needed a login...
> Click on the bottom link that says
>
>
> ← Go to Hunter Goatley
>
> --
>
> -- Rob

Found the specific article - https://hunter.goatley.com/vax-professional-articles/vax-pro-02/

Pretty neat! Your program takes the approach of modifying the command buffer directly, which seems to have some benefits. I'd always imagined someone having done something similar to this program in the past, and I shouldn't be surprised there's an example from decades back. Thanks for sharing.

On 10/28/2021 9:04 AM, Stephen Tyree wrote:
> On Thursday, October 28, 2021 at 9:37:50 AM UTC-4, Robert A. Brooks wrote:
>> On 10/28/2021 3:27 AM, Jan-Erik Söderholm wrote:
>>>
>>> That link needed a login...

Oops. I didn't realize I'd posted the edit link.

>> Click on the bottom link that says

Thanks, Rob.

> Found the specific article - https://hunter.goatley.com/vax-professional-articles/vax-pro-02/
>
> Pretty neat! Your program takes the approach of modifying the command buffer directly, which seems to have some benefits. I'd always imagined someone having done something similar to this program in the past, and I shouldn't be surprised there's an example from decades back. Thanks for sharing.
>

Thanks for checking it out! 8-)

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goathunter@goatley.com http://hunter.goatley.com/