Den 2024-01-27 kl. 20:48, skrev Arne Vajhøj:
> On 1/27/2024 1:48 PM, Jan-Erik Söderholm wrote:
>> Den 2024-01-27 kl. 19:02, skrev Chris Townley:
>>> What really upset me was some early *nixs that hid the drive devices,
>>> but wouldn't let you rename (mv) files from one device to another.
>>> Useful unless you knew what was on which drive!
>>
>> No different from VMS. You can only RENAME within the same physical
>> storage volume/disk. Between different volumes/disks, you need to COPY.
>
> Yes. But disks are visible in the full file names, so you know.
>
> Arne
>

Two rooted/conceiled logical names can either be on the same
disk or on two different disks. In the first case RENAME works
but not in the second.

You do not know if you do not translate the rooted logicals first.

Op 28.jan.2024 om 00:28 schreef Dave Froble:
> On 1/27/2024 1:48 PM, Single Stage to Orbit wrote:
>> On Sat, 2024-01-27 at 00:32 -0500, Dave Froble wrote:
>>> On 1/26/2024 3:32 PM, Single Stage to Orbit wrote:
>>>> Unix has some great tools for searching for folders and files. Are
>>>> there similar ones in VMS like `grep` or `find`?
>>>>
>>>> THe folder structure in OpenVMS is wierd... what's the root folder
>>>> equivalent is it [000000] or is it cleverer than that?
>>
>> [ snip ]
>>
>>> Each disk has what you are calling a root directory.  Within it are
>>> top level  directorys.  The "ROOT" can be addressed as [0,0],
>>> [000000], or [000,000].  Don't ask me why more than one method.  I
>>> don't know.
>>
>> Looks like some form of octal?
>>
>>> Do note that one should never, well almost never, place anything in
>>> that directory.  I've been guilty of doing so, when the disk is
>>> temporary, and will be re-inited sometime.  Usually some OS
>>> distribution files.
>>>
>>> What is your specific question(s)?
>>
>> All is good, I understand now what the folder structure is like for
>> each disk.
>>
>> In my system account when I log in and run the dir command it shows me
>> this:
>>
>> $ dir/page
>>
>> Directory SYS$SYSROOT:[SYSMGR]
>>
>> ACCOUNTNG.DAT;1     CLUE$STARTUP_KAKAPO.LOG;28
>> CLUE$STARTUP_KAKAPO.LOG;27
>> CLUE$STARTUP_KAKAPO.LOG;26        IOGEN$PREFIX.DAT;1
>> LAN$ACP.LOG;28
>> LAN$ACP.LOG;27        LAN$ACP.LOG;26    MAIN.TPU$JOURNAL;1
>> NET$INSTALL_IDENTIFIERS.LOG;1
>> OPERATOR.LOG;30     OPERATOR.LOG;29    OPERATOR.LOG;28     ssh.DIR;1
>> SSHD_CONFIG_.TPU$JOURNAL;1        SSH_CONFIG_.TPU$JOURNAL;2
>> SYS$DUMP_CONFIG.DAT;1            SYS$SMHANDLER.LOG;28
>> SYS$SMHANDLER.LOG;27            SYS$SMHANDLER.LOG;26
>> SYSTARTUP_VMS.JOU;1 TCPIP$CONFIG_CONVERSION.FLG;1
>> TCPIP$V51_CONVERSION.FLG;1
>> VMSIMAGES.DAT;1     X86Community-20240401.txt;1
>>
>> Total of 25 files.
>>
>> Directory SYS$COMMON:[SYSMGR]
>>
>> ACME$START.COM;1    ACME$START.TEMPLATE;1
>> AGEN$NEW_NODE_DEFAULTS.TEMPLATE;1
>> AGEN$NEW_SATELLITE_DEFAULTS.TEMPLATE;1    AMDS$DIAGNOSTICS.COM;1
>> AMDS$DRIVER_ACCESS.DAT;1        AMDS$DRIVER_ACCESS.TEMPLATE;1
>> [ snip ]
>>
>> Why does it shows me two directories?
>>
>
> It can be a bit confusing until you understand the rather neat thing
> that was done with VMS.
>
> I guess there was the desire to allow for multiple copies of the OS on
> the system disk.  Thus SYS0, SYS1, SYS2, ...
>

