- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Unexpected ODS5 wildcard file-spec result
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2009 07:05 AM
11-11-2009 07:05 AM
Unexpected ODS5 wildcard file-spec result
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2009 07:58 AM
11-11-2009 07:58 AM
Re: Unexpected ODS5 wildcard file-spec result
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2009 09:20 AM
11-11-2009 09:20 AM
Re: Unexpected ODS5 wildcard file-spec result
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2009 11:50 AM
11-11-2009 11:50 AM
Re: Unexpected ODS5 wildcard file-spec result
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 $
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2009 08:59 PM
11-15-2009 08:59 PM
Re: Unexpected ODS5 wildcard file-spec result
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2009 05:31 AM
11-16-2009 05:31 AM
Re: Unexpected ODS5 wildcard file-spec result
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2009 07:46 AM
11-16-2009 07:46 AM
Re: Unexpected ODS5 wildcard file-spec result
The initially reported problem is an ODS5 "feature": dots in directory names do not always work as expected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-19-2009 03:48 AM
11-19-2009 03:48 AM
Re: Unexpected ODS5 wildcard file-spec result
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-19-2009 04:06 AM
11-19-2009 04:06 AM
Re: Unexpected ODS5 wildcard file-spec result
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2010 08:10 PM
10-03-2010 08:10 PM
Re: Unexpected ODS5 wildcard file-spec result
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2011 02:00 AM
03-20-2011 02:00 AM
Re: Unexpected ODS5 wildcard file-spec result
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2011 07:45 AM
03-20-2011 07:45 AM
Re: Unexpected ODS5 wildcard file-spec result
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2011 10:48 AM
03-20-2011 10:48 AM
Re: Unexpected ODS5 wildcard file-spec result
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2011 07:31 PM
03-20-2011 07:31 PM
Re: Unexpected ODS5 wildcard file-spec result
>> 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