$ TO SCRFELD:[TOS]
===============================================================================
Processing SCRFELD:[TOS]
Checking SCRFELD:[TOS]
TO_1 = DISK_USER:[DECUSERVE_USER.FELDMAN]
TO_0 = SCRFELD:[TOS] ! (current default)
Your default is
SCRFELD:[TOS]
$ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
%DIFF-F-OPENIN, error opening SCRFELD:[TOS.B.*]CLEAR_NBACK_LNMS.COM; as input
-RMS-E-NMF, no more files found
$
$ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
Number of difference sections found: 0
Number of difference records found: 0

DIFFERENCES /PARALLEL-
SCRFELD:[TOS.A.TO_V530]CLEAR_NBACK_LNMS.COM;1-
SCRFELD:[TOS.B.T]CLEAR_NBACK_LNMS.COM;1
$

$ SHOW LOG/FUL SCRFELD
"SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal] (LNM$PROCESS_TABLE)
$
OpenVMS V8.4-2L2

TIA!

On Monday, December 12, 2022 at 1:45:46 AM UTC-5, alanfe...@gmail.com wrote:
> $ TO SCRFELD:[TOS]
> ===============================================================================
> Processing SCRFELD:[TOS]
> Checking SCRFELD:[TOS]
>
> TO_1 = DISK_USER:[DECUSERVE_USER.FELDMAN]
> TO_0 = SCRFELD:[TOS] ! (current default)
>
> Your default is
> SCRFELD:[TOS]
>
> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
> %DIFF-F-OPENIN, error opening SCRFELD:[TOS.B.*]CLEAR_NBACK_LNMS.COM; as input
> -RMS-E-NMF, no more files found
> $
> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
> Number of difference sections found: 0
> Number of difference records found: 0
>
> DIFFERENCES /PARALLEL-
> SCRFELD:[TOS.A.TO_V530]CLEAR_NBACK_LNMS.COM;1-
> SCRFELD:[TOS.B.T]CLEAR_NBACK_LNMS.COM;1
> $
>
> $ SHOW LOG/FUL SCRFELD
> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal] (LNM$PROCESS_TABLE)
> $
> OpenVMS V8.4-2L2
>
> TIA!

$ SHOW SYMBOL DIFP
DIFP == "DIFFERENCES/PARALLEL"
$

Not a new problem with V8.4-2L2, easily reproducible on OpenVMS Alpha V8.2 as well.

If you issue a $ SET WATCH FILE/CLASS=ALL before the DIFF command, it shows

....
%XQP, Thread #0, Read only directory access (39801,21,0)
%XQP, Thread #0, Directory scan for: TEST.TXT;4294934528, Status: 00000001 <<< ???
%XQP, Thread #0, Directory scan for: TEST.TXT;0, Status: 00000000
%XQP, Thread #0, Access (39801,21,0) Status: 00000930
%DIFF-F-OPENIN, error opening USERDISK1:[HALLE.ITRC.B.*]TEST.TXT; as input
-RMS-E-NMF, no more files found
....

for the first DIFF command and

....
%XQP, Thread #0, Read only directory access (39801,21,0)
%XQP, Thread #0, Directory scan for: TEST.TXT;0, Status: 00000001
....

when repeating the DIFF command.

Maybe some data initialization problem in P1 space ?

Volker.

> %XQP, Thread #0, Directory scan for: TEST.TXT;4294934528, Status: 00000001 <<< ???

This version no. is interesting:

AXPVMS $ x=4294934528
AXPVMS $ sho sym x
X = -32768 Hex = FFFF8000 Octal = 37777700000

Volker.

On 2022-12-12, Volker Halle <volker_halle@hotmail.com> wrote:
>
>> %XQP, Thread #0, Directory scan for: TEST.TXT;4294934528, Status: 00000001 <<< ???
>
> This version no. is interesting:
>
> AXPVMS $ x=4294934528
> AXPVMS $ sho sym x
> X = -32768 Hex = FFFF8000 Octal = 37777700000
>

Does it also fail on other architectures such as Itanium or x86-64 ?

Simon.

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

> Does it also fail on other architectures such as Itanium or x86-64 ?

If tails in the same way on VSI OpenVMS x86-64 V9.2

It fails in the same way on OpenVMS I64 V8.2