No that was not the primary reason. Each Sys0, SYS1, SYS2, etc had a
syscommon directory, which usually was a link to [VMS$COMMON], as Arne
explained.
The reason that SYS0, SYS1, etc was needed is that even systems booting
with the same OS (in [SYSCOMMON]) need specific data, such as system
parameters and sometimes specific DCL procedures.
By having SYS$SYSROOT defined as a search list to SYS$SPECIFIC,
SYS$COMMON, automatically first the specific data for that node was
selected and if not present, then the common data. Log files were
written in the SYS$SPECIFIC part.

When we were running a 25 node cluster with multiple system disks, we
even expanded that idea by defining a CLUSTERCOMMON name which was added
at the end of the search list. Some DCL procedures were common to all
nodes, even those booted from different system disks.

On Sat, 2024-01-27 at 14:52 -0500, Arne Vajhøj wrote:
> > It now makes sense, each disk has the root folder containing other
> > directories and other things.
>
> Yes.
>
> 000000.dir is the root directory on each disk.
>
> It is a little bit special that it contains itself.
>
> disk:[foobar]
> disk:[000000.foobar]
> disk:[000000.000000.foobar]
>
> are all the same.

Makes perfect sense. Easy to avoid recursive issues. Thanks.
--
Tactical Nuclear Kittens

On Sat, 2024-01-27 at 15:22 -0500, Arne Vajhøj wrote:
> And regarding the technical stuff behind it, then
> it is possible because:
> * the device part and the directory part of default
>    are store separately (in a logical SYS$DISK and
>    in process memory respectively)
> * the device part does not need to be a device only
>    but can be a device plus a directory accessed via
>    a so called rooted logical
> * a logical can have multiple values

I see how powerful it can be, I can list them with SH LOG.
--
Tactical Nuclear Kittens

On Sat, 2024-01-27 at 15:06 -0500, Arne Vajhøj wrote:
> > Why does it shows me two directories?
>
> Now it starts to become a little bit tricky to explain.
>
> Let us start with the practical version.
>
> In VMS "default directory" does not need to be
> a single directory - it can actually be a list of
> directories.

Ah that bit does make sense, logicals are why we can see more than one
directory.

This makes sense:

$ sh def
SYS$SYSROOT:[SYSMGR]
= SYS$SYSROOT:[SYSMGR]
= SYS$COMMON:[SYSMGR]

So, it is the logicals that are used with dir to show us the files and
folders. Pretty nifty, just have to make sure when I add files, I need
to be in the correct folder, yes? By default it puts files into the
first directory, as you've mentioned previously.
--
Tactical Nuclear Kittens

> The Pr1mos team, of course! Love those MFDs!

Eventually they implemented < being a valid path -- a super "virtual"
mfd under which all of the mounted packs were listed.

De

On 1/27/2024 9:11 PM, kludge@panix.com wrote:
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Defining something as "weird" because you're not familiar with
>> it isn't very enlightened. If that's the metric one judges by,
>> consider how many orders of magnitude more people these days
>> will call VMS's filesystem layout "weird" because it's different
>> than something they are more familiar with, such as Linux, the
>> Mac or Windows. Who's to say who's right under such subjective
>> criteria?
>
> The Pr1mos team, of course! Love those MFDs!

Ah yes, Primos!!!

Query: How do you completely trash a disk under Primos? :-)

bill
(actually, I have never seen it tried on other OSes so it may be
possible elsewhere.)

In article <up4307$3iq8f$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/27/2024 2:38 PM, Dan Cross wrote:
>> Defining something as "weird" because you're not familiar with
>> it isn't very enlightened. If that's the metric one judges by,
>> consider how many orders of magnitude more people these days
>> will call VMS's filesystem layout "weird" because it's different
>> than something they are more familiar with, such as Linux, the
>> Mac or Windows. Who's to say who's right under such subjective
>> criteria?
>>
>> - Dan C.
>>
>
>But, most here already know that I'm not enlightened ...
>
>:-)

Hah!

>As for "right", well, usually it's in the eye of the beholder.

I suppose. But generally, at least we acknowledge that as being
subjective.

- Dan C.

In article <up4d5c$dt1$1@panix1.panix.com>, <kludge@panix.com> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>Defining something as "weird" because you're not familiar with
>>it isn't very enlightened. If that's the metric one judges by,
>>consider how many orders of magnitude more people these days
>>will call VMS's filesystem layout "weird" because it's different
>>than something they are more familiar with, such as Linux, the
>>Mac or Windows. Who's to say who's right under such subjective
>>criteria?
>
>The Pr1mos team, of course! Love those MFDs!

