topic Re: DAT file transfer issues in Operating System - OpenVMS

DAT file transfer issues

Sethunath K.O — Wed, 10 Dec 2008 06:22:19 GMT

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

Re: DAT file transfer issues

Robert Gezelter — Wed, 10 Dec 2008 06:25:22 GMT

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

Re: DAT file transfer issues

Bojan Nemec — Wed, 10 Dec 2008 07:39:43 GMT

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

Re: DAT file transfer issues

labadie_1 — Wed, 10 Dec 2008 07:40:18 GMT

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.

Re: DAT file transfer issues

Hoff — Wed, 10 Dec 2008 13:25:32 GMT

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.

Re: DAT file transfer issues

marsh_1 — Wed, 10 Dec 2008 13:58:09 GMT

hi,

possibly zipping/unzipping file may work.

Re: DAT file transfer issues

Steven Schweda — Wed, 10 Dec 2008 14:23:32 GMT

> 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.

Re: DAT file transfer issues

Sethunath K.O — Thu, 01 Jan 2009 04:51:45 GMT

Thank you for your help.
It'sworking fine now