Ha. You may be right there. Software numbering is always an arcane endeavour. đ
/Ben From: ARSList [mailto:[email protected]] On Behalf Of LJ LongWing Sent: January-31-18 9:49 AM To: ARSList <[email protected]> Subject: Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5 my hesitance regarding '9.5' specifically is surrounding that 9.5 was the planned version of the next version of Remedy which included Innovation Suite....a bit over a year ago Innovation Suite was moved off into it's own product suite and is no longer planned to be part of Remedy....because of that I don't expect BMC to 'reuse' that version number at any point in the future...if they continue with the current numbering scheme, I expect them to skip 9.5 entirely and go with a 9.6 or 10.0 or something like that....but I personally don't think they will use 9.5....all of these statements are my own personal thoughts on the subject and not 'inside knowledge' of any sort :) On Wed, Jan 31, 2018 at 8:26 AM, Ben Chernys <[email protected] <mailto:[email protected]> > wrote: Hi LJ, I am getting this from my client â although I was involved in the support ticket. So, I didnât hear it from the horseâs mouth. I was told âaround 9.5â. It doesnât really matter when it is fixed. The OOTB ITSM apps generally do not have umlauts in the âQuery Fieldsâ defined for the forms. Meta-Update works around the problem by supplying its own QueryFields list. This bug is rare. I have two clients with this problem. One modified HPD:Help Deskâs Query Fields list to have fields whose values include umlauts. The other has their own app. In fact, it does make sense. I have heard statements like this from many many software companies and I myself have made statements like this. Remedy is a big piece of software and all fixes need to be tracked and scheduled. It just indicates that this is currently planned to be fixed in that release. Once it is assigned and investigated, times may change. Cheers Ben From: ARSList [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of LJ LongWing Sent: January-31-18 8:08 AM To: ARSList <[email protected] <mailto:[email protected]> > Subject: Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5 Ben, Your statement regarding being fixed around '9.5' doesn't make any sense to me....did whoever you talked to SAY 9.5 or did they say 'next release', or more likely 'future version'? On Wed, Jan 31, 2018 at 7:59 AM, Ben Chernys <[email protected] <mailto:[email protected]> > wrote: FYI BMC has raised this as a bug and is expecting to fix it around 9.5. Cheers Ben From: Ben Chernys [mailto:[email protected] <mailto:[email protected]> ] Sent: May-29-17 7:57 AM To: '[email protected] <mailto:[email protected]> ' <[email protected] <mailto:[email protected]> > 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? - "solved" workaround 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:[email protected]] Sent: May-25-17 9:10 AM To: '[email protected] <mailto:[email protected]> ' <[email protected] <mailto:[email protected]> > 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:[email protected]] On Behalf Of Grooms, Frederick W Sent: May-24-17 8:52 PM To: [email protected] <mailto:[email protected]> 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:[email protected]] On Behalf Of Ben Chernys Sent: Wednesday, May 24, 2017 7:05 PM To: [email protected] <mailto:[email protected]> 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 <tel:+49%20171%203802329> GMT - 7 + [ DST ] Mobile +1 403 <tel:(403)%20554-0887> 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_ -- ARSList mailing list [email protected] <mailto:[email protected]> https://mailman.rrr.se/cgi/listinfo/arslist -- ARSList mailing list [email protected] <mailto:[email protected]> https://mailman.rrr.se/cgi/listinfo/arslist
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
