Discussion:
Keypad state in various VMS utilities
(too old to reply)
Chris Townley
2020-10-03 14:05:46 UTC
Permalink
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
2020-10-03 14:59:17 UTC
Permalink
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
2020-10-03 15:19:48 UTC
Permalink
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
2020-10-03 18:08:55 UTC
Permalink
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.
--
Pure Personal Opinion | HoffmanLabs LLC
Chris Townley
2020-10-03 18:53:54 UTC
Permalink
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
2020-10-03 19:37:29 UTC
Permalink
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)
2020-10-03 20:41:39 UTC
Permalink
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
2020-10-04 08:08:28 UTC
Permalink
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
2020-10-04 16:13:40 UTC
Permalink
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
2020-10-04 17:45:51 UTC
Permalink
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.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-10-04 21:08:19 UTC
Permalink
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
2020-10-05 00:34:27 UTC
Permalink
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
2020-10-05 16:13:49 UTC
Permalink
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
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-10-05 17:35:01 UTC
Permalink
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
2020-10-05 16:29:10 UTC
Permalink
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 ?
--
Marc Van Dyck
Jan-Erik Söderholm
2020-10-05 17:37:37 UTC
Permalink
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)
2020-10-05 20:34:11 UTC
Permalink
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.

Loading...