RE: CPF2973 - CPYFRMIMPF

["Shannon ODonnell" <sodonnell@xxxxxxxxxxxxxxxxxxxxxxxxx>]

FYI... there is nothing but common letters (i.e., p, r, t, s, etc..) in one
record that is not in another record. No extraneous double quotes, single
quotes, @ or # symbols or anything out of the ordinary.  

Obviously something is different about one record over another, but whatever
it is, it is not visible to the naked eye. I have even looked at the hex
values of each character in each record, thinking that perhaps something is
just not being displayed in the 5250 character set that might appear if I
view its hex value. Nodda.


I'm going to try applying the PTFs I have found, even though they do not
address this specific problem, and see if that makes a difference.

Thanks for all the suggestions.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Shannon ODonnell
Sent: Wednesday, August 09, 2006 5:39 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: CPF2973 - CPYFRMIMPF

I do not see anything in one record that is not in the other. I'm going to
do a quick compare to list what characters are in one record that are not in
the others.  It's the only thing I can think of left to check.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Douglas Handy
Sent: Wednesday, August 09, 2006 5:22 PM
To: Midrange Systems Technical Discussion
Subject: Re: CPF2973 - CPYFRMIMPF

Shannon,

I wrote a program to do a character count on commas (the delimiter for this
> file) for one of the failing records and a couple that did not fail and
> there were the same number of commas.  But that was a good thought.


It wasn't just the comma in the description.  If any of the data itself
include double quote characters such as Paul's example of 15", that can also
wreck havoc with comma delimited files.

Doug