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

Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 latterI'd appreciate any links to possible solutions.

Thanks

--PaulMelbourne, Australia

---This email has been checked for viruses by Avast antivirus software.https://www.avast.com/antivirus

Post by Paul RichardsI'm running OpenVMS on the FreeAXP emulator with PuTTY, which isbundled with FreeAXP.Unfortunately my PC keyboard does not make it easyto use VMS software like editors, e.g. EDT, as the keycodes emitted donot match up with those expected from a VT100/200 etc.Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 thesedays, a laptop with numaric keypad has become standard and youpay extra for the smaller/lighter models, not the other wayaround as it was some years ago.

Post by Paul Richardsbut 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 latterI'd appreciate any links to possible solutions.Thanks

Post by Paul RichardsI'm running OpenVMS on the FreeAXP emulator with PuTTY, which isbundled with FreeAXP.Unfortunately my PC keyboard does not make it easyto use VMS software like editors, e.g. EDT, as the keycodes emitted donot match up with those expected from a VT100/200 etc.Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 thesedays, a laptop with numaric keypad has become standard and youpay extra for the smaller/lighter models, not the other wayaround as it was some years ago.

Post by Paul Richardsbut 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 latterI'd appreciate any links to possible solutions.Thanks

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

Post by Paul RichardsI'm running OpenVMS on the FreeAXP emulator with PuTTY, which isbundled with FreeAXP.Unfortunately my PC keyboard does not make it easyto use VMS software like editors, e.g. EDT, as the keycodes emitted donot match up with those expected from a VT100/200 etc.0Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 theabsence 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 outhow to use the tools without needing the keypad, or figuring out whichchord the keyboard uses to generate the particular keypress, or gettingan 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 toenable the keypad within the keyboard. Windows from an aeon or two agoused NUMLOCK or shift-NUMLOCK for that embedded keypad, IIRC.

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

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

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

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

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

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

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

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

--PaulMelbourne, Australia

---This email has been checked for viruses by Avast antivirus software.https://www.avast.com/antivirus

Post by Paul RichardsI'm running OpenVMS on the FreeAXP emulator with PuTTY, which isbundled with FreeAXP.Unfortunately my PC keyboard does not make it easyto use VMS software like editors, e.g. EDT, as the keycodes emitted donot match up with those expected from a VT100/200 etc.Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 latterI'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 adark day if it ever quite working ....

Post by Paul RichardsI'm running OpenVMS on the FreeAXP emulator with PuTTY, which isbundled with FreeAXP.Unfortunately my PC keyboard does not make it easyto use VMS software like editors, e.g. EDT, as the keycodes emitted donot match up with those expected from a VT100/200 etc.Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 latterI'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 tobe a dark day if it ever quite working ....

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

Post by Paul RichardsI'm running OpenVMS on the FreeAXP emulator with PuTTY, which isbundled with FreeAXP.Unfortunately my PC keyboard does not make it easyto use VMS software like editors, e.g. EDT, as the keycodes emitted donot match up with those expected from a VT100/200 etc.Is there a way of somehow mapping the PC keyboard so that the keycodesemitted 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 latterI'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 tobe a dark day if it ever quite working ....

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

Post by Jan-Erik SoderholmAny truly professional would quickly adopt to whatever new/modernhardware there is. Asking for old discontinued keyboards will probablyonly be an disservice to VMS, making it look even worse.

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

Post by Stephen HoffmanVSI has a choice to make. Adopt the PC keyboard in OpenVMS softwareand RTLs and in the documentation, adopt some other keyboard such asthe Apple extended wired, or get into the traditional LK keyboardmanufacturing business directly or with Nemonix or some other vendor.Or continue to ignore the keyboard difficulties and presume that theVT/LK keyboard interface is an emulator problem, which has been thekeyboard strategy for a while. But those existing LK keyboards are allaging out. That's even if VSI's statements against plans for OpenVMSworkstation support hold, as you'll still need console or iLO or DRACkeyboard access for the baseline configuration and then for servermanagement 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 havekeyboard layouts for EDT and DEBUG that are PC friendly. TPU'spredefined keyboards should also have that variation.

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

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard 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.

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard 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.