Multics squeezed into 16 bits!

- Dan C.

On 1/28/2024 10:35 AM, Single Stage to Orbit wrote:
> On Sat, 2024-01-27 at 15:06 -0500, Arne Vajhøj wrote:
>>> Why does it shows me two directories?
>>
>> Now it starts to become a little bit tricky to explain.
>>
>> Let us start with the practical version.
>>
>> In VMS "default directory" does not need to be
>> a single directory - it can actually be a list of
>> directories.
>
> Ah that bit does make sense, logicals are why we can see more than one
> directory.
>
> This makes sense:
>
> $ sh def
> SYS$SYSROOT:[SYSMGR]
> = SYS$SYSROOT:[SYSMGR]
> = SYS$COMMON:[SYSMGR]
>
> So, it is the logicals that are used with dir to show us the files and
> folders. Pretty nifty, just have to make sure when I add files, I need
> to be in the correct folder, yes? By default it puts files into the
> first directory, as you've mentioned previously.

Yes.

$ eve sys$specific:[sysmgr]something.com

and

$ eve sys$common:[sysmgr]something.com

work - and IMHO are easily understandable names.

Arne

On Sun, 28 Jan 2024 14:38:39 +0100, Fred. Zwarts wrote:

> The reason that SYS0, SYS1, etc was needed is that even systems booting
> with the same OS (in [SYSCOMMON]) need specific data, such as system
> parameters and sometimes specific DCL procedures.
> By having SYS$SYSROOT defined as a search list to SYS$SPECIFIC,
> SYS$COMMON, automatically first the specific data for that node was
> selected and if not present, then the common data. Log files were
> written in the SYS$SPECIFIC part.

VMS never had a clear separation between where you put code, read-only
data, user/admin-writable config files, and system-writable data, did it?
E.g. FHS-style /usr/bin for ordinary executables, /usr/sbin for sysadmin-
specific executables, /usr/lib for shareable libraries, /usr/share for
read-only data (architecture-independent), /etc for modifiable config
files, /var/log for logfiles, /var/lib for important system-writable data.

On 1/28/2024 3:34 PM, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 14:38:39 +0100, Fred. Zwarts wrote:
>> The reason that SYS0, SYS1, etc was needed is that even systems booting
>> with the same OS (in [SYSCOMMON]) need specific data, such as system
>> parameters and sometimes specific DCL procedures.
>> By having SYS$SYSROOT defined as a search list to SYS$SPECIFIC,
>> SYS$COMMON, automatically first the specific data for that node was
>> selected and if not present, then the common data. Log files were
>> written in the SYS$SPECIFIC part.
>
> VMS never had a clear separation between where you put code, read-only
> data, user/admin-writable config files, and system-writable data, did it?
> E.g. FHS-style /usr/bin for ordinary executables, /usr/sbin for sysadmin-
> specific executables, /usr/lib for shareable libraries, /usr/share for
> read-only data (architecture-independent), /etc for modifiable config
> files, /var/log for logfiles, /var/lib for important system-writable data.

In theory VMS has something similar.

SYS$MANAGER - the system managers COM files
SYS$SYSTEM - the ordinary system EXE files
SYS$LIBRARY - libraries (object libraries, shareable libraries,
shareable images)
SYS$STARTUP - product startup files
SYS$LOADABLE_IMAGES - kernel and driver stuff
SYS$HELP - help libraries
SYS$UPDATE - system update stuff
etc.

But it miss something for config and log.

And then we have all the products ported from *nix which
typical end up with the *nix directories under a product
root on VMS.

Arne

On 2024-01-27, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/27/2024 8:52 AM, bill wrote:
>> On 1/27/2024 12:32 AM, Dave Froble wrote:
>>> On 1/26/2024 3:32 PM, Single Stage to Orbit wrote:
>>>> Unix has some great tools for searching for folders and files. Are
>>>> there similar ones in VMS like `grep` or `find`?
>>>>
>>>> THe folder structure in OpenVMS is wierd... what's the root folder
>>>> equivalent is it [000000] or is it cleverer than that?
>>>>
>>>
>>> No, the Unix directory structure is weird, the VMS directory structure is
>>> reasonable.
>>>
>>
>> What is weird about the Unix directory structure? It is a simple tree.
>>
>> In what way is it different from the VMS structure other than not having
>> lots of "roots"?
>>
>
> Because I'm familiar with the VMS structure ???
>

Try using z/OS sometime. :-)

Simon.

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

