[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

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  



We currently have a system Red Hat Enterprise Linux Server release 7.2 (Maipo) (Linux 3.10.0-327.36.1.el7.x86_64)



I have not seen your error




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
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 - 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).



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!



Ben Chernys
Senior Software Architect


Canada / Deutschland
Mobile:    +49 171 380 2329   GMT - 7 + [ DST ]

Mobile     +1 403  554 0887
Web:         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!






_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_