Keypad state in various VMS utilities

[Chris Townley]

An old issue, but coming back to VMS I find it strange that many VMS utilities seem to silently switch on the application keypad, seemingly to no effect other than making numeric entry more error prone.

Any ideas why, or how to prevent it?


Chris

[Michael Moroney]

Post by Chris Townley
An old issue, but coming back to VMS I find it strange that many VMS utilities seem to silently switch on the application keypad, seemingly to no effect other than making numeric entry more error prone.
Any ideas why, or how to prevent it?

The PROPER behavior of any VMS utility which messes with any terminal state, including
keypad state is:

1) Save the terminal state ($SENSEMODE) and save it away.
2) Change the terminal state the way the program wishes.
3) Upon exit, set the terminal back as found in 1). Ideally with an exit handler,
so that the terminal isn't left in a funky state if the user ^Ys the program.
4) Some states, including the terminal's keypad mode are maintained separately
by VMS and the terminal (emulator) itself. Appropriate escape sequences need
to be sent to the terminal to set them back correctly.

A $ SET TERMINAL/INQUIRE usually sets the out-of-synch things back.

[Chris Townley]

Post by Michael Moroney

Post by Chris Townley
An old issue, but coming back to VMS I find it strange that many VMS utilities seem to silently switch on the application keypad, seemingly to no effect other than making numeric entry more error prone.
Any ideas why, or how to prevent it?

The PROPER behavior of any VMS utility which messes with any terminal state, including
1) Save the terminal state ($SENSEMODE) and save it away.
2) Change the terminal state the way the program wishes.
3) Upon exit, set the terminal back as found in 1). Ideally with an exit handler,
so that the terminal isn't left in a funky state if the user ^Ys the program.
4) Some states, including the terminal's keypad mode are maintained separately
by VMS and the terminal (emulator) itself. Appropriate escape sequences need
to be sent to the terminal to set them back correctly.
A $ SET TERMINAL/INQUIRE usually sets the out-of-synch things back.

I am not saying they are no resetting it, but for example in the authorize utility, what use are they making of the application keyboard?

Many other examples

Chris

[Stephen Hoffman]

Post by Chris Townley
An old issue, but coming back to VMS I find it strange that many VMS
utilities seem to silently switch on the application keypad, seemingly
to no effect other than making numeric entry more error prone.
Any ideas why, or how to prevent it?

I suspect that is an artifact of the use of SMG within AUTHORIZE and
other tools.
This SMG usage likely for command-line recall within the prompting.
SMG being old and crufty, but still eminently preferable to using $qio
calls for any of this.

[Chris Townley]

Post by Stephen Hoffman

Post by Chris Townley
An old issue, but coming back to VMS I find it strange that many VMS
utilities seem to silently switch on the application keypad, seemingly
to no effect other than making numeric entry more error prone.
Any ideas why, or how to prevent it?

I suspect that is an artifact of the use of SMG within AUTHORIZE and
other tools.
This SMG usage likely for command-line recall within the prompting.
SMG being old and crufty, but still eminently preferable to using $qio
calls for any of this.

That would make sense. So presumably no easy way to override...

Chris

[David Jones]

Post by Stephen Hoffman
I suspect that is an artifact of the use of SMG within AUTHORIZE and
other tools.
This SMG usage likely for command-line recall within the prompting.
SMG being old and crufty, but still eminently preferable to using $qio
calls for any of this.

I use SMG all the time solely for its virtual keyboard recall buffer feature. I never
see the keypad being put in application mode unless I create a key table and
include it as an argument in the read call. I rarely find it worth the trouble to define
application keypad keys in command line interfaces (as opposed to screen oriented
interfaces). Apparently the coder, back in 1987, thought that it would be 'cleaner'
to supply a keytable to SMG$READ_COMPOSED_LINE() than specify a null
pointer.

[Phillip Helbig (undress to reply)]

Post by David Jones
I use SMG all the time solely for its virtual keyboard recall buffer
feature. I never see the keypad being put in application mode unless I
create a key table and include it as an argument in the read call. I
rarely find it worth the trouble to define application keypad keys in
command line interfaces (as opposed to screen oriented interfaces).

I use the keypad in EDT (OK, screen oriented), MAIL and NEWSRDR (in
addition to the EDT keypad when using EDT within those applications),
which I guess are command-line interfaces, probabably several hours a
day (and, occasionally, the debugger as well) and have been doing so for
more than a quarter of a century, which means that I have saved a huge
amount of time thanks to the application keypad, and why a real VMS
keyboard is a necessity for me. Of course, people who never learned to
type blindly with ten fingers have probably wasted so many years of
their life already that the relative benefit from a keypad (which should
also be used with, if not 10, then 5 fingers, and blindly) is probably
minimal.

[Jan-Erik Söderholm]

