ADD EXPORT/OPTION=DATA_CONVERSION not OK

[Hans Kokshoorn]

I would like to share textfiles created on my OpenVMS system with my windows environment using TCP/IP NFS and MS Services for Unix (SFU). All works fine except for the fact that I have problems with incompatible CR/LF between OpenVMS and Windows. According to the documentation the export option DATA_CONVERSION should solve this, but it does not. Specifying DATA_CONVERSION or NODATA_CONVERSION gives the same result.

I tried this on OpenVMS VAX 6.2 UCX 4.2 ECO5 and OpenVMS Alpha V7.3-2 TCP/IP V5.4 ECO5. Results are the same.

Any ideas?

[Steven Schweda]

What are the attributes (DIRE /FULL) of a
problem file on the VMS system? What were
you expecting to happen, and what did happen?
What in the documentation led you to expect
what you expect?

As I read the HELP, I'd expect the NFS
server to convert, say, a variable-length
record format to UNIX-friendly stream-LF,
but I would not expect it to convert
anything to a PC-friendly stream format (with
CR-LF line endings).

"Stream formats are returned unconverted."

Were you expecting the NFS server to convert
a file with LF line endings to CR-LF line
endings?

[Hans Kokshoorn]

Thanks for your fast response.

Yes, I expect a sequential file, variable length, carrage return carriage control to be converted. (Not Stream LF)

This is how I create a textfile:

$create test.txt
thisisline1
thisisline2
thisisline3
^Z
DIR/FULL gives:
Directory DKB400:[DIRDEW]
TEST.TXT;4 File ID: (8706,1,0)
Size: 1/3 Owner: [TCPIP,TCPIP$NOBODY]
Created: 10-MAY-2006 15:03:46.80
Revised: 10-MAY-2006 15:04:02.80(1)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 3, Extend: 0, Global buffer count: 0
No version limit
Record format: Variable length, maximum 0 bytes, longest 11 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RWED, World:RWED
Access Cntrl List: None
Client attributes: None

Opening this file on windows gives all 3 lines on the same line (no CR/LF)

[Steven Schweda]

> no CR/LF

But it is converting from the embedded byte
counts in a variable-length-format file to
LF line endings, right? (And these would be
just fine on a non-Windows system, like, say,
UNIX, right?)

I don't think that you can persuade the NFS
server to convert anything to CR-LF line
endings for you.

Better software on the Windows side?

ASCII-mode FTP transfers should fix the line
endings, but why should an NFS server? It
won't swap bytes around for little-endian
versus big-endian, either.