PC/VT Keyboarrd Mapping

[Paul Richards]

I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.

Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?

I don't have a numeric keypad on my laptop but I have function keys F1
- F12 and the usual QWERTY keyboard.

I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.

Thanks

[Jan-Erik Soderholm]

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.
Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop...

And there is your problem. Get yourself a new laptop. In these
days, a laptop with numaric keypad has become standard and you
pay extra for the smaller/lighter models, not the other way
around as it was some years ago.

Post by Paul Richards
but I have function keys F1
- F12 and the usual QWERTY keyboard.
I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.
Thanks

[Jim]

Post by Jan-Erik Soderholm

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.
Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop...

And there is your problem. Get yourself a new laptop. In these
days, a laptop with numaric keypad has become standard and you
pay extra for the smaller/lighter models, not the other way
around as it was some years ago.

Post by Paul Richards
but I have function keys F1
- F12 and the usual QWERTY keyboard.
I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.
Thanks

Or maybe add a USB keyboard with a numeric keypad (if mobility is not an issue).

[Stephen Hoffman]

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.0
Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop but I have function keys F1
- F12 and the usual QWERTY keyboard.

Check the PuTTY docs to see how they map the keypad keys, in the
absence of a numeric keypad.

http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter4.html#4.4.3

Using a keyboard without a numeric keypad is going to mean figuring out
how to use the tools without needing the keypad, or figuring out which
chord the keyboard uses to generate the particular keypress, or getting
an add-on numeric keypad that the emulator supports. That's (usually)
in the editor documentation. Sometimes the box — and it's been a
~decade since I've particularly used a Windows box — has a way to
enable the keypad within the keyboard. Windows from an aeon or two ago
used NUMLOCK or shift-NUMLOCK for that embedded keypad, IIRC.

Post by Paul Richards
I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.

Search the comp.os.vms archives for key mapping discussions and
terminal emulator discussions — there are quite a few of these over the
years.

https://groups.google.com/d/msg/comp.os.vms/9DIFTtYLpn0/elmyIr62NwAJ
https://groups.google.com/d/msg/comp.os.vms/HtUX-GuyqbM/0NOjo9V9yTkJ
https://groups.google.com/d/msg/comp.os.vms/pUQW5AJbEh0/FPZSoo9vEQIJ

[Paul Sture]

<snip>

Windows from an aeon or two ago used NUMLOCK or shift-NUMLOCK for
that embedded keypad, IIRC.

FWIW I have used the equivalent on an OS X laptop to jump back and forth
and use the 'numeric keypad' overlay on the keyboard.

Not the most satisfying of experiences but it did do the job.

A useful workaround for TPU is to define ctrl-D as Do and ctrl-F as
Find. You can still do stuff if you find yourself without the
application keypad, albeit slowly.

Here is my EVE$INIT file (I picked ctrl-D and CTRL-F not only because
they provide something easy to remember but because they are not
used by default by either EVE or DCL command line editing):

$ type eve$init
DEFINE KEY=CONTROL-D DO
DEFINE KEY=CONTROL-F FIND

and the login.com entry to enable it:

$ define eve$init sys$login:eveini.eve


EDT in line mode is also useful, and of course once you are up and
running to the point where you can install Vim, you need neither the
numeric keypad nor function keys.

[Paul Richards]

Post by Stephen Hoffman

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it
easy to use VMS software like editors, e.g. EDT, as the keycodes
emitted do not match up with those expected from a VT100/200 etc.0
Is there a way of somehow mapping the PC keyboard so that the
keycodes emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop but I have function keys
F1 - F12 and the usual QWERTY keyboard.

Check the PuTTY docs to see how they map the keypad keys, in the
absence of a numeric keypad.
http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter4.html#4.4.3
Using a keyboard without a numeric keypad is going to mean figuring
out how to use the tools without needing the keypad, or figuring out
which chord the keyboard uses to generate the particular keypress, or
getting an add-on numeric keypad that the emulator supports. That's
(usually) in the editor documentation. Sometimes the box — and it's
been a ~decade since I've particularly used a Windows box — has a way
to enable the keypad within the keyboard. Windows from an aeon or
two ago used NUMLOCK or shift-NUMLOCK for that embedded keypad, IIRC.

Post by Paul Richards
I'm not sure if this a VT question or a PuTTY question. If the
latter I'd appreciate any links to possible solutions.

Search the comp.os.vms archives for key mapping discussions and
terminal emulator discussions — there are quite a few of these over
the years.
https://groups.google.com/d/msg/comp.os.vms/9DIFTtYLpn0/elmyIr62NwAJ
https://groups.google.com/d/msg/comp.os.vms/HtUX-GuyqbM/0NOjo9V9yTkJ
https://groups.google.com/d/msg/comp.os.vms/pUQW5AJbEh0/FPZSoo9vEQIJ

Steven (and others): I have found another laptop which has a numeric
keypad. I've copied over FreeAXP/OpenVMS and certainly the F1 - F10
keys now work as expected with, say, VTFM.

It seems that, depending on whether NUM-LOCK is on or off, certain keys
e.g./, *, -, emit different responses.

[David Froble]

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.
Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop but I have function keys F1
- F12 and the usual QWERTY keyboard.
I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.
Thanks

I'm just sooo happy with the LK411-AA keyboard I'm using, and it's going to be a
dark day if it ever quite working ....

[Jan-Erik Soderholm]

Post by David Froble

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.
Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop but I have function keys F1
- F12 and the usual QWERTY keyboard.
I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.
Thanks

I'm just sooo happy with the LK411-AA keyboard I'm using, and it's going to
be a dark day if it ever quite working ....

Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

[David Froble]

Post by Jan-Erik Soderholm

Post by David Froble

Post by Paul Richards
I'm running OpenVMS on the FreeAXP emulator with PuTTY, which is
bundled with FreeAXP.Unfortunately my PC keyboard does not make it easy
to use VMS software like editors, e.g. EDT, as the keycodes emitted do
not match up with those expected from a VT100/200 etc.
Is there a way of somehow mapping the PC keyboard so that the keycodes
emitted match up with those of the VT100/200?
I don't have a numeric keypad on my laptop but I have function keys F1
- F12 and the usual QWERTY keyboard.
I'm not sure if this a VT question or a PuTTY question. If the latter
I'd appreciate any links to possible solutions.
Thanks

I'm just sooo happy with the LK411-AA keyboard I'm using, and it's going to
be a dark day if it ever quite working ....

Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

So, when the Fred Flintstone cars come out, you're going to give up your current
car?

Better, yes.

Backward, NO!

[Stephen Hoffman]

Post by David Froble

Post by Jan-Erik Soderholm
Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

So, when the Fred Flintstone cars come out, you're going to give up
your current car?
Better, yes.
Backward, NO!

VSI has a choice to make. Adopt the PC keyboard in OpenVMS software
and RTLs and in the documentation, adopt some other keyboard such as
the Apple extended wired, or get into the traditional LK keyboard
manufacturing business directly or with Nemonix or some other vendor.
Or continue to ignore the keyboard difficulties and presume that the
VT/LK keyboard interface is an emulator problem, which has been the
keyboard strategy for a while. But those existing LK keyboards are all
aging out. That's even if VSI's statements against plans for OpenVMS
workstation support hold, as you'll still need console or iLO or DRAC
keyboard access for the baseline configuration and then for server
management operations, as OpenVMS can't (yet?) be remotely managed,
provisioned and deployed.

[Bob Koehler]

Post by Stephen Hoffman
VSI has a choice to make. Adopt the PC keyboard in OpenVMS software
and RTLs and in the documentation, adopt some other keyboard such as
the Apple extended wired, or get into the traditional LK keyboard
manufacturing business directly or with Nemonix or some other vendor.
Or continue to ignore the keyboard difficulties and presume that the
VT/LK keyboard interface is an emulator problem, which has been the
keyboard strategy for a while. But those existing LK keyboards are all
aging out. That's even if VSI's statements against plans for OpenVMS
workstation support hold, as you'll still need console or iLO or DRAC
keyboard access for the baseline configuration and then for server
management operations, as OpenVMS can't (yet?) be remotely managed,
provisioned and deployed.

I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly. TPU's
predefined keyboards should also have that variation.

But I mean full PC keyboards, with all 3 keypads. Anyone who wants
to live without the other keypads can run vi and gdb, for all I care.

[l***@gmail.com]

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

EDT is another tool that needs to die.

In my RSTS/E days, we used a TECO-based screen editor called VTED (a local adaptation of some code originally from DECUS or somewhere). Unfortunately that was never ported to the VAX. So I gritted my teeth and put up with EDT for whatever far-too-long fraction of my lifetime it was until TPU came along, which was halfway decent in comparison (even with that weird initial (mis)behaviour with search pattern matches).

Nowadays of course I use Emacs. Is Emacs available for VMS? That has to be a big improvement to whatever DEC-originated editor you might be using now.

[John Reagan]