If fails differently on OpenVMS VAX V6.2 and V7.3

CHARON $ diff [.a.to_v53]test.txt [.b.*]
%DIFF-F-OPENIN, error opening SYS$SYSDEVICE:[ITRC.B.*]TEST.TXT; as input
-RMS-F-DIR, error in directory name

Volker.

On 2022-12-12 06:45:44 +0000, alanfe...@gmail.com said:

> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
> ...
> $ SHOW LOG/FUL SCRFELD
> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]"
> [concealed,terminal] (LNM$PROCESS_TABLE)
> $

AFAIK, usual preferred command syntax with a concealed rooted logical
name would be thus:

DIFP SCRFELD:[A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [B.*]

Trailing dot (from the logical name, correctly) and leading dot (from
the appended directory) passes along some variation of [TOS..A] and
[TOS..B].

Looks like a dusty corner within the name and default name and
related-spec parsing, among other dusty corners within filespec parsing.

Shouldn't blow up, but arguably also probably shouldn't work.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/12/2022 11:14 AM, Volker Halle wrote:
>> Does it also fail on other architectures such as Itanium or x86-64 ?
>
> If tails in the same way on VSI OpenVMS x86-64 V9.2
>
> It fails in the same way on OpenVMS I64 V8.2
>
> If fails differently on OpenVMS VAX V6.2 and V7.3
>
> CHARON $ diff [.a.to_v53]test.txt [.b.*]
> %DIFF-F-OPENIN, error opening SYS$SYSDEVICE:[ITRC.B.*]TEST.TXT; as input
> -RMS-F-DIR, error in directory name
>
> Volker.
>

Parsing a filespec on VMS has always been interesting ...

--
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 12/12/2022 1:27 PM, Stephen Hoffman wrote:
> On 2022-12-12 06:45:44 +0000, alanfe...@gmail.com said:
>
>> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
>> ...
>> $ SHOW LOG/FUL SCRFELD
>> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal]
>> (LNM$PROCESS_TABLE)
>> $
>
> AFAIK, usual preferred command syntax with a concealed rooted logical name would
> be thus:
>
> DIFP SCRFELD:[A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [B.*]
>
> Trailing dot (from the logical name, correctly) and leading dot (from the
> appended directory) passes along some variation of [TOS..A] and [TOS..B].
>
> Looks like a dusty corner within the name and default name and related-spec
> parsing, among other dusty corners within filespec parsing.
>
> Shouldn't blow up, but arguably also probably shouldn't work.
>
>

Some people are way too fond of rooted logical names ...

--
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 2022-12-12 21:18:18 +0000, Dave Froble said:

> On 12/12/2022 1:27 PM, Stephen Hoffman wrote:
>> On 2022-12-12 06:45:44 +0000, alanfe...@gmail.com said:
>>
>>> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
>>> ...
>>> $ SHOW LOG/FUL SCRFELD
>>> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal]
>>> (LNM$PROCESS_TABLE)
>>> $
>>
>> AFAIK, usual preferred command syntax with a concealed rooted logical
>> name would be thus:
>>
>> DIFP SCRFELD:[A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [B.*]
>>
>> Trailing dot (from the logical name, correctly) and leading dot (from
>> the appended directory) passes along some variation of [TOS..A] and
>> [TOS..B].
>>
>> Looks like a dusty corner within the name and default name and
>> related-spec parsing, among other dusty corners within filespec parsing.
>>
>> Shouldn't blow up, but arguably also probably shouldn't work.
>>
>
> Some people are way too fond of rooted logical names ...

There are some people too fond of logical names, too.

Though this case looks more like filename parsing gone awry.

Wouldn't be the first time there was a bug in filename parsing either,
as somebody else (A.M.) once remarked. While debugging a
parsing-related error.

OpenVMS filename syntax is... baroque.

More baroque in recent years, in service to continued app compatibility.

DIDing, FIDing, ^U, mount points, what's implemented in the CRTL and
what's in the XQP, etc.

And in the current (2019) doc, UTF-8 / UCS-2 doc is ~missing, the
"^UP^" POSIX stuff is seemingly missing, and there's a section
"Information about Unicode TBS".

The more I know about the filename parsing and character encoding in
this context, and how logical names fit in, the less I understand about
it all...

All that before discussions of normalizing a filenames, something that
does not (yet?) exist.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/12/2022 5:24 PM, Stephen Hoffman wrote:
> On 2022-12-12 21:18:18 +0000, Dave Froble said:
>
>> On 12/12/2022 1:27 PM, Stephen Hoffman wrote:
>>> On 2022-12-12 06:45:44 +0000, alanfe...@gmail.com said:
>>>
>>>> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
>>>> ...
>>>> $ SHOW LOG/FUL SCRFELD
>>>> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal]
>>>> (LNM$PROCESS_TABLE)
>>>> $
>>>
>>> AFAIK, usual preferred command syntax with a concealed rooted logical name
>>> would be thus:
>>>
>>> DIFP SCRFELD:[A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [B.*]
>>>
>>> Trailing dot (from the logical name, correctly) and leading dot (from the
>>> appended directory) passes along some variation of [TOS..A] and [TOS..B].
>>>
>>> Looks like a dusty corner within the name and default name and related-spec
>>> parsing, among other dusty corners within filespec parsing.
>>>
>>> Shouldn't blow up, but arguably also probably shouldn't work.
>>>
>>
>> Some people are way too fond of rooted logical names ...
>
> There are some people too fond of logical names, too.

Ayep ...

> Though this case looks more like filename parsing gone awry.

It's the other side of lots of flexibility, many options,some might claim too
many options.

> Wouldn't be the first time there was a bug in filename parsing either, as
> somebody else (A.M.) once remarked. While debugging a parsing-related error.

The rooted logical stuff is interesting, but, sometimes just because one can do
something, doesn't then mean that they should do it.

The early developers wanted multiple OS roots. Ok, maybe that might be Ok. But
then others took the concept, and used it where it just wasn't needed. They did
it because they could. Reminds me of "the road to hell is paved with good
intentions" and other such.

> OpenVMS filename syntax is... baroque.

Don't make me look up that word ...

:-)

