Re: VAX FTP to AS/400 (via NT) with packed f

Since you get one or the other part corrupted when you change conversions then 
we can probably assume that the file is looking okay on your NT Server.
If you are in doubt then browse the file on your NT server with some utility.
CCSID seems to be pretty important.  Try doing a DSPFD on the file and seeing 
what the CCSID is.
When I transfer a file using Client Access there is an option (File, 
properties), where you tell it to translate CCSID 65535.  This one has bitten 
me several times.





clarke@teri.org on 03/09/99 01:07:40 PM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     midrange-l@midrange.com@Internet
cc:      

Subject:        VAX FTP to AS/400 (via NT) with packed f


I have a bit of a dilemma on my hands and am turning to 'the list' for   
help, as I so often do when I'm in a jam (and almost always results in   
the answer I was looking for!).

We have a servicer who presently provides us with a data file on tape   
which we have no problem processing directly on our AS/400.  The tape is   
created by a program running on a VAX machine, sent to us, copied from   
tape to file (cpyfrmtap), and processed via our Cobol/400 program.  One   
note ... this file contains packed fields.

In our effort to get away from tapes and human intervention, we have   
turned to FTP (naturally).  However we are having a bear of a time   
getting a file on the 400 that we can actually read!  The process goes   
like this ... servicer creates file on VAX, copies file via FTP to   
<their> NT based FTP server, then copy file via FTP to <our> NT based FTP   
server, from which we copy the file up to the 400 (no FTP on our 400 at   
this time - maybe someday).  We are basically trying 2 methods on our end   
to get the file up to the 400.  The first being to just copy the file to   
a folder and using CPYFRMPCD to copy to file.  The second method is to   
use NetSoft's File Transfer utility to copy directly from PC to AS/400   
file.  In either case, we can get to a point where we either have good   
alphanumeric data and garbage packed fields, or vice versa.  We have   
tried literally every conversion combination available with each method.   
 The provider of this file swears it is exactly the same as what we   
receive today on tape.  We have also had them try FTP with both ASCII and   
binary options.

My question is this ... Does anyone know if this is even a workable   
solution?  Is there something about packed fields that FTP cannot deal   
with?  Am I missing something obvious (I don't mind looking like an idiot   
if it means getting this resolved :-))?  I realize that one obvious   
solution would be to do away with the packed fields, however this is   
something of a 'legacy' application which works well with other servicers   
(whom use direct system to system transfers via SNA and BSC protocols via   
existing dedicated and dial-up lines).  So we don't want to put ourselves   
in a situation where we're maintaining multiple incoming file formats.

As always, any insight would be greatly appreciated!  Thanks in advance!

Regards,

Bob Clarke
   

WINMAIL.DAT