Post by l***@gmail.com

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

EDT is another tool that needs to die.
In my RSTS/E days, we used a TECO-based screen editor called VTED (a local adaptation of some code originally from DECUS or somewhere). Unfortunately that was never ported to the VAX. So I gritted my teeth and put up with EDT for whatever far-too-long fraction of my lifetime it was until TPU came along, which was halfway decent in comparison (even with that weird initial (mis)behaviour with search pattern matches).
Nowadays of course I use Emacs. Is Emacs available for VMS? That has to be a big improvement to whatever DEC-originated editor you might be using now.

There is at least two different Emacs for OpenVMS. That is what I use as a daily editor. Works great using PuTTY via my Windows 7 box.

[hb]

Post by John Reagan

Post by l***@gmail.com
Nowadays of course I use Emacs. Is Emacs available for VMS? That
has to be a big improvement to whatever DEC-originated editor you
might be using now.

There is at least two different Emacs for OpenVMS. That is what I
use as a daily editor. Works great using PuTTY via my Windows 7
box.

I don't know about these two different versions John is referring to.
The support for VMS was removed in Emacs 23. There are sources which
claim to be version 21.2, which I didn't find in any source repository.
These sources are on the VMS freeware CD V8.0. They should build and
work on Alpha. In the same directory there are source code changes for
that version which make it build and run on I64. In
https://groups.google.com/forum/#!topic/comp.os.vms/DGISjZP4fUs%5B151-175%5D
there is a pointer to changes for VAX.

Then there is microemacs (uemacs or µemacs) which should build and run
on VMS. I haven't tried it for a long time. I don't know what the
current version is. There was at least the popular version 3.12 for
which you can find executables for VAX and Alpha. It's not obvious to me
whether microemacs is still maintained.

Then there is jed, which comes with a emacs and EDT mode
(http://www.jedsoft.org/jed/). Current version is 0.99-19 It should
build on Alpha and I64. It is still maintained. There are executables of
an older version (0.99-17) on the VMS freeware CD V7.0 (the version on
V8.0 is even older).

[John Reagan]

Post by hb

Post by John Reagan

Post by l***@gmail.com
Nowadays of course I use Emacs. Is Emacs available for VMS? That
has to be a big improvement to whatever DEC-originated editor you
might be using now.

There is at least two different Emacs for OpenVMS. That is what I
use as a daily editor. Works great using PuTTY via my Windows 7
box.

I don't know about these two different versions John is referring to.
The support for VMS was removed in Emacs 23. There are sources which
claim to be version 21.2, which I didn't find in any source repository.
These sources are on the VMS freeware CD V8.0. They should build and
work on Alpha. In the same directory there are source code changes for
that version which make it build and run on I64. In
https://groups.google.com/forum/#!topic/comp.os.vms/DGISjZP4fUs%5B151-175%5D
there is a pointer to changes for VAX.

That the one I use. 21.2. I didn't mean to imply current support but that you can get a somewhat recent version of Emacs. I probably can use it for another 50 years before I'd learn enough Emacs to tell the difference between 21.2 and the latest version.

Doug G uses the older DEC Emacs, not sure of the heritage of that one.

[David Froble]

Post by l***@gmail.com

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

EDT is another tool that needs to die.
In my RSTS/E days, we used a TECO-based screen editor called VTED (a local adaptation of some code originally from DECUS or somewhere). Unfortunately that was never ported to the VAX. So I gritted my teeth and put up with EDT for whatever far-too-long fraction of my lifetime it was until TPU came along, which was halfway decent in comparison (even with that weird initial (mis)behaviour with search pattern matches).
Nowadays of course I use Emacs. Is Emacs available for VMS? That has to be a big improvement to whatever DEC-originated editor you might be using now.

Why is it that whatever you use is great ... and whatever I use should die?

[Stephen Hoffman]

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are no new LK keyboards. There are fewer keyboards with keypads, too.

Unfortunately what you're using — the keypad-based application and
keypad-based editors — is dying out, David. (I too became quite fond
of keypad tools, but then the GUI won for most folks and most users,
and the command-line tools went to the subset keyboard or — for those
that really needed it — to the PC-compatible keyboard.) The
added-function-button PC keyboards are becoming scarce, too.

But if you're using EDT now and are not likely to migrate to a
keyboard-based editor, try LSEDIT. It has the same EDT keypad, it's
much faster than EDT, and COMPILE /REVIEW is well worth the effort of
the migration from EDT. The pattern searches are very handy, too.
Yes, the LSEDIT command line is different. LSEDIT can be run without
the keypad, as can EDT. But I find the LSEDIT command line easier to
deal with.

Downside: EDT, LSEDIT and EVE/TPU are OpenVMS-specific, and don't exist
on other platforms. (Yes, you can find some open source for EDT, but
then you're back in the keypad quagmire.)

Among the more common text editors... Learning vim or emacs here will
take many years to retrain your fingers and to learn the new commands.
The usual analog to EDT on other systems is the pico / nano
editor, and that's keyboard based. No keypad is required. But that's
where the command line is headed. For application development, the GUI
and IDEs are what most folks are increasingly using. The available
IDEs on other platforms well past what LSEDIT can provide, and
massively far past the edit-compile-link sequence common on OpenVMS.

But for OpenVMS software and tools — whether you're at VSI or an
end-user, and whether the software is OpenVMS itself or some
application package — the DEC VT LK-series keyboard is no longer
manufactured. If that doesn't provide a convincing argument around
where hardware and dependent software is inevitably headed, I'm not
sure what will. Even if the LK production starts up again, that still
adds hardware dependencies for all of the users involved in the
LK-dependent project.

OpenVMS apps either need to forget about the VMS-layout LK and/or
provide an alternative to the keypad, or somebody start up LK
production. And then sell enough of those new LK keyboards to matter,
and that seems unlikely to succeed given pricing and commoditization.

[Jan-Erik Soderholm]

Post by Stephen Hoffman

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are fewer keyboards with keypads, too.

It's not what I'm seeing. Many new "professional" laptops has
larger screens today, and it seems as the manfacturers just as
well put in a real keyboard with numeric kaypad also.

And besides, even if you have an laptop, most professionals will
hook up an external keyboard and screen anyway.

Post by Stephen Hoffman
Unfortunately what you're using — the keypad-based application...

You've got to keep applications apart from the editing.
I use EDT to edit our web based "GUI" applications.

Post by Stephen Hoffman
and keypad-based editors — is dying out...

EDT isn't "dying". Or, it is dying at the same pace as VMS is.

Post by Stephen Hoffman
OpenVMS apps either need to forget about the VMS-layout LK and/or provide
an alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few small
differences that should be easy to learn for any IT professional.

Or are you now talking about the end-user applications? Yes, they should
not be depending on VT-style kayboards and keys, and they will probably
mostly be based on web interfaces, so it is a non-issue. I do not see
a huge volume of newly written VT-based applications today.

But that is something completely different then me using EDT.

[Stephen Hoffman]

Post by Stephen Hoffman

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are fewer keyboards with keypads, too.

It's not what I'm seeing. Many new "professional" laptops has larger
screens today, and it seems as the manfacturers just as well put in a
real keyboard with numeric kaypad also.

Big and heavy laptops, sure. Some folks have called those
battleship-class. For the folks that are unable or unwilling to carry
around the extra weight that's typically associated with those laptops,
a different approach for applications is warranted.

And besides, even if you have an laptop, most professionals will hook
up an external keyboard and screen anyway.

Yes, many will. For those using OpenVMS, ponder why that might be the
case. The laptop keyboard might be cramped or might just be a bad
keyboard — both of those cases certainly exist — or the folks might be
using keys and keypads and features that don't exist on the laptop
keyboard. It's the latter case that I'm referencing. Which means
you're adding hardware. In the case of the LK, hardware which is no
longer manufactured is a prerequisite for effective use of the
software. I've seen more than a few folks using external mice, too.

Watching a typical Windows user arrive at a table, set up the power
supply and — for those that want or need it — the external keyboard and
the mouse — is always interesting to watch. Particularly when
comparing with folks that don't. Roller bags or porters can help
with all that, too. But I digress.

Keeping application software working is laudable. But dependencies
on declining hardware and particularly dependences on hardware that is
no longer available — such as the DEC LK — not so much. Best to remove
those dependencies.

Post by Stephen Hoffman
Unfortunately what you're using — the keypad-based application...

You've got to keep applications apart from the editing.
I use EDT to edit our web based "GUI" applications.

Applications using the keypad are dying out. EDT is an application.

Applications that use the LK are dead. That hardware is no longer available.

Applications that use a PC keyboard and a full-size PC keypad are
certainly preferable to those still using a DEC LK layout, but those
applications are still reducing what hardware is compatible with the
applications.

Post by Stephen Hoffman
and keypad-based editors — is dying out...

EDT isn't "dying". Or, it is dying at the same pace as VMS is.

EDT was deprecated some twenty years ago. EVE/TPU and LSEDIT were the
migration path.

Keypad-based editors and other keypad-based applications are dying out.
That's because you can depend on the keyboard being present, but can't
depend on the keypad — PC extended, or particularly the DEC LK — being
available.

Post by Stephen Hoffman
OpenVMS apps either need to forget about the VMS-layout LK and/or provide
an alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few small
differences that should be easy to learn for any IT professional.

Other than that applications that have dependencies on the keypad, and
that the traditional extended keypad is becoming less common, and that
the DEC LK keyboard is no longer manufactured, sure.

Get off the LK.

Reduce your dependencies on the full-sized keyboards, and work to
eliminate dependencies on DEC LK keyboard layouts.

[David Froble]

Post by Jan-Erik Soderholm

Post by Stephen Hoffman

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are fewer keyboards with keypads, too.

It's not what I'm seeing. Many new "professional" laptops has
larger screens today, and it seems as the manfacturers just as
well put in a real keyboard with numeric kaypad also.
And besides, even if you have an laptop, most professionals will
hook up an external keyboard and screen anyway.

Post by Stephen Hoffman
Unfortunately what you're using — the keypad-based application...

You've got to keep applications apart from the editing.
I use EDT to edit our web based "GUI" applications.

Post by Stephen Hoffman
and keypad-based editors — is dying out...

EDT isn't "dying". Or, it is dying at the same pace as VMS is.

Post by Stephen Hoffman
OpenVMS apps either need to forget about the VMS-layout LK and/or provide
an alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few small
differences that should be easy to learn for any IT professional.
Or are you now talking about the end-user applications? Yes, they should
not be depending on VT-style kayboards and keys, and they will probably
mostly be based on web interfaces, so it is a non-issue. I do not see
a huge volume of newly written VT-based applications today.
But that is something completely different then me using EDT.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What he wrote ....

[Jan-Erik Soderholm]

Post by David Froble

Post by Jan-Erik Soderholm

Post by Stephen Hoffman

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are fewer keyboards with keypads, too.

It's not what I'm seeing. Many new "professional" laptops has
larger screens today, and it seems as the manfacturers just as
well put in a real keyboard with numeric kaypad also.
And besides, even if you have an laptop, most professionals will
hook up an external keyboard and screen anyway.

Post by Stephen Hoffman
Unfortunately what you're using — the keypad-based application...

You've got to keep applications apart from the editing.
I use EDT to edit our web based "GUI" applications.

Post by Stephen Hoffman
and keypad-based editors — is dying out...

EDT isn't "dying". Or, it is dying at the same pace as VMS is.

Post by Stephen Hoffman
OpenVMS apps either need to forget about the VMS-layout LK and/or provide
an alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few small
differences that should be easy to learn for any IT professional.
Or are you now talking about the end-user applications? Yes, they should
not be depending on VT-style kayboards and keys, and they will probably
mostly be based on web interfaces, so it is a non-issue. I do not see
a huge volume of newly written VT-based applications today.
But that is something completely different then me using EDT.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What he wrote ....

OK. The difference might be that you are talkning about yourself.
I try to look at the VMS world at large, as far as I know it.

I think the "market" I'm looking at is slightly larger then
the one you are talking about.

If one look at the VMS markets today (banking, large companies
logistics back-office), that is not VT-based.

And again, we should not mix up the end-users environment
with what we as programmers might prefer or use.

[David Froble]

Post by Jan-Erik Soderholm

Post by David Froble

Post by Jan-Erik Soderholm

Post by Stephen Hoffman

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are fewer keyboards with keypads, too.

It's not what I'm seeing. Many new "professional" laptops has
larger screens today, and it seems as the manfacturers just as
well put in a real keyboard with numeric kaypad also.
And besides, even if you have an laptop, most professionals will
hook up an external keyboard and screen anyway.

Post by Stephen Hoffman
Unfortunately what you're using — the keypad-based application...

You've got to keep applications apart from the editing.
I use EDT to edit our web based "GUI" applications.

Post by Stephen Hoffman
and keypad-based editors — is dying out...

EDT isn't "dying". Or, it is dying at the same pace as VMS is.

Post by Stephen Hoffman
OpenVMS apps either need to forget about the VMS-layout LK and/or provide
an alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few small
differences that should be easy to learn for any IT professional.
Or are you now talking about the end-user applications? Yes, they should
not be depending on VT-style kayboards and keys, and they will probably
mostly be based on web interfaces, so it is a non-issue. I do not see
a huge volume of newly written VT-based applications today.
But that is something completely different then me using EDT.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What he wrote ....

OK. The difference might be that you are talkning about yourself.
I try to look at the VMS world at large, as far as I know it.
I think the "market" I'm looking at is slightly larger then
the one you are talking about.
If one look at the VMS markets today (banking, large companies
logistics back-office), that is not VT-based.
And again, we should not mix up the end-users environment
with what we as programmers might prefer or use.

And I did no such thing. All I wrote in another post was that it was going to
be a black day when my keyboard died. Nothing about apps.

Just picked up a LK450 ....

:-)

[Jan-Erik Soderholm]

Post by David Froble

Post by Jan-Erik Soderholm

Post by David Froble

Post by Jan-Erik Soderholm

Post by Stephen Hoffman

Post by David Froble
Why is it that whatever you use is great ... and whatever I use should die?

There are fewer keyboards with keypads, too.

It's not what I'm seeing. Many new "professional" laptops has
larger screens today, and it seems as the manfacturers just as
well put in a real keyboard with numeric kaypad also.
And besides, even if you have an laptop, most professionals will
hook up an external keyboard and screen anyway.

Post by Stephen Hoffman
Unfortunately what you're using — the keypad-based application...

You've got to keep applications apart from the editing.
I use EDT to edit our web based "GUI" applications.

Post by Stephen Hoffman
and keypad-based editors — is dying out...

EDT isn't "dying". Or, it is dying at the same pace as VMS is.

Post by Stephen Hoffman
OpenVMS apps either need to forget about the VMS-layout LK and/or provide
an alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few small
differences that should be easy to learn for any IT professional.
Or are you now talking about the end-user applications? Yes, they should
not be depending on VT-style kayboards and keys, and they will probably
mostly be based on web interfaces, so it is a non-issue. I do not see
a huge volume of newly written VT-based applications today.
But that is something completely different then me using EDT.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What he wrote ....

OK. The difference might be that you are talkning about yourself.
I try to look at the VMS world at large, as far as I know it.
I think the "market" I'm looking at is slightly larger then
the one you are talking about.
If one look at the VMS markets today (banking, large companies
logistics back-office), that is not VT-based.
And again, we should not mix up the end-users environment
with what we as programmers might prefer or use.

And I did no such thing. All I wrote in another post was that it was going
to be a black day when my keyboard died. Nothing about apps.
Just picked up a LK450 ....
:-)

