true, but THIS list is sometimes the manual that people use :)....and on a side note, those (RTFM) are the command line parameters I use when doing a remote shutdown command on a windows box....din't used to use them in that order, but one day noticed that they spelled it if re-arranged...so now I don't forget which parameters I like to use :D
On Tue, Jul 23, 2013 at 10:59 AM, Jason Miller <jason.mil...@gmail.com>wrote: > ** Yup, we are not talking about a crash in this case so I didn't mention > it. The documentation does mention it though so I figured one could RTFM > :) > > On Tue, Jul 23, 2013 at 9:48 AM, Longwing, Lj <llongw...@usgs.gov> wrote: > >> ** >> Jason, >> Just a 'warning' for you regarding the Buffer Log setting. This is great >> when dealing with 'general' output, but when trying to capture crash data, >> the value should be turned off because it's possible that the thread that's >> crashing might not output its final data to log because of buffer....so I >> agree having it on 'in general' is a good idea...but depending on the WHY >> of it being on...Buffer may not be the right setting. >> >> >> On Tue, Jul 23, 2013 at 10:30 AM, Jason Miller <jason.mil...@gmail.com>wrote: >> >>> ** We haven't noticed any issues. We also haven't done any true >>> benchmarks but all seems well. You'll probably want to make sure you have >>> Buffer Logged Lines checked. See "Buffering log output" >>> https://docs.bmc.com/docs/display/public/ars81/Server+logging+modes >>> >>> I resisted for the longest time in fear of performance issues as well as >>> security. All your data is now being written the app server's disk as well >>> as the db. I finally broke down and figured the app server is sacred space >>> and if you can't trust the people who have access to the server then you >>> have bigger issues. Sure there is something to be said about increasing >>> your data's surface area but one must weigh the benefit vs.risk for their >>> environment. >>> >>> Regarding logs parsing I think you'll only get teasers about the WWRUG13 >>> sessions for now. There is something about why buy the cow if the milk is >>> free? This is has always been a quandary; there is a need to have people >>> pay to put on the conference but there are those who will never be able >>> make that happen. Should they suffer just because their funding is tight? >>> Liking open source things I don't necessarily think so but I guess that is >>> also why the conference is considered an investment in your Remedy >>> shop?.?.?. >>> >>> Jason >>> >>> >>> On Tue, Jul 23, 2013 at 7:14 AM, Pargeter, Christie :CO IS < >>> cparg...@lhs.org> wrote: >>> >>>> ** >>>> >>>> Do you see a performance hit for having the logging turned on? Also, >>>> is there another site with more info about the Log Parsing & Management >>>> session. I can’t get funding for WWRUG.**** >>>> >>>> ** ** >>>> >>>> *From:* Action Request System discussion list(ARSList) [mailto: >>>> arslist@ARSLIST.ORG] *On Behalf Of *Jason Miller >>>> *Sent:* Monday, July 22, 2013 4:37 PM >>>> >>>> *To:* arslist@ARSLIST.ORG >>>> *Subject:* Re: Attachments Vanishing**** >>>> >>>> ** ** >>>> >>>> ** Do you have server side logging turned on? If you have >>>> Filter/SQL/Escalation logging turned on you should be able to search for >>>> the INSERT/DELETE to the B table and see who did it and if you are really >>>> lucky the workflow that did it. One you know who and when you can >>>> hopefully identify a user procedure that is being done (or not done) or >>>> system oddity that is doing it.**** >>>> >>>> ** ** >>>> >>>> In the last 8 months or so I have become a fan of leaving server side >>>> logging on full time. I have been able to track down so many odd things by >>>> logging API/SQL/Filter/Escalations to one ~2 GB log file.**** >>>> >>>> ** ** >>>> >>>> PLUG: I have seen a preview of the tools that will be demonstrated in >>>> the "Log Parsing and Management" session at WWRUG13 ( >>>> http://wwrug13.com/breakouts.html) and these are amazing for making >>>> that 2 GB log file something manageable and useful in a hurry.**** >>>> >>>> ** ** >>>> >>>> Jason**** >>>> >>>> ** ** >>>> >>>> On Mon, Jul 22, 2013 at 1:17 PM, Pargeter, Christie :CO IS < >>>> cparg...@lhs.org> wrote:**** >>>> >>>> ** **** >>>> >>>> This has nothing to do with Tasks. This is all around the attachments >>>> on the parent Change’s Work Info tab. Our Help Desk is building these >>>> Changes with a template then go in and add a Work Info with an attachment >>>> (Summary is just “notes & CRQ” then attach the document). Then they select >>>> Next Stage & Save to the db (all of this is at the Mode = Create). **** >>>> >>>> **** >>>> >>>> Then we hear that the attachment either never arrives to the other team >>>> or it “vanishes” after a “couple of days”.**** >>>> >>>> **** >>>> >>>> *From:* Action Request System discussion list(ARSList) [mailto: >>>> arslist@ARSLIST.ORG] *On Behalf Of *Pargeter, Christie :CO IS >>>> *Sent:* Monday, July 22, 2013 11:16 AM**** >>>> >>>> >>>> *To:* arslist@ARSLIST.ORG >>>> *Subject:* Attachments Vanishing**** >>>> >>>> **** >>>> >>>> ** **** >>>> >>>> Has anyone had this with 7.6.4? We are getting reports of a ton of >>>> Change tasks “vanishing” from the system. I asked my DBA to turn on >>>> logging for the B tables but I am not seeing anything. We are using the >>>> Classic view of ITSM 7.6.4.**** >>>> >>>> **** >>>> >>>> Thanks**** >>>> >>>> **** >>>> >>>> ARS 7.6.4 SP 4**** >>>> >>>> ITSM 7.6.4 SP 4**** >>>> >>>> RKM 7.6.4 SP 4**** >>>> >>>> SLM 7.6.4 SP 1**** >>>> >>>> Window 2008 – 64 Bit**** >>>> >>>> MS SQ 2005**** >>>> >>>> IIS/Tomcat**** >>>> >>>> MidTier 7.6.4 SP 4**** >>>> >>>> **** >>>> >>>> _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_ >>>> >>> >>> _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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
