DAT file transfer issues

[Sethunath K.O]

Hi,
I wanted to transfer Data file (sequential and TXT file) from VAX to UNIX and Tandem.

For testing purpose I have transferred a sequential DAT file from VAX to Tandem using FTP. But while checking from Tandem I found that the numeric field/string fields in the DAT file are not appearing properly.

That is if I do FTP/BIN – string is not appearing properly and FTP/ASCII numeric field is not appearing properly.

Any tips please?

Thanks in advance
Sethu

[Robert Gezelter]

Sethu,

Please post a DIRECTORY/FULL of the DAT file.

A sample of the "problem" would also be helpful.

- Bob Gezelter, http://www.rlgsc.com

[Bojan Nemec]

Sethu,

What do you mean with numeric fields?

If they are binary you maybe have a problem with different data rapresentation. This could be a different endian ordering (VAX is little endian). The floating point rapresentation on VAX is also little endian which differs from the IEEE standard.

For data transfer between different operating systems is better to avoid binary data and use full text. Be also avare on some text rapresentations like overpunch (and zoned) numeric format rapresentation which is the default in VAX Cobol programs.


Bojan

[labadie_1]

Hello

A tool like CFT, renamed Synchrony Transfer now

http://axway.com/products/synchrony_transfer.php

or XCOM
http://www.ca.com/us/products/product.aspx?id=145

installed on Vms and Tandem, will solve that problem.

Yes, you will have to pay for both products.

[Hoff]

Use xxd or DUMP or such commands and determine if what you started with matches what you ended up with; if the original file is byte-for-byte identical to the copied file. If that's the case and the files match, then it's not the transfer, it's the data encoding.

For data transfer and data conversions, file structures intended for interchange - such as the surprisingly hazardous CSV and the rather better XML - have become available.

Floating point on VAX is not IEEE, and it's little endian.

Unix can be little or big endian.

Character encodings can differ.

Internal file structures of (for instance) RMS indexed files or SQL databases tend not to be portable. (Salient exception: SQLite.)

Most applications eventually have an export mechanism, where the contents of (often opaque) binary files are transfered into CSV or XML or such, and into an ISO Latin-1 (usually) character set and (better) within a Stream LF sequential file format.

OpenVMS itself offers no generic data export tool for random application binary files. The application maintainer is expected to write that conversion using application-specific format knowledge, and language I/O or RMS I/O calls or such to write the file.

[marsh_1]

hi,

possibly zipping/unzipping file may work.

[Steven Schweda]

> possibly zipping/unzipping file may work.

I'd bet against that. Zip+UnZip can fix
CR+LF line endings (and, perhaps, do
EBCDIC/ASCII conversions), but this sounds
like neither of those.

"DAT file" is not a sufficient description of
a file's contents to say exactly what went
wrong, and "not appearing properly" is not a
very useful description of the problems,
either, but differences in endianity and
floating-point format could cause enough
difficulties to account for (vague)
complaints like this.

[Sethunath K.O]

Thank you for your help.
It'sworking fine now