Tweet
I'd like to start off by saying that I'm not very familiar with how CCSIDs work. We do everything in English and I thought we stored everything in single byte until I starting seeing this problem.
Our system was installed with DBCS (system value QIGC = 1) so all our DDS files have a CCSID of 937. A google search result said this is because our job CCSID is 65535 and our system language is ENU (CCSID 37) and the DBCS equivalent of that is 937.
We have a file that stores an encoded username and password as double byte data. All of that works fine until we use MMAIL/EMLMSG to send an email. The MMAIL process changes the CCSID of the job if it is 65535 to the system default which is 37 based on the QLANGID system value (ENU). The email works fine but when the job tries to lookup data in the double byte table we get a data mapping error..
All this makes sense and I understand why the error is happening but I'm not sure what to make of it. I'm not sure why the system creates the file with CCSID 937 but returns 37 when getting the default CCSID for ENU (MMAIL uses QLGRTVDC API). I'm also not sure how to work around this. Obviously, I could change the job CCSID after calling MMAIL back to *SYSVAL or *USRPRF but that seems like a bad approach since MMAIL is used in a lot of places. I could also change the USRPRF CCSID to 937 instead of 65535 but I don't know what impact that would have this user is used to run all our system jobs.
One other strange this is this all used to work fine prior to use moving to a new server. I'm assuming this is because the encoded data uses the system's serial number as part of the encoding algorithm and the old encoded data didn't have issues with CCSID 37. The other possibility is that we had a default CCSID of something other than 65535 which caused MMAIL to not change the job CCSID to 37. I'm thinking it's the first option since we did a full system restore from the old system. I'm assuming that would also restore the system values but I'm not sure about that.
Any guidance is appreciated.
Thanks
Our system was installed with DBCS (system value QIGC = 1) so all our DDS files have a CCSID of 937. A google search result said this is because our job CCSID is 65535 and our system language is ENU (CCSID 37) and the DBCS equivalent of that is 937.
We have a file that stores an encoded username and password as double byte data. All of that works fine until we use MMAIL/EMLMSG to send an email. The MMAIL process changes the CCSID of the job if it is 65535 to the system default which is 37 based on the QLANGID system value (ENU). The email works fine but when the job tries to lookup data in the double byte table we get a data mapping error..
All this makes sense and I understand why the error is happening but I'm not sure what to make of it. I'm not sure why the system creates the file with CCSID 937 but returns 37 when getting the default CCSID for ENU (MMAIL uses QLGRTVDC API). I'm also not sure how to work around this. Obviously, I could change the job CCSID after calling MMAIL back to *SYSVAL or *USRPRF but that seems like a bad approach since MMAIL is used in a lot of places. I could also change the USRPRF CCSID to 937 instead of 65535 but I don't know what impact that would have this user is used to run all our system jobs.
One other strange this is this all used to work fine prior to use moving to a new server. I'm assuming this is because the encoded data uses the system's serial number as part of the encoding algorithm and the old encoded data didn't have issues with CCSID 37. The other possibility is that we had a default CCSID of something other than 65535 which caused MMAIL to not change the job CCSID to 37. I'm thinking it's the first option since we did a full system restore from the old system. I'm assuming that would also restore the system values but I'm not sure about that.
Any guidance is appreciated.
Thanks
Comment