info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PC/VT Keyboarrd Mapping
477 views
Skip to first unread message
Paul Richards
Jun 22, 2016, 5:08:58 AM6/22/16
to
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
--
Paul
Melbourne, Australia
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
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
--
Paul
Melbourne, Australia
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Jan-Erik Soderholm
Jun 22, 2016, 5:15:47 AM6/22/16
to
Den 2016-06-22 kl. 11:08, skrev 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...
> 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?
>
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.
Jim
Jun 22, 2016, 9:34:15 AM6/22/16
to
Stephen Hoffman
Jun 22, 2016, 10:12:31 AM6/22/16
to
On 2016-06-22 09:08:51 +0000, Paul Richards said:
> 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
> 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
>
> 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
> 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.
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.
> I'm not sure if this a VT question or a PuTTY question. If the latter
> I'd appreciate any links to possible solutions.
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
--
Pure Personal Opinion | HoffmanLabs LLC
Paul Sture
Jun 22, 2016, 3:05:58 PM6/22/16
to
On 2016-06-22, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2016-06-22 09:08:51 +0000, Paul Richards said:
<snip>
> On 2016-06-22 09:08:51 +0000, Paul Richards said:
> Windows from an aeon or two ago used NUMLOCK or shift-NUMLOCK for
> that embedded keypad, IIRC.
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.
--
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.
David Froble
Jun 22, 2016, 4:42:45 PM6/22/16
to
Paul Richards wrote:
> 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
> 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
>
dark day if it ever quite working ....
Jan-Erik Soderholm
Jun 22, 2016, 7:24:48 PM6/22/16
to
hardware there is. Asking for old discontinued keyboards will probably
only be an disservice to VMS, making it look even worse.
David Froble
Jun 22, 2016, 8:08:15 PM6/22/16
to
car?
Better, yes.
Backward, NO!
Paul Richards
Jun 22, 2016, 11:06:13 PM6/22/16
to
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.
Robert A. Brooks
Jun 22, 2016, 11:09:14 PM6/22/16
to
On 6/22/2016 7:24 PM, Jan-Erik Soderholm wrote:
> 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.
> 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.
Works quite well.
Yes, I'm a traditionalist.
--
-- Rob
lawren...@gmail.com
Jun 22, 2016, 11:59:39 PM6/22/16
to
On Wednesday, June 22, 2016 at 9:08:58 PM UTC+12, Paul Richards wrote:
> 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.
> I don't have a numeric keypad on my laptop but I have function keys F1
> - F12 and the usual QWERTY keyboard.
Paul Richards
Jun 23, 2016, 1:30:57 AM6/23/16
to
Paul Richards
Jun 23, 2016, 1:33:27 AM6/23/16
to
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
Jun 23, 2016, 1:36:36 AM6/23/16
to
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.
Jan-Erik Soderholm
Jun 23, 2016, 3:06:50 AM6/23/16
to
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.
Stephen Hoffman
Jun 23, 2016, 8:48:08 AM6/23/16
to
On 2016-06-23 00:08:13 +0000, David Froble said:
> Jan-Erik Soderholm wrote:
>>
>> 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.
> Jan-Erik Soderholm wrote:
>>
>> 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!
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.
Stephen Hoffman
Jun 23, 2016, 8:57:46 AM6/23/16
to
On 2016-06-23 03:09:13 +0000, Robert A. Brooks said:
> On 6/22/2016 7:24 PM, Jan-Erik Soderholm wrote:
>
>> 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.
> ...
> On 6/22/2016 7:24 PM, Jan-Erik Soderholm wrote:
>
>> 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
> operating system. I've got a stock of them; they connect to various
> Windows systems using PowerTerm and a PS/2-to-USB adapter.
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
Bob Koehler
Jun 23, 2016, 9:13:04 AM6/23/16
to
In article <nkglq6$p3s$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>
> 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
>
> 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.
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.
Kerry Main
Jun 23, 2016, 10:00:08 AM6/23/16
to comp.os.vms to email gateway
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
Jun 23, 2016, 10:39:28 AM6/23/16
to
On 2016-06-23 13:55:10 +0000, Kerry Main said:
>
> 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
>
> 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?
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.
David Froble
Jun 23, 2016, 12:48:18 PM6/23/16
to
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.
Kerry Main
Jun 23, 2016, 12:55:04 PM6/23/16
to comp.os.vms to email gateway
> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 23-Jun-16 10:39 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] PC/VT Keyboarrd Mapping
>
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 23-Jun-16 10:39 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] PC/VT Keyboarrd Mapping
>
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.
Bob Koehler
Jun 24, 2016, 8:45:39 AM6/24/16
to
In article <mailman.16.1466690169.1...@rbnsn.com>, "Kerry Main" <kemain...@gmail.com> writes:
>
> 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.
>
> Can you imagine telling Microsoft Engineers what tools they should
> use to build Windows?
lawren...@gmail.com
Jun 24, 2016, 7:40:24 PM6/24/16
to
On Friday, June 24, 2016 at 1:13:04 AM UTC+12, Bob Koehler wrote:
> 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.
> 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.
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.
lawren...@gmail.com
Jun 24, 2016, 7:53:33 PM6/24/16
to
On Friday, June 24, 2016 at 2:00:08 AM UTC+12, Kerry Main wrote:
> 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...
> Can you imagine telling Microsoft Engineers what tools they should
> use to build Windows?
John Reagan
Jun 24, 2016, 8:12:56 PM6/24/16
to
David Froble
Jun 24, 2016, 9:26:27 PM6/24/16
to
Jan-Erik Soderholm
Jun 25, 2016, 6:51:43 AM6/25/16
to
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.
hb
Jun 25, 2016, 7:06:07 AM6/25/16
to
On 06/25/2016 02:12 AM, John Reagan wrote:
>>> 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.
>>> 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.
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).
VAXman-
Jun 25, 2016, 7:48:17 AM6/25/16
to
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Phillip Helbig (undress to reply)
Jun 25, 2016, 8:08:25 AM6/25/16
to
In article <1f7121c1-17ec-4541...@googlegroups.com>,
proper keyboard.
> 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
> 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.)
lawren...@gmail.com writes:
> > 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
> > 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.
proper keyboard.
> EDT is another tool that needs to die.
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
> 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.
EDT emulation on unix. :-) (However, it just emulates the keypad.)
Stephen Hoffman
Jun 25, 2016, 8:20:10 AM6/25/16
to
On 2016-06-25 01:26:25 +0000, David Froble said:
> 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.
> Why is it that whatever you use is great ... and whatever I use should die?
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
Jun 25, 2016, 9:06:18 AM6/25/16
to
Den 2016-06-25 kl. 14:20, skrev Stephen Hoffman:
> On 2016-06-25 01:26:25 +0000, David Froble said:
>
>> Why is it that whatever you use is great ... and whatever I use should die?
>
> On 2016-06-25 01:26:25 +0000, David Froble said:
>
>> 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.
> 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.
> and keypad-based editors — is dying out...
EDT isn't "dying". Or, it is dying at the same pace as VMS is.
> OpenVMS apps either need to forget about the VMS-layout LK and/or provide
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.
John Reagan
Jun 25, 2016, 9:22:26 AM6/25/16
to
On Saturday, June 25, 2016 at 7:06:07 AM UTC-4, hb wrote:
> On 06/25/2016 02:12 AM, John Reagan wrote:
> >>> 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.
> On 06/25/2016 02:12 AM, John Reagan wrote:
> >>> 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.
>
Doug G uses the older DEC Emacs, not sure of the heritage of that one.
Stephen Hoffman
Jun 25, 2016, 10:14:46 AM6/25/16
to
On 2016-06-25 13:06:18 +0000, Jan-Erik Soderholm said:
> Den 2016-06-25 kl. 14:20, skrev Stephen Hoffman:
>> On 2016-06-25 01:26:25 +0000, David Froble said:
>>
>>> 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
> Den 2016-06-25 kl. 14:20, skrev Stephen Hoffman:
>> On 2016-06-25 01:26:25 +0000, David Froble said:
>>
>>> 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.
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.
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.
>
>> 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 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.
>> 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
>> and keypad-based editors — is dying out...
>
> EDT isn't "dying". Or, it is dying at the same pace as VMS is.
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.
>> 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.
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.
Simon Clubley
Jun 25, 2016, 10:59:31 AM6/25/16
to
On 2016-06-23, Bob Koehler <koe...@eisner.nospam.decuserve.org> wrote:
>
> 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'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 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.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
Jun 25, 2016, 11:07:38 AM6/25/16
to
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)]
David Froble
Jun 25, 2016, 12:59:47 PM6/25/16
to
What he wrote ....
Jan-Erik Soderholm
Jun 25, 2016, 3:36:06 PM6/25/16
to
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.
Jan-Erik Soderholm
Jun 25, 2016, 3:41:32 PM6/25/16
to
Den 2016-06-25 kl. 16:59, skrev Simon Clubley:
> On 2016-06-23, Bob Koehler <koe...@eisner.nospam.decuserve.org> wrote:
>>
>> 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.
> On 2016-06-23, Bob Koehler <koe...@eisner.nospam.decuserve.org> wrote:
>>
>> 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.
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
Jun 25, 2016, 4:02:51 PM6/25/16
to
David Froble
Jun 26, 2016, 2:09:53 AM6/26/16
to
be a black day when my keyboard died. Nothing about apps.
Just picked up a LK450 ....
:-)
Jan-Erik Soderholm
Jun 26, 2016, 4:42:06 AM6/26/16
to
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...
hb
Jun 26, 2016, 11:00:34 AM6/26/16
to
On 06/25/2016 10:02 PM, John Reagan wrote:
> 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
> 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.
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
Jun 26, 2016, 11:39:59 AM6/26/16
to
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
Jun 26, 2016, 12:20:56 PM6/26/16
to
On 2016-06-26 15:39:57 +0000, John Reagan said:
> 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
> It might have to do with some DECC$ logicals I set.
names won't continue to derail unrelated applications.
John E. Malmberg
Jun 26, 2016, 12:21:41 PM6/26/16
to
Regards,
-John
John Reagan
Jun 26, 2016, 1:09:39 PM6/26/16
to
John Reagan
Jun 26, 2016, 1:20:34 PM6/26/16
to
On Sunday, June 26, 2016 at 12:20:56 PM UTC-4, Stephen Hoffman wrote:
> On 2016-06-26 15:39:57 +0000, John Reagan said:
>
> > 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).
> On 2016-06-26 15:39:57 +0000, John Reagan said:
>
> > 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.
>
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
Jun 26, 2016, 3:44:52 PM6/26/16
to
On 6/26/16 12:20 PM, John Reagan wrote:
>
> 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.
>
> 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
Jun 26, 2016, 4:04:39 PM6/26/16
to
On 2016-06-26 17:20:33 +0000, John Reagan said:
> On Sunday, June 26, 2016 at 12:20:56 PM UTC-4, Stephen Hoffman wrote:
>> On 2016-06-26 15:39:57 +0000, John Reagan said:
>>
>>> 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
> On Sunday, June 26, 2016 at 12:20:56 PM UTC-4, Stephen Hoffman wrote:
>> On 2016-06-26 15:39:57 +0000, John Reagan said:
>>
>>> 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).
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.
> And some, like this one being discussed, should have never seen the
> light of day.
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
Jun 26, 2016, 4:31:41 PM6/26/16
to
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
wb8...@qsl.net_work
Stephen Hoffman
Jun 26, 2016, 4:50:31 PM6/26/16
to
On 2016-06-26 20:31:44 +0000, John E. Malmberg said:
> 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
> 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.
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.
> 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.
deprecated and — what should happen for these cases, but likely won't —
announce a schedule for eventual removal.
> 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.
some are not.
> * 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.
John Reagan
Jun 26, 2016, 9:22:00 PM6/26/16
to
lawren...@gmail.com
Jun 26, 2016, 10:09:19 PM6/26/16
to
On Monday, June 27, 2016 at 8:50:31 AM UTC+12, Stephen Hoffman wrote:
> Compatibility and piling on the technical debt and adding
> arcana and complexity?
A.k.a. “Microsoft Windows”.
> Compatibility and piling on the technical debt and adding
> arcana and complexity?
Bob Koehler
Jun 27, 2016, 9:27:24 AM6/27/16
to
In article <nkls7n$unl$2...@news.kjsl.com>, hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
> In article <1f7121c1-17ec-4541...@googlegroups.com>,
> lawren...@gmail.com writes:
>
>> > 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.
>
lawren...@gmail.com didn't write that, I did.
> In article <1f7121c1-17ec-4541...@googlegroups.com>,
> lawren...@gmail.com writes:
>
>> > 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.
>
Bob Koehler
Jun 27, 2016, 9:30:01 AM6/27/16
to
In article <nklstl$vhn$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>
> 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
>
> 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.)
there using nu/TPU from a/Soft. Runs on lots of platforms.
Stephen Hoffman
Jun 27, 2016, 10:07:59 AM6/27/16
to
On 2016-06-27 01:21:58 +0000, John Reagan said:
> 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
> 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.
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.
Stephen Hoffman
Jun 27, 2016, 10:19:50 AM6/27/16
to
John Reagan
Jun 27, 2016, 3:33:42 PM6/27/16
to
On Monday, June 27, 2016 at 10:07:59 AM UTC-4, Stephen Hoffman wrote:
> On 2016-06-27 01:21:58 +0000, John Reagan said:
>
> > 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.
> On 2016-06-27 01:21:58 +0000, John Reagan said:
>
> > 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.
>
$ 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
Jun 27, 2016, 4:06:21 PM6/27/16
to
On 2016-06-27 19:33:40 +0000, John Reagan said:
> 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
> Common enough that there was work to make sure the native RTLs and
> translated RTLs cooperated. The Fortran RTLs share LUN information for
> example.
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.
> 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.
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
Jun 28, 2016, 8:30:00 AM6/28/16
to
On Monday, June 27, 2016 at 4:06:21 PM UTC-4, Stephen Hoffman wrote:
> On 2016-06-27 19:33:40 +0000, John Reagan said:
>
> > 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.
> On 2016-06-27 19:33:40 +0000, John Reagan said:
>
> > 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.
>
> > 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.
> 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.
>
> > 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.
>
hb
Jun 28, 2016, 5:13:36 PM6/28/16
to
On 06/25/2016 10:02 PM, John Reagan wrote:
> 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
> 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.
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
Jun 29, 2016, 1:04:42 PM6/29/16
to
Phillip Helbig (undress to reply)
Jun 29, 2016, 3:01:31 PM6/29/16
to
In article <nkup9s$2q8$1...@gioia.aioe.org>, hb <end...@inter.net> writes:
> > 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.
>
> > 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.
> rooted logical names and the current default directory, when the latter
> is specified with square brackets - and vice versa.
Of course, > as part of a directory spec will confuse PIPE.
petehe...@gmail.com
Feb 20, 2017, 12:15:01 AM2/20/17
to
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?
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
Feb 20, 2017, 3:49:31 AM2/20/17
to
> Do you know [...]
No.
> [...] do you know if either of these keyboards will work
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.
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?
> connect to while using my Mac computer?
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
Feb 20, 2017, 1:06:22 PM2/20/17
to
In article <090cd350-1aef-4817...@googlegroups.com>, petehe...@gmail.com writes:
> 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
> 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?
your Mac to emulate a terminal.
John Reagan
Feb 20, 2017, 2:44:59 PM2/20/17
to
On Monday, February 20, 2017 at 1:06:22 PM UTC-5, Bob Koehler wrote:
> In article <>, peteherrera writes:
> > 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).
> > 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.
Stephen Hoffman
Feb 22, 2017, 2:01:58 PM2/22/17
to
On 2017-02-20 05:14:58 +0000, petehe...@gmail.com said:
> 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
> 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?
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.
> 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?
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.
0 new messages