Post by Phillip Helbig (undress to reply)

Post by David Jones
I use SMG all the time solely for its virtual keyboard recall buffer
feature. I never see the keypad being put in application mode unless I
create a key table and include it as an argument in the read call. I
rarely find it worth the trouble to define application keypad keys in
command line interfaces (as opposed to screen oriented interfaces).

I use the keypad in EDT (OK, screen oriented), MAIL and NEWSRDR (in
addition to the EDT keypad when using EDT within those applications),
which I guess are command-line interfaces, probabably several hours a
day (and, occasionally, the debugger as well) and have been doing so for
more than a quarter of a century, which means that I have saved a huge
amount of time thanks to the application keypad, and why a real VMS
keyboard is a necessity for me. Of course, people who never learned to
type blindly with ten fingers have probably wasted so many years of
their life already that the relative benefit from a keypad (which should
also be used with, if not 10, then 5 fingers, and blindly) is probably
minimal.

I have used the PC numeric keypad for so long with EDT that I'd probably
miss some strokes if presented with "real" (whatever that is today!)
"VMS keyboard". I find it better to simply learn to use whatever there
is available today. And so I did 25+ years ago.

Anyway, when I have used EDT and then switch back to som PC application,
I usually have to press "NumLock" to get the digits back on the keypad.
I'm not sure if that this is a similar issue that is described here...

[David Jones]

Post by Jan-Erik Söderholm
Anyway, when I have used EDT and then switch back to som PC application,
I usually have to press "NumLock" to get the digits back on the keypad.
I'm not sure if that this is a similar issue that is described here...

If you "set host 0/log" to your system and run authorize, when you logout the
resulting sethost.log shows that that program sends <esc>= to the terminal to
explicitly put the keypad into application mode. At program exit, authorize
sends <esc>< to revert to numeric keypad mode. You have to dump/record
the log file see in binary all of the characters being output (excluding carriage
control implied by the carriage control argument).

[Stephen Hoffman]

Post by Jan-Erik Söderholm
Anyway, when I have used EDT and then switch back to som PC
application, I usually have to press "NumLock" to get the digits back
on the keypad. I'm not sure if that this is a similar issue that is
described here...

That would appear to be a bug in the terminal emulator app, or a bug in
the host operating system app switching.
That the emulator app did not restore the keyboard state at
loss-of-keyboard-focus. Or the operating system.
EDT cannot change the Microsoft Windows keyboard state, as EDT knows
nothing of managing Windows keyboards when a Windows app loses focus.
That keyboard transition is necessarily performed by the emulator app.
Not by any app operating within the terminal emulator session, EDT or
otherwise.
Or that keyboard transition is probably best performed by the operating system.
Another Windows app mucking with keyboard state would react similarly,
if that Windows app didn't restore keyboard state at
loss-of-keyboard-focus.
Restoring keyboard state at loss-of-focus does not seem to be performed
by Microsoft Windows, which is mildly surprising.

[Jan-Erik Söderholm]

Post by Jan-Erik Söderholm
Anyway, when I have used EDT and then switch back to som PC application,
I usually have to press "NumLock" to get the digits back on the keypad.
I'm not sure if that this is a similar issue that is described here...

That would appear to be a bug in the terminal emulator app, or a bug in the
host operating system app switching.
That the emulator app did not restore the keyboard state at
loss-of-keyboard-focus. Or the operating system.
EDT cannot change the Microsoft Windows keyboard state, as EDT knows
nothing of managing Windows keyboards when a Windows app loses focus.
That keyboard transition is necessarily performed by the emulator app.
Not by any app operating within the terminal emulator session, EDT or
otherwise.
Or that keyboard transition is probably best performed by the operating system.
Another Windows app mucking with keyboard state would react similarly, if
that Windows app didn't restore keyboard state at loss-of-keyboard-focus.
Restoring keyboard state at loss-of-focus does not seem to be performed by
Microsoft Windows, which is mildly surprising.

Yes, I thought that it was emulator related. And sorry, I forgot the envir.

Win10 using Putty in a remote Citrix "remote desktop", if it matters.

Probably not the same issue that was mentioned here...
And it is a very minor issue.

[Chris Townley]

Post by Jan-Erik Söderholm

Post by Jan-Erik Söderholm
Anyway, when I have used EDT and then switch back to som PC application,
I usually have to press "NumLock" to get the digits back on the keypad.
I'm not sure if that this is a similar issue that is described here...