I have no problem with the basic filespec stuff. I actually prefer the
"[a.b.c]" directory specification over "/A/B/C", but I do understand the latter
might be easier to parse. Don't know, never used it much. Don't like it.

> More baroque in recent years, in service to continued app compatibility.

If apps don't get "tricky" then perhaps compatibility might be easier.

> DIDing, FIDing, ^U, mount points, what's implemented in the CRTL and what's in
> the XQP, etc.

Ok, opinion time. The CRTL should deal with C stuff. VMS stuff has no place in
the CRTL. Just my opinion. Originally VMS stuff had System Services, LIB$,
etc. Then someone got lazy.

--
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 Monday, December 12, 2022 at 7:26:54 PM UTC-5, Dave Froble wrote:
> On 12/12/2022 5:24 PM, Stephen Hoffman wrote:
> > On 2022-12-12 21:18:18 +0000, Dave Froble said:
> >
> >> On 12/12/2022 1:27 PM, Stephen Hoffman wrote:
> >>> On 2022-12-12 06:45:44 +0000, alanfe...@gmail.com said:
> >>>
> >>>> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
> >>>> ...
> >>>> $ SHOW LOG/FUL SCRFELD
> >>>> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal]
> >>>> (LNM$PROCESS_TABLE)
> >>>> $
> >>>
> >>> AFAIK, usual preferred command syntax with a concealed rooted logical name
> >>> would be thus:
> >>>
> >>> DIFP SCRFELD:[A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [B.*]
> >>>
> >>> Trailing dot (from the logical name, correctly) and leading dot (from the
> >>> appended directory) passes along some variation of [TOS..A] and [TOS...B].
> >>>
> >>> Looks like a dusty corner within the name and default name and related-spec
> >>> parsing, among other dusty corners within filespec parsing.
> >>>
> >>> Shouldn't blow up, but arguably also probably shouldn't work.
> >>>
> >>
> >> Some people are way too fond of rooted logical names ...
> >
> > There are some people too fond of logical names, too.
> Ayep ...
> > Though this case looks more like filename parsing gone awry.
> It's the other side of lots of flexibility, many options,some might claim too
> many options.
> > Wouldn't be the first time there was a bug in filename parsing either, as
> > somebody else (A.M.) once remarked. While debugging a parsing-related error.
> The rooted logical stuff is interesting, but, sometimes just because one can do
> something, doesn't then mean that they should do it.
>
> The early developers wanted multiple OS roots. Ok, maybe that might be Ok.. But
> then others took the concept, and used it where it just wasn't needed. They did
> it because they could. Reminds me of "the road to hell is paved with good
> intentions" and other such.
> > OpenVMS filename syntax is... baroque.
> Don't make me look up that word ...
>
> :-)
>
> I have no problem with the basic filespec stuff. I actually prefer the
> "[a.b.c]" directory specification over "/A/B/C", but I do understand the latter
> might be easier to parse. Don't know, never used it much. Don't like it.
> > More baroque in recent years, in service to continued app compatibility..
> If apps don't get "tricky" then perhaps compatibility might be easier.
> > DIDing, FIDing, ^U, mount points, what's implemented in the CRTL and what's in
> > the XQP, etc.
> Ok, opinion time. The CRTL should deal with C stuff. VMS stuff has no place in
> the CRTL. Just my opinion. Originally VMS stuff had System Services, LIB$,
> etc. Then someone got lazy.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486
Without getting too far off into a tangent...

