[Info-vax] Most popular application programming languages on VMS ?

[John Reagan]

On Thursday, January 10, 2019 at 2:45:16 PM UTC-5, Dave Froble wrote:
> On 1/10/2019 12:52 PM, John Reagan wrote:
> > On Thursday, January 10, 2019 at 12:31:23 PM UTC-5, Dave Froble wrote:
> >> On 1/10/2019 6:05 AM, gérard Calliet wrote:
> >>
> >>> I thought about collaboration, but it seems collaborated business is
> >>> very far from the VMS culture.
> >>
> >> I can see both sides of this issue.
> >>
> >> I offered to look at the DLM, attempt to implement numeric range
> >> locking.  I was told VSI doesn't have the time and people to
> >> manage/oversee any such work, at this time.
> >>
> >> I can understand that it could be a distraction.  The other side is,
> >> nothing is achieved.  I personally believe that VSI could use all the
> >> help they could get, but, they do need to be assured the help is not
> >> going to be a hindrance.
> >>
> >> I also see a difference.  What I proposed would have a direct effect on
> >> the port.  Helping provide an add-on, such as a compiler, would have no
> >> appreciable effect on the port.
> >>
> >> If VMS is to benefit from the things that have seemed to benefit Linux,
> >> ie; pieces developed and contributed by many people, then VSI would need
> >> to accept such contributions.  Now, I'm not making any accusations, but,
> >> I sometimes wonder if they want to be the sole owner of anything
> >> distributed with VMS.
> >>
> >> I'd hope they will in time accept contributions and collaboration.
> >>
> >> --
> >> David Froble                       Tel: 724-529-0450
> >> Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
> >> DFE Ultralights, Inc.
> >> 170 Grimplin Road
> >> Vanderbilt, PA  15486
> >
> > We've come back to that?  The DLM already has the support for ranges.  The CRTL uses it today for byte-range-locking.  It has to do more processing to deal with overlapping ranges vs completely contained ranges to match the POSIX definitions.
> >
> > $ search sys$library:starlet.req lki$_brl, lki$_range
> > literal LKI$_BRL = 265;                 !  IS THE LOCK A BYTE RANGE LOCK
> > literal LKI$_RANGE = 266;               !  Range of request
> 
> John, while I don't get out much, still, I've seen nothing in the 
> documentation about how to take out a byte range lock, nor nothing to 
> describe how such a capability works.  Does such exist?  Can you point 
> me to it?
> 
> Other than my not finding any documentation, it would not surprise me 
> that such has been implemented, since the only thing needed would be the 
> addition of a "type" piece of data to the lock data structures, and some 
> code to be executed for that specific type.
> 
> I don't know anything about Posix definitions.  However, it seems clear 
> to me, if a numeric range is locked, any request for any intersection 
> with that range would have to wait, or be denied.
> 
> It would be good to know this information, since a product I have can 
> perform I/O on any number of dick blocks, from 1 to 127.  Currently it 
> takes out a lock for each block when doing so.  Not the best solution.
> 
> 
> -- 
> David Froble                       Tel: 724-529-0450
> Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA  15486

I was discussing with Rob that the documentation for that DLM feature is probably buried in some New Features manual or in some CRTL update document.  It might not be written down anywhere (it probably should).

The CRTL uses the DLM with the range feature (don't think of them as bytes in a file, but just a specialization of a normal named lock) to be notified of multiple programs that are using the CRTL's implementation of fcntl().  

http://pubs.opengroup.org/onlinepubs/9699919799/ and search for "fcntl".

One could ask for RMS to provide such a feature as part of its interface (it would then have to use the DLM to implement it).  If that would happen, the CRTL's implementation of fcntl() could be greatly simplified.

And back to the question about "code donations", etc., such things get really complicated with licenses, ownership, patent protection, etc.  For example, if you send me something with a GPL license, I'll delete it.  If you send me something, with copyright to you, I'll delete it.  If you send me something with no copyright, I'll delete it.  I believe VSI's agreement with HPE would prevent it; plus GPL code might require us to open source vast amounts of OS code (but since we aren't the owner, we can't).  

The process for submitting code to LLVM requires a very specific license in the source files AND signed agreements from both the engineer and their employer (if available).  And it has been controversial as well.  LLVM is updating their license and it having to go back and have ALL updates from the beginning of time revetted and relicensed.  If the owner does not agree; cannot be found; no longer alive; etc., then the code will have to be removed and reimplemented.