Hi All,
I have heard back from the customer. The work-around does indeed work around the problem. It seems the bug is related only to building the short description string for an ARGetListEntry response. The server comes back to the client and the client responds that it can't decode the result (ARERR 992) if and only if the any of the result's descriptions have umlauts. Meta-Update uses that string in its messaging: Qry 1 of x: default short description (get fields) from the record. Simple solution for those using the API is to override the default short description generation with a single field known to not contain any special characters such as umlauts (such as '1'). This bug seems to have been introduced in 9.1 or at least this customer did not experience it before the upgrade to 9.1.0 - from which version I know not - but running on HP-UX. :) I haven't tested in on my servers (9.1.02, 8.1, .) to see when it was introduced and the fact that I run UTF-8 may affect the test. Cheers Ben www.softwaretoolhouse.com <http://www.softwaretoolhouse.com> From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] Sent: May-25-17 9:10 AM To: 'arslist@ARSLIST.ORG' <arslist@ARSLIST.ORG> Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using UTF-8 on their DB on anything > 7.6.04? Hi Fred, Thanks for your reply. I have no access at all to the client Windows machine or the Linux server - not even WebEx. As for the DB, I expect the BMC software is not lying when it reports its character set. The info below is from the values of the server info stuff which Meta-Update makes available to you on startup. The ./arsys reports LANG, LC_ALL with en_US.UTF-8 I did check on my server and was surprised that the machine, the Remedy user, etc seems to be on utf8 and the DB on utf16 - and a different locale as well. I suppose it would be easy enough to look at ITSM's normal forms and stick an umlaut in one of their query results fields. Your email has spurred that idea, so I thank you for that. I am still waiting the results of the enhancement (step 1) and patch (if matching the locale and charset fails) I gave the client. The patch will circumvent the whole problem as the query will only return field 1 as its short description. I am unclear what strings to set on the client for locale and charset to match. In particular relating to the "iso" prefix: de_DE.iso-8859-15 or de_DE.8859-15 Thanks again Fred. I know I can count on you when it comes to Linux and Oracle. Is Axton still around? My 8.1.02, 9.1.02 servers are running that, though my 7.6.04 is running Windows (on XP64 I believe!) MS SQL server. I upgraded a copy of 8.1 to make my 9.1.02 but I think I need to build one from scratch in both Linux and Windows. Thanks again, Ben From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: May-24-17 8:52 PM To: arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG> Subject: Re: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using UTF-8 on their DB on anything > 7.6.04? ** >From the bin directory, what do you get if you run > ./arsystem env | sort Look at the values of CLIENT_LOCALE en_us.8859-1 LANG C LC_ALL C What is the database character set you see when you run the following SELECT * FROM NLS_DATABASE_PARAMETERS ; We currently have a 9.1.02.003 system Red Hat Enterprise Linux Server release 7.2 (Maipo) (Linux 3.10.0-327.36.1.el7.x86_64) Using NLS_CHARACTERSET US7ASCII I have not seen your error Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys Sent: Wednesday, May 24, 2017 7:05 PM To: arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG> Subject: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using UTF-8 on their DB on anything > 7.6.04? ** Hi Folks, I have a customer using what I think of as a first. An Oracle DB with charset DB_CHAR_SET := (11) iso-8859-15 This is against ARS 9.1.00 201610281101 running on Linux 2.6.32-573.3.1.el6.x86_64 against Oracle 12.1.0.2.0 - 64bit Production. I issue a Query and the response includes the default Form based list of query fields. There apparently is no way to request none. You can override the default which is the obvious work-around and will be tested shortly. Presumably, you may say the client is using the same character set and get around the issue being thrown by the translation dlls. In this case the form's query fields includes those with umlauts. When such a record (containing an umlaut in a form specified query field) is queried, the ARERR 91 occurs. When said query returns records with no umlauts in the generated "short description", there is no error. The client (Meta-Update) is running under Windows and is compiled with 9.1 libraries. An 8.1 library version also suffered the same problem. The Linux version has not yet been tested. I would tend to think it is a client api responsibility - given the plethora of modified character translate open source dlls - but the fact that both the 8.1.2 and 9.1 compiles behave the same way (with changes in these supplied dlls) - makes me want to think of the server. I guess after spending some hours, I am quite curious. I believe I have an enhancement that may work (to define the character set as above in the ARControl block) and one that most likely will work (to request an override to the form's configured fields). So, 1. Anyone ever experienced this? We have not tried the Windows driver at this point. 2. Does anyone NOT use UTF-8 on their DB with anything above 7.6.04? 3. Any comments? Thanks a bunch in advance for your efforts! Cheers, Ben Chernys Senior Software Architect Canada / Deutschland Mobile: +49 171 380 2329 GMT - 7 + [ DST ] Mobile +1 403 554 0887 Email: Ben.Chernys_AT_softwaretoolhouse.com <mailto:Ben.Chernys_AT_softwaretoolhouse.com> Web: <http://www.softwaretoolhouse.com/> www.softwaretoolhouse.com We are a BMC Technology Alliance Partner Check out Software Tool House's free Diary Editor and our Freebies Section for ITSM Forms and Fields spreadsheet. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. Meta-Archive does ITSM Archiving your way: with your forms and your multi-tenant rules, treating each root request as a complete tree and checking associatuions. Archive output to different servers, HTML pages with links to attachments or archive forms. Pre ITSM 9.1.02? Clarify? Roll your own? No problem! You can keep your valuable data! <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
