Alpha FDL and TCPIP

[juana perley]

We have just migrated from the VAX to Alpha 7.3.2. We have also switched from Multinet to TCPIP services. We are doing a convert/fdl on a sequential file and then ftp the file to a server. The file is then picked up by a vendor who processes the requests. The problem is that they are rejecting the file as invalid length. The program that writes out the file has not changed in 2 years. The file that is transferred contains multiple records of 276 bytes. The downstream system executes the first record but none of the others. It seems as if the FDL is not stripping out the carriage return. The FDL has Carriage_Control as none.

[Hein van den Heuvel]

Well, donuts to dollars that the change was introduced by the tcp stack change. I'm not suggesting either was broken, just that they are different. Why not share some more exact details with us? Like:
- The exact FDL file used
- Perhaps a DIR/FULL on the convert input and output
- Perhaps a DUMP/BLOCK=COUNT=0 on the output.
- an indication whehter you use Binary or Ascii more in ftp.
- Perhaps a DUMP from the receiving side.

If you still can, please gather the above details for yourself for both the VAX and thae APLHA case. I suspect that will pretty soon confirm that the files after teh convert are byte-for-byte the same (but hey, stranger things have happened, so do check!)

If you are goign to share DUMP data with us, please stick it in a text file and attach as the presentation makes dumps almost unreadable.

Hint: check out the EXCHANGE /NET command.

hth,
Hein.

[Bojan Nemec · Accepted solution]

Hi,

Because of the Carriage_Control none I supose that they need a flat file on the other side. With flat I mean no record terminators.

If it is so you must send the file in binary mode. If you send it as ASCII the FTP protocol adds record terminators.

If the other side needs record terminators, modify the FDL so that produces a stream (if the other side is Windows) or stream_LF (if the other side is *NIX) file. Send this file binary.

Bojan

[labadie_1]

if you want to exchange your file without any problem, until you have solved your Ftp problem, and if the remote node is a Vms one, just do
$ backup my_file file.bck/sav
$ ftp
bin
open remote
user
pass
put file.bck.

Then on the remote node, use the tool
http://h71000.www7.hp.com/freeware/freeware50/000tools/
named reset_backup_saveset_file_attributes.com

to put again correct file attributes, and then get your file
$ backup file.bck/sav *.*/lo

[Antoniov.]

Adding another info to Labdie'hints you can compress data using zip/unzip.
$ backup my_file file.bck/sav
$ zip "-V" file file.bck
$ ftp
bin
open remote
user
pass
put file.zip

Then on the remote node,
unzip file

Antonio Vigliotti

[Willem Grooters]

Besides record attributes (of which carriage-control is one) have a look to record format.
There might be a problem there.

To find out where the problem is, find out what are the differences between VAX and Alpha. Check the files that are inputted to FTP (DIR/FULL at least, eventually ANA/RMS, of the file to be sent) and if these are equal, the resulting file on the receiving side. (suggestion: zip the file on the target system, transfer it (binary) to VMS and unzip there. You could then compare the resulting file with the original one).

Willem

[juana perley]

Everyone was great on the question. Putting in bin after the ftp logon worked. I had considered bin, but when I read what in the help section of TCPIP, ASCII seemed to be what we wanted.

Again, thanks to all who answered.