Post by l***@gmail.comNowadays of course I use Emacs. Is Emacs available for VMS? Thathas to be a big improvement to whatever DEC-originated editor youmight be using now.

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

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 whichclaim 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 andwork on Alpha. In the same directory there are source code changes forthat version which make it build and run on I64. Inhttps://groups.google.com/forum/#!topic/comp.os.vms/DGISjZP4fUs%5B151-175%5Dthere is a pointer to changes for VAX.

Then there is microemacs (uemacs or µemacs) which should build and runon VMS. I haven't tried it for a long time. I don't know what thecurrent version is. There was at least the popular version 3.12 forwhich you can find executables for VAX and Alpha. It's not obvious to mewhether 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 shouldbuild on Alpha and I64. It is still maintained. There are executables ofan older version (0.99-17) on the VMS freeware CD V7.0 (the version onV8.0 is even older).

Post by l***@gmail.comNowadays of course I use Emacs. Is Emacs available for VMS? Thathas to be a big improvement to whatever DEC-originated editor youmight be using now.

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

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 whichclaim 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 andwork on Alpha. In the same directory there are source code changes forthat version which make it build and run on I64. Inhttps://groups.google.com/forum/#!topic/comp.os.vms/DGISjZP4fUs%5B151-175%5Dthere 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.

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard 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?

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

Unfortunately what you're using — the keypad-based application andkeypad-based editors — is dying out, David. (I too became quite fondof 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 thosethat really needed it — to the PC-compatible keyboard.) Theadded-function-button PC keyboards are becoming scarce, too.

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

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

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

But for OpenVMS software and tools — whether you're at VSI or anend-user, and whether the software is OpenVMS itself or someapplication package — the DEC VT LK-series keyboard is no longermanufactured. If that doesn't provide a convincing argument aroundwhere hardware and dependent software is inevitably headed, I'm notsure what will. Even if the LK production starts up again, that stilladds hardware dependencies for all of the users involved in theLK-dependent project.

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

Post by Stephen HoffmanOpenVMS apps either need to forget about the VMS-layout LK and/or providean alternative to the keypad...

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

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

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

Big and heavy laptops, sure. Some folks have called thosebattleship-class. For the folks that are unable or unwilling to carryaround 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 hookup an external keyboard and screen anyway.

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

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

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

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 arecertainly preferable to those still using a DEC LK layout, but thoseapplications are still reducing what hardware is compatible with theapplications.

EDT was deprecated some twenty years ago. EVE/TPU and LSEDIT were themigration 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'tdepend on the keypad — PC extended, or particularly the DEC LK — beingavailable.

Post by Stephen HoffmanOpenVMS apps either need to forget about the VMS-layout LK and/or providean alternative to the keypad...

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

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

Get off the LK.

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

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

Post by Stephen HoffmanOpenVMS apps either need to forget about the VMS-layout LK and/or providean alternative to the keypad...

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

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

Post by Stephen HoffmanOpenVMS apps either need to forget about the VMS-layout LK and/or providean alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few smalldifferences that should be easy to learn for any IT professional.Or are you now talking about the end-user applications? Yes, they shouldnot be depending on VT-style kayboards and keys, and they will probablymostly be based on web interfaces, so it is a non-issue. I do not seea 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 thenthe one you are talking about.

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

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

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

Post by Stephen HoffmanOpenVMS apps either need to forget about the VMS-layout LK and/or providean alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few smalldifferences that should be easy to learn for any IT professional.Or are you now talking about the end-user applications? Yes, they shouldnot be depending on VT-style kayboards and keys, and they will probablymostly be based on web interfaces, so it is a non-issue. I do not seea 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 thenthe one you are talking about.If one look at the VMS markets today (banking, large companieslogistics back-office), that is not VT-based.And again, we should not mix up the end-users environmentwith 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 tobe a black day when my keyboard died. Nothing about apps.

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