There are uses for rooted directories not only for the OS and clusters, but also for the installations that have multiple user groups and require some level of separation as well as common files. I have used this method along with group level and names logical name tables to isolate specific clients from each other while still maintaining common executables and procedures.. As with any "feature", it can be abused but can also be an asset when used proper

Dan

On Monday, December 12, 2022 at 7:26:54 PM UTC-5, Dave Froble wrote:
> On 12/12/2022 5:24 PM, Stephen Hoffman wrote:
> > On 2022-12-12 21:18:18 +0000, Dave Froble said:
> >
> >> On 12/12/2022 1:27 PM, Stephen Hoffman wrote:
> >>> On 2022-12-12 06:45:44 +0000, alanfe...@gmail.com said:
> >>>
> >>>> $ DIFP SCRFELD:[.A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [.B.*]
> >>>> ...
> >>>> $ SHOW LOG/FUL SCRFELD
> >>>> "SCRFELD" [super] = "DSA2:[USR_SCRATCH.FELDMAN.]" [concealed,terminal]
> >>>> (LNM$PROCESS_TABLE)
> >>>> $
> >>>
> >>> AFAIK, usual preferred command syntax with a concealed rooted logical name
> >>> would be thus:
> >>>
> >>> DIFP SCRFELD:[A.TO_V530]CLEAR_NBACK_LNMS.COM;1 [B.*]
> >>>
> >>> Trailing dot (from the logical name, correctly) and leading dot (from the
> >>> appended directory) passes along some variation of [TOS..A] and [TOS..B].
> >>>
> >>> Looks likeasdf a dusty corner within the name and default name and related-spec
> >>> parsing, among other dusty corners within filespec parsing.
> >>>
> >>> Shouldn't blow up, but arguably also probably shouldn't work.
> >>>
> >>
> >> Some people are way too fond of rooted logical names ...
> >
> > There are some people too fond of logical names, too.
> Ayep ...
> > Though this case looks more like filename parsing gone awry.
> It's the other side of lots of flexibility, many options,some might claim too
> many options.
> > Wouldn't be the first time there was a bug in filename parsing either, as
> > somebody else (A.M.) once remarked. While debugging a parsing-related error.
> The rooted logical stuff is interesting, but, sometimes just because one can do
> something, doesn't then mean that they should do it.
>
> The early developers wanted multiple OS roots. Ok, maybe that might be Ok. But
> then others took the concept, and used it where it just wasn't needed. They did
> it because they could. Reminds me of "the road to hell is paved with good
> intentions" and other such.

I find the rooted directory bit very useful. In this case, I can maintain a parallel world on the scratch disk on EISNER. The top directories aren't the same, but with the rooted directory, I can make my own directory tree the same.

I can have

DISK_USER:[DECUSERVE_USER.FELDMAN]
SCRFELD:[DECUSERVE_USER.FELDMAN]

Then I can create a parallel directory structure on the scratch disk, move less important old versions of files and other less important files to SCRFELD:, where I am not limited by a disk quota.

I can use commands like $ BACK/VERI/DELE files SCRFELD: !!! and the files go over without having to specify the scratch disk version of the directory I happen to be in!

> > OpenVMS filename syntax is... baroque.
> Don't make me look up that word ...
>
> :-)
>
> I have no problem with the basic filespec stuff. I actually prefer the
> "[a.b.c]" directory specification over "/A/B/C", but I do understand the latter
> might be easier to parse. Don't know, never used it much. Don't like it.
> > More baroque in recent years, in service to continued app compatibility.
> If apps don't get "tricky" then perhaps compatibility might be easier.
> > DIDing, FIDing, ^U, mount points, what's implemented in the CRTL and what's in
> > the XQP, etc.
> Ok, opinion time. The CRTL should deal with C stuff. VMS stuff has no place in
> the CRTL. Just my opinion. Originally VMS stuff had System Services, LIB$,
> etc. Then someone got lazy.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