OK, right. We seems to agree that your keyboard preferences is
irrelevant for OpenVMS as such. Fine then. And I'm sure you'd be
better prepared for the future by *not* picking up any LK450...

[Bob Koehler]

Post by Stephen Hoffman
Downside: EDT, LSEDIT and EVE/TPU are OpenVMS-specific, and don't exist
on other platforms. (Yes, you can find some open source for EDT, but
then you're back in the keypad quagmire.)

I don't think you can buy it now, but there are still people out
there using nu/TPU from a/Soft. Runs on lots of platforms.

[Stephen Hoffman]

Post by Bob Koehler

Post by Stephen Hoffman
Downside: EDT, LSEDIT and EVE/TPU are OpenVMS-specific, and don't exist
on other platforms. (Yes, you can find some open source for EDT, but
then you're back in the keypad quagmire.)

I don't think you can buy it now, but there are still people out
there using nu/TPU from a/Soft. Runs on lots of platforms.

http://edt-text-editor.sourceforge.net

[Jan-Erik Soderholm]

Post by l***@gmail.com

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

EDT is another tool that needs to die.
In my RSTS/E days, we used a TECO-based screen editor called VTED (a
local adaptation of some code originally from DECUS or somewhere).
Unfortunately that was never ported to the VAX. So I gritted my teeth
and put up with EDT for whatever far-too-long fraction of my lifetime it
was until TPU came along, which was halfway decent in comparison (even
with that weird initial (mis)behaviour with search pattern matches).
Nowadays of course I use Emacs. Is Emacs available for VMS? That has to
be a big improvement to whatever DEC-originated editor you might be
using now.

My first and most important requirement on an editor is that it always
should be available "out-of-the" box no matter what customer site I get
to. So anything that doesn't come with VMS is out, such as Emacs.

Then, personaly, I never have come around learning TPU, EDT has served
me well both in the early days on RSX and VMS. Now, I haven't looked
too closely at this, but it is my impession that EDT is slightly more
"kind" against VT emulators then TPU is.

[V***@SendSpamHere.ORG]

Post by Jan-Erik Soderholm

Post by l***@gmail.com

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

EDT is another tool that needs to die.
In my RSTS/E days, we used a TECO-based screen editor called VTED (a
local adaptation of some code originally from DECUS or somewhere).
Unfortunately that was never ported to the VAX. So I gritted my teeth
and put up with EDT for whatever far-too-long fraction of my lifetime it
was until TPU came along, which was halfway decent in comparison (even
with that weird initial (mis)behaviour with search pattern matches).
Nowadays of course I use Emacs. Is Emacs available for VMS? That has to
be a big improvement to whatever DEC-originated editor you might be
using now.

My first and most important requirement on an editor is that it always
should be available "out-of-the" box no matter what customer site I get
to. So anything that doesn't come with VMS is out, such as Emacs.
Then, personaly, I never have come around learning TPU, EDT has served
me well both in the early days on RSX and VMS. Now, I haven't looked
too closely at this, but it is my impession that EDT is slightly more
"kind" against VT emulators then TPU is.

$ SET TERMINAL/TYPE=VT100 with most of the emulators and TPU is usable.

[Phillip Helbig (undress to reply)]

Post by l***@gmail.com

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

I don't really see the point of working on VMS with anything but a
proper keyboard.

Post by l***@gmail.com
EDT is another tool that needs to die.

Definitely not. If you don't like it, don't use it.

Though it has a couple of limitations (doesn't like lines longer than
255 characters and can't process more than 65535 lines in one command),
in practice this is not a problem, at least for hand-edited files. It
has some advantages over EVE: it is faster, it doesn't read in the whole
file unless necessary, it is easier to use in batch, the cursor movement
is more sensible, macros can be written more compactly.

I've spent a large fraction of my life in EDT! :-D

Post by l***@gmail.com
Nowadays of course I use Emacs. Is Emacs available for VMS? That has to be
a big improvement to whatever DEC-originated editor you might be using now.

Yes, Emacs exists for VMS, but why? The only thing good about it is the
EDT emulation on unix. :-) (However, it just emulates the keypad.)

[Simon Clubley]

Post by Phillip Helbig (undress to reply)

Post by l***@gmail.com
Nowadays of course I use Emacs. Is Emacs available for VMS? That has to be
a big improvement to whatever DEC-originated editor you might be using now.

Yes, Emacs exists for VMS, but why? The only thing good about it is the
EDT emulation on unix. :-) (However, it just emulates the keypad.)

Why Emacs over EDT:

1) It supports screens larger than 24 lines high.