Post by Stephen HoffmanOpenVMS apps either need to forget about the VMS-layout LK and/or providean alternative to the keypad...

The keypad works just OK on any standard PC keyboard. With a few smalldifferences that should be easy to learn for any IT professional.Or are you now talking about the end-user applications? Yes, they shouldnot be depending on VT-style kayboards and keys, and they will probablymostly be based on web interfaces, so it is a non-issue. I do not seea 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 thenthe one you are talking about.If one look at the VMS markets today (banking, large companieslogistics back-office), that is not VT-based.And again, we should not mix up the end-users environmentwith what we as programmers might prefer or use.

And I did no such thing. All I wrote in another post was that it was goingto 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 isirrelevant for OpenVMS as such. Fine then. And I'm sure you'd bebetter prepared for the future by *not* picking up any LK450...

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

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

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

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

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard 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 (alocal adaptation of some code originally from DECUS or somewhere).Unfortunately that was never ported to the VAX. So I gritted my teethand put up with EDT for whatever far-too-long fraction of my lifetime itwas until TPU came along, which was halfway decent in comparison (evenwith that weird initial (mis)behaviour with search pattern matches).Nowadays of course I use Emacs. Is Emacs available for VMS? That has tobe a big improvement to whatever DEC-originated editor you might beusing now.

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

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

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard 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 (alocal adaptation of some code originally from DECUS or somewhere).Unfortunately that was never ported to the VAX. So I gritted my teethand put up with EDT for whatever far-too-long fraction of my lifetime itwas until TPU came along, which was halfway decent in comparison (evenwith that weird initial (mis)behaviour with search pattern matches).Nowadays of course I use Emacs. Is Emacs available for VMS? That has tobe a big improvement to whatever DEC-originated editor you might beusing now.

My first and most important requirement on an editor is that it alwaysshould be available "out-of-the" box no matter what customer site I getto. So anything that doesn't come with VMS is out, such as Emacs.Then, personaly, I never have come around learning TPU, EDT has servedme well both in the early days on RSX and VMS. Now, I haven't lookedtoo 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.