On 2024-01-28, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <up4307$3iq8f$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>>On 1/27/2024 2:38 PM, Dan Cross wrote:
>>> Defining something as "weird" because you're not familiar with
>>> it isn't very enlightened. If that's the metric one judges by,
>>> consider how many orders of magnitude more people these days
>>> will call VMS's filesystem layout "weird" because it's different
>>> than something they are more familiar with, such as Linux, the
>>> Mac or Windows. Who's to say who's right under such subjective
>>> criteria?
>>>
>>
>>But, most here already know that I'm not enlightened ...
>>
>>:-)
>
> Hah!
>
>>As for "right", well, usually it's in the eye of the beholder.
>
> I suppose. But generally, at least we acknowledge that as being
> subjective.
>

$ set response/mode=good_natured

Don't be too hard on David, Dan. He still likes to use line numbers
in his BASIC code... :-)

Simon.

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

On 1/29/2024 8:24 AM, Simon Clubley wrote:
> On 2024-01-28, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <up4307$3iq8f$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 1/27/2024 2:38 PM, Dan Cross wrote:
>>>> Defining something as "weird" because you're not familiar with
>>>> it isn't very enlightened. If that's the metric one judges by,
>>>> consider how many orders of magnitude more people these days
>>>> will call VMS's filesystem layout "weird" because it's different
>>>> than something they are more familiar with, such as Linux, the
>>>> Mac or Windows. Who's to say who's right under such subjective
>>>> criteria?
>>>>
>>>
>>> But, most here already know that I'm not enlightened ...
>>>
>>> :-)
>>
>> Hah!
>>
>>> As for "right", well, usually it's in the eye of the beholder.
>>
>> I suppose. But generally, at least we acknowledge that as being
>> subjective.
>>
>
> $ set response/mode=good_natured
>
> Don't be too hard on David, Dan. He still likes to use line numbers
> in his BASIC code... :-)
>
> Simon.
>

That is a filthy slander ...

Line numbers can be used in place of labels for GoTo statements, which you'll
also probably also slander. But they can be useful. Other than that, line
numbers can be useful for appending boiler plate code to a program. Line
numbers are used in handling error exceptions and handling.

Your implication that I use numbers on every line is just false.

If I'm going to have:

On Error GoTo 32000

Ahhh, what's the use, you're probably just laughing ...

--
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 1/29/2024 8:11 AM, Simon Clubley wrote:
> On 2024-01-27, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/27/2024 8:52 AM, bill wrote:
>>> On 1/27/2024 12:32 AM, Dave Froble wrote:
>>>> On 1/26/2024 3:32 PM, Single Stage to Orbit wrote:
>>>>> Unix has some great tools for searching for folders and files. Are
>>>>> there similar ones in VMS like `grep` or `find`?
>>>>>
>>>>> THe folder structure in OpenVMS is wierd... what's the root folder
>>>>> equivalent is it [000000] or is it cleverer than that?
>>>>>
>>>>
>>>> No, the Unix directory structure is weird, the VMS directory structure is
>>>> reasonable.
>>>>
>>>
>>> What is weird about the Unix directory structure? It is a simple tree.
>>>
>>> In what way is it different from the VMS structure other than not having
>>> lots of "roots"?
>>>
>>
>> Because I'm familiar with the VMS structure ???
>>
>
> Try using z/OS sometime. :-)
>
> Simon.
>

NO! Just no.

--
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 2024-01-29, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/29/2024 8:11 AM, Simon Clubley wrote:
>>
>> Try using z/OS sometime. :-)
>>
>
> NO! Just no.
>

Oh, David, open your mind to new knowledge-learning possibilities. :-)

Simon.

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

On 1/29/2024 1:29 PM, Simon Clubley wrote:
> On 2024-01-29, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/29/2024 8:11 AM, Simon Clubley wrote:
>>>
>>> Try using z/OS sometime. :-)
>>>
>>
>> NO! Just no.
>>
>
> Oh, David, open your mind to new knowledge-learning possibilities. :-)
>
> Simon.
>

My mind is always open to new knowledge-learning possibilities.

But at this time that doesn't include much in software development.

I'm working on a new aircraft design that I'm building, Some unique features.
Lots of learning. Can't wait to start testing it. What to choose? Programmer?
Test pilot? What do you think?

I'm designing a humidifier that will be inexpensive and easy to fix. I really
hate the stuff you buy, new every year, cause it's junk. Forget about finding
replacement parts.

I have additional interests ...

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