On 2022-11-15, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2022-11-15 kl. 15:11, skrev Simon Clubley:
>> On 2022-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/14/2022 1:59 PM, Simon Clubley wrote:
>>>> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>>>>> As software becomes more and more expensive, I think the need to have an
>>>>>>>> efficient operating system that provides database features in the kernel
>>>>>>>> becomes more important.
>>>>>>>
>>>>>>> Database in the actual OS kernel or just database shipping with the
>>>>>>> OS distribution?
>>>>>>>
>>>>>>> It is not uncommon to put application functionality in the
>>>>>>> kernel today, but I am not keen on the idea.
>>>>>>
>>>>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>>>>> I want fast database access, I want rapid transaction turnover, I don't care
>>>>>> necessarily about realtime operation or any direct UI other than for
>>>>>> administration, or ever specifically making deadline. I'm thinking of a
>>>>>> specialized database engine.
>>>>>
>>>>> I don't think I have ever heard about that for database.
>>>>
>>>> Rdb ? :-)
>>>
>>> I thought that was in user space not kernel space (P0 vs S0 in
>>> more VMSish teminology).
>>>
>>
>> I thought the core Rdb components ran in Executive mode. Was I wrong
>> about that ?
>>
>> Simon.
>>
>
> Maybe so, but the question was if Rdb run in the kernel, wasn't it?
>

If you read Scott's requirements above, you will see he was talking about
it being part of the kernel, but running at a ring below kernel mode.
That description fits executive mode perfectly.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

суббота, 12 ноября 2022 г. в 05:41:42 UTC+1, jake....@gmail.com:

> It would *definitely* make sense for VMS to provide a posix_spawn() API since it would be more efficient than the current method. Getting back to shells, I discovered bash had so many global variables
> that I needed to put them somewhere if I was going to try my plan to get the VMS port working more reliably by passing subshell data instead of bash (and every other UNIX shell)'s behavior
> of using fork() and the subshell inheriting stuff.

I'm not sure about the efficiency benefit of the posix_spawn() API, but now I'm adding it to the CRTL. At a minimum, posix_spawn avoids using the setjump/longjump.

On 11/16/22 2:06 AM, Vitaly Pustovetov wrote:
> суббота, 12 ноября 2022 г. в 05:41:42 UTC+1, jake....@gmail.com:

>> It would *definitely* make sense for VMS to provide a posix_spawn()
>> API since it would be more efficient than the current method.
>
> I'm not sure about the efficiency benefit of the posix_spawn() API,
> but now I'm adding it to the CRTL. At a minimum, posix_spawn avoids
> using the setjump/longjump.
👍

On 11/15/2022 1:36 PM, Simon Clubley wrote:
> On 2022-11-15, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2022-11-15 kl. 15:11, skrev Simon Clubley:
>>> On 2022-11-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/14/2022 1:59 PM, Simon Clubley wrote:
>>>>> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>>>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>>>>>> As software becomes more and more expensive, I think the need to have an
>>>>>>>>> efficient operating system that provides database features in the kernel
>>>>>>>>> becomes more important.
>>>>>>>>
>>>>>>>> Database in the actual OS kernel or just database shipping with the
>>>>>>>> OS distribution?
>>>>>>>>
>>>>>>>> It is not uncommon to put application functionality in the
>>>>>>>> kernel today, but I am not keen on the idea.
>>>>>>>
>>>>>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>>>>>> I want fast database access, I want rapid transaction turnover, I don't care
>>>>>>> necessarily about realtime operation or any direct UI other than for
>>>>>>> administration, or ever specifically making deadline. I'm thinking of a
>>>>>>> specialized database engine.
>>>>>>
>>>>>> I don't think I have ever heard about that for database.
>>>>>
>>>>> Rdb ? :-)
>>>>
>>>> I thought that was in user space not kernel space (P0 vs S0 in
>>>> more VMSish teminology).
>>>
>>> I thought the core Rdb components ran in Executive mode. Was I wrong
>>> about that ?
>>
>> Maybe so, but the question was if Rdb run in the kernel, wasn't it?
>
> If you read Scott's requirements above, you will see he was talking about
> it being part of the kernel, but running at a ring below kernel mode.
> That description fits executive mode perfectly.

