Files created by an AS400

[Brian K. White]

On 11/22/2010 6:32 PM, Nancy Palmquist wrote:
> Fellow filePro programmers,
>
> I am trying to troubleshoot a problem where a file is  created by an
> AS400 computer (I have no idea about OS or anything.) as a print image.
> Then it is supposed be moved to a Windows machine and read by filePro as
> ASCII.  I have  a program that may do some translation first before it
> is full ASCII, but that program is waiting for an upgrade to 64 bit.  It
> does run in XP Mode, however so that is where we are testing.
>
> Windows side computer went bad and it was replaced with Win7 64 bit.
> AS400 computer was upgraded to 64 bit (got no idea what that might have
> changed.) The software on the AS400 generates a print image file that is
> then moved somehow to the Windows computer.
>
> But I can not longer read the file.  It looks like garbage when it gets
> to me.
>
> Does anyone have some experience with an AS400 and could they give me a
> bit of coaching as to what I might need to ask about to see where the
> issue might be?
>
> I am thinking: 1) file they are now creating is wrong, 2) transport
> mechanism to Windows is changing the file somehow.
>
> I do not know the transport mechanism - if that could be it.
>
> They email the file to me to test, so that could be doing the damage but
> I think it is wrong before that.
>
> I appreciate any suggestions.
>
> Nancy

I would say you just plain need to know all that stuff you don't know 
right now.

Email from a user of unknown clue level? You don't know where or how 
they got the file or how it was handled? Useless!

Some thoughts, any or all of these could be happening in any order, any 
number of times, thouroughly stirring the data up by the time you see 
it. Each of these is a simple conversion and easy to undo, but once an 
unknown number of these might be happening in an unknown order and 
unknown number of times, the resulting data has been stirred too much to 
be able to tell what happened to it just by looking. In that case that's 
it, all bets are off and it's just a waste of everyones time to even 
touch it without going back and nailing down the generation & transport 
path completely.

Newer OS's tend to operate by default in Unicode rather than plain 
ascii. Maybe the new as400 server is creating utf text files even though 
the old one created ascii or ebcdic.

as400 might be generating ebcdic instead of ascii.

New as400 might be different endianness than the old one (unlikely).

The software on the new server being a new install, may be missing some 
oddball little scripts and tweaks the old server had for massaging this 
file before it goes out.

Lastly the unknown handling by various people before you get to see it 
just makes it impractical to even start.

If you look at the file directly in a text editor, and you think you can 
see what it is or how it has been munged, like you can see that it's 
byte-swapped or that there are linefeeds instead of CR/LF's or that some 
characters have been URL encoded by someones email client, or that it 
was once a base64 encoded attachment but the mime formatting has been 
broken by being forwarded from one email to another, etc etc etc, then 
lucky you you can do something about it. But if it really just looks 
like garbage, and all those generation and handling questions are 
unknown, then that's all there is to it. It's not your fault they handed 
you garbage and can't even say where or how they got it.

Maybe you can request the as400 people to armor the text files while 
still on the as400 that created them, by gzipping them so that they are 
handled like binaries by every other transport stage without requiring 
the users involved to know anything.

Then when you unzip it, at least then even if it still looks like 
garbage, as long as 7zip/winrar/winzip unzipped it at all, at least then 
you know that the contents are exactly as they were on the as400, and 
that allows you to try a few likely conversions without wasting your 
time. There are only so many likely possibilities in that case.

If it's not sensitive data I'll take a look if you want and see if I can 
tell what it is, but really, you will need to nail down the entire 
transport path anyways because even if you figure out how to unscramble 
this manual email, that probably doesn't mean much because it's probably 
not the same as the files will be from the normal automated procedure 
that no people have manually handled.

-- 
bkw