Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.vms > #58749 > unrolled thread

PC/VT Keyboarrd Mapping

Back to article view | Back to comp.os.vms

Contents

  PC/VT Keyboarrd Mapping "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-22 04:08 -0500
    Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-22 11:15 +0200
      Re: PC/VT Keyboarrd Mapping Jim <mckinneyj@saic.com> - 2016-06-22 06:34 -0700
    Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 10:12 -0400
      Re: PC/VT Keyboarrd Mapping Paul Sture <nospam@sture.ch> - 2016-06-22 21:05 +0200
      Re: PC/VT Keyboarrd Mapping "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-22 22:06 -0500
    Re: PC/VT Keyboarrd Mapping David Froble <davef@tsoft-inc.com> - 2016-06-22 16:42 -0400
      Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 01:24 +0200
        Re: PC/VT Keyboarrd Mapping David Froble <davef@tsoft-inc.com> - 2016-06-22 20:08 -0400
          Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 08:48 -0400
            Re: PC/VT Keyboarrd Mapping koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 09:11 -0400
              Re: PC/VT Keyboarrd Mapping lawrencedo99@gmail.com - 2016-06-24 03:10 -0700
                Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-24 17:12 -0700
                  Re: PC/VT Keyboarrd Mapping hb <end.of@inter.net> - 2016-06-25 13:05 +0200
                    Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-25 06:22 -0700
                Re: PC/VT Keyboarrd Mapping David Froble <davef@tsoft-inc.com> - 2016-06-24 21:26 -0400
                  Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-25 08:20 -0400
                    Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 15:06 +0200
                      Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-25 10:14 -0400
                      Re: PC/VT Keyboarrd Mapping David Froble <davef@tsoft-inc.com> - 2016-06-25 12:59 -0400
                        Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 21:36 +0200
                          Re: PC/VT Keyboarrd Mapping David Froble <davef@tsoft-inc.com> - 2016-06-26 02:09 -0400
                            Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-26 10:42 +0200
                    Re: PC/VT Keyboarrd Mapping koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-27 09:28 -0400
                      Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-27 10:19 -0400
                Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 12:51 +0200
                  Re: PC/VT Keyboarrd Mapping   VAXman-  @SendSpamHere.ORG - 2016-06-25 11:48 +0000
                Re: PC/VT Keyboarrd Mapping helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-25 12:08 +0000
                  Re: PC/VT Keyboarrd Mapping Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 15:07 +0000
                  Re: PC/VT Keyboarrd Mapping koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-27 09:25 -0400
              Re: PC/VT Keyboarrd Mapping Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 14:59 +0000
                Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 21:41 +0200
                  Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-25 13:02 -0700
                    Re: PC/VT Keyboarrd Mapping hb <end.of@inter.net> - 2016-06-26 17:00 +0200
                      Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-26 08:39 -0700
                        Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 12:20 -0400
                          Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-26 10:20 -0700
                            math.h (Re: PC/VT Keyboarrd Mapping) "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-26 14:44 -0500
                            Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 16:04 -0400
                            Re: PC/VT Keyboarrd Mapping "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-26 15:31 -0500
                              Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 16:50 -0400
                                Re: PC/VT Keyboarrd Mapping lawrencedo99@gmail.com - 2016-06-26 19:09 -0700
                              Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-26 18:21 -0700
                                Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-27 10:07 -0400
                                  Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-27 12:33 -0700
                                    Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-27 16:06 -0400
                                      Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-28 05:29 -0700
                        Re: PC/VT Keyboarrd Mapping "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-26 11:21 -0500
                          Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-26 10:09 -0700
                    Emacs 21.2, was Re: PC/VT Keyboarrd Mapping hb <end.of@inter.net> - 2016-06-28 23:13 +0200
                      Re: Emacs 21.2, was Re: PC/VT Keyboarrd Mapping John Reagan <xyzzy1959@gmail.com> - 2016-06-29 10:04 -0700
                    Re: Emacs 21.2, was Re: PC/VT Keyboarrd Mapping helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-29 19:01 +0000
        Re: PC/VT Keyboarrd Mapping "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-22 23:09 -0400
          Re: PC/VT Keyboarrd Mapping Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 09:06 +0200
            Re: PC/VT Keyboarrd Mapping David Froble <davef@tsoft-inc.com> - 2016-06-23 12:48 -0400
          Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 08:57 -0400
            Re: PC/VT Keyboarrd Mapping "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-23 09:55 -0400
              Re: PC/VT Keyboarrd Mapping Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 10:39 -0400
                Re: PC/VT Keyboarrd Mapping "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-23 12:49 -0400
              Re: PC/VT Keyboarrd Mapping koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-24 08:44 -0400
              Re: PC/VT Keyboarrd Mapping lawrencedo99@gmail.com - 2016-06-24 03:11 -0700
    Re: PC/VT Keyboarrd Mapping lawrencedo99@gmail.com - 2016-06-22 20:59 -0700
      Re: PC/VT Keyboarrd Mapping "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-23 00:30 -0500
      Re: PC/VT Keyboarrd Mapping "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-23 00:33 -0500
      Re: PC/VT Keyboarrd Mapping "Paul Richards" <paulrichards@iinet.net.au> - 2016-06-23 00:36 -0500

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#58949

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 
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.

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

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

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

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

SSIO, among others.


-- 
Pure Personal Opinion | HoffmanLabs LLC 

[toc] | [prev] | [next] | [standalone]

#58957

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”.

[toc] | [prev] | [next] | [standalone]

#58956

On Sunday, June 26, 2016 at 4:31:41 PM UTC-4, John E. Malmberg wrote:
> On 6/26/2016 12:20 PM, John Reagan wrote:
> > 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).
> >
> > And some, like this one being discussed, should have never seen the
> > light of day. A new feature was added to the CRTL to make access()
> > smarter. Most folks might even call it a bug fix (I would). Why make it
> > default to 'off'? Why give you the option to return to the old behavior?
> > We don't invent logical names in other areas to selectively un-do a bug
> > fix! At the minimum, I'll make sure the default for this one turns into
> > 'enabled' (which is what I assumed it would be all along).
> 
> The issue is probably that many times a buggy behavior got fixed in the 
> VMS CRTL, it broke some significant customer code that was depending on 
> that bug.
> 
> After a few rounds of that, a team can get gun shy at making a fixed 
> behavior a default.
> 
> There is a big mess there.  And the thing do do might be to freeze 
> decc$shr and create a new decc$vsi_shr that is expected to follow the C 
> standards and not use run-time feature settings.
> 
> The big transition issue for this is that there are a number of really 
> bad VMS CRTL behaviors that should be fixed if you are splitting off a 
> fixed copy.
> 
> * Some feature and compile time defines are to enable fixed behaviors 
> that default to broken.
> 
> * Some feature and compile time defines are to enable broken behaviors 
> that default to fixed.
> 
> * And there are some a few that are needed to change from Unix to VMS 
> behaviors that rarely need to be run-time behaviors, but are not 
> available as compile time behaviors.
> 
> Regards,
> -John
> wb8tyw@qsl.net_work

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.

[toc] | [prev] | [next] | [standalone]

#58990

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.




-- 
Pure Personal Opinion | HoffmanLabs LLC 

[toc] | [prev] | [next] | [standalone]

#59014

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.

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

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

$ DEFINE/SYSTEM/EXEC DECC$UNIX_LEVEL 90

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

[toc] | [prev] | [next] | [standalone]

#59017

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.



-- 
Pure Personal Opinion | HoffmanLabs LLC 

[toc] | [prev] | [next] | [standalone]

#59045

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.

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

Those are the kind of scenarios that need to be discussed.  I'm all for breaking stuff. :) 
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#58942

On 6/26/2016 10:39 AM, John Reagan wrote:
> On Sunday, June 26, 2016 at 11:00:34 AM UTC-4, hb wrote:
>> 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
>> angle brackets - and I'll try to fix it. But I don't see a general
>> problem with extended parsing (for example, ^x^f works as expected on an
>> ODS-5 disk with extended parsing enabled). Can you give some examples
>> what doesn't work?
>
> It might have to do with some DECC$ logicals I set.  It comes up in
> raw emacs mode since it couldn't read the base emacs definitions.
> I'll figure out the guilty party and let you know.  Maybe a
> configuration issue at our end.
>
> It also doesn't like files with ACLs.  If I have write access via
> some held identifier but no write access via the protection mask, I
> only get read access.

It might be the setting of DECC$ACL_ACCESS_CHECK

Regards,
-John

[toc] | [prev] | [next] | [standalone]

#58943

On Sunday, June 26, 2016 at 12:21:41 PM UTC-4, John E. Malmberg wrote:
> On 6/26/2016 10:39 AM, John Reagan wrote:
> > On Sunday, June 26, 2016 at 11:00:34 AM UTC-4, hb wrote:
> >> 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
> >> angle brackets - and I'll try to fix it. But I don't see a general
> >> problem with extended parsing (for example, ^x^f works as expected on an
> >> ODS-5 disk with extended parsing enabled). Can you give some examples
> >> what doesn't work?
> >
> > It might have to do with some DECC$ logicals I set.  It comes up in
> > raw emacs mode since it couldn't read the base emacs definitions.
> > I'll figure out the guilty party and let you know.  Maybe a
> > configuration issue at our end.
> >
> > It also doesn't like files with ACLs.  If I have write access via
> > some held identifier but no write access via the protection mask, I
> > only get read access.
> 
> It might be the setting of DECC$ACL_ACCESS_CHECK
> 
> Regards,
> -John

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

[toc] | [prev] | [next] | [standalone]

#59069 — Emacs 21.2, was Re: PC/VT Keyboarrd Mapping

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
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
/
$

[toc] | [prev] | [next] | [standalone]

#59100 — Re: Emacs 21.2, was Re: PC/VT Keyboarrd Mapping

On Tuesday, June 28, 2016 at 5:13:36 PM UTC-4, hb wrote:
> 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
> 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
> /
> $

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).

[toc] | [prev] | [next] | [standalone]

#59105 — Re: Emacs 21.2, was Re: PC/VT Keyboarrd Mapping

In article <nkup9s$2q8$1@gioia.aioe.org>, hb <end.of@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.
> 
> It looks like the angel bracket problem shows/showed with concealed
> rooted logical names and the current default directory, when the latter
> is specified with square brackets - and vice versa.

One can define both versions.

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

[toc] | [prev] | [next] | [standalone]

#58814

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.

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

[toc] | [prev] | [next] | [standalone]

#58820

Den 2016-06-23 kl. 05:09, skrev Robert A. Brooks:
> 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.
>
> I've been using the same LK461 for over 16 years to develop our
> beloved operating system.  I've got a stock of them; they connect to
> various Windows
> systems using PowerTerm and a PS/2-to-USB adapter.
>
> Works quite well.
>

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

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

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



> Yes, I'm a traditionalist.
>

[toc] | [prev] | [next] | [standalone]

#58854

Jan-Erik Soderholm wrote:
> Den 2016-06-23 kl. 05:09, skrev Robert A. Brooks:
>> 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.
>>
>> I've been using the same LK461 for over 16 years to develop our
>> beloved operating system.  I've got a stock of them; they connect to
>> various Windows
>> systems using PowerTerm and a PS/2-to-USB adapter.
>>
>> Works quite well.
>>
> 
> Perhaps. Perhaps at VSI. But not at some place where VMS is
> already at stake and every additional little "thing" that make
> VMS stand out as "troublesome" will push it closer to the door.
> 
> We, who manage VMS in these environments must make watever we
> can to play along in the IT mainstream.
> 
> Pointing at VSI and claimning that a 16 year old LK461 works
> well *there*, doesn't help much.
> 
> 
> 
>> Yes, I'm a traditionalist.
>>
> 

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

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

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

Most people don't want a PC ...

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

Most people don't want a notebook ...

(which has even worse KB)

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

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

[toc] | [prev] | [next] | [standalone]

#58837

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

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

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

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

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



-- 
Pure Personal Opinion | HoffmanLabs LLC 

[toc] | [prev] | [next] | [standalone]

#58845

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 23-Jun-16 8:58 AM
> To: info-vax@rbnsn.com
> Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] PC/VT Keyboarrd Mapping
> 
> 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.
> > ...
> > I've been using the same LK461 for over 16 years to develop our
> beloved
> > operating system.  I've got a stock of them; they connect to various
> > Windows systems using PowerTerm and a PS/2-to-USB adapter.
> 
> You and the rest of VSI *need* to use what most customers are using
> now
> or soon will be using if/when changes are planned.
> 
> That won't be LK461 keyboards.   Not unless y'all are getting into
that
> production business.
> 
> OpenVMS *needs* to work effectively with the hardware the users are
> using, and not with a sixteen-year-old and out-of-production custom
> keyboard.
> 
> Or more succinctly, "dogfooding".
> https://en.wikipedia.org/wiki/Eating_your_own_dog_food
> 

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

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

:-)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[toc] | [prev] | [next] | [standalone]

#58847

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 
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.






-- 
Pure Personal Opinion | HoffmanLabs LLC 

[toc] | [prev] | [next] | [standalone]

#58855

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 23-Jun-16 10:39 AM
> To: info-vax@rbnsn.com
> Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] PC/VT Keyboarrd Mapping
> 
> 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
> encourage their own folks to use their own tools.
> 
> To use what they are selling.
> 
> In the case of OpenVMS, that usage doesn't and can't happen when
> you're
> using keyboards that simply aren't available anymore.
> 

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

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


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[toc] | [prev] | [next] | [standalone]

#58885

In article <mailman.16.1466690169.13355.info-vax_rbnsn.com@rbnsn.com>, "Kerry Main" <kemain.nospam@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.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.os.vms

csiph-web