It certainly matches the running in inner mode part.

It does not really match the concept as such.

The point of Tux, http.sys etc. is to avoid switches
between user and kernel mode and to avoid copying
data between process buffers and system buffers.

Rdb does not achieve any of that.

Rdb must be running in executive mode not for
performance reasons but for safety/security reasons.
Having an intended multi-user database running embedded
in processes create some unique problems. Having the
data structures protected against user mode access
mitigate those.

Arne

On 11/15/2022 8:52 AM, Scott Dorsey wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 11/11/2022 7:40 PM, Scott Dorsey wrote:
>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>> On 11/10/2022 9:51 AM, Scott Dorsey wrote:
>>>>>> As software becomes more and more expensive, I think the need to have an
>>>>>> efficient operating system that provides database features in the kernel
>>>>>> becomes more important.
>>>>>
>>>>> Database in the actual OS kernel or just database shipping with the
>>>>> OS distribution?
>>>>>
>>>>> It is not uncommon to put application functionality in the
>>>>> kernel today, but I am not keen on the idea.
>>>>
>>>> I think in the kernel. Maybe not in the top ring, but in a ring below it.
>>>> I want fast database access, I want rapid transaction turnover, I don't care
>>>> necessarily about realtime operation or any direct UI other than for
>>>> administration, or ever specifically making deadline. I'm thinking of a
>>>> specialized database engine.
>>>
>>> I don't think I have ever heard about that for database.
>>
>> Rdb ? :-)
>
> RDB is a start, and RDB is about as tight integration as you can get today.
> It was state of the art in the 1980s and allowed better database performance
> than anything else on comparable hardware.
>
> I'd like to see that sort of design moved forward into the 21st century with
> even tighter integration, maybe a microkernel with very low overhead, and a
> special purpose system that does nothing but serve databases out.
>
> We already have some special purpose systems that do nothing but serve web
> pages out but for the most part the web frontend can be distributed so there
> is little need for the ultimate performance on a single box. For database
> use there is.

Ways to do databases distributed / active-active cluster has been found.

Oracle RAC, DB2 Purescale, ASE Cluster Edition, MySQL Cluster,
DB2 Warehouse Edition, rqlite, Cassandra, HBase, MongoDB, Voldemort
etc..

Arne

On Friday, 14 October 2022 at 4:09:34 am UTC+11, John Dallman wrote:
> In its glory days of the 1980s, VMS got used for all sorts of technical
> computing and business IT.
>
> My employers used it as a software development system, producing
> mathematical modelling code for VMS, plus a wide range of other platforms.
> Demand for the code on VMS shrank in the 1990s, and it became expensive
> compared to doing development on Windows. We had dropped it by the year
> 2000. We'd resume support if there was significant demand for it on
> x86-64, which is why I joined this newsgroup.
>
> What do you use VMS for in the 2020s?
>
> John
Read this (and weep?)
https://www.theregister.com/2022/11/17/asx_blockchain_reading_project_paused/
Phil

On 2022-11-17, Phil Howell <phow9917@gmail.com> wrote:
> On Friday, 14 October 2022 at 4:09:34 am UTC+11, John Dallman wrote:
>> In its glory days of the 1980s, VMS got used for all sorts of technical
>> computing and business IT.
>>
>> My employers used it as a software development system, producing
>> mathematical modelling code for VMS, plus a wide range of other platforms.
>> Demand for the code on VMS shrank in the 1990s, and it became expensive
>> compared to doing development on Windows. We had dropped it by the year
>> 2000. We'd resume support if there was significant demand for it on
>> x86-64, which is why I joined this newsgroup.
>>
>> What do you use VMS for in the 2020s?
>>
>> John
> Read this (and weep?)
> https://www.theregister.com/2022/11/17/asx_blockchain_reading_project_paused/
> Phil

I noticed they hardened the current system. I wonder what hardening
techniques they used ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Phil Howell via
> Info-vax
> Sent: Thursday, November 17, 2022 3:03 AM
> To: info-vax@rbnsn.com
> Cc: Phil Howell <phow9917@gmail.com>
> Subject: Re: [Info-vax] What does VMS get used for, these days?
>
> On Friday, 14 October 2022 at 4:09:34 am UTC+11, John Dallman wrote:
> > In its glory days of the 1980s, VMS got used for all sorts of
> > technical computing and business IT.
> >
> > My employers used it as a software development system, producing
> > mathematical modelling code for VMS, plus a wide range of other
> platforms.
> > Demand for the code on VMS shrank in the 1990s, and it became
> > expensive compared to doing development on Windows. We had dropped
> it
> > by the year 2000. We'd resume support if there was significant demand
> > for it on x86-64, which is why I joined this newsgroup.
> >
> > What do you use VMS for in the 2020s?
> >
> > John
> Read this (and weep?)
> https://www.theregister.com/2022/11/17/asx_blockchain_reading_project_
> paused/
> Phil

Issue appears to be related to what I would refer to as overall "solution
latency" associated with distributed solutions that use the network as its
backbone for inter-service communications.

One needs to look at the sum of all the latencies in an overall solution to
determine if it will work or not.

In todays rapidly evolving server, storage and local caching technology
speeds and enhancements, excessive distributed network communications and
the associated latency (not bandwidth) is emerging as the biggest
contributor to the overall solution latency.

Interesting times.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 11/17/2022 2:02 AM, Phil Howell wrote:
> On Friday, 14 October 2022 at 4:09:34 am UTC+11, John Dallman wrote:
>> What do you use VMS for in the 2020s?

> Read this (and weep?)
> https://www.theregister.com/2022/11/17/asx_blockchain_reading_project_paused/

Why weep?

The block chain thing got canned and they are back
to running Cobol on VMS I64. Good for VMS.

They did not say VMS, but Cobol on Itanium is
likely VMS.

Arne

On 11/18/2022 7:21 AM, kemain.nospam@gmail.com wrote:
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Phil Howell via Info-vax
>> Sent: Thursday, November 17, 2022 3:03 AM

>> Read this (and weep?)
>> https://www.theregister.com/2022/11/17/asx_blockchain_reading_project_
>> paused/
>
> Issue appears to be related to what I would refer to as overall "solution
> latency" associated with distributed solutions that use the network as its
> backbone for inter-service communications.
>
> One needs to look at the sum of all the latencies in an overall solution to
> determine if it will work or not.

That seemed to have been the specific problem encountered.

But the underlying problem was that they had chosen a block chain
model with distributed server when that model for their business case
had mostly downsides (latency) and little upside (they still wanted
their system to be master).

Arne

On 19/11/2022 5:12 am, Arne Vajhøj wrote:
> On 11/17/2022 2:02 AM, Phil Howell wrote:
>> On Friday, 14 October 2022 at 4:09:34 am UTC+11, John Dallman wrote:
>>> What do you use VMS for in the 2020s?
>
>> Read this (and weep?)
>> https://www.theregister.com/2022/11/17/asx_blockchain_reading_project_paused/
>
> Why weep?
>
> The block chain thing got canned and they are back
> to running Cobol on VMS I64. Good for VMS.
>
> They did not say VMS, but Cobol on Itanium is
> likely VMS.
>
> Arne
>
>
I thought they left VMS when they left SEATS?

On 11/19/2022 3:20 AM, John Dallman wrote:
> In article <tl9i99$13ti$1@gioia.aioe.org>, maher_rjSPAMLESS@hotmail.com
> (Richard Maher) wrote:
>> On 19/11/2022 5:12 am, Arne Vajhøj wrote:
>>> They did not say VMS, but Cobol on Itanium is likely VMS.
>> I thought they left VMS when they left SEATS?
>
> They're trying to hire a Senior Analyst Programmer to work on CHESS,
> requiring a good knowledge of OpenVMS:
> <https://www2.asx.com.au/content/dam/asx/about/job-opportunities/securitie
> s-and-payments/senior-analyst-programmer%20-chess.pdf>

Very much indeed.

<quote>
* Expertise in design, build and maintenance of COBOL programmes
* Experience of COBOL batch processing
* Experience of using DECForms
* Highly proficient in writing SQL queries/ Oracle RDB
* Experience of building and maintenance of OpenVMS PASCAL programmes
* Experience of OpenVMS operating system
* Working knowledge of DCL (Digital Command Language), command line
interpreter for OpenVMS
systems, with ability to read/write command scripts
</quote>

That is about as VMSish as it can be.

But I did not know that when I wrote the above. I was
just considering VMS way more likely than HP-UX for
a Cobol application.

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: Saturday, November 19, 2022 9:32 AM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] What does VMS get used for, these days?
>
> On 11/19/2022 3:20 AM, John Dallman wrote:
> > In article <tl9i99$13ti$1@gioia.aioe.org>,
> > maher_rjSPAMLESS@hotmail.com (Richard Maher) wrote:
> >> On 19/11/2022 5:12 am, Arne Vajhøj wrote:
> >>> They did not say VMS, but Cobol on Itanium is likely VMS.
> >> I thought they left VMS when they left SEATS?
> >
> > They're trying to hire a Senior Analyst Programmer to work on CHESS,
> > requiring a good knowledge of OpenVMS:
> > <https://www2.asx.com.au/content/dam/asx/about/job-
> opportunities/secur
> > itie s-and-payments/senior-analyst-programmer%20-chess.pdf>
>
> Very much indeed.
>
> <quote>
> * Expertise in design, build and maintenance of COBOL programmes
> * Experience of COBOL batch processing
> * Experience of using DECForms
> * Highly proficient in writing SQL queries/ Oracle RDB
> * Experience of building and maintenance of OpenVMS PASCAL programmes
> * Experience of OpenVMS operating system
> * Working knowledge of DCL (Digital Command Language), command line
> interpreter for OpenVMS systems, with ability to read/write command
> scripts </quote>
>
> That is about as VMSish as it can be.
>
> But I did not know that when I wrote the above. I was just considering VMS
> way more likely than HP-UX for a Cobol application.
>
> Arne
>

Not Cobol, but semi-related historical tidbit - when the Shanghai Stock Exchange in 2005 (at the time, SSE was rumoured to eventually take over as WW #1 trading platform) did an industry wide RFP for their next generation Stock Exchange platform, the OS platform chosen to host this new mission critical, multi-site, highly secure solution was OpenVMS on Integrity HW.

The new system went live in early 2010 timeframe.

Key point - this new OpenVMS solution replaced the old environment that ran on ... HP-UX.

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 19/11/2022 4:20 pm, John Dallman wrote:
> https://www2.asx.com.au/content/dam/asx/about/job-opportunities/securitie
> s-and-payments/senior-analyst-programmer%20-chess.pdf
Cool!

On 2022-11-08 22:21, Stephen Hoffman wrote:
> On 2022-11-06 18:18:29 +0000, Robert Carleton said:
>
>> Going a slightly different way, does files versioning help relieve the
>> programmers from some of the work necessary to roll back a corrupted
>> dataset when something goes wrong with their job? In the IBM world,
>> they talk about the production control analysts managing the batch
>> processing. I suppose file version control might be one of the tools
>> that they use, maybe in organizations that have a lot of duty separation.
>
> For small stuff, sure. XQP file versions can and do work. For more
> complex code changes as tend to be typical, file version rollbacks get
> gnarly as most change sets lack a consistent number of versions for a
> set of related code changes across a selection of files. Rolling back
> changes with file versions then means finding the right group of file
> versions. Which is usually not ;-1 or ;-2 across all of the various
> files involved in the source code change.

Not really an XQP feature. But ODS-[125]. The wise way to roll back is
by using the file timestamps, and not directly the version numbers. That
do work acceptably well if you just want to roll back to a previous
point. However, it's not as good/nice as a proper version control
system, I would agree.

> XQP file versions also tend to need explicit management, and version
> cleanups can be hazardous for the practices used at some sites. And
> there's no good means to clean up intermediate file versions between
> those that a developer might wish to preserve.

There is a workaround for that, but it is a still a bit of a headache.
But protect the versions you want to keep from delete, and then run a
purge. Probably not a bad idea to protect versions that are significant
anyway, to avoid accidental deletions by fumbly fingers anyway. But it's
still rather semi-manual.

> IBM Rational Clearcase VOB is a very nice implementation of file
> versioning for app development, though that never really caught on more
> generally. The VOB presents a build or version or baselevel or whatever
> a developer or development team might call a collection of related
> source code changes, as a synthetic file system as a view from within
> the DVCS. The usual implementation here is based on a FUSE, which is
> fairly commonly feature available. There are undoubtedly some other and
> analogous implementations to VOBs, too. Switch the build or version or
> whatever, and the (virtual, synthetic) part of the file system you're
> looking and working within switches to what that build or baselevel
> would look like.

I think clearcase was very nice and cool. Almost all implementation I've
used did not use FUSE, but was playing quite a lot inside the kernel
(FUSE is rather new relative to this), but I can imagine they would have
moved over to FUSE as that started to appear. (I haven't used clearcase
in probably 20 years now...)

> For the development projects I'm typically dealing with, pushing changes
> to the local DVCS is the usual approach when building stuff and is
> integrated within the IDE, and that makes rollbacks easy. Once ready to
> share, the code gets pushed from local into general availability.
> Getting better support in LSEDIT might help some, and other folks can
> choose to use VSC as that gets better integrated. If you're not using an
> IDE, then you're probably going to be getting familiar with git command
> line syntax.

Except git is not really a tool you want to use on the command line.
Referring to commits by hashes that are 64 for or so random characters
to type just is not doable. Cut and paste makes it sortof manageable,
but it still sucks big time.

> As a competitive feature, I suspect there'd be much more interest in
> integration with git or hg and with common IDE such as VSC than with the
> existing file versioning scheme. But sure, XQP file versioning does work
> for smaller efforts and smaller pools, and it does work when the
> developer and the local tooling is lacking. (Which it kinda is lacking,
> on OpenVMS. VSC and VGIT only gets you so far. The current compiler
> overhaul will absolutely help, as that becomes available. And that'll
> then help with better VSC integration, too.)

Didn't VMS have some tool for source control?

> XQP file versions have been around for over forty years, so probably not
> going to be a big draw for new apps and new developers. Not compared
> with git or hg or VSC or recent compilers or other of what are
> increasingly considered "table stakes" features.

Well, file versions existed in RSX about 50 years ago. No XQP, but ACP.

Johnny

On 01/12/2022 17:31, Johnny Billquist wrote:

>
> Didn't VMS have some tool for source control?
>

That would be CMS - part of DECSet

--
Chris

On 12/1/2022 12:31 PM, Johnny Billquist wrote:
> On 2022-11-08 22:21, Stephen Hoffman wrote:
>> As a competitive feature, I suspect there'd be much more interest in
>> integration with git or hg and with common IDE such as VSC than with
>> the existing file versioning scheme. But sure, XQP file versioning
>> does work for smaller efforts and smaller pools, and it does work when
>> the developer and the local tooling is lacking. (Which it kinda is
>> lacking, on OpenVMS. VSC and VGIT only gets you so far. The current
>> compiler overhaul will absolutely help, as that becomes available. And
>> that'll then help with better VSC integration, too.)
>
> Didn't VMS have some tool for source control?

Lots of options.

DECset has CMS.

RCS runs on VMS.

Mercurial runs on VMS.

VGIT (subset of Git) runs on VMS.

SVN runs on VMS I64.

CVS supposedly runs on VMS.

SVNKit (Java SVN) supposedly runs on VMS.

Arne

On 2022-12-01 17:31:48 +0000, Johnny Billquist said:

> On 2022-11-08 22:21, Stephen Hoffman wrote:
>> On 2022-11-06 18:18:29 +0000, Robert Carleton said:
>>
>>> Going a slightly different way, does files versioning help relieve the
>>> programmers from some of the work necessary to roll back a corrupted
>>> dataset when something goes wrong with their job? In the IBM world,
>>> they talk about the production control analysts managing the batch
>>> processing. I suppose file version control might be one of the tools
>>> that they use, maybe in organizations that have a lot of duty
>>> separation.
>>
>> For small stuff, sure. XQP file versions can and do work. For more
>> complex code changes as tend to be typical, file version rollbacks get
>> gnarly as most change sets lack a consistent number of versions for a
>> set of related code changes across a selection of files. Rolling back
>> changes with file versions then means finding the right group of file
>> versions. Which is usually not ;-1 or ;-2 across all of the various
>> files involved in the source code change.
>
> Not really an XQP feature. But ODS-[125]. The wise way to roll back is
> by using the file timestamps, and not directly the version numbers.
> That do work acceptably well if you just want to roll back to a
> previous point. However, it's not as good/nice as a proper version
> control system, I would agree.

The wise way is to use a version control system or DVCS. Not
re-inventing a version control system from first principles and spare
parts, and particularly not one built upon a PURGE-prone substrate of
file versions.

>> XQP file versions also tend to need explicit management, and version
>> cleanups can be hazardous for the practices used at some sites. And
>> there's no good means to clean up intermediate file versions between
>> those that a developer might wish to preserve.
>
> There is a workaround for that, but it is a still a bit of a headache.
> But protect the versions you want to keep from delete, and then run a
> purge. Probably not a bad idea to protect versions that are significant
> anyway, to avoid accidental deletions by fumbly fingers anyway. But
> it's still rather semi-manual.

Versions are adequate for rolling back small-scale work. They're an
increasing hassle as multiple modules become involved with one change.

>> IBM Rational Clearcase VOB is a very nice implementation of file
>> versioning for app development, though that never really caught on more
>> generally. The VOB presents a build or version or baselevel or whatever
>> a developer or development team might call a collection of related
>> source code changes, as a synthetic file system as a view from within
>> the DVCS. The usual implementation here is based on a FUSE, which is
>> fairly commonly feature available. There are undoubtedly some other and
>> analogous implementations to VOBs, too. Switch the build or version or
>> whatever, and the (virtual, synthetic) part of the file system you're
>> looking and working within switches to what that build or baselevel
>> would look like.
>
> I think clearcase was very nice and cool. Almost all implementation
> I've used did not use FUSE, but was playing quite a lot inside the
> kernel (FUSE is rather new relative to this), but I can imagine they
> would have moved over to FUSE as that started to appear. (I haven't
> used clearcase in probably 20 years now...)

A git FUSE wouldn't surprise.

OpenVMS lacks FUSE-like APIs, though a user-written ACP can help with
that. ACPs are undocumented, but not particularly difficult. Just don't
decide to parallel the DECnet ACP, as that design is just weird.
Parallel the magtape ACP, if you have source listings access.)

MOUNT would need some help here too were a FUSE to be added, as last I
checked MOUNT was unable to launch a user-specified ACP, among other
limits. It assumed anything mounted was a file system (which is not
always the case), and MOUNT had direct knowledge of supported file
system formats. Basically, anybody working in this area and with their
own ACP gets to write their own MOUNT analog.

>> For the development projects I'm typically dealing with, pushing
>> changes to the local DVCS is the usual approach when building stuff and
>> is integrated within the IDE, and that makes rollbacks easy. Once ready
>> to share, the code gets pushed from local into general availability.
>> Getting better support in LSEDIT might help some, and other folks can
>> choose to use VSC as that gets better integrated. If you're not using
>> an IDE, then you're probably going to be getting familiar with git
>> command line syntax.
>
> Except git is not really a tool you want to use on the command line.
> Referring to commits by hashes that are 64 for or so random characters
> to type just is not doable. Cut and paste makes it sortof manageable,
> but it still sucks big time.

I've yet to meet a command-line IDE. But then it's been a while since
I've used RSX-11, too.

>> As a competitive feature, I suspect there'd be much more interest in
>> integration with git or hg and with common IDE such as VSC than with
>> the existing file versioning scheme. But sure, XQP file versioning does
>> work for smaller efforts and smaller pools, and it does work when the
>> developer and the local tooling is lacking. (Which it kinda is lacking,
>> on OpenVMS. VSC and VGIT only gets you so far. The current compiler
>> overhaul will absolutely help, as that becomes available. And that'll
>> then help with better VSC integration, too.)
>
> Didn't VMS have some tool for source control?

DECset CMS. Which was and remains limited in its scale and scope.

I think CMS ODS-5 support is now mostly working, though one of my
favorite quotes is from the era when it wasn't: "the attempt to add
ODS-5 support to CMS apparently turned into a Keystone Cops-like
adventure for HPE."

CMS is unlikely to be a big draw, either. Maybe if DEC had done a
distributed CMS, but that never happened. (There was some work to add
that distributed support for a project based on CMS, but that work
ended a very long time ago.)

>> XQP file versions have been around for over forty years, so probably
>> not going to be a big draw for new apps and new developers. Not
>> compared with git or hg or VSC or recent compilers or other of what are
>> increasingly considered "table stakes" features.
>
> Well, file versions existed in RSX about 50 years ago. No XQP, but ACP.

Still not a big draw, membership in the half-century club aside. File
versions aren't a competitor for DVCS support. And OpenVMS DVCS
integration and support is lacking, discussions of vgit aside.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/1/22 12:50 PM, Stephen Hoffman wrote:

> A git FUSE wouldn't surprise.

Not exactly a FUSE but it did have a virtual file system:

https://github.com/microsoft/VFSForGit

which has been superseded by other mechanisms that make it possible to
operate only on what you're working on instead of everything in a
monster repo:

https://github.com/microsoft/scalar

As I understand it, Microsoft contributed these to make it possible to
get the source code to Windows into git.

On 12/1/22 11:31 AM, Johnny Billquist wrote:

> Except git is not really a tool you want to use on the command line.

And yet somehow tens of thousands of people do so without considering it
a major problem. It is a rather large command language and can take a
while to learn, but you don't really need to know that much of it to be
productive.

> Referring to commits by hashes that are 64 for or so random characters
> to type just is not doable. Cut and paste makes it sortof manageable,
> but it still sucks big time.

You only need to specify as many characters as necessary to make the
commit ID unique; seven is a common convention. And copy and paste
works quite well. And there are lots of shortcuts for
commonly-referred-to commits, such as tag names, branch names, HEAD (the
tip of the current branch). Plus there are suffixes that make it easy to
get other commits relative to the commits that are easy to spell: HEAD^10
gives you the 10th parent of the tip of the current branch, to cite only
one example. See "git help revisions" for details.

On Thu, 2022-12-01 at 18:31 +0100, Johnny Billquist wrote:
> Except git is not really a tool you want to use on the command line.
> Referring to commits by hashes that are 64 for or so random
> characters to type just is not doable. Cut and paste makes it sortof
> manageable, but it still sucks big time.

Yes, git does tend to do that, but it also gives you a "short" form of
the hash that can be used instead to refer to objects. Works quite
nicely.
--
Tactical Nuclear Kittens

On Thursday, October 13, 2022 at 11:09:34 AM UTC-6, John Dallman wrote:
> In its glory days of the 1980s, VMS got used for all sorts of technical
> computing and business IT. ...

It's still used for an old county treasurer application.

My first Fortran programming job was for geophysics applications on petroleum exploration packages: 1MB memory on a VAX 780 or .5 MB memory on a VAX 750, with an attached MAP array processor for number crunching. DoD also used VAXes. Both of those are much more fun than accounting.