• Subject: Re: VAX FTP to AS/400 (via NT) with pack
  • From: Patrick Townsend <townsend@xxxxxxxxxxxxxx>
  • Date: Tue, 09 Mar 1999 16:46:52 -0800
  • Organization: Patrick Townsend & Associates, Inc.

Bob,

Interesting! More comments below:

Bob Clarke 3rd x4502 wrote:
> 
> Thanks for your feedback, Patrick.  Some comments/answers ...
> 
> >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.
> 
> Well, funny you should mention that.  I just spoke to the folks on the
> VAX end and they are 'taking
> another look' at the original (tape) process.  Now they seem to think
> that <maybe> they were converting
> the file to EBCDIC, which would explain why it worked fine via tape
> (wouldn't it?).
> 
     Well, the VAX does support an option to convert to EBCDIC 
     when copying to tape. But this would scramble any packed
     numeric data and make it useless. For example, a COMP-3 
     numeric field on the VAX might look like this in hex: 
    
        x'01234F'

     After translation to EBCDIC it is going to be some *very*
     different number. So I think there must be something going
     on at the VAX that is not very clear yet...


> >2. After copying from the tape to the AS/400 was the data in ASCII or
> >EBCDIC?
> 
> See #1 above - In thinking about this I presume it would have to have
> been EBCDIC
> if we were simply copying the tape file to disk and processing, right?
>  Cpyfrmtap does
> not assume ASCII source and translate, does it?
> 
         Right, CPYFRMTAP will not do character translation unless
         you use OVRTAPF command to specify that it is in ASCII:

           ovrtapf qtape code(*ascii)

         Or, if you are not using one of the IBM supplied tape
         files your tape file may already specify code = *ASCII.

> >3. If you are on V3R2, V3R7, V4R1 or later you have FTP on your AS/400.
> >It just needs to be configured.
> 
> Will be on V3R2 in about a week or two.  However the thinking around here
> is to
> keep the mission critical apps/data on the AS/400 as far from the general
> public
> as possible.
> 
        Right. But you'll have FTP at no cost if you want to use
        it.

> >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).
> 
> Mmm.  Sounds about right to me.  So now if I understand correctly, the
> packed
> data if transferred without translation can be read from one system to
> another.
> However the alphanumeric requires translation which, when done, mangles
> the
> packed fields.  Hence the reason I can read one or the other depending on
> the
> translation, but not both.  Do I understand that correctly?
> 
       Yup. The last time I did a VAX conversion to an IBM midrange
       processor (and, no, I am not going to tell you how long ago
       that was <g>) I transferred the file to the IBM system in 
       ASCII. Then I wrote an RPG program that ran through the file
       and converted just the character fields to EBCDIC leaving
       the numerics untouched. The file could then be processed 
       using normal RPG coding.

       Note that this technique only works for COMP3 or other
       Cobol type numeric packing. If the numeric fields are packed
       by a Basic application on the VAX it may not work. Basic
       longs and shorts are probably OK, but variants, etc., are
       probably not.


Good luck!
Patrick

> >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.
> 
> Well, yes.  However that would mean a separate front-end process for
> getting
> the data to it's ultimate destination, and thus maintain multiple
> processes going
> forward - something I'm not partial to.
> 
> Again, thanks for the feedback.  You've been quite helpful.
> 
>   ------------------------------------------------------------------------
>                   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
+---


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].