I have seen this on a SYSOUT created with a Cobol program....Moving spaces to a print line can cause nulls for sure... How is the file transferred ? Binary will not change anything, but if they transfer it with CR/LF and ebcdic to ascii enabled ... Could be interesting Scott J Ford Software Engineer http://www.identityforge.com
________________________________ From: Joel C. Ewing <[email protected]> To: [email protected] Sent: Thursday, December 29, 2011 12:10 PM Subject: Re: removing nulls from a file On 12/29/2011 09:19 AM, Brad Wissink wrote: > We have a client that is trying to transfer us a file and it is loaded with > nulls. They say that is the way it comes from the purchased software they > have on their workstation. The file has a null character inserted after > every character so it looks like this > > 1 12/29/2011 becomes > F1004000F100F2006100F200F9006100F200F000F100F100....... > > Has anyone seen anything like this before? Is there a quick and easy way to > remove all the nulls? > It's almost as if they are using software that somehow mistakenly thinks EBCDIC is a two-byte character encoding, or the process for conversion to EBCDIC was written by a neophyte programmer who treated each character as a null-terminated string and some how managed to include the null termination for each character when outputting the converted data. Maybe they have their software package mis-configured in some way, or since they are talking about workstation software producing the data, the software package generating the data may be ignorant of EBCDIC and the fault may be in what technique they are using after-the-fact to either convert the data to EBCDIC or transmit the data with conversion. If at all possible, try to get clarification of exactly what software and options they are using to produce the data and exactly what technique and options they are using to transmit the data. If possible, get them to transmit via other methods (Email, FTP, etc.) samples of any intermediate files as binary data so you can see exactly what data format they are really dealing with on their workstation (as opposed to what the client may think he has). If they are really transmitting twice the number of needed bytes, fixing the problem at their end would be the better solution. Perhaps given enough background on what they are doing, a solution would become obvious, or you would be able to search on-line for a solution if the client lacks the technical expertise to do so on their own. If everything is kosher on their end and the byte doubling is somehow occurring just on your receiving system, then hopefully you will have enough to be able to recreate and fix the problem on your end. Just cleaning up bad data after the fact will work, but is not as desirable as eliminating the creation of the bad data in the first place. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
