C function to check for valid openVMS path specifcation

[Almond Desailly]

Hi all,

I want to know whether there is any C library function, which I can use to check whether a given string is a valid OpenVMS path format or not.
Though I can write one, but if there already exists one such function (may be a DECC function), then I would not want to devote any time in writing that part of code.

I tried to google this out, but it would not give any desirable result.

Thanks in advance!

Cheers,
Almond

[Steven Schweda]

I'd vote for the $PARSE system service.

HELP SYSTEM_SERVICES $PARSE

is not very informative, other than to
suggest the manual to read. If an example
might be helpful, then you might look
through, say, the Info-ZIP Zip source code
for "sys$parse". ("[vms]vms.c" is one
place.) As usual, calling a system service
like this one tends to involve some
relatively messy code elements, such as
string descriptors, and, because it involves
the file system(s), various RMS structures
(FAB, NAM[L]). The addition of ODS5 and the
NAML structure added some complications for a
program like Zip, which can still be built on
VMS VAX V5.4 (ODS2-only), but if you steal
enough code, it should work. If you don't
demand so much portability, then the code
could be streamlined some. (I didn't see
your VMS version in your original problem
statement.) A Web search for "sys$parse"
should find more examples, of course.

> [...] Though I can write one, [...]

While it might seem to be easier to write
your own code, $PARSE is the gold standard
for what's good and what's bad.

[Hoff]

Do you mean syntactically valid, or whether or not the file or directory exists?

Because standard C doesn't know a whole lot about VMS-format specifications, you're going to have to call out to extensions or more often to VMS calls, if you want to work with VMS-format file specifications.

For a syntactically valid VMS specification, yes, call $parse with the NAM$V_SYNCHK flag set. This won't catch missing directories, et al.; valid specifications that won't necessarily work.

This discussion borders on various obscure areas of C on VMS, as the rules are somewhat arcane, and also given that valid C paths can also be Unix-format paths, and both Unix and VMS specifications can be equally valid, but quite different.

There are all sorts of corner cases scattered around here, too, with the conversions, and with details such as ODS-2 and ODS-5 support and settings.

I generally recommend sticking with Unix-format specifications, as they're easier to parse and deal with.

If not, try it. That's the standard and best test. See if it works. (The same holds for testing permissions. Try it.)

I don't know if off-hand if there's a C call akin to sys$parse. Usually, most anything other than / and \0 are accepted in a filename.

If you want or have to use C specifications but also need to work with VMS format specifications, then there are routines (decc$to_vms and decc$from_vms) that convert these from and to VMS-format specifications. There are (were) examples of both in the C library reference manual.

The compatibility was described in /Symbolic Links and POSIX Pathname Support/ in recent C documentation.

As for rolling your own, you can be assured that home-grown to parse filenames will very likely be wrong. (I don't mean that to be offensive, either.) And should there be changes to how VMS works in this area (and there have been) your code then differs from VMS. There are still applications that insist on ODS-2 specifications, and even VMS itself can't manage <> syntax in various of its own tools.

Here's what POSIX has to say about portable specs:

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html

And POSIX defines upper and lowercase alphabetic, numeric, underscore, hyphen and dot as the portable characters.

Various Unix implementations and file systems can deal with a whole lot more than that, and VMS adds the $, and pretty soon you're finished with your tea and down the rabbit hole. And VMS has also added UTF-8 and VTF-7 characters, just for "fun".

Beyond "try it", there isn't a simple answer.

[H.Becker]

>>> I don't know if off-hand if there's a C call akin to sys$parse. Usually, most anything other than / and \0 are accepted in a filename.
<<<
realpath(). But is has no equivalent flag for NAM$V_SYNCHK. In Posix it checks if all the intermediate directories exist. And yes, a Posix path is a C-style string, which excludes only the \0.

>>> And VMS has also added UTF-8 and VTF-7 characters, just for "fun".
<<<
UTF-8 is just an encoding for up to four UNICODE charactes with ISL-2 characters. SYS$PARSE supports ISL-2 characters, so it supports UTF-8. The CRTL supports UTF-8. VTF-7 is just an encoding for UCS-2 characters. The CRTL only supports VTF-7 in the VMS file name space.

[Hoff]

>UTF-8 is just an encoding for up to four UNICODE charactes with ISL-2 characters. SYS$PARSE supports ISL-2 characters, so it supports UTF-8. The CRTL supports UTF-8. VTF-7 is just an encoding for UCS-2 characters. The CRTL only supports VTF-7 in the VMS file name space.


I rest my case, your honor.

[John McL]

You'll probably find useful information in chapter 12 ('Symbolic links and POSIX pathname support') of the C Runtime Library Reference manual.

URL: http://h71000.www7.hp.com/doc/83final/5763/OVMS_83_CRTL_REF.PDF

[Hoff]

The VMS implementation of extended filename encoding, um, quite bizarre. (And it doesn't get to character encoding within the files, as that's largely a non-starter.)

For some discussions of UTF-8 and VTF-7 encoding and of porting code involving UTF-8, see:

http://snow.hoffmanlabs.net/node/1481

And for grins, also see

sys$examples:filename_compare.c

(I'd also suggest testing whether the above works with the UTF-8 encoding, as there's no mention of it there.)

The VTF-7 stuff seems entirely undocumented, and looks like it might have been some early version or variant of encoding, or a DEC-internal spec that was never released.

And thanks for the pointer to the C manuals, I'd completely forgotten to mention the forest of C logical names that can be in play. Depending on what you're up to, change one or two of these and the application can fall down in odd ways.

All of which goes back to my original comment: you really don't want to drop down this rabbit hole if you can avoid it. You may end up more than late for your tea. Use the existing calls, and (best you can) stay away from trying to judge what characters are permissible or not.

Reposting as ITRC is being ITRC again today.

[Hoff]

Ah, nuts. Corrected URL...

http://labs.hoffmanlabs.com/node/1481

[Craig A Berry]

There is a rather gnarly example of calling sys$parse in the Perl sources here:

http://perl5.git.perl.org/perl.git/blob/HEAD:/vms/vms.c#l5400

The "int_rmsexpand" function takes input in either Unix or VMS format and attempts to handle older and newer maximum filename lengths as well as some of the DECC$* features. It explicitly punts on UTF-8. All in all, reading (or maintaining) this code can certainly feel like falling down a rabbit hole.

[Almond Desailly]

Hi all,

Thanks for overwhelming responses ..
I will try the various options that have been mentioned by you all...

(and just to add, I was just looking to syntactically validate a string for a valid openVMS path.)

Thanks again

Thanks,
Almond

[Steven Schweda]

> (and just to add, I was just looking to
> syntactically validate a string for a valid
> openVMS path.)

But, as you can see, that can mean different
things, especially in a C context, where a
UNIX-like file spec is also accepted.

[David Jones_21]

For just checking syntax, SYS$FILESCAN is an alternative to SYS$PARSE that may be easier for a novice to use.

[John Gillings]

re David, $FILESCAN

I'm not sure $FILESCAN does what Almond wants. $FILESCAN is happy to parse any random string, looking for anything which might be a filespec. You'll get a success status regardless of what you input (as long as the arguments are valid). For a completely invalid filespec the fldflags parameter will be empty, but any trailing garbage will be ignored in a valid filespec.

You could use the valuelst item list to extract the fields which $FILESCAN found, then reconstruct the proposed filespec and compare it with your input. If not equal there were excess characters in the string, and it is therefore invalid. That seems like a lot of work, and I suspect it would fail if you fed it an access control string with a password.

Perhaps try LIB$TRIM_FILESPEC?

LIB$TRIM_FILESPEC(instring,outstring,width,outlength)

make "width" longer than instring and check for a non-null outstring. Status seems to be success for all input strings. TRIM_FILESPEC uses $FILESCAN, but does all the unpacking and packing for you.

(BTW what decided to remove the HTML versions of the OpenVMS document set, replacing them with only PDF?

Not only do I now have to download a complete manual to read anything, but I now have to search it, rather than navigate an index. No doubt it's cheaper because they no longer have to maintain HTML indexes, but at what cost to customer satisfaction? At the very least they could have left the existing versions)

[Steven Schweda]

> (BTW what decided to remove the HTML
> versions of the OpenVMS document set,
> replacing them with only PDF?

It's a mystery to me. I seem to recall
having the same complaint about the HP-UX
"man" stuff. Idiocy would seem to be the
most likely explanation.

> [...] At the very least they could have
> left the existing versions)

No, at the _very_ least, they could have
removed everything. But I'll admit that
removing the most conveniently useful
material is pretty close.

[Dennis Handly]

>John: BTW what decided to remove the HTML versions of the OpenVMS document set, replacing them with only PDF?

This was mentioned before on the HP-UX side:
http://h30499.www3.hp.com/t5/HP-UX-Technical-Documentation/BSC-Why-bad-decision-broken-links-and-unable-to-find-old/m-p/4734258#M1310

http://h30499.www3.hp.com/t5/Your-Questions-Regarding-ITRC/an-excellent-resource-replaced-by-worst-docs-hp-com-vs-BSC/m-p/4627287#M3393

http://h30499.www3.hp.com/t5/Your-Questions-Regarding-ITRC/2010-Jan-March-31-Performance-access-issue-whine-thread/m-p/5217017#M5228

http://h30499.www3.hp.com/t5/HP-UX-Technical-Documentation/A-Greasemonkey-script-for-BSC-documents/m-p/4469289#M1203

http://h30499.www3.hp.com/t5/HP-UX-Technical-Documentation/How-To-Find-Documents/m-p/4697783#M1269

>Not only do I now have to download a complete manual to read anything, but I now have to search it, rather than navigate an index.

Unfortunately. :-(

>Steven: I seem to recall having the same complaint about the HP-UX "man" stuff.

Yes see above and they improved it by a PDF quick links page:
http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02456334/c02456334.pdf

[Hoff]

>>Not only do I now have to download a complete manual to read anything, but I now have to search it, rather than navigate an index.

>Unfortunately. :-(

Mac OS X boxes will search the downloaded PDFs at blinding speed with the Spotlight search tool, and AFAIK Windows 7 also offers high-performance searches.

Downloading PDFs was already far more efficient than the HTML-based approach. (This also given the longstanding problems with the HP "search" engine indexing, and the unfortunate fondness for blocking Googlebot from various parts of the HP web site.)

There are secondary issues around the formatting of the downloaded PDF files. Many unfortunately seem to have been generated by substandard tools or conversions, and lack internal hyperlinks and related PDF features.

[John Gillings]

Hoff,

>Mac OS X boxes will search the downloaded
>PDFs at blinding speed

Sure, searches are fast, independent of OS, but they have no context, and I can't search until I've completed a 2MB download. That takes time, especially on this side of the planet. Since the documents themselves have cryptic names, it's non trivial to cache copies and keep track of them, and I then have to track changes.
Consider, suppose I want to look up a specific routine, let's say CREATE. With an INDEX I can use headings to go direct to the top of the routine I'm looking for. With a text search function, I get a bazillion hits in other contexts which aren't relevant to what I'm looking for. Indeed, the indexes and TOCs in the PDFs are a HINDERANCE because the documents themselves have no cross links. Thus, when I'm searching for even a highly specific string like LIB$TRIM_FILESPEC, the first few hits are in the (useless) index or TOC, instead of what I'm looking for.

[John Gillings]

I knew that HP had descended into Dilbert World to some extent, but hadn't realised how far!

Here is HPs response regarding the documentation:

"We regret the inconvenience. The HTML pages
were not complying to the HP standards and
had to be removed from the site."

So, instead of pushing back on the standard saying "that would inconvenience our paying customers - the standard should be changed", or reprocessing the HTML pages to conform with whatever nonsense the pointy haired bosses decided to call a standard, the "solution" is to delete useful information?

Wow!

[Steven Schweda]

> [...] not complying to the HP standards [...]

And I was afraid that they wouldn't have a
good reason. Silly of me, I see now.

This from the people who give us "Error while
posting the reply" half the time when we're
foolish enough to try "Submit>>" after
"Preview>>". It's enough to drive one to
personal abuse.

[WW304289]

Some nitpicking.

> [...] not complying to the HP standards [...]

This "complying to" got my attention so I went and checked.

From <>

"
Is it comply with or comply to?

It is "comply with" or "conform to" not "comply to."

To act in agreement with rules or requests.
Definitely comply with
"

It will be interesting to see what form they will use in the announcement about complete removal of the documentation.

-Boris

[Steven Schweda]

> It will be interesting to see what form
> they will use in the announcement about
> complete removal of the documentation.

"different than".