Re: Guidelines for converting programs to ODS-5?

In article <JVmZ40H++ZCo@xxxxxxxxxxxxxxxxxxxxxxxx>,
wb8tyw@xxxxxxxxxxx (John E. Malmberg) wrote:

In article <45D10D9A.48AB8E09@xxxxxxxxxxxxxxxx>,
David J Dachtera <djesys.no@xxxxxxxxxxxxxxxx> writes:

JF Mezei wrote:

For adding ODS-5 feature access from a program, I've conditionally
compiled my RMS code for VAX vs. other, using NAM vs. NAML.

Note that an Alpha can have access to ODS2 disks as well. So an alpha
executable shouldn't assume ODS5 for everything.

Another reason why I keep suggesting that VMS should have a "make valid
file name" function (perhaps an item code in SYS$PARSE) that would ensure
the file name is converted to a valid form for the target disk depending
on
its structure. This way, programs could allow input of any file name, and
use that service to convert the file name into a valid one for the target
device.

How do you convert it back?

It would take a while to even come up with a list of all the popular ways to
encode a UNIX file specification into a ODS-2 legal method, and many of the
methods are one way.

For example, if a program needs to open foo.bar.dat, a robust program could
need to look for:

foo^.bar.dat foo_bar.dat foo.bar_dat and even
foo__46bar.dat foo.bar__46.dat

Add in the trick of using the $ character to invert case that some
conversions
do, you have even more possibilities to search for. The last too encodings
have been used by various versions of Pathworks, Advanced Server, and SAMBA,
and are the only way that is reversible.


And that is with out getting UNICODE into the picture.


One method of coding is documented in Appendix C of the TCP/IP
Management Guide "How NFS Converts File Names"

--
Paul Sture
.