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.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.