2) You can have multiple buffers on the screen at the same time.

3) You can edit large files with arbitary record lengths.

4) You can do things like tabify and brace matching.

Why EDT over Emacs:

1) You can use it on an ASR-33.

2) [I give up. :-) There is no 2)]

Simon.

[Bob Koehler]

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly.

***@gmail.com didn't write that, I did.

[Simon Clubley]

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly. TPU's
predefined keyboards should also have that variation.

I have not used a DEC keyboard for development for over a decade.

I do however use the EDT keypad layout on a full PC keyboard on a
daily basis and it works fine. The only real difference is that there's
no delete word key (which I don't miss) and the 3x2 keypad between the
main keyboard and the keypad is used based on PC key labeling and not
the LK keypad assigned position.

This means that Page up is the top right key, Page down is the bottom
right key, Insert is the top left key and Delete is the bottom left key.

After a decade that feels natural to me and I can still use a EDT keypad
based editor (either emacs on Linux or TPU on VMS) just fine.

Simon.

[Jan-Erik Soderholm]

Post by Simon Clubley

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly. TPU's
predefined keyboards should also have that variation.

I have not used a DEC keyboard for development for over a decade.

I'm pretty sure 99% of VMS developers hasn't.

Post by Simon Clubley
I do however use the EDT keypad layout on a full PC keyboard on a
daily basis and it works fine. The only real difference is that there's
no delete word key (which I don't miss) and the 3x2 keypad between the
main keyboard and the keypad is used based on PC key labeling and not
the LK keypad assigned position.
This means that Page up is the top right key, Page down is the bottom
right key, Insert is the top left key and Delete is the bottom left key.
After a decade that feels natural to me and I can still use a EDT keypad
based editor (either emacs on Linux or TPU on VMS) just fine.
Simon.

Yes, what I've been saying. A standard PC keyboard works perfectly well.
I do not think I have used a kayboard with the old DEC layout since we
ditched the VT520's 25 (or whatever) years ago.

[John Reagan]

Post by Jan-Erik Soderholm

Post by Simon Clubley

Post by Bob Koehler
I've asked for this before, and I'll say it again. VMS needs to have
keyboard layouts for EDT and DEBUG that are PC friendly. TPU's
predefined keyboards should also have that variation.

I have not used a DEC keyboard for development for over a decade.

I'm pretty sure 99% of VMS developers hasn't.

Post by Simon Clubley
I do however use the EDT keypad layout on a full PC keyboard on a
daily basis and it works fine. The only real difference is that there's
no delete word key (which I don't miss) and the 3x2 keypad between the
main keyboard and the keypad is used based on PC key labeling and not
the LK keypad assigned position.
This means that Page up is the top right key, Page down is the bottom
right key, Insert is the top left key and Delete is the bottom left key.
After a decade that feels natural to me and I can still use a EDT keypad
based editor (either emacs on Linux or TPU on VMS) just fine.
Simon.

Yes, what I've been saying. A standard PC keyboard works perfectly well.
I do not think I have used a kayboard with the old DEC layout since we
ditched the VT520's 25 (or whatever) years ago.

Absolutely. I use a standard PC keyboard and use the keypad with LSE, DTM, and Notes. It all works just fine. I have an LSE init file that makes F9-F12 into the "DO" key. I tend to use Emacs all the time, but Emacs seems to have issues when I have SET PROC/PARSE=EXTENDED enabled. It also has issues with using angle braces instead of square braces in filespecs. Those are the times I'll just hop into LSE.

[hb]

Post by John Reagan
Absolutely. I use a standard PC keyboard and use the keypad with
LSE, DTM, and Notes. It all works just fine. I have an LSE init
file that makes F9-F12 into the "DO" key. I tend to use Emacs all
the time, but Emacs seems to have issues when I have SET
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

Admitted, I'm not a regular Emacs user, but I can see the problem with
angle brackets - and I'll try to fix it. But I don't see a general
problem with extended parsing (for example, ^x^f works as expected on an
ODS-5 disk with extended parsing enabled). Can you give some examples
what doesn't work?

[John Reagan]

Post by hb

Post by John Reagan
Absolutely. I use a standard PC keyboard and use the keypad with
LSE, DTM, and Notes. It all works just fine. I have an LSE init
file that makes F9-F12 into the "DO" key. I tend to use Emacs all
the time, but Emacs seems to have issues when I have SET
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

Admitted, I'm not a regular Emacs user, but I can see the problem with
angle brackets - and I'll try to fix it. But I don't see a general
problem with extended parsing (for example, ^x^f works as expected on an
ODS-5 disk with extended parsing enabled). Can you give some examples
what doesn't work?

It might have to do with some DECC$ logicals I set. It comes up in raw emacs mode since it couldn't read the base emacs definitions. I'll figure out the guilty party and let you know. Maybe a configuration issue at our end.

It also doesn't like files with ACLs. If I have write access via some held identifier but no write access via the protection mask, I only get read access.

[Stephen Hoffman]

Post by John Reagan
It might have to do with some DECC$ logicals I set.

Nuke those from orbit. It's the only way to be sure those logical
names won't continue to derail unrelated applications.

[John Reagan]

Post by Stephen Hoffman

Post by John Reagan
It might have to do with some DECC$ logicals I set.

Nuke those from orbit. It's the only way to be sure those logical
names won't continue to derail unrelated applications.

We are doing some CRTL work right now (adding stdint.h, adding missing stuff to other headers, untangling the mess inside math.h, etc.). There are about 1/3rd of the logicals that I'm tempted to remove and pick a 'mandatory default'. I don't think anybody would know (but then again, those probably aren't the ones screwing people over).

And some, like this one being discussed, should have never seen the light of day. A new feature was added to the CRTL to make access() smarter. Most folks might even call it a bug fix (I would). Why make it default to 'off'? Why give you the option to return to the old behavior? We don't invent logical names in other areas to selectively un-do a bug fix! At the minimum, I'll make sure the default for this one turns into 'enabled' (which is what I assumed it would be all along).

[Craig A. Berry]

We are doing some CRTL work right now ... untangling the mess inside math.h, etc.).

While you're in there, you may want to look at the IEEE floating point
classification macros. The standard says they should work for
"real-floating" data of any size, but the ones you've got now only work
for doubles, not for singles or long doubles. For example, here's the
signbit implementation you have now:

#define __VALH(x) ((unsigned int *)&x)[1]
#define signbit(x) (__VALH(x) & 0x80000000)

Because that's explicitly operating on the second longword of a longword
pair, it only works for T_FLOAT because that's the only size consisting
of two longwords.

If you replace that with this:

#define __HIGHBYTE(x) (((unsigned char *)&x)[sizeof(x)-1])
#define signbit(x) (__HIGHBYTE(x) & 0x80)

it will work for S_FLOAT, T_FLOAT, and X_FLOAT equally well because the
byte containing the classification info follows the same pattern, but
just has a different location for the different sizes. Similar things
should be possible for isnan, isinf, etc.

Of course if long double on x86_64 will be the 80-bit kind common on
that platform rather than X_FLOAT, then you're not quite done yet. But
I'd be surprised if you did that since IIRC Alpha didn't have hardware
support for X_FLOAT yet that was/is the long double format there, so why
would x86_64 be different.

[Stephen Hoffman]

Post by John Reagan

Post by John Reagan
It might have to do with some DECC$ logicals I set.

Nuke those from orbit. It's the only way to be sure those logical>
names won't continue to derail unrelated applications.

We are doing some CRTL work right now (adding stdint.h, adding missing
stuff to other headers, untangling the mess inside math.h, etc.).
There are about 1/3rd of the logicals that I'm tempted to remove and
pick a 'mandatory default'. I don't think anybody would know (but then
again, those probably aren't the ones screwing people over).

Add a linked-in object module containing the settings data and some
symbols accessible from the code behind main() and the VAXC$CRTL_INIT
callback (there's a Compaq C reference in the local HELP CRTL help
library entry for that call, too) or some such, and deprecate all of
the DECC$ logical names. Or if they're not already linked into the
module via that object module containing data, update the code behind
main() able to read a same-name-as-the-image settings file from a
searchlist of directories — that'd at least let most apps retrofit a
saner settings design, and without relinking. Do the settings file
contents using json or such, and allow the app to read user settings
from there, and pretty soon you have something approaching a more
manageable design. Maybe even use SET IMAGE to manage the contents of
the module in the executable. For compatibility, some CC /UNHACK
/OUTPUT=settings.json tool that reads the current forest of logical
names and creates the json file and/or the data object to link into the
executable.

Post by John Reagan
And some, like this one being discussed, should have never seen the
light of day.

The whole management-by-logical name design — this DECC$ logical name
implementation, and across all of the other users of that approach I've
encountered — accumulates technical debt faster than a black hole
accumulates mass. KIWF.

[John E. Malmberg]

Post by John Reagan

Post by Stephen Hoffman

Post by John Reagan
It might have to do with some DECC$ logicals I set.

Nuke those from orbit. It's the only way to be sure those logical
names won't continue to derail unrelated applications.

We are doing some CRTL work right now (adding stdint.h, adding
missing stuff to other headers, untangling the mess inside math.h,
etc.). There are about 1/3rd of the logicals that I'm tempted to
remove and pick a 'mandatory default'. I don't think anybody would
know (but then again, those probably aren't the ones screwing people

over).

Post by John Reagan
And some, like this one being discussed, should have never seen the
light of day. A new feature was added to the CRTL to make access()
smarter. Most folks might even call it a bug fix (I would). Why make it
default to 'off'? Why give you the option to return to the old behavior?
We don't invent logical names in other areas to selectively un-do a bug
fix! At the minimum, I'll make sure the default for this one turns into
'enabled' (which is what I assumed it would be all along).

The issue is probably that many times a buggy behavior got fixed in the
VMS CRTL, it broke some significant customer code that was depending on
that bug.

After a few rounds of that, a team can get gun shy at making a fixed
behavior a default.

There is a big mess there. And the thing do do might be to freeze
decc$shr and create a new decc$vsi_shr that is expected to follow the C
standards and not use run-time feature settings.

The big transition issue for this is that there are a number of really
bad VMS CRTL behaviors that should be fixed if you are splitting off a
fixed copy.

* Some feature and compile time defines are to enable fixed behaviors
that default to broken.

* Some feature and compile time defines are to enable broken behaviors
that default to fixed.

* And there are some a few that are needed to change from Unix to VMS
behaviors that rarely need to be run-time behaviors, but are not
available as compile time behaviors.

Regards,
-John
***@qsl.net_work

[Stephen Hoffman]

Post by John E. Malmberg
The issue is probably that many times a buggy behavior got fixed in the
VMS CRTL, it broke some significant customer code that was depending on
that bug.
After a few rounds of that, a team can get gun shy at making a fixed
behavior a default.

Ayup, and you're always and inevitably left with a decision in these
cases. Compatibility and piling on the technical debt and adding
arcana and complexity? Or forward progress for VSI and for customers
maintaining their applications, and for folks writing new applications?
Tough call. Choosing the former is what got OpenVMS where it is —
in both senses of that.

Post by John E. Malmberg
There is a big mess there. And the thing do do might be to freeze
decc$shr and create a new decc$vsi_shr that is expected to follow the C
standards and not use run-time feature settings.

Wholesale abandonment is certainly viable for this case. Mark it
deprecated and — what should happen for these cases, but likely won't —
announce a schedule for eventual removal.

Post by John E. Malmberg
The big transition issue for this is that there are a number of really
bad VMS CRTL behaviors that should be fixed if you are splitting off a
fixed copy.
* Some feature and compile time defines are to enable fixed behaviors
that default to broken.
* Some feature and compile time defines are to enable broken behaviors
that default to fixed.

There's also no consistency in the naming; some names are negations,
some are not.

Post by John E. Malmberg
* And there are some a few that are needed to change from Unix to VMS
behaviors that rarely need to be run-time behaviors, but are not
available as compile time behaviors.

SSIO, among others.

[l***@gmail.com]

Post by Stephen Hoffman
Compatibility and piling on the technical debt and adding
arcana and complexity?

A.k.a. “Microsoft Windows”.

[John Reagan]

Post by John Reagan

Post by John Reagan

Post by Stephen Hoffman

Post by John Reagan
It might have to do with some DECC$ logicals I set.

Nuke those from orbit. It's the only way to be sure those logical
names won't continue to derail unrelated applications.

We are doing some CRTL work right now (adding stdint.h, adding
missing stuff to other headers, untangling the mess inside math.h,
etc.). There are about 1/3rd of the logicals that I'm tempted to
remove and pick a 'mandatory default'. I don't think anybody would
know (but then again, those probably aren't the ones screwing people

over).

Post by John Reagan
And some, like this one being discussed, should have never seen the
light of day. A new feature was added to the CRTL to make access()
smarter. Most folks might even call it a bug fix (I would). Why make it
default to 'off'? Why give you the option to return to the old behavior?
We don't invent logical names in other areas to selectively un-do a bug
fix! At the minimum, I'll make sure the default for this one turns into
'enabled' (which is what I assumed it would be all along).

The issue is probably that many times a buggy behavior got fixed in the
VMS CRTL, it broke some significant customer code that was depending on
that bug.
After a few rounds of that, a team can get gun shy at making a fixed
behavior a default.
There is a big mess there. And the thing do do might be to freeze
decc$shr and create a new decc$vsi_shr that is expected to follow the C
standards and not use run-time feature settings.
The big transition issue for this is that there are a number of really
bad VMS CRTL behaviors that should be fixed if you are splitting off a
fixed copy.
* Some feature and compile time defines are to enable fixed behaviors
that default to broken.
* Some feature and compile time defines are to enable broken behaviors
that default to fixed.
* And there are some a few that are needed to change from Unix to VMS
behaviors that rarely need to be run-time behaviors, but are not
available as compile time behaviors.
Regards,
-John

The trouble with two RTLs is that they will never be separate. People will demand that you can fopen() with one RTL but fprintf() with the other. Same for setenv()/getenv(). The two RTLs would have to have a private channel between each other.

[Stephen Hoffman]

Post by John Reagan
The trouble with two RTLs is that they will never be separate. People
will demand that you can fopen() with one RTL but fprintf() with the
other. Same for setenv()/getenv(). The two RTLs would have to have a
private channel between each other.

Ayup. Particularly if some app is exposing RTL constructs directly
through its API, and that the caller is then using. But how common is
that?

Announce the new RTL and preferably with all of the core VSI apps and
tools migrated and with most of the rest migrating, announce that
mixing RTLs won't work and isn't supported, announce the public
schedule for the deprecation of the old RTL first through the removal
and relocation of old RTL into a separate and extra-cost license and
installation, and then through copying the RTL and the compatibility
kit to NLA0:.

This deprecation might well be fodder for using the multi-version
approach, if y'all start to make that into a supportable and
sustainable design for OpenVMS itself and for applications.

Getting rid of specific and targeted and problematic old code and
redesigning or replacing inadequate or broken or insecure APIs is a
complete shift from past practice. But it's also the only way you're
going to make more than token forward progress with OpenVMS.

Make the folks that don't want to move and don't want to migrate pay
for that, if they are even upgrading. Make the folks that are moving
and are updating their apps have an easier time, and with better
capabilities.

[John Reagan]

Post by Stephen Hoffman

Post by John Reagan
The trouble with two RTLs is that they will never be separate. People
will demand that you can fopen() with one RTL but fprintf() with the
other. Same for setenv()/getenv(). The two RTLs would have to have a
private channel between each other.

Ayup. Particularly if some app is exposing RTL constructs directly
through its API, and that the caller is then using. But how common is
that?

Common enough that there was work to make sure the native RTLs and translated RTLs cooperated. The Fortran RTLs share LUN information for example.

Post by Stephen Hoffman
Announce the new RTL and preferably with all of the core VSI apps and
tools migrated and with most of the rest migrating, announce that
mixing RTLs won't work and isn't supported, announce the public
schedule for the deprecation of the old RTL first through the removal
and relocation of old RTL into a separate and extra-cost license and
installation, and then through copying the RTL and the compatibility
kit to NLA0:.
This deprecation might well be fodder for using the multi-version
approach, if y'all start to make that into a supportable and
sustainable design for OpenVMS itself and for applications.
Getting rid of specific and targeted and problematic old code and
redesigning or replacing inadequate or broken or insecure APIs is a
complete shift from past practice. But it's also the only way you're
going to make more than token forward progress with OpenVMS.
Make the folks that don't want to move and don't want to migrate pay
for that, if they are even upgrading. Make the folks that are moving
and are updating their apps have an easier time, and with better
capabilities.

I'm guessing that most folks really don't want to toss ALL the baggage. Go and do

$ DEFINE/SYSTEM/EXEC DECC$UNIX_LEVEL 90

and sit back and wait for the phone calls to start. I don't think even the C compiler will work with that turned on.

[Stephen Hoffman]

Post by John Reagan
Common enough that there was work to make sure the native RTLs and
translated RTLs cooperated. The Fortran RTLs share LUN information for
example.

But that's an instance of the "same" RTL translated, and not a
completely different RTL? I'd kind of expect that case to work.

Now if I had code using VSI Clang LLVM RTL C11, I'm not so sure I'd
expect that to interoperate with other translated code using a
translated VAX C RTL and native Compaq C RTL circa C90 mixed in for the
most complete code conflagration.

Skewing somewhat away from blanket upward-compatibility and making new
code easier to write and to maintain is preferable, though that'll be
unpopular with some existing code in the short term, but offset by
better support, features and stability with the newer RTL over the mid-
and longer-term. As an example of this stalled migration, getting
folks off of VAX C should not still be going on. Folks can either fix
the ancient application code, or stay on the ancient release where that
code best belongs. Do I like fixing crufty old code? No. But
getting that old code off VAX C made the code vastly more stable.

Post by John Reagan
I'm guessing that most folks really don't want to toss ALL the baggage.
Go and do
$ DEFINE/SYSTEM/EXEC DECC$UNIX_LEVEL 90
and sit back and wait for the phone calls to start. I don't think even
the C compiler will work with that turned on.

Tried that knob some years ago. Those switches are much like playing
minesweeper. Various routines blow up within (formerly) running code.
That's also part of why I utterly despise that mechanism, as some of
those errors can be quite subtle when you're off app-stacking and
somebody wants one of those knobs and somebody else has an adverse
reaction. But then I (again) realize that basename() is utterly borked
when passed OpenVMS filenames, and wonder why I even bother.

[John Reagan]

Post by Stephen Hoffman

Post by John Reagan
Common enough that there was work to make sure the native RTLs and
translated RTLs cooperated. The Fortran RTLs share LUN information for
example.

But that's an instance of the "same" RTL translated, and not a
completely different RTL? I'd kind of expect that case to work.

Some of the RTLs that get translated are subtly different with conditional code than the RTLs that ship on the platform. So in theory, there have been be up to 5 different RTLs that we built (VAX to ship on VAX, VAX to translate to Alpha, Alpha to ship on Alpha, Alpha to translate to Itanium, Itanium to ship on Itanium). The RTL business isn't for the faint of heart.

Post by Stephen Hoffman
Now if I had code using VSI Clang LLVM RTL C11, I'm not so sure I'd
expect that to interoperate with other translated code using a
translated VAX C RTL and native Compaq C RTL circa C90 mixed in for the
most complete code conflagration.

Those are the kind of scenarios that need to be discussed. I'm all for breaking stuff. :)

Post by Stephen Hoffman
Skewing somewhat away from blanket upward-compatibility and making new
code easier to write and to maintain is preferable, though that'll be
unpopular with some existing code in the short term, but offset by
better support, features and stability with the newer RTL over the mid-
and longer-term. As an example of this stalled migration, getting
folks off of VAX C should not still be going on. Folks can either fix
the ancient application code, or stay on the ancient release where that
code best belongs. Do I like fixing crufty old code? No. But
getting that old code off VAX C made the code vastly more stable.

Post by John Reagan
I'm guessing that most folks really don't want to toss ALL the baggage.
Go and do
$ DEFINE/SYSTEM/EXEC DECC$UNIX_LEVEL 90
and sit back and wait for the phone calls to start. I don't think even
the C compiler will work with that turned on.

Tried that knob some years ago. Those switches are much like playing
minesweeper. Various routines blow up within (formerly) running code.
That's also part of why I utterly despise that mechanism, as some of
those errors can be quite subtle when you're off app-stacking and
somebody wants one of those knobs and somebody else has an adverse
reaction. But then I (again) realize that basename() is utterly borked
when passed OpenVMS filenames, and wonder why I even bother.

I'll have somebody take a run at basename(). It does work for the simple cases that most people have. Send me your edge conditions and I'll add them to the list. I actually think it is time for me to start another thread to talk about the CRTL.

[John E. Malmberg]

Post by John Reagan

Post by hb

Post by John Reagan
Absolutely. I use a standard PC keyboard and use the keypad with
LSE, DTM, and Notes. It all works just fine. I have an LSE init
file that makes F9-F12 into the "DO" key. I tend to use Emacs all
the time, but Emacs seems to have issues when I have SET
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

Admitted, I'm not a regular Emacs user, but I can see the problem with
angle brackets - and I'll try to fix it. But I don't see a general
problem with extended parsing (for example, ^x^f works as expected on an
ODS-5 disk with extended parsing enabled). Can you give some examples
what doesn't work?

It might have to do with some DECC$ logicals I set. It comes up in
raw emacs mode since it couldn't read the base emacs definitions.
I'll figure out the guilty party and let you know. Maybe a
configuration issue at our end.
It also doesn't like files with ACLs. If I have write access via
some held identifier but no write access via the protection mask, I
only get read access.

It might be the setting of DECC$ACL_ACCESS_CHECK

Regards,
-John

[John Reagan]

Post by John E. Malmberg

Post by John Reagan

Post by hb

Post by John Reagan
Absolutely. I use a standard PC keyboard and use the keypad with
LSE, DTM, and Notes. It all works just fine. I have an LSE init
file that makes F9-F12 into the "DO" key. I tend to use Emacs all
the time, but Emacs seems to have issues when I have SET
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

Admitted, I'm not a regular Emacs user, but I can see the problem with
angle brackets - and I'll try to fix it. But I don't see a general
problem with extended parsing (for example, ^x^f works as expected on an
ODS-5 disk with extended parsing enabled). Can you give some examples
what doesn't work?

It might have to do with some DECC$ logicals I set. It comes up in
raw emacs mode since it couldn't read the base emacs definitions.
I'll figure out the guilty party and let you know. Maybe a
configuration issue at our end.
It also doesn't like files with ACLs. If I have write access via
some held identifier but no write access via the protection mask, I
only get read access.

It might be the setting of DECC$ACL_ACCESS_CHECK
Regards,
-John

That's is. Why in the world would the default be 'disable'? I went and read the internal notesfile that discussed adding the support back in 2003. There was no reason NOT to make it default 'on' and not even have the logical to being with. Sigh...

[hb]

Post by John Reagan
Absolutely. I use a standard PC keyboard and use the keypad with
LSE, DTM, and Notes. It all works just fine. I have an LSE init
file that makes F9-F12 into the "DO" key. I tend to use Emacs all
the time, but Emacs seems to have issues when I have SET
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

It looks like the angel bracket problem shows/showed with concealed
rooted logical names and the current default directory, when the latter
is specified with square brackets - and vice versa.

What seems to work without any problem:
Process set to extended parsing
Current directory on an ODS-5 disk: [] style
Copy of the emacs dump file saved as Emacs-21_2.Dump;1 in the current
directory
File names in lowercase

For example
$ mcr bld_root:[local.bin]emacs-21_2 -map <>emacs-21_2.dump
sys$disk:<>lowercase.txt

What didn't work was editing a file specified like
<>lowercase.txt
or
root:<whatever>lowercase.txt
with root defined /translation=(concealed,terminal)

No surprise, using square brackets in both error cases worked as expected.

I changed the code and fixed "something" (FILEIO.C) and I hope I didn't
break something else. The changes are independent of the platforms
VAX/Alpha/I64. Diffs/patches are appended. Whether the change can/needs
to be applied to 19.28 (which I assume is the other version), I don't know.

Emacs was build and runs on Alpha V8.3, with a "recent" CRTL as well as
recent include files and HP C V7.3-010.

To build in this environment (and likely on recent I64 versions) you
need to make the call to access() consistent, either always use (the
#defined) sys_access() and maybe prefix that with __LONG_GID_ or use
access() from decc$shr. I dared to do the first one (OK, looks like a
hack, because including unistd.h in VMSFNS.C creates more compile time
errors/warnings than I wanted to handle). Otherwise my friend the LINKER
will complain about an undefined symbol SYS_ACCESS in VMSFNS.OBJ - and
the LINKER is always right :-)

On not so recent versions, especially of unistd.h, there is no such
build problem - and sys_access, more or less a CRTL-workaround-code, is
used.

When using access() from DECC$SHR, I experienced write access problems
for files which were not write protected. I didn't spend the time to
investigate. And no, I don't see any DECC$ feature logicals being defined.

PATCHES:

$ diff/slp [-.emacs212_3.src]fileio.c;-1 ;
$ diff/slp [-.emacs212_3.src]vmsfns.c;-1 ;
$ ty *.dif

BLD_ROOT:[EMACS.BUILD]FILEIO.DIF;1

- 1064
int fbrack = 0;
- 1232
fbrack = 0;
- 1258, 1263
{
lbrack++, brack = 0;
if (fbrack==0)
fbrack = p[0];
else
p[0] = fbrack;
}
/* count close brackets, set close bracket pointer */
if (p[0] == ']' || p[0] == '>')
{
rbrack++, brack = p;
p[0] = fbrack + 2;
}
/* detect ][ or >< */
if ((p[0] == ']' && p[1] == '[') || (p[0] == '>' && p[1] == '<'))
- 1303
p = tmp+(colon-nm)+8;
/

BLD_ROOT:[EMACS.BUILD]VMSFNS.DIF;1

- 27
#if __USE_LONG_GID_T
# pragma __extern_prefix __save
# pragma __extern_prefix "__long_gid_"
#endif

int access (const char *__file_spec, int __mode);

#if __USE_LONG_GID_T
# pragma __extern_prefix __restore
#endif
/
$

[John Reagan]

Post by hb

Post by John Reagan
Absolutely. I use a standard PC keyboard and use the keypad with
LSE, DTM, and Notes. It all works just fine. I have an LSE init
file that makes F9-F12 into the "DO" key. I tend to use Emacs all
the time, but Emacs seems to have issues when I have SET
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

It looks like the angel bracket problem shows/showed with concealed
rooted logical names and the current default directory, when the latter
is specified with square brackets - and vice versa.
Process set to extended parsing
Current directory on an ODS-5 disk: [] style
Copy of the emacs dump file saved as Emacs-21_2.Dump;1 in the current
directory
File names in lowercase
For example
$ mcr bld_root:[local.bin]emacs-21_2 -map <>emacs-21_2.dump
sys$disk:<>lowercase.txt
What didn't work was editing a file specified like
<>lowercase.txt
or
root:<whatever>lowercase.txt
with root defined /translation=(concealed,terminal)
No surprise, using square brackets in both error cases worked as expected.
I changed the code and fixed "something" (FILEIO.C) and I hope I didn't
break something else. The changes are independent of the platforms
VAX/Alpha/I64. Diffs/patches are appended. Whether the change can/needs
to be applied to 19.28 (which I assume is the other version), I don't know.
Emacs was build and runs on Alpha V8.3, with a "recent" CRTL as well as
recent include files and HP C V7.3-010.
To build in this environment (and likely on recent I64 versions) you
need to make the call to access() consistent, either always use (the
#defined) sys_access() and maybe prefix that with __LONG_GID_ or use
access() from decc$shr. I dared to do the first one (OK, looks like a
hack, because including unistd.h in VMSFNS.C creates more compile time
errors/warnings than I wanted to handle). Otherwise my friend the LINKER
will complain about an undefined symbol SYS_ACCESS in VMSFNS.OBJ - and
the LINKER is always right :-)
On not so recent versions, especially of unistd.h, there is no such
build problem - and sys_access, more or less a CRTL-workaround-code, is
used.
When using access() from DECC$SHR, I experienced write access problems
for files which were not write protected. I didn't spend the time to
investigate. And no, I don't see any DECC$ feature logicals being defined.
$ diff/slp [-.emacs212_3.src]fileio.c;-1 ;
$ diff/slp [-.emacs212_3.src]vmsfns.c;-1 ;
$ ty *.dif
BLD_ROOT:[EMACS.BUILD]FILEIO.DIF;1
- 1064
int fbrack = 0;
- 1232
fbrack = 0;
- 1258, 1263
{
lbrack++, brack = 0;
if (fbrack==0)
fbrack = p[0];
else
p[0] = fbrack;
}
/* count close brackets, set close bracket pointer */
if (p[0] == ']' || p[0] == '>')
{
rbrack++, brack = p;
p[0] = fbrack + 2;
}
/* detect ][ or >< */
if ((p[0] == ']' && p[1] == '[') || (p[0] == '>' && p[1] == '<'))
- 1303
p = tmp+(colon-nm)+8;
/
BLD_ROOT:[EMACS.BUILD]VMSFNS.DIF;1
- 27
#if __USE_LONG_GID_T
# pragma __extern_prefix __save
# pragma __extern_prefix "__long_gid_"
#endif
int access (const char *__file_spec, int __mode);
#if __USE_LONG_GID_T
# pragma __extern_prefix __restore
#endif
/
$

I'll look into using that patch in the next week or so when Mike Z returns from vacation (he's the one who did our local build).

[Phillip Helbig (undress to reply)]

Post by hb

Post by John Reagan
PROC/PARSE=EXTENDED enabled. It also has issues with using angle
braces instead of square braces in filespecs. Those are the times
I'll just hop into LSE.

It looks like the angel bracket problem shows/showed with concealed
rooted logical names and the current default directory, when the latter
is specified with square brackets - and vice versa.

One can define both versions.

Of course, > as part of a directory spec will confuse PIPE.

[Robert A. Brooks]

Post by Jan-Erik Soderholm
Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

Perhaps.

I've been using the same LK461 for over 16 years to develop our
beloved operating system. I've got a stock of them; they connect to various Windows
systems using PowerTerm and a PS/2-to-USB adapter.

Works quite well.

Yes, I'm a traditionalist.

[Jan-Erik Soderholm]

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

Perhaps.
I've been using the same LK461 for over 16 years to develop our
beloved operating system. I've got a stock of them; they connect to various Windows
systems using PowerTerm and a PS/2-to-USB adapter.
Works quite well.

Perhaps. Perhaps at VSI. But not at some place where VMS is
already at stake and every additional little "thing" that make
VMS stand out as "troublesome" will push it closer to the door.

We, who manage VMS in these environments must make watever we
can to play along in the IT mainstream.

Pointing at VSI and claimning that a 16 year old LK461 works
well *there*, doesn't help much.

Post by Robert A. Brooks
Yes, I'm a traditionalist.

[David Froble]

Post by Jan-Erik Soderholm

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

Perhaps.
I've been using the same LK461 for over 16 years to develop our
beloved operating system. I've got a stock of them; they connect to various Windows
systems using PowerTerm and a PS/2-to-USB adapter.
Works quite well.

Perhaps. Perhaps at VSI. But not at some place where VMS is
already at stake and every additional little "thing" that make
VMS stand out as "troublesome" will push it closer to the door.
We, who manage VMS in these environments must make watever we
can to play along in the IT mainstream.
Pointing at VSI and claimning that a 16 year old LK461 works
well *there*, doesn't help much.

Post by Robert A. Brooks
Yes, I'm a traditionalist.

So, yeah, some of us old fossils remember a few "better" things from the past.
The question is, why have they not endured? Simple answer, volume. Oh, yeah,
and "cheap".

Most people don't want an IBM et-al mainframe ...

Most people don't want a really great VMS system ...

Most people don't want a PC ...

(and so the cheapest KB available didn't bother them, and that's what we all got)

Most people don't want a notebook ...

(which has even worse KB)

Most people now got their tablets and smart phones, and nobody wants to mfg for
the few fossils using any and all of the above ....

This LK411 could be mfg just as easily as the junk. The junk mfgs just don't
want to be bothered.

[Stephen Hoffman]

Post by Jan-Erik Soderholm
Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.

...
I've been using the same LK461 for over 16 years to develop our beloved
operating system. I've got a stock of them; they connect to various
Windows systems using PowerTerm and a PS/2-to-USB adapter.

You and the rest of VSI *need* to use what most customers are using now
or soon will be using if/when changes are planned.

That won't be LK461 keyboards. Not unless y'all are getting into that
production business.

OpenVMS *needs* to work effectively with the hardware the users are
using, and not with a sixteen-year-old and out-of-production custom
keyboard.

Or more succinctly, "dogfooding".
https://en.wikipedia.org/wiki/Eating_your_own_dog_food

[Kerry Main]

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: 23-Jun-16 8:58 AM
Subject: Re: [Info-vax] PC/VT Keyboarrd Mapping

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
Any truly professional would quickly adopt to whatever new/modern
hardware there is. Asking for old discontinued keyboards will

probably

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
only be an disservice to VMS, making it look even worse.

...
I've been using the same LK461 for over 16 years to develop our

beloved

Post by Robert A. Brooks
operating system. I've got a stock of them; they connect to various
Windows systems using PowerTerm and a PS/2-to-USB adapter.

You and the rest of VSI *need* to use what most customers are using now
or soon will be using if/when changes are planned.
That won't be LK461 keyboards. Not unless y'all are getting into that
production business.
OpenVMS *needs* to work effectively with the hardware the users are
using, and not with a sixteen-year-old and out-of-production custom
keyboard.
Or more succinctly, "dogfooding".
https://en.wikipedia.org/wiki/Eating_your_own_dog_food

Another view of this would be "carpenters should never tell another
carpenter what tools they should use on a project"

Can you imagine telling Microsoft Engineers what tools they should
use to build Windows?

:-)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

Post by Kerry Main
Another view of this would be "carpenters should never tell another
carpenter what tools they should use on a project"
Can you imagine telling Microsoft Engineers what tools they should use
to build Windows?

"Dogfooding" is a term originally used by Microsoft, and intended to
encourage their own folks to use their own tools.

To use what they are selling.

In the case of OpenVMS, that usage doesn't and can't happen when you're
using keyboards that simply aren't available anymore.

[Kerry Main]

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: 23-Jun-16 10:39 AM
Subject: Re: [Info-vax] PC/VT Keyboarrd Mapping

Post by Kerry Main
Another view of this would be "carpenters should never tell another
carpenter what tools they should use on a project"
Can you imagine telling Microsoft Engineers what tools they should use
to build Windows?

"Dogfooding" is a term originally used by Microsoft, and intended to
encourage their own folks to use their own tools.
To use what they are selling.
In the case of OpenVMS, that usage doesn't and can't happen when you're
using keyboards that simply aren't available anymore.

The dog food concept has been around forever (ok, long time), but
telling developers what type of keyboard to use on a Windows laptop
for developing OpenVMS code is a huuuuge stretch ..

It's a personal preference whether an emulated or physical keyboard
is used.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Bob Koehler]

