Mark Phippard wrote:
> Long term solution, I think, will be to remove the variant characters
> from column names in the tables we might need to access via JDBC.

The last time I had this problem, I referenced the allowed characters for 
file names in the ISO 9660 standard.

This is not the one we usually use to cut CDs on Windows, but a more 
generic, limited, one-size-fits-all standard.

It's limited to upper case US characters, numbers, and the underscore. 
Even though it was defined for an ASCII world, I think it is reasonably 
safe for EBCDIC.

I *think* you'll find that these are the same on all EBCDIC code pages, 
but I haven't verfied this personally (the underscore being the one I 
would have to check -- the rest I think are just fine).

Anyway, if I had to do this again, that would be my departure point. 

I would avoid  # (pound sign)  @ (at sign) and $ (US dollar sign) since 
(as I recall) their US  numeric assignments in code page 37 are 
specifically designed and expected to be some other glyph (some other 
unicode encoding, to be precise) in the other code pages in the world 
(hence their designation as "national" characters).  As I recall,  the # 
(pound sign) is the "AE" ligature in German, for instance.

By the same token, I would also avoid other probable "national" characters 
such as the British Pound character.

The number of characters with constant assignments are pretty small 
because there are, after all, only 256 of them per code page and it's a 
big world.

Again, it would take a bit of work to be sure even of this, but that's a 
head start on the answer I would use, anyway.


Larry Loen, Senior Programmer, iSeries i5/OS 

(Speaking for myself, of course)

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2021 by 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.