Why does this DIFF command fail, then run fine the 2nd time around?

Post by ***@gmail.com
$ 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"
$

Volker Halle

2022-12-12 10:26:01 UTC

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.

Volker Halle

2022-12-12 10:28:28 UTC

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

Simon Clubley

2022-12-12 13:05:26 UTC

Post by Volker Halle

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

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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Volker Halle

2022-12-12 16:14:56 UTC

Post by Simon Clubley
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.

Dave Froble

2022-12-12 21:17:08 UTC

Post by Volker Halle

Post by Simon Clubley
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Stephen Hoffman

2022-12-12 18:27:40 UTC

Post by ***@gmail.com
$ 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

Dave Froble

2022-12-12 21:18:18 UTC

AFAIK, usual preferred command syntax with a concealed rooted logical name would
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Stephen Hoffman

2022-12-12 22:24:50 UTC

AFAIK, usual preferred command syntax with a concealed rooted logical
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

Dave Froble

2022-12-13 00:25:40 UTC

AFAIK, usual preferred command syntax with a concealed rooted logical name
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 ...

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
More baroque in recent years, in service to continued app compatibility.

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

Post by Stephen Hoffman
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

abrsvc

2022-12-13 00:54:00 UTC

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

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

Ayep ...

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
More baroque in recent years, in service to continued app compatibility.

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

Post by Stephen Hoffman
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
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

alanfe...@gmail.com

2022-12-13 03:00:48 UTC

AFAIK, usual preferred command syntax with a concealed rooted logical name
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 ...

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
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!

Post by Stephen Hoffman
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.

Post by Stephen Hoffman
More baroque in recent years, in service to continued app compatibility.

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

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

Jan-Erik Söderholm

2022-12-13 07:18:29 UTC

Post by ***@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.

Volker Halle

2022-12-13 07:38:37 UTC

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.

Fred. Zwarts

2022-12-13 09:20:35 UTC

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.

alanfe...@gmail.com

2022-12-29 04:20:14 UTC