Though it has a couple of limitations (doesn't like lines longer than255 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. Ithas some advantages over EVE: it is faster, it doesn't read in the wholefile unless necessary, it is easier to use in batch, the cursor movementis more sensible, macros can be written more compactly.

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

Post by l***@gmail.comNowadays of course I use Emacs. Is Emacs available for VMS? That has to bea 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 theEDT emulation on unix. :-) (However, it just emulates the keypad.)

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard layouts for EDT and DEBUG that are PC friendly. TPU'spredefined 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 adaily basis and it works fine. The only real difference is that there'sno delete word key (which I don't miss) and the 3x2 keypad between themain keyboard and the keypad is used based on PC key labeling and notthe LK keypad assigned position.

This means that Page up is the top right key, Page down is the bottomright 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 keypadbased editor (either emacs on Linux or TPU on VMS) just fine.

Simon.

--Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFPMicrosoft: Bringing you 1980s technology to a 21st century world

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard layouts for EDT and DEBUG that are PC friendly. TPU'spredefined 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 ClubleyI do however use the EDT keypad layout on a full PC keyboard on adaily basis and it works fine. The only real difference is that there'sno delete word key (which I don't miss) and the 3x2 keypad between themain keyboard and the keypad is used based on PC key labeling and notthe LK keypad assigned position.This means that Page up is the top right key, Page down is the bottomright 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 keypadbased 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 weditched the VT520's 25 (or whatever) years ago.

Post by Bob KoehlerI've asked for this before, and I'll say it again. VMS needs to havekeyboard layouts for EDT and DEBUG that are PC friendly. TPU'spredefined 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 ClubleyI do however use the EDT keypad layout on a full PC keyboard on adaily basis and it works fine. The only real difference is that there'sno delete word key (which I don't miss) and the 3x2 keypad between themain keyboard and the keypad is used based on PC key labeling and notthe LK keypad assigned position.This means that Page up is the top right key, Page down is the bottomright 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 keypadbased 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 weditched 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.

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

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

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

Admitted, I'm not a regular Emacs user, but I can see the problem withangle brackets - and I'll try to fix it. But I don't see a generalproblem with extended parsing (for example, ^x^f works as expected on anODS-5 disk with extended parsing enabled). Can you give some exampleswhat 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.

Nuke those from orbit. It's the only way to be sure those logicalnames 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).

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 pointclassification macros. The standard says they should work for"real-floating" data of any size, but the ones you've got now only workfor doubles, not for singles or long doubles. For example, here's thesignbit implementation you have now:

it will work for S_FLOAT, T_FLOAT, and X_FLOAT equally well because thebyte containing the classification info follows the same pattern, butjust has a different location for the different sizes. Similar thingsshould be possible for isnan, isinf, etc.

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

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 missingstuff to other headers, untangling the mess inside math.h, etc.).There are about 1/3rd of the logicals that I'm tempted to remove andpick a 'mandatory default'. I don't think anybody would know (but thenagain, those probably aren't the ones screwing people over).

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

Post by John ReaganAnd some, like this one being discussed, should have never seen thelight of day.

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

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

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

over).

Post by John ReaganAnd some, like this one being discussed, should have never seen thelight 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 itdefault 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 bugfix! 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 theVMS CRTL, it broke some significant customer code that was depending onthat bug.

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

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

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

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

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

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

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

Ayup, and you're always and inevitably left with a decision in thesecases. Compatibility and piling on the technical debt and addingarcana and complexity? Or forward progress for VSI and for customersmaintaining 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. MalmbergThere is a big mess there. And the thing do do might be to freezedecc$shr and create a new decc$vsi_shr that is expected to follow the Cstandards and not use run-time feature settings.

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

Post by John E. MalmbergThe big transition issue for this is that there are a number of reallybad VMS CRTL behaviors that should be fixed if you are splitting off afixed copy.* Some feature and compile time defines are to enable fixed behaviorsthat default to broken.* Some feature and compile time defines are to enable broken behaviorsthat 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 VMSbehaviors that rarely need to be run-time behaviors, but are notavailable as compile time behaviors.

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

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

over).

Post by John ReaganAnd some, like this one being discussed, should have never seen thelight 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 itdefault 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 bugfix! 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 theVMS CRTL, it broke some significant customer code that was depending onthat bug.After a few rounds of that, a team can get gun shy at making a fixedbehavior a default.There is a big mess there. And the thing do do might be to freezedecc$shr and create a new decc$vsi_shr that is expected to follow the Cstandards and not use run-time feature settings.The big transition issue for this is that there are a number of reallybad VMS CRTL behaviors that should be fixed if you are splitting off afixed copy.* Some feature and compile time defines are to enable fixed behaviorsthat default to broken.* Some feature and compile time defines are to enable broken behaviorsthat default to fixed.* And there are some a few that are needed to change from Unix to VMSbehaviors that rarely need to be run-time behaviors, but are notavailable 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.

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

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

Announce the new RTL and preferably with all of the core VSI apps andtools migrated and with most of the rest migrating, announce thatmixing RTLs won't work and isn't supported, announce the publicschedule for the deprecation of the old RTL first through the removaland relocation of old RTL into a separate and extra-cost license andinstallation, and then through copying the RTL and the compatibilitykit to NLA0:.

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

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

Make the folks that don't want to move and don't want to migrate payfor that, if they are even upgrading. Make the folks that are movingand are updating their apps have an easier time, and with bettercapabilities.

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

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

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 HoffmanAnnounce the new RTL and preferably with all of the core VSI apps andtools migrated and with most of the rest migrating, announce thatmixing RTLs won't work and isn't supported, announce the publicschedule for the deprecation of the old RTL first through the removaland relocation of old RTL into a separate and extra-cost license andinstallation, and then through copying the RTL and the compatibilitykit to NLA0:.This deprecation might well be fodder for using the multi-versionapproach, if y'all start to make that into a supportable andsustainable design for OpenVMS itself and for applications.Getting rid of specific and targeted and problematic old code andredesigning or replacing inadequate or broken or insecure APIs is acomplete shift from past practice. But it's also the only way you'regoing to make more than token forward progress with OpenVMS.Make the folks that don't want to move and don't want to migrate payfor that, if they are even upgrading. Make the folks that are movingand are updating their apps have an easier time, and with bettercapabilities.

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.

Post by John ReaganCommon enough that there was work to make sure the native RTLs andtranslated RTLs cooperated. The Fortran RTLs share LUN information forexample.

But that's an instance of the "same" RTL translated, and not acompletely 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'dexpect that to interoperate with other translated code using atranslated VAX C RTL and native Compaq C RTL circa C90 mixed in for themost complete code conflagration.

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

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

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

Post by John ReaganCommon enough that there was work to make sure the native RTLs andtranslated RTLs cooperated. The Fortran RTLs share LUN information forexample.

But that's an instance of the "same" RTL translated, and not acompletely 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 HoffmanNow if I had code using VSI Clang LLVM RTL C11, I'm not so sure I'dexpect that to interoperate with other translated code using atranslated VAX C RTL and native Compaq C RTL circa C90 mixed in for themost complete code conflagration.

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

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

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

Tried that knob some years ago. Those switches are much like playingminesweeper. Various routines blow up within (formerly) running code.That's also part of why I utterly despise that mechanism, as some ofthose errors can be quite subtle when you're off app-stacking andsomebody wants one of those knobs and somebody else has an adversereaction. But then I (again) realize that basename() is utterly borkedwhen 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.

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

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

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

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

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

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

It might be the setting of DECC$ACL_ACCESS_CHECKRegards,-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...

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

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

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

What didn't work was editing a file specified like<>lowercase.txtorroot:<whatever>lowercase.txtwith 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'tbreak something else. The changes are independent of the platformsVAX/Alpha/I64. Diffs/patches are appended. Whether the change can/needsto 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 asrecent include files and HP C V7.3-010.

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

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

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

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

It looks like the angel bracket problem shows/showed with concealedrooted logical names and the current default directory, when the latteris specified with square brackets - and vice versa.Process set to extended parsingCurrent directory on an ODS-5 disk: [] styleCopy of the emacs dump file saved as Emacs-21_2.Dump;1 in the currentdirectoryFile names in lowercaseFor example$ mcr bld_root:[local.bin]emacs-21_2 -map <>emacs-21_2.dumpsys$disk:<>lowercase.txtWhat didn't work was editing a file specified like<>lowercase.txtorroot:<whatever>lowercase.txtwith 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'tbreak something else. The changes are independent of the platformsVAX/Alpha/I64. Diffs/patches are appended. Whether the change can/needsto 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 asrecent include files and HP C V7.3-010.To build in this environment (and likely on recent I64 versions) youneed to make the call to access() consistent, either always use (the#defined) sys_access() and maybe prefix that with __LONG_GID_ or useaccess() from decc$shr. I dared to do the first one (OK, looks like ahack, because including unistd.h in VMSFNS.C creates more compile timeerrors/warnings than I wanted to handle). Otherwise my friend the LINKERwill complain about an undefined symbol SYS_ACCESS in VMSFNS.OBJ - andthe LINKER is always right :-)On not so recent versions, especially of unistd.h, there is no suchbuild problem - and sys_access, more or less a CRTL-workaround-code, isused.When using access() from DECC$SHR, I experienced write access problemsfor files which were not write protected. I didn't spend the time toinvestigate. 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 *.difBLD_ROOT:[EMACS.BUILD]FILEIO.DIF;1- 1064int fbrack = 0;- 1232fbrack = 0;- 1258, 1263{lbrack++, brack = 0;if (fbrack==0)fbrack = p[0];elsep[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] == '<'))- 1303p = 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_"#endifint 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).

Post by Jan-Erik SoderholmAny truly professional would quickly adopt to whatever new/modernhardware there is. Asking for old discontinued keyboards will probablyonly be an disservice to VMS, making it look even worse.

Perhaps.

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

Post by Jan-Erik SoderholmAny truly professional would quickly adopt to whatever new/modernhardware there is. Asking for old discontinued keyboards will probablyonly be an disservice to VMS, making it look even worse.

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

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

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

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

Post by Jan-Erik SoderholmAny truly professional would quickly adopt to whatever new/modernhardware there is. Asking for old discontinued keyboards will probablyonly be an disservice to VMS, making it look even worse.

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

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

Post by Jan-Erik SoderholmAny truly professional would quickly adopt to whatever new/modernhardware there is. Asking for old discontinued keyboards will probablyonly be an disservice to VMS, making it look even worse.

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

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

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

OpenVMS *needs* to work effectively with the hardware the users areusing, and not with a sixteen-year-old and out-of-production customkeyboard.

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

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

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

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

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

Post by Kerry MainAnother view of this would be "carpenters should never tell anothercarpenter what tools they should use on a project"Can you imagine telling Microsoft Engineers what tools they should useto build Windows?

"Dogfooding" is a term originally used by Microsoft, and intended toencourage 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'reusing keyboards that simply aren't available anymore.

Post by Kerry MainAnother view of this would be "carpenters should never tell anothercarpenter what tools they should use on a project"Can you imagine telling Microsoft Engineers what tools they should useto build Windows?

"Dogfooding" is a term originally used by Microsoft, and intended toencourage 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'reusing keyboards that simply aren't available anymore.

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

Post by Kerry MainCan you imagine telling Microsoft Engineers what tools they shoulduse 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...

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

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

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

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

Post by p***@gmail.comDo 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 onyour Mac to emulate a terminal.

Post by p***@gmail.comDo 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 onyour 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).

Post by p***@gmail.comDo you know if a lk461-aa keyboard or a Realforce RGB keyboard or theTopre Realforce 104UG high profile 45g keyboard will work on a Macwhich is running MacOS Sierra?

For what purpose? Running macOS as a remote client for an OpenVMSsystem? Booting OpenVMS via simh? As a DEC-compatible PS/2keyboard, 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 toUSB or USB-C — I've not found one — the DEC-specific keys won't berecognized by macOS and whatever terminal emulator you're planning touse without added customizations. LK463 USB keyboard might be alittle 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 workwith 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 elsewhereon mapping the macOS function keys, though I've found it entirelyfeasible to operate with the standard keyboard and command-linecommands within various of the OpenVMS tools and utilities; within EDTor 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, thoughiTerm2 and some other terminal emulators for macOS are also used byvarious folks.

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

vim or emacs are alternatives for OpenVMS and for macOS, and theextended 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 andsoftware chains to keep these keypads working are only going to getlonger and more precarious. Recent Mac systems already need dongles,at least until USB-C widgets become more prevalent. Which meanslearning command mode, and (hopefully, eventually) VSI starts toremediate the existing assumptions and dependencies on editing andfunction keypads.

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

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

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

--PaulMelbourne, Australia

---This email has been checked for viruses by Avast antivirus software.https://www.avast.com/antivirus

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

Do you have a key labelled “Fn”, along with alternate labels on somekeys that look like a numeric keypad? My laptop provides its numerickeypad 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 anotherlaptop with a numeric keypad and I have transferred my FreeAXP/OpenVMSto that pc.

--PaulMelbourne, Australia

---This email has been checked for viruses by Avast antivirus software.https://www.avast.com/antivirus