Post by Kerry Main
Can you imagine telling Microsoft Engineers what tools they should
use to build Windows?

Yes, but it would be like attacking a brick wall with a garden hose.

[l***@gmail.com]

Post by Kerry Main
Can you imagine telling Microsoft Engineers what tools they should
use to build Windows?

Considering their increasing embrace of cross-platform, open-source tools like Git, Python and even some features of the Linux kernel itself, it is pretty clear that they realize their own platform is slipping down the same path where DEC ended up at the bottom...

[p***@gmail.com]

Do you know if a lk461-aa keyboard or a Realforce RGB keyboard or the Topre Realforce 104UG high profile 45g keyboard will work on a Mac which is running MacOS Sierra?

And secondly, do you know if either of these keyboards will work while using the TPU editor on an OpenVMS system which I will connect to while using my Mac computer?

[Steven Schweda]

Do you know [...]

No.

[...] do you know if either of these keyboards will work
while using the TPU editor on an OpenVMS system which I will
connect to while using my Mac computer?

Define "work". What makes those keyboard models special?

I use a normal (old?) Apple USB keyboard (A1048) with my
Mac Pro (Early 2008), and, with a little xmodmap action, I
can do what I want to do with EDIT /TPU (EDT keypad) in an
xterm. (I map only some of the keypad keys. In the EDT
keypad mode, I don't need the "Do" or other more exotic keys,
but I assume that those could be mapped onto some function
keys, if I cared more.)

