Unexpected ODS5 wildcard file-spec result

[Steven Schweda]

I assume that the explanation of the behavior
shown below is obvious to anyone else, but I'm
not seeing it.

First, the things which I expect:

ALP $ show default
ALP$DKA100:[search_test]

ALP $ dire [...]

Directory ALP$DKA100:[search_test]

a^.b^.c.DIR;1 a_b_c.DIR;1

Total of 2 files.

Directory ALP$DKA100:[search_test.a^.b^.c]

file.dot;2

Total of 1 file.

Directory ALP$DKA100:[search_test.a_b_c]

file.und;1

Total of 1 file.

Grand total of 3 directories, 4 files.


ALP $ dire [.*a*...] ! (Same with "*b*".)

Directory ALP$DKA100:[search_test.a^.b^.c]

file.dot;2

Total of 1 file.

Directory ALP$DKA100:[search_test.a_b_c]

file.und;1

Total of 1 file.

Grand total of 2 directories, 2 files.


But:

ALP $ dire [.*c*...]

Directory ALP$DKA100:[search_test.a_b_c]

file.und;1

Total of 1 file.

I don't see a (good) reason for the difference
between "*a*" or "*b*" and "*c*".
Enlightenment would be gratefully received.

ALP $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 4
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.3

ECO's should be close to current.

ALP $ show process /parse_style

11-NOV-2009 08:56:34.83 User: SYSTEM Process ID: 20202F77
Node: ALP Process name: "SYSTEM_39447"

Parse Style: Extended

(But "Traditional" doesn't help.)

[Hein van den Heuvel]

Sure looks like a bug to me.
Testing variation:

$ dir/nohead/notrail [...]
MDA1:[HEIN]a^.b^.c.dir;1
MDA1:[HEIN.a^.b^.c]file.dot;1

works:

$ dir/nohead/notrail [.*a*...]
MDA1:[HEIN.a^.b^.c]file.dot;1
$ dir/nohead/notrail [.*b*...]
MDA1:[HEIN.a^.b^.c]file.dot;1
$ dir/nohead/notrail [.*^.c*...]
MDA1:[HEIN.a^.b^.c]file.dot;1

fails:

$ dir/nohead/notrail [.*c*...]
%DIRECT-E-OPENIN, error opening MDA1:[HEIN.*C*...]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

With our without trailing * does not matter.

Hein.

[Hoff]

Smells like an off-by-one bug.

[Steven Schweda]

> Sure looks like a bug to me.

That was my initial impression, but I'm
always open to a good argument.

It seems to be a low-level ($SEARCH?)
problem, not DCL-specific:

ALP $ zip31l a.zip [.*a*...]*.*
adding: [.a^.b^.c]file.dot (stored 0%)
adding: [.a_b_c]file.und (stored 0%)
ALP $ zip31l c.zip [.*c*...]*.*
adding: [.a_b_c]file.und (stored 0%)
ALP $

[John McL]

This might be related to a bug that we reported to HP a few months ago for ODS2 disks.

IIRC, we found that when there's a logical name with a search list for the directory and wildcard character in the file name, we were seeing repeats of the files for the last directory in the search list. I think it only appeared when relevant files existed in that last directory.

The symptom was as if directory scan context was losing position and couldn't identify the end of the directory list.

[Hoff]

John McL: when you have searchlists of sufficient number or complexity involved, you'll sometimes see very bad (but also expected) behavior as the file system works through the directory specification "stickiness" processing; as the defaults for filenames are applied.

The LINKER is the most common target for these defaulting reports given how many file specifications get passed into that device, and ended up with a way to shut off that processing.

How? Specify RMS_RELATED_CONTEXT=YES/NO in the LINKER options file.

[H.Becker]

The LINKer's bad behavior is seen with complex/long search lists and logical names: very time consuming RMS work to find out that a specified input file is not there. Switching off the RMS_RELATED_CONTEXT helps, but then you need to have a full filespec for each input file.

The initially reported problem is an ODS5 "feature": dots in directory names do not always work as expected.

[Mashood K]

I am Mashood from OpenVMS RMS Engineering.

I did some quick tests on this and noticed
that there is a problem with directories named
a^.b_c.dir also.

We have raised an internal problem report to track this issue and will work on fixing this.

Please let us know the impact of this so that
we can prioritize this work.

Regards,
Mashood

[Steven Schweda]

> Please let us know [...]

It's certainly annoying. I was trying to
compare a couple of directories,
[.openssl-1_0_0-beta4...] and
[.openssl-1^.0^.0-beta4...] by looking at
[.*beta4...], and I got no data from the
[.openssl-1^.0^.0-beta4...] tree. It seemed
to me to be a pretty serious problem. SEARCH
fails, DIRECTORY fails, everything (more or
less) fails.

I'm only a non-paying parasite/peon, so my
opinion may have little value, but if there
are any real customers out there using ODS5
extended file names, I'd guess (hope) that
they'd like something this fundamental to
work correctly. It certainly cost me some
time. (I might threaten to cancel my support
contracts, if I had any.)

[Steven Schweda]

As the anniversary approaches, I observe that
this problem remains in VMS Alpha V8.4 (with
VMS84A_SYS V1.0 and VMS84A_UPDATE V1.0) and
VMS IA64 V8.4 (with VMS84I_SYS V1.0 and
VMS84I_UPDATE V3.0).

[P Muralidhar Kini]

Steven,

In the case of the directory with name a^.b^.c.dir, when XQP parses the directory filename of A^.B^.C (common routine for both file and directory), it thinks that the last dot (before C) is that of the extension and hence only characters before the last dot are considered rather than the whole filename as it should be in this case. This is why the file spec of *a* and *b* works but *c* does not.

This problem is being worked upon and hopefully there wont be another anniversary :)

Regards,
Murali

[Steven Schweda]

> This problem is being worked upon and
> hopefully there wont be another anniversary
> :)

It's nice to know that it's on someone's
to-do list, but now that my patch access has
been cut off, a fix which I can't get may not
make much of a practical difference to me.

[Joseph Huber_1]

To narrow the time when the behaviour was introduced:
in VMS 7.3-1 it was not yet present:

$dire [.*c*...]

Directory DISK$HUBER:[HUBER.SCRATCH.a^.b^.c]
file.dot;1
Total of 1 file.
Directory DISK$HUBER:[HUBER.SCRATCH.a_b_c]
file.und;1

$ show process /parse_style
...
Parse Style: Extended

Total of 1 file.

[P Muralidhar Kini]

Hi Joseph,

>> To narrow the time when the behaviour was introduced:
>> in VMS 7.3-1 it was not yet present:
Thanks for the information.

I thought it to be a day 1 bug which probably got introduced when support for extended characters were added to XQP.

As the problem is not seen on V73-1 version, it must have been introduced in one of the later versions. Interesting.

Regards,
Murali