Where I work, we have an IBM Power System that we use for data storage and access. It is currently running i OS 6.1. We have a website on an IIS server that pulls data from this server and has several different web apps that do different functions. All of these have some sort of search function. There is an issue with case sensitivity on two of these sites.
Here's where it gets a bit hairy. This problem only started happening when we upgraded from v5r4 to v6r1 on the IBM system. Again though, it does not happen on all of the sites (there are 8 total, 2 have the issue). This is very strange, because all of them use the same IO procedures. The website was developed by another party, who is able to remotely test our database. They are running v7r1, and didn't have any issues when using the site with our database. The website accesses the data via ODBC, and I've tried reconfiguring the DSN. One of the support people even had me register their exact ODBC config with a .reg file, and still nothing. Both they and I have run out of ideas, so for now, we've resorted to a help link. I happened to be working on a different website that uses the same server for queries, and the ODBC connection in this site had the same behavior...names and any other search fields seem to all be case sensitive. I know, since I got a sudden surprise of my site not working, that my site was NOT case sensitive before the v6r1 upgrade. We also use a 3rd party app to run SQL queries, and on the same DSN the queries in this application are NOT case sensitive. So as you can see, I can't find any correlation. Does anyone know of issues with IBM DSNs or case sensitivity with IBM servers/filesystems that could cause this for certain queries?
If the suspect is the ODBC driver, check the DSN. Select the Language tab, and then choose the sort type 'Sort based on language ID'. Then choose your language ID. The default setting is 'Sort based on *HEX values'.
If the suspect is the IBM i server, have the admin check the SRTSEQ property of the server jobs - QZDASOINIT, probably - to set it to *LANGIDSHR. The default is *HEX. Clearly, this will affect ALL ODBC access to the IBM server, not just your access. But if that's how it was before the upgrade, perhaps it would be best to put it back.
It might be more transparent if the queries handled the monocasing explicitly. So rather than ...WHERE CUSTNAME LIKE 'JONES%'... it would be ...WHERE UPPER(CUSTNAME) LIKE 'JONES%'...