For those times you are Tomb Raiding I would like to plug LJ's parsing tools: http://remedylegacy.com/tools. I cannot believe how much these have change my troubleshooting life. The combination of these tools and leaving server API/SQL/Filter/ESC logging on full time to a single file has resulted in finding the root of complex issue again and again. I can typically weed through gigabytes of logs and parse (and reparse) it down to just the interesting section in minutes.
Jason On Tue, Feb 17, 2015 at 5:30 AM, Warren R. Baltimore II < warrenbaltim...@gmail.com> wrote: > ** > That's the beauty of an inherited system! You get to play Tomb Raider > everytime you run into a problem. This one was just plain weird because I > NEVER would have thought to look for workflow. Like Doug said earlier, > this isn't supposed to be an issue at that level! > > Soon this thing is going to be retired.... > > ....I will not shed a tear! > > On Mon, Feb 16, 2015 at 4:41 PM, Joe D'Souza <jdso...@shyle.net> wrote: > >> ** >> >> Mine too. It brings out my “Sheldon-ism” when I see some developers leave >> a fully developed system with the default note, warning and error number >> which makes it that much more harder to trace the cause of these messages. >> >> >> >> I have an approach with those numbers that tells me 1) if it was a filter >> or active link, 2) which form it might be originating from (which is very >> useful if the error is from some other forms happening from a push or set >> field to or from some other form) and 3) identifies it right off the bat if >> it’s a note, warning or error (as some users have a difficult time >> reporting these messages accurately). >> >> >> >> Just that number should be able to convey information such as this and >> other information if possible. Sometimes it may need additional info such >> as what kind of a client it is coming from, etc. So depending on your need, >> it is a nice idea to design message numbers that tell you a brief story. >> >> >> >> My 2 cents. >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Rick Westbrock >> *Sent:* Monday, February 16, 2015 10:08 AM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> This is a great example of why I always create unique custom error >> messages and store them in a form so that I can easily reference them. One >> of my pet peeves is re-using message numbers (especially the default value) >> for multiple unrelated functions. >> >> >> >> -Rick >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Mueller, Doug >> *Sent:* Saturday, February 14, 2015 1:12 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> ** >> >> Warren, >> >> >> >> Just to confirm behavior. >> >> >> >> The AR System does not record anywhere in the DB where you are logged in >> from. So, there is no relationship here to USER_CACHE or anything else. >> There is an in memory list of connections. That in memory list is what >> holds where you are connected from and would complain if it was different >> systems. No amount of reloading or resetting or reviewing or anything of >> the user_cache table would have made any difference – and you found that >> out. >> >> >> >> IF the error was being caused by something within Remedy itself, >> restarting the system would have cleared this in memory list and corrected >> the problem. >> >> >> >> Nowhere in our logic do we have workflow that records where a user is >> logging in from. The logic you found is custom logic as you suspected. It >> looks like whoever implemented it coopted our error message and issued the >> same error as we would issue. >> >> >> >> I am glad that you found the custom logic causing the problem in this >> situation. >> >> >> >> Doug Mueller >> >> >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *Warren >> R. Baltimore II >> *Sent:* Friday, February 13, 2015 10:00 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> ** >> >> Well.... You guys all rock. But it turned out to be workflow related! >> >> I don't know if this is out of the box, but there are some active links >> that fire when a person first logs in to my system and checks if they >> logged in from some where else. My suspicion is that it is custom and >> related to the addition of a government warning that pops up when a user >> first logs in. This workflow checks a form to see if a person is still >> logged in. There is some workflow that is supposed to delete the form >> entry when you log out, but because of the initial dbase issues I was >> having, that didn't happen for these 2 users (supposition on my part). >> This is separate from whatever process Remedy installed to check the >> licensing requirements, but it gives the same error message when tripped! >> Once I deleted the 2 users entries from this form, they were able to log in >> without issue (without the admin privs). Problem solved. >> >> I've been here for 6 years almost, and this is the first time I've run >> into this! >> >> Thank you again for everyone's kind suggestions. I now know more about >> how Remedy cache's users then I ever thought possible! >> >> Take care! >> >> Warren >> >> >> >> On Fri, Feb 13, 2015 at 12:22 PM, Joe D'Souza <jdso...@shyle.net> wrote: >> >> ** >> >> Great point.. >> >> >> >> With a recent Windows update, my outlook client using pop/smtp to connect >> to my mail server, would not connect to the incoming mail server. >> >> >> >> Ptroblem turned out to be outlook no longer likes IPv6 to be enabled at >> the time of an initial connect. So I have to disable IPv6, have outlook >> connect to the incoming mail server, and then re-enable IPv6 after which it >> works fine. This happens everytime I restart my machine and seems to be a >> flaw with one of the updates. >> >> >> >> I know that is not the same issue as you, but could be a related issue? >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Grooms, Frederick W >> *Sent:* Friday, February 13, 2015 11:53 AM >> >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> Here is an off-hand thought … Does the machine the user is on have >> multiple network cards? Could it be some weird multi-home network issue >> (one transaction the sever see the connection from IP a.b.c.x and another >> from IP a.b.c.y)? >> >> >> >> Fred >> >> >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Warren R. Baltimore II >> *Sent:* Friday, February 13, 2015 10:47 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: USER_CACHE Problems >> >> >> >> ** >> >> Good morning/afternoon/evening/night my fellow listers! >> >> First off, I apologize for not responding sooner to everyone's kind offer >> of support. It was a bit chilly this morning here in Maryland, so my kids >> schools went to a 2 hour delay to prevent the little darlings from having >> to wear gloves and a hat (insert sarcastic eye roll here)! >> >> The issue is not spawned by a user still being logged on to a separate >> machine. In fact, I had them log out, go to another machine, and then come >> back and log back in. They got the message, and the user.log reflected the >> other machine. But even after they are logged out from that machine and >> they just focus on the one. It keeps happening. That's why I gave him the >> admin license just so he wouldn't keep receiving the message. >> >> I've just finished working with my 2 problem children. I've taken quite >> a bit of logging and I am hoping I can track down where Remedy tracks this >> info and fix it there. I'll let you know what I find. Might be kind of >> interesting! >> >> Take care for now! >> >> Happy Friday! >> >> Warren >> >> >> >> >> >> On Fri, Feb 13, 2015 at 8:32 AM, Misi Mladoniczky wrote: >> >> Hi, >> >> An admin can login from multiple machines, that is why the error >> disappears >> when changing to admin. >> >> Best Regards - Misi, RRR AB, http://rrr.se >> >> >> > If you gave the person admin permissions and the problem went away and >> then >> > came back after you removed it. Then the issue isn't the user_cache. >> The >> > issue is the permissions that the user has and the permissions required >> for >> > the screen you are trying to access. Everything is changing when >> > permissions are changed so the user_cache and that whole under lying >> system >> > is working fine. >> > >> > I am sorry I don't have better advice for you, but I would say find >> someone >> > who it is working for and making sure that this user has the same >> access. >> > Another thing to look into is the data for their permissions in the db. >> > You might see a bit of corruption in the group assignment. I have found >> > issues with manually pasting in values sometimes. I hope some of that >> > helps. >> > >> > Brian Goralczyk >> > >> > Brian Goralczyk >> > Phone 574-643-1144 >> > Email bgoralc...@gmail.com >> > >> > On Thu, Feb 12, 2015 at 1:04 PM, Grooms, Frederick W < >> > frederick.w.gro...@xo.com> wrote: >> > >> >> What error is the user getting? 9361 ? >> >> >> >> Also ... When updating a user I think the user cache only gets updated >> >> when one of the following changes (so your checkbox may not have >> updated it) >> >> Login Name, Password, License Type, Email Address, Default Notify >> >> mechanism >> >> >> >> >> >> You could change their license type to read, save, refresh, and change >> it >> >> back to see if that user's record in the user_cache is updated >> >> >> >> >> >> -----Original Message----- >> >> From: Action Request System discussion list(ARSList) [mailto: >> >> arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >> >> Sent: Thursday, February 12, 2015 11:56 AM >> >> To: arslist@ARSLIST.ORG >> >> Subject: Re: USER_CACHE Problems >> >> >> >> Hi, >> >> >> >> If you get ARERR 329, the user/password seems not to match. At least >> not to >> >> what is in the cache... >> >> >> >> You can use another program named arecache to add a new admin user >> that you >> >> can later use with arreload. >> >> >> >> Note that the -s option changed to/from -t at some point. I do not >> remember >> >> which version. >> >> >> >> Choose a Login Name and Request ID that does not exist. >> >> >> >> arcache -Ua -d -e 00001500 -n loginname -s server -g "1;" -l1 -p >> passwd >> >> >> >> If you are out of fixed licenses, you might need to delete a current >> Fixed >> >> user before you add the new one. >> >> >> >> arcache -Ud -d -e 0000000000000000x -s ServerName >> >> >> >> Finally try the arreload again. >> >> >> >> I also recall a bug with arreload together with the -d option. Try >> avoiding >> >> -d. I do not remember the exact version with this problem either... >> >> >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >> 2011) >> >> >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at >> WWRUG10/11/12/13): >> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >> logs. >> >> Find these products, and many free tools and utilities, at >> http://rrr.se. >> >> >> >> >> >> -----Original Message----- >> >> > I did bounce the Remedy system after the problem started. It didn't >> work >> >> > though.... I've been trying the following command: >> >> > >> >> > # ./arreload -a "[userid]" -p "[password]" -u "User" -s >> "[servername]" >> >> -f -d >> >> > >> >> > I get the following: >> >> > >> >> > Action Request System Reload Cache Manager Version 6.03.00 patch >> 016 >> >> > Remedy, a BMC Software company. >> >> > Copyright (c) 1991 - 2005 BMC Software, Inc. >> >> > All rights reserved. >> >> > Summary of command line arguments: >> >> > User form : User >> >> > Group form : >> >> > Admin user : [userid] >> >> > Update server: [servername] >> >> > Flush items from CURRENT server only >> >> > Verifying Admin access to 'source' server -- [servername] >> >> > FAILED! >> >> > Message not in catalog; Message number = 329 (ARERR 329) >> >> > [servername] >> >> > >> >> > >> >> > ARERR 329 : >> >> > >> >> > Invalid password or authentication string for an existing user >> >> > >> >> > The password you have specified for the user name is not recognized. >> The >> >> > problem can be >> >> > >> >> > either with the password or with the authentication string (if using >> NT >> >> > authentication, the >> >> > >> >> > authentication string is the NT domain) or both. Enter the password >> >> defined >> >> > for this user >> >> > >> >> > name to access the system as that user. >> >> > >> >> > I've used both Demo with a Fixed license and Admin privs. as well as >> my >> >> own >> >> > user id that also has admin privs. Am I missing something? >> >> > >> >> > >> >> > >> >> >-----Original Message----- >> >> > On Thu, Feb 12, 2015 at 9:26 AM, Grooms, Frederick W wrote: >> >> > >> >> >> The logged in status for a user is only in memory (not stored in the >> >> >> database) so have you restarted the AR System? >> >> >> >> >> >> When using the arreload utility make sure to turn off the max >> number of >> >> >> records returned limit (if you have one set on the server) before >> >> running >> >> >> or you will only get that number of users loaded into the user_cache >> >> >> >> >> >> Fred >> >> >> >> >> >> -----Original Message----- >> >> >> From: Action Request System discussion list(ARSList) [mailto: >> >> >> arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >> >> >> Sent: Thursday, February 12, 2015 7:58 AM >> >> >> To: arslist@ARSLIST.ORG >> >> >> Subject: Re: USER_CACHE Problems >> >> >> >> >> >> Hi, >> >> >> >> >> >> Have you tried the arreload-program? >> >> >> arreload -u User -f -a adminuser -p adminpassword >> >> >> >> >> >> The -f is supposed to flush the cache before reloading it. >> >> >> >> >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >> >> 2011) >> >> >> >> >> >> -----Original Message----- >> >> >> From: Action Request System discussion list(ARSList) [mailto: >> >> >> arslist@ARSLIST.ORG] On Behalf Of Warren R. Baltimore II >> >> >> Sent: Thursday, February 12, 2015 8:06 AM >> >> >> To: arslist@ARSLIST.ORG >> >> >> Subject: Re: USER_CACHE Problems >> >> >> >> >> >> ** >> >> >> Gave it a shot....no joy in mudville I'm afraid.... Thanks for the >> idea >> >> >> though! >> >> >> >> >> >> -----Original Message----- >> >> >> On Thu, Feb 12, 2015 at 8:37 AM, Karthik wrote: >> >> >> ** >> >> >> Deleting and recreating their user record works? >> >> >> >> >> >> - Karthik >> >> >> >> >> >> -----Original Message----- >> >> >> On 12 February 2015 at 18:29, Warren R. Baltimore II wrote: >> >> >> ** >> >> >> ARS 6.3 >> >> >> Oracle 10x >> >> >> Sun OS 5.1 >> >> >> >> >> >> A little help please! >> >> >> >> >> >> My legacy server is showing an issue that I have not dealt with >> before. >> >> >> >> >> >> A couple of days, my database started showing some problems related >> to >> >> >> tablespace. This caused a bunch of weird issues. The tablespace >> issue >> >> has >> >> >> been resolved. A couple of my users had closed their clients during >> >> that >> >> >> time and when they came back received the error message that they >> were >> >> >> still logged on and would they like the other session closed. They >> >> would >> >> >> answer in the affirmative, but when they would then log back on, >> they >> >> would >> >> >> get the same message. I then tried to kick them off from the admin >> >> tool, >> >> >> but they would still get the message. >> >> >> >> >> >> I then triggered (I think) a re-cache by adding a display only >> checkbox >> >> >> and then doing a modify all against all users with that checkbox >> >> checked. >> >> >> I did this based on kbase articles that talked about this type of >> issue. >> >> >> However I still have a couple of users who are getting this message. >> >> >> >> >> >> User logs don't show a need for them to be released, in fact they >> just >> >> >> show them logging in as normal. >> >> >> >> >> >> They are able to work by just closing (using the x to close the >> window). >> >> >> None the less, it is very annoying! >> >> >> >> >> >> Any ideas? >> >> >> >> >> >> Thanks! >> >> >> >> >> >> -- >> >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367 >> >> >> >> >> >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: >> "Where the Answers Are" and have been for 20 years_ >> >> >> >> >> -- >> >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367 >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: >> "Where the Answers Are" and have been for 20 years_ > > > > > -- > Warren R. Baltimore II > Remedy Developer > 410-533-5367 > _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"