Den 2022-12-13 kl. 04:00, skrev alanfe...@gmail.com:

> I find the rooted directory bit very useful. In this case, I can maintain a parallel world on the scratch disk on EISNER. The top directories aren't the same, but with the rooted directory, I can make my own directory tree the same.
>
> I can have
>
> DISK_USER:[DECUSERVE_USER.FELDMAN]
> SCRFELD:[DECUSERVE_USER.FELDMAN]
>
> Then I can create a parallel directory structure on the scratch disk, move less important old versions of files and other less important files to SCRFELD:, where I am not limited by a disk quota.
>
> I can use commands like $ BACK/VERI/DELE files SCRFELD: !!! and the files go over without having to specify the scratch disk version of the directory I happen to be in!
>
>

There are other cases where rooted dirs saves a lot of work.

Take as an example an Rdb database. All the files and directories
that Rdb used for storage areas, RUJ and AIJ files, backup files
and so on *should* be on rooted dirs. Then you do not need to
recreate (backup/restore) the database just because your physical
disks has changed names. Just adjust your rooted dirs to the new
physical disk names and start-up Rdb again.

Normal logical names will not do, since Rdb will translate them
and store the translated name in the database.

Please note that this apparent filename parsing problem has nothing to do with rooted logical names, as can be seen with the output posted above:

$ diff [.a.to_v53]test.txt [.b.*]
%DIFF-F-OPENIN, error opening SYS$SYSDEVICE:[ITRC.B.*]TEST.TXT; as input

As the problem 'disappears' after the first execution of this command in the current process and you have to log out and log in again to be able to reproduce this behaviour again, it most likely is related to some XQP data structure initialization in P1 space.

Volker.

Op 13.dec..2022 om 01:25 schreef Dave Froble:

>
> I have no problem with the basic filespec stuff.  I actually prefer the
> "[a.b.c]" directory specification over "/A/B/C", but I do understand the
> latter might be easier to parse.  Don't know, never used it much.  Don't
> like it.
>

One of the problems is that there is so much more than the basic
filespec stuff. Mostly because of compatibility with older specs.
Apart from [a.b.c] there is <a.b.c> and [200,172], which becomes very
'interesting' when mixed, e.g. the rooted logical names uses <> and the
remainder uses [], not only interesting to parse it, but also to apply
it to a related filespec.
In addition there are logical names that can be concealed or not, or
terminal, or not. A lot of room for bugs.

On Tuesday, December 13, 2022 at 4:20:40 AM UTC-5, F.Zwarts wrote:
> Op 13.dec..2022 om 01:25 schreef Dave Froble:
> >
[...]
To all in this thread:

Just made an interesting discovery today:

DIFFERENCES

Parameters

input1-filespec

Specifies the first file to be compared. The file specification
must include a file name and a file type. The asterisk (*) and
the percent sign (%) wildcard characters are not allowed.

input2-filespec

Specifies the second file to be compared. Unspecified fields
default to the corresponding fields in the input1-filespec
parameter. The asterisk (*) and the percent sign (%) wildcard
characters are not allowed.

If you do not specify a secondary input file, the DIFFERENCES
command uses the next lower version of the primary input file.

DIFFERENCES Subtopic?

OK, no * or % in the params. But my example here only fails the first time you run it! Simply repeating the command, then it works fine.

Well, it seems to only work if your input2-filespace is in the first subdir. So best not to use it.