That would appear to be a bug in the terminal emulator app, or a bug in the
host operating system app switching.
That the emulator app did not restore the keyboard state at
loss-of-keyboard-focus. Or the operating system.
EDT cannot change the Microsoft Windows keyboard state, as EDT knows
nothing of managing Windows keyboards when a Windows app loses focus.
That keyboard transition is necessarily performed by the emulator app.
Not by any app operating within the terminal emulator session, EDT or
otherwise.
Or that keyboard transition is probably best performed by the operating system.
Another Windows app mucking with keyboard state would react similarly, if
that Windows app didn't restore keyboard state at loss-of-keyboard-focus.
Restoring keyboard state at loss-of-focus does not seem to be performed by
Microsoft Windows, which is mildly surprising.

Yes, I thought that it was emulator related. And sorry, I forgot the envir.
Win10 using Putty in a remote Citrix "remote desktop", if it matters.
Probably not the same issue that was mentioned here...
And it is a very minor issue.

But annoying. I have for years got fed up with PuTTY leaving the NumLock in a confused state. Otherwise a fine program IMHO

Chris

[Stephen Hoffman]

Post by Jan-Erik Söderholm
Yes, I thought that it was emulator related. And sorry, I forgot the envir.
Win10 using Putty in a remote Citrix "remote desktop", if it matters.

Tried the new-ish Microsoft Windows Terminal, as an alternative?

https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701

https://github.com/Microsoft/Terminal

[Jan-Erik Söderholm]

Post by Stephen Hoffman

Post by Jan-Erik Söderholm
Yes, I thought that it was emulator related. And sorry, I forgot the envir.
Win10 using Putty in a remote Citrix "remote desktop", if it matters.

Tried the new-ish Microsoft Windows Terminal, as an alternative?
https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701
https://github.com/Microsoft/Terminal

Not yet, but could be an alternative. Even better if it proves to be
an alternative to the "MicroFocus Extra!" emulator (formally Attachmate).

The requirement is that it should run in a Citrix environment and that
it should open a telnet session to our VMS boxes directly from the menu
without any other steps in between.

I have problems testing it since the Citrix remote desktop I have at the
moment is under a hard lockdown, can't even run a Command prompt...

[Marc Van Dyck]

Post by Phillip Helbig (undress to reply)

Post by David Jones
I use SMG all the time solely for its virtual keyboard recall buffer
feature. I never see the keypad being put in application mode unless I
create a key table and include it as an argument in the read call. I
rarely find it worth the trouble to define application keypad keys in
command line interfaces (as opposed to screen oriented interfaces).

I use the keypad in EDT (OK, screen oriented), MAIL and NEWSRDR (in
addition to the EDT keypad when using EDT within those applications),
which I guess are command-line interfaces, probabably several hours a
day (and, occasionally, the debugger as well) and have been doing so for
more than a quarter of a century, which means that I have saved a huge
amount of time thanks to the application keypad, and why a real VMS
keyboard is a necessity for me. Of course, people who never learned to
type blindly with ten fingers have probably wasted so many years of
their life already that the relative benefit from a keypad (which should
also be used with, if not 10, then 5 fingers, and blindly) is probably
minimal.

So, nobody else than me is using the DEFINE/KEy feature in DCL to map
their most often used DCL commands to keypad keys ?

[Jan-Erik Söderholm]

Post by Marc Van Dyck

Post by Phillip Helbig (undress to reply)

Post by David Jones
I use SMG all the time solely for its virtual keyboard recall buffer
feature. I never see the keypad being put in application mode unless I
create a key table and include it as an argument in the read call. I
rarely find it worth the trouble to define application keypad keys in
command line interfaces (as opposed to screen oriented interfaces).

I use the keypad in EDT (OK, screen oriented), MAIL and NEWSRDR (in
addition to the EDT keypad when using EDT within those applications),
which I guess are command-line interfaces, probabably several hours a
day (and, occasionally, the debugger as well) and have been doing so for
more than a quarter of a century, which means that I have saved a huge
amount of time thanks to the application keypad, and why a real VMS
keyboard is a necessity for me.  Of course, people who never learned to
type blindly with ten fingers have probably wasted so many years of
their life already that the relative benefit from a keypad (which should
also be used with, if not 10, then 5 fingers, and blindly) is probably
minimal.

So, nobody else than me is using the DEFINE/KEy feature in DCL to map
their most often used DCL commands to keypad keys ?

I define symbols. Generally speaking, when I had multiple VMS customers,
I got the habit of defining/expecting as little as possible. Only used
the built in VMS features and command as-is. That way I did not depend
on anything being setup in special ways.

[Phillip Helbig (undress to reply)]

Post by Marc Van Dyck
So, nobody else than me is using the DEFINE/KEy feature in DCL to map
their most often used DCL commands to keypad keys ?

I did that a long time ago, but found that it didn't save much time,
perhaps because I can type quickly but also because the most common
commands change depending on what I am doing. By far the most time is
spent in EDT. I have almost all keys defined there, including ones
preceded by GOLD or used simultaneously with CONTROL. Also in MAIL and
NEWSRDR I've defined many additional keys.