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 < ben.cher...@softwaretoolhouse.com> 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:arslist-boun...@arslist.org] *On Behalf Of *LJ > LongWing > *Sent:* January-31-18 8:08 AM > *To:* ARSList <arslist@arslist.org> > *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 <Ben.Chernys@ > 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 > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
