vgit clone <repo>
from public repositories seems to fail for me with the following error error about failing to make the .git subdirectory. An example:

$ vgit clone https://github.com/vmssoftware/python_3_8_2.git
Cloning into 'python_3_8_2'...
Bad news:
failed to make directory 'python_3_8_2/.git': bad file version number [2]

Has anyone been able to get past that error?

On 2023-05-09 14:48:47 +0000, MJ OSEXAMINE said:

> vgit clone <repo>
> from public repositories seems to fail for me with the following error
> error about failing to make the .git subdirectory. An example:
>
> $ vgit clone https://github.com/vmssoftware/python_3_8_2.git
> Cloning into 'python_3_8_2'...
> Bad news:
> failed to make directory 'python_3_8_2/.git': bad file version number [2]
>
> Has anyone been able to get past that error?

With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start there.

(I started putting these and quota checks into tooling, as that reduced
the support.)

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/9/23 10:58 AM, Stephen Hoffman wrote:
> On 2023-05-09 14:48:47 +0000, MJ OSEXAMINE said:
>
>> vgit clone <repo>
>> from public repositories seems to fail for me with the following error
>> error about failing to make the .git subdirectory. An example:
>>
>> $ vgit clone https://github.com/vmssoftware/python_3_8_2.git
>> Cloning into 'python_3_8_2'...
>> Bad news:
>>  failed to make directory 'python_3_8_2/.git': bad file version number
>> [2]
>>
>> Has anyone been able to get past that error?
>
> With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start there.
>
> (I started putting these and quota checks into tooling, as that reduced
> the support.)

Setting DECC$EFS_CHARSET in the environment might also make a difference.

On Tuesday, May 9, 2023 at 11:58:51 AM UTC-4, Stephen Hoffman wrote:
> With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start there..

I should have checked that the disk had ODS-5, as that turned out to be the issue.
Doing the init without specifying /struct still defaults to ODS-2, apparently.
Thanks.

On 2023-05-09 16:48:52 +0000, MJ OS_EXAMINE said:

> On Tuesday, May 9, 2023 at 11:58:51 AM UTC-4, Stephen Hoffman wrote:
>> With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start there.
> I should have checked that the disk had ODS-5, as that turned out to be
> the issue.
> Doing the init without specifying /struct still defaults to ODS-2, apparently.

It is safe to assume that OpenVMS app and system defaults are somewhere
between somewhat-less-than-optimal, and wrong. Most were probably
reasonable choices, once upon a time.

It is also safe to assume that OpenVMS tools will not check
prerequisites such as required quotas or volume formats, and the
resulting misconfigurations can or will fail with obscure messages.

Compatibility is a harsh default, particularly when the costs of
compatibility are shifted to new work and not onto under- or
unmaintained apps. Trade-offs between short term and long term are
never fun choices.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/9/2023 5:05 PM, Stephen Hoffman wrote:
> On 2023-05-09 16:48:52 +0000, MJ OS_EXAMINE said:
>
>> On Tuesday, May 9, 2023 at 11:58:51 AM UTC-4, Stephen Hoffman wrote:
>>> With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start there.
>> I should have checked that the disk had ODS-5, as that turned out to be the
>> issue.
>> Doing the init without specifying /struct still defaults to ODS-2, apparently.
>
> It is safe to assume that OpenVMS app and system defaults are somewhere between
> somewhat-less-than-optimal, and wrong. Most were probably reasonable choices,
> once upon a time.

If talking about disk initialization, I for one would assume that defaulting to
original operations would be reasonable, and using newer capabilities an option.
Or, if the option was not specified, ask the user which is desired.

> It is also safe to assume that OpenVMS tools will not check prerequisites such
> as required quotas or volume formats, and the resulting misconfigurations can or
> will fail with obscure messages.

One needs to be a bit competent to do things, though, obscure messages are never
acceptable.

> Compatibility is a harsh default, particularly when the costs of compatibility
> are shifted to new work and not onto under- or unmaintained apps. Trade-offs
> between short term and long term are never fun choices.
>

Quite so.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 09/05/2023 23:37, Dave Froble wrote:
> On 5/9/2023 5:05 PM, Stephen Hoffman wrote:
>> On 2023-05-09 16:48:52 +0000, MJ OS_EXAMINE said:
>>
>>> On Tuesday, May 9, 2023 at 11:58:51 AM UTC-4, Stephen Hoffman wrote:
>>>> With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start
>>>> there.
>>> I should have checked that the disk had ODS-5, as that turned out to
>>> be the
>>> issue.
>>> Doing the init without specifying /struct still defaults to ODS-2,
>>> apparently.
>>
>> It is safe to assume that OpenVMS app and system defaults are
>> somewhere between
>> somewhat-less-than-optimal, and wrong. Most were probably reasonable
>> choices,
>> once upon a time.
>
> If talking about disk initialization, I for one would assume that
> defaulting to original operations would be reasonable, and using newer
> capabilities an option.  Or, if the option was not specified, ask the
> user which is desired.
>
>> It is also safe to assume that OpenVMS tools will not check
>> prerequisites such
>> as required quotas or volume formats, and the resulting
>> misconfigurations can or
>> will fail with obscure messages.
>
> One needs to be a bit competent to do things, though, obscure messages
> are never acceptable.
>
>> Compatibility is a harsh default, particularly when the costs of
>> compatibility
>> are shifted to new work and not onto under- or unmaintained apps.
>> Trade-offs
>> between short term and long term are never fun choices.
>>
>
> Quite so.
>

