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

Bob,

Some thoughts:

1. The VAX is an ASCII system. Was the data on the tape in ASCII? If it
had packed fields my guess would be that the application on the VAX was
Cobol and it was using normal Cobol Comp-3 type packing, which can be
usually be processed on the AS/400.

2. After copying from the tape to the AS/400 was the data in ASCII or
EBCDIC? 

3. If you are on V3R2, V3R7, V4R1 or later you have FTP on your AS/400.
It just needs to be configured. 

4. You are absolutely right that FTP does not handle any kind of numeric
packing/unpacking. In binary mode it transfers the file image from one
system to another. In ASCII mode with the AS/400 the AS/400 will perform
ASCII to EBCDIC translation (mangling any packed numerics).

5. Is it possible to get the VAX system to unpack the numerics before
sending the data? If so, you can transfer via FTP (or shared folder) and
have the data translated to EBCDIC on the transfer or copy.

Hth,
Patrick

Bob Clarke 3rd x4502 wrote:
> 
> 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
> 
> 
>   ------------------------------------------------------------------------
>                   Name: WINMAIL.DAT
>    WINMAIL.DAT    Type: Text Document 
>(application/x-unknown-content-type-txtfile)
>               Encoding: BASE64

-- 
IBM AS/400 communications, FTP automation, and network security
software and consulting services.

http://www.patownsend.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---