On 12/29/2011 10:17 AM, Scott Ford wrote:
I have seen this on a SYSOUT created with a Cobol program....
Moving spaces to a print line can cause nulls for sure...
Huh? How?
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
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