I haven't checked on VMS 9.2-1 but the defaults for initialising a disk
have been unusable for a very long time

--
Chris

On 5/9/23 5:40 PM, Chris Townley wrote:
> On 09/05/2023 23:37, Dave Froble wrote:
>> On 5/9/2023 5:05 PM, Stephen Hoffman wrote:
>>> On 2023-05-09 16:48:52 +0000, MJ OS_EXAMINE said:
>>>
>>>> On Tuesday, May 9, 2023 at 11:58:51 AM UTC-4, Stephen Hoffman wrote:
>>>>> With SET PROCESS/PARSE=EXTEND and on an ODS-5 disk? If not, start
>>>>> there.
>>>> I should have checked that the disk had ODS-5, as that turned out to
>>>> be the
>>>> issue.
>>>> Doing the init without specifying /struct still defaults to ODS-2,
>>>> apparently.
>>>
>>> It is safe to assume that OpenVMS app and system defaults are
>>> somewhere between
>>> somewhat-less-than-optimal, and wrong. Most were probably reasonable
>>> choices,
>>> once upon a time.
>>
>> If talking about disk initialization, I for one would assume that
>> defaulting to original operations would be reasonable, and using newer
>> capabilities an option.  Or, if the option was not specified, ask the
>> user which is desired.

Defaulting to "original operations" for 10 or 20 years after those
defaults are deprecated might make sense. After that, not so much. How
many years did ODS-1 get? ODS-2 is now well past its due date.

>>> It is also safe to assume that OpenVMS tools will not check
>>> prerequisites such
>>> as required quotas or volume formats, and the resulting
>>> misconfigurations can or
>>> will fail with obscure messages.
>>
>> One needs to be a bit competent to do things, though, obscure messages
>> are never acceptable.
>>
>>> Compatibility is a harsh default, particularly when the costs of
>>> compatibility
>>> are shifted to new work and not onto under- or unmaintained apps.
>>> Trade-offs
>>> between short term and long term are never fun choices.
>>>
>>
>> Quite so.
>>
>
> I haven't checked on VMS 9.2-1 but the defaults for initialising a disk
> have been unusable for a very long time

I think /LIMIT, which actually means *don't* limit future expansion,
has been de rigeur for quite a while now.

On 2023-05-09 22:37:27 +0000, Dave Froble said:

> On 5/9/2023 5:05 PM, Stephen Hoffman wrote:
>>
>> It is safe to assume that OpenVMS app and system defaults are somewhere
>> between somewhat-less-than-optimal, and wrong. Most were probably
>> reasonable choices, once upon a time.
>
> If talking about disk initialization, I for one would assume that
> defaulting to original operations would be reasonable, and using newer
> capabilities an option. Or, if the option was not specified, ask the
> user which is desired.

The OpenVMS volume INITIALIZE defaults have been utter dross for
decades, well beyond the /STRUCTURE=2 or =5 default discussion.

The settings made sense for a VAX-11 box running V3 or so and several
megabytes of memory, with hugely expensive disks with capacities
measured in megabytes.

Nowadays, not so much.

I'm sure somebody somewhere has an app that can only work with ODS-2
and not subset ODS-5, though.

This extends out into caching and other areas too, with the performance
of SSDs over HDDs.

Various of the virtual memory system parameter defaults were overhauled
at V7.0, but there are many other areas with defaults that are... less
than optimal.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2023-05-10 00:40, Chris Townley wrote:
> On 09/05/2023 23:37, Dave Froble wrote:

>> One needs to be a bit competent to do things, though, obscure messages
>> are never acceptable.
>>
>>> Compatibility is a harsh default, particularly when the costs of
>>> compatibility
>>> are shifted to new work and not onto under- or unmaintained apps.
>>> Trade-offs
>>> between short term and long term are never fun choices.
>>>
>>
>> Quite so.
>>
>
> I haven't checked on VMS 9.2-1 but the defaults for initialising a disk
> have been unusable for a very long time

Defaults for initializing a disk aren't even that usable on RSX... :-)
You always want to override some of them.

Johnny

On 10/05/2023 16:25, Johnny Billquist wrote:
> On 2023-05-10 00:40, Chris Townley wrote:
>> On 09/05/2023 23:37, Dave Froble wrote:
>
>>> One needs to be a bit competent to do things, though, obscure
>>> messages are never acceptable.
>>>
>>>> Compatibility is a harsh default, particularly when the costs of
>>>> compatibility
>>>> are shifted to new work and not onto under- or unmaintained apps.
>>>> Trade-offs
>>>> between short term and long term are never fun choices.
>>>>
>>>
>>> Quite so.
>>>
>>
>> I haven't checked on VMS 9.2-1 but the defaults for initialising a
>> disk have been unusable for a very long time
>
> Defaults for initializing a disk aren't even that usable on RSX... :-)
> You always want to override some of them.
>
>   Johnny
>

They weren't much use on VAXes either.

I remember having to backup, reinitialise and restore disks on 8530, and
4000s many times.

--
Chris