 |
» |
|
|
|
Ask the Wizard Questions
File name with foreign characters
The Question is:
I observed the following discrepancy:
When doing a
$ CREATE {QUE.DAT
%CREATE-E-OPENOUT, error opening ?QUE.DAT as output
-RMS-F-SYN, file specification syntax error
but with a
$ CREATE máqana.dat
%CREATE-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MÁQANA.DAT; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-W-BADFILENAME, bad file name syntax
Apparently, the first gets stopped by RMS and the second by the XQP.
Checking the literature, both the RMS internals book and the VMS system service
reference for such routines as SYS$FILESCAN
clearly consider accented LETTERS in DECMCS to be legal in filenames.
RMS seems to already conform.
The corresponding fix to F11BXQP seems trivial,
(I patched mine, on both VAX and Alpha and nothing broke)
but has never been made. Why not?
The Answer is:
Unfortunately the fix isn't quite as trivial as it seems. You're right, having
F11BXQP accept DECMCS characters in file name strings is a fairly trivial patch.
However, there are a couple of irregularities in the MCS that make a complete
fix more complex. The most obvious of these is that the German sharp S (ß) is a
lower case character only with no upper case form. Yet, of course, F11BXQP
blindly upcases all file names.
Deciding what collating sequense, if any, should be used to sort the names in a
directory is another potential complicating factor.
The set of annoying complications has so far created sufficient resistance to
prevent the file name character set from being expanded. However, we have
recently applied significant engineering effort in this area, and the character
set supported in file names will be substantially expanded in a version of
OpenVMS to release in the near future. Directory entries containing DECMC
characters that you have created with your patched file system should be
compatible with the new release.
|
