×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
This is a big thank you to David Gibbs for providing this excellent
forum, and to Scott Klement for explaining (back on 03/14/2017!) the
problem I was having.
The issue was a tab-delimited file that happened to contain a BOM of
x'EF BB BF'. The first field was a numeric field, and CPYFRMIMPF was
getting a CPF2845 with reason code 7 "The FROMFILE numeric field ACCTNBR
contains blank characters, or other characters that are not valid for a
numeric field."
I found that IBM issued PTF SI79338 to correct CPYFRMIMPF's handling of
BOMs, and that my customer had this PTF applied.
Wikipedia informed me that x'EF BB EF' is for UTF-8, and that "This is
not literally a 'byte order' mark, since a code unit in these encodings
is one byte and therefore cannot have bytes in a 'wrong' order.
Nevertheless, the BOM can be used to indicate the encoding of the text
that follows it."
Then I googled midrange.com and found Scott's explanation at
https://archive.midrange.com/midrange-l/201703/msg00449.html. ; I checked
the file, and it had CCSID 1252. After I changed it to CCSID 1208, all
was well.
An interesting side note is that when the file was CCSID 1252, looking
at its contents with WRKLNK option 2 or 5 I could see the BOM bytes.
After changing the CCSID to 1208, options 2 & 5 no longer showed the BOM
unless I used F10 to display hex.
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx /
As an Amazon Associate we earn from qualifying purchases.