|
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?). >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? >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. >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? >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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.