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 < ben.cher...@softwaretoolhouse.com> wrote: > FYI > > > > BMC has raised this as a bug and is expecting to fix it around 9.5. > > > > Cheers > > Ben > > > > *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] > *Sent:* May-29-17 7:57 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? - "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 > > > > > > *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com > <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 <arslist@ARSLIST.ORG>] *On Behalf Of *Grooms, > Frederick W > *Sent:* May-24-17 8:52 PM > *To:* 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 <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 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 > [image: logoSthInc-sm] > > Canada / Deutschland > Mobile: +49 171 380 2329 <+49%20171%203802329> GMT - 7 + [ DST ] > > Mobile +1 403 554 0887 <(403)%20554-0887> > Email: Ben.Chernys_AT_softwaretoolhouse.com > 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! > > > 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 > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
