This <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzakb/ldata.htm">chart</a> documents the valid mappings across data types. O to A is not shown as a valid mapping (which I don't find too surprising as O is mixed SBCS and DBCS). The table does however show O to UTF8 as being valid. UTF8 is treated as character data so that might work in terms of tricking the case tool. I don't have the time to try it this morning though. I would suggest though that you examine alternative case tools given the response by the vendor. I can see someone saying they don't support DBCS -- in which case you're in an unsupported environment and you're just out of luck. But to treat O as numeric is clearly a bug, and to respond that they'll just let the bug continue to exist strikes me as being an indicator that the tool is no longer being maintained/invested in. A product, to my way of thinking, should recognize unsupported data characteristics and simply not process it. To default to a bogus data type (numeric) sounds like an ELSE or OTHERWISE leg being run without thinking it through... -------------- Choyle, I'm not sure if you are using Infinium which is converting to DBCS yes, but some of my customers are having issues where Infinium changed many text fields (names, addresses, etc) to Type O in the Reference files, causing problems when copying spool files (as with laser checks). During Printer files compilation, if the compiler sees any Open data type fields, it will compile the Printfile as DBCS-Yes and some laser software processes will detect and stop. Resolution: Override the DDS to "A" if the referenced field is Type O, and add the keyword:IGCALTTYP. Do a DSPF and insure that the file created DBCS Capable =No. This may apply to LFs as well, don't know. /George InfiniumPro@hotmail.com ------------------------------- George, I'm intrigued by your insight... Yes, we are talking about the recent Infinium upgrades. Our case tool recognized the changes to the PF object, and prompted us to go through a process to flow them into the programs... However, the result of that was that they now recognize the "O" fields as numeric. They have come back to me and are attempting to resolve the situation on their end. In the meantime, your resolution may be my best answer if it will work for LF's as well as DSPF's and PRTF's. Thanks! Chris -----------------------------

This <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzakb/ldata.htm">chart</a> documents the valid mappings across data types. O to A is not shown as a valid mapping (which I don't find too surprising as O is mixed SBCS and DBCS). The table does however show O to UTF8 as being valid. UTF8 is treated as character data so that might work in terms of tricking the case tool. I don't have the time to try it this morning though. I would suggest though that you examine alternative case tools given the response by the vendor. I can see someone saying they don't support DBCS -- in which case you're in an unsupported environment and you're just out of luck. But to treat O as numeric is clearly a bug, and to respond that they'll just let the bug continue to exist strikes me as being an indicator that the tool is no longer being maintained/invested in. A product, to my way of thinking, should recognize unsupported data characteristics and simply not process it. To default to a bogus data type (numeric) sounds like an ELSE or OTHERWISE leg being run without thinking it through... -------------- Choyle, I'm not sure if you are using Infinium which is converting to DBCS yes, but some of my customers are having issues where Infinium changed many text fields (names, addresses, etc) to Type O in the Reference files, causing problems when copying spool files (as with laser checks). During Printer files compilation, if the compiler sees any Open data type fields, it will compile the Printfile as DBCS-Yes and some laser software processes will detect and stop. Resolution: Override the DDS to "A" if the referenced field is Type O, and add the keyword:IGCALTTYP. Do a DSPF and insure that the file created DBCS Capable =No. This may apply to LFs as well, don't know. /George InfiniumPro@hotmail.com ------------------------------- George, I'm intrigued by your insight... Yes, we are talking about the recent Infinium upgrades. Our case tool recognized the changes to the PF object, and prompted us to go through a process to flow them into the programs... However, the result of that was that they now recognize the "O" fields as numeric. They have come back to me and are attempting to resolve the situation on their end. In the meantime, your resolution may be my best answer if it will work for LF's as well as DSPF's and PRTF's. Thanks! Chris -----------------------------