If you don't learn what you want from this eight-month-old
thread, then I imagine that there are other many other old
threads on the topic, too. Or you could start a new one.

[Bob Koehler]

Post by p***@gmail.com
Do you know if a lk461-aa keyboard or a Realforce RGB keyboard or the Topre Realforce 104UG high profile 45g keyboard will work on a Mac which is running MacOS Sierra?
And secondly, do you know if either of these keyboards will work while using the TPU editor on an OpenVMS system which I will connect to while using my Mac computer?

The second one depends very much on what software you are using on
your Mac to emulate a terminal.

[John Reagan]

Post by Bob Koehler

Post by p***@gmail.com
Do you know if a lk461-aa keyboard or a Realforce RGB keyboard or the Topre Realforce 104UG high profile 45g keyboard will work on a Mac which is running MacOS Sierra?
And secondly, do you know if either of these keyboards will work while using the TPU editor on an OpenVMS system which I will connect to while using my Mac computer?

The second one depends very much on what software you are using on
your Mac to emulate a terminal.

Correct. I've found iTerm2 to be much better at keypad emulation than Terminal. (The best I've found is PuTTY running on my Windows 7 and 10 boxes - it works with LSE, EDT, DTM, etc. with almost zero changes out of the box - I did have to change the mapping to Latin-1 to get correct line drawing).

[Stephen Hoffman]

Post by p***@gmail.com
Do you know if a lk461-aa keyboard or a Realforce RGB keyboard or the
Topre Realforce 104UG high profile 45g keyboard will work on a Mac
which is running MacOS Sierra?

For what purpose? Running macOS as a remote client for an OpenVMS
system? Booting OpenVMS via simh? As a DEC-compatible PS/2
keyboard, the LK461 will not adapt easily nor work very well for that.
If you're able to even find a working adapter to get you from PS/2 to
USB or USB-C — I've not found one — the DEC-specific keys won't be
recognized by macOS and whatever terminal emulator you're planning to
use without added customizations. LK463 USB keyboard might be a
little easier, but you're still going to be dealing with key mapping.

As for the other keyboards mentioned, no idea.

The standard Apple extended wired keyboard can be gotten to mostly work
with OpenVMS, and the terminal emulators do deal with that fairly well.
The layout is also pretty close to an LK400 series keyboard.
There've been postings here in the comp.os.vms newsgroup and elsewhere
on mapping the macOS function keys, though I've found it entirely
feasible to operate with the standard keyboard and command-line
commands within various of the OpenVMS tools and utilities; within EDT
or LSEDIT or Notes or the Debugger or other tools, for instance.
Without needing or using a function or editing keypad.

Terminal.app works sufficiently for my needs with OpenVMS, though
iTerm2 and some other terminal emulators for macOS are also used by
various folks.

Post by p***@gmail.com
And secondly, do you know if either of these keyboards will work while
using the TPU editor on an OpenVMS system which I will connect to while
using my Mac computer?

vim or emacs are alternatives for OpenVMS and for macOS, and the
extended wired keyboard can be gotten to work with most OpenVMS tools.
But then the editing and function keypads are basically at a dead-end,
so it's better long-term to start moving away as the hardware and
software chains to keep these keypads working are only going to get
longer and more precarious. Recent Mac systems already need dongles,
at least until USB-C widgets become more prevalent. Which means
learning command mode, and (hopefully, eventually) VSI starts to
remediate the existing assumptions and dependencies on editing and
function keypads.

[l***@gmail.com]

Post by Paul Richards
I don't have a numeric keypad on my laptop but I have function keys F1
- F12 and the usual QWERTY keyboard.

Do you have a key labelled “Fn”, along with alternate labels on some keys that look like a numeric keypad? My laptop provides its numeric keypad that way.

[Paul Richards]

[Paul Richards]

Post by l***@gmail.com

Post by Paul Richards
I don't have a numeric keypad on my laptop but I have function keys
F1 - F12 and the usual QWERTY keyboard.

Do you have a key labelled “Fn”, along with alternate labels on some
keys that look like a numeric keypad? My laptop provides its numeric
keypad that way.

Yes, I do but the alternate labels provide functions like turning on
Bluetooth, screen brightness etc. As I said in my reply to Steven I
have another laptop with a numeric keypad and I've transferred my
FreeAXP/OpenVMS over to that.

[Paul Richards]

Post by l***@gmail.com

Post by Paul Richards
I don't have a numeric keypad on my laptop but I have function keys
F1 - F12 and the usual QWERTY keyboard.

Do you have a key labelled “Fn”, along with alternate labels on some
keys that look like a numeric keypad? My laptop provides its numeric
keypad that way.

Yes, I do but the alternate functions are for turning on Bluetooth,
screen brightness etc. As I said in my reply to Steven I have another
laptop with a numeric keypad and I have transferred my FreeAXP/OpenVMS
to that pc.