× 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.



Booth,

How are these files getting to your system?

This sort of thing is always a problem with file transfer. Other systems have no notion whatsoever of CCSIDs, that's really an IBM thing you don't see anywhere else. When you transfer a file, the CCSID attribute is not transferred with it (unless you package it up in a save file, of course.)

So you are blaming the customer for what is, in my opinion, not the customer's fault. Most likely, the system is just picking a DEFAULT based on it's own system of rules for assigning them, and has no idea what the actual CCSID of the data is. It's up to you to go back and set it appropriately.

-SK


On 5/26/2016 1:15 PM, Booth Martin wrote:
The problem is that one customer out of many is sending files and some, but not all of those files, are not what they say they. WRKLNK suggests that the data is EBCDIC but the properties of the file say it is 0819. btw, it is WRKLNK that suggested the 00500 code page. I had already tried a half dozen other code pages, including 37. When I copy the file specifying an 819 code page the new file appears to be fixed.

Arguing with the customer apparently didn't solve the problem. We have no control over the incoming files; they are what they are.

The immediate problem seems to be to identify a file that is bad before it sneaks into the workflow and gums up the works. So my thought was to run some sort of process that would tell me what WRKLNK thinks the code page is, and compare that to the CCSID attribute. If different, shunt the file to a "problems" folder and then deal with it there.



On 5/26/2016 5:46 AM, Scott Klement wrote:
Booth,

... So why are you attempting to use (and failing)
819?? Or much, much worse, using 500 (a flavor of EBCDIC that is
probably not even correct, since we don't typically use 500 in the USA,
and I assume you are still based in the USA?)

So why are you doing things this way?

...

But if you write EBCDIC data (most likely CCSID 37) but tell the system
it's 819, and then have the system choose to interpret it as 500, you'll
almost certainly have a big mess.

-SK


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.