Re: Help with ODBC driver with ARS client 7.1 and Win 7
Try to create your own ODBC, which would fix the direction hopefully. Thanks Regards, Mahendra Mahalkar On Thu, Jan 21, 2010 at 3:40 AM, jham36 jha...@gmail.com wrote: The compatibility matrix for 7.1 only mentions support for XP and Vista. You should try the 7.5 user tool. That is supported for Windows 7 and will work against a 7.1 server. James On Jan 20, 4:53 pm, David Levenseller davidlevensel...@mail.und.nodak.edu wrote: Hello, Is anyone out there running the ARS User Client 7.1.00 with Windows 7? I was able to get it installed ok but I can't seem the get the ODBC driver to work. I want to install Crystal Reports 10 so I can run reports again. I worked back when I had Vista. Any thoughts or suggestions? Thanks David Levenseller University of North Dakota Help Center Leader davidlevensel...@mail.und.nodak.edu Voice (701)777-2380 FAX (701)777-3978 ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.netsponsor%3armisoluti...@verizon.netARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.netsponsor%3armisoluti...@verizon.netARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
BMC Remedy Data Import bug!?
Hi, I ran BMC Remedy Data Import (7.5 patch 3) against a 7.0 server. It turned out to be a bad choice... I did an Update Old Record with New Record Data, as I have done hundreds of times with older AR Import Tools. I mapped two fields only, the Entry ID, and a field I wanted to set to NULL. The result was that most fields except the core fields was cleared out. I restored a backup and tried again with the old 7.0 AR Import Tool, and things behaved as expected. It kept everything except the NULLed field. I have double checked the settings I used in 7.5 patch 3, and it was correct. 1. Has anyone experienced anything similar? 2. Has anyone done this (Update Old Record...) against a 7.5 server with good results? Another thing. I tried setting ARAPILOGGING=1 before I started dataimporttool.exe from the commandline. I can not find any arapires.log or arapicmd.log on the entire server. Has this functionality gone away??? I wanted to see if the client sent any unwarranted NULL-transaction-values to the server. Best Regards - Misi, RRR AB, http://rrr.se Products from RRR Scandinavia: * 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Jack Hobbs is out of the office.
I will be out of the office starting 21/01/2010 and will not return until 22/01/2010. I will respond to your message when I return, alternatively please contact the IT servicedesk. Regards This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. This footer also confirms that this email message has been scanned for the presence of computer viruses. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Aggregate Industries. Aggregate Industries Limited, Registered in England Number 5655952. Registered Office: Bardon Hall, Copt Oak Road, Markfield, Leicestershire, LE67 9PJ. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: BMC Remedy Data Import bug!?
This is currently a bug in the Data Import tool. If you are updating records with the Make Non-Core Required Fields Optional set, then it also sets all the non-core required fields to NULL. I believe this has been fixed in the upcoming 7.5 patch 4 of the Import tool. Regards, Rahul Maheshwari DISCLAIMER: The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 3:52 PM To: arslist@ARSLIST.ORG Subject: BMC Remedy Data Import bug!? Hi, I ran BMC Remedy Data Import (7.5 patch 3) against a 7.0 server. It turned out to be a bad choice... I did an Update Old Record with New Record Data, as I have done hundreds of times with older AR Import Tools. I mapped two fields only, the Entry ID, and a field I wanted to set to NULL. The result was that most fields except the core fields was cleared out. I restored a backup and tried again with the old 7.0 AR Import Tool, and things behaved as expected. It kept everything except the NULLed field. I have double checked the settings I used in 7.5 patch 3, and it was correct. 1. Has anyone experienced anything similar? 2. Has anyone done this (Update Old Record...) against a 7.5 server with good results? Another thing. I tried setting ARAPILOGGING=1 before I started dataimporttool.exe from the commandline. I can not find any arapires.log or arapicmd.log on the entire server. Has this functionality gone away??? I wanted to see if the client sent any unwarranted NULL-transaction-values to the server. Best Regards - Misi, RRR AB, http://rrr.se Products from RRR Scandinavia: * 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Archive form.
Hello list, I have archived some data from helpdesk form. The archived form get created (as seen from aradmin tool). But I don't know how to view it from aruser tool as it is not coming in the form search list. Please let me know, how can I view data in my archived form. With Regards, Anuj Dua ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Archive form.
Hi Anuj, The reason you are not seeing the form is because the singular, plural values are not set in the admin tool, under view properties, under the Aliases and Labels tab. Set these values and relogin to the user tool. Best Regards, John Joseph Date: Thu, 21 Jan 2010 15:34:14 +0530 From: anuj@st.com Subject: Archive form. To: arslist@ARSLIST.ORG ** Hello list, I have archived some data from helpdesk form. The archived form get created (as seen from aradmin tool). But I don’t know how to view it from aruser tool as it is not coming in the form search list. Please let me know, how can I view data in my archived form. With Regards, Anuj Dua_Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _ New Windows 7: Find the right PC for you. Learn more. http://windows.microsoft.com/shop ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
7.1 MidTier on 64 Bit Windows
Can anybody tell me whether the following will work. The compatibility matrix leads me to think that it is supported: Windows 2003 64 Bit 32 Bit JVM (5.14) MidTier 7.1 p5 Everything appears to install without issue but I cannot get Remedy pages to load. Also, after MidTier install, I cannot get a simple test.html page to load (before MidTier install test.html worked). The one issue I see is that with IIS I cannot get the jakarta re director to load under the ISAPI Filters tab. It lets me add it but it never says its UP. Thank you Frank Caruso ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: 7.1 MidTier on 64 Bit Windows
Frank, In the advanced settings for the application pool I believe there is a setting to enable 32bit applications that may need to be set if it isn't already. HTH, Wes -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Frank Caruso Sent: Thursday, January 21, 2010 7:29 AM To: arslist@ARSLIST.ORG Subject: 7.1 MidTier on 64 Bit Windows ** Can anybody tell me whether the following will work. The compatibility matrix leads me to think that it is supported: Windows 2003 64 Bit 32 Bit JVM (5.14) MidTier 7.1 p5 Everything appears to install without issue but I cannot get Remedy pages to load. Also, after MidTier install, I cannot get a simple test.html page to load (before MidTier install test.html worked). The one issue I see is that with IIS I cannot get the jakarta re director to load under the ISAPI Filters tab. It lets me add it but it never says its UP. Thank you Frank Caruso _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Work Info History not Locked?
Hi all, Long time listener, first time poster. I've somehow become the accidental administrator of our Remedy system despite my warnings. We have recently come under scruntiny as all of our Work Info Entries are Unlocked by default and can be edited/modified at any point in time. Is there some way I can enforce the Locked status for a Work Info entry? Bonus points if I'm able to retro-actively set this field to locked for all historical records as well. Cheers! Scott. ARServer 7.0.01 patch 002 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Identification of table entry
Hi All, Is there a way to identify new entry in a table in a form? We could do it by keeping an optional field and getting colcount of a table and writing a filter whenever db and tr of field changes. But the optional field occupies some data in a form. Can this be done using a display only or any other way to identify this? Regards, Vani. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Allocating floating license to unregistered users
Dear List, I am pretty sure we had our system set up to allocate a floating license to a user who logged into the system without an entry in the User form. But now I am finding that such users are getting a read-only license. Am I mis-remembering, or is there a way to allow unregistered users to get floating licenses? I can't find it in the documentation, but perhaps I just haven't looked in the right place. Dwayne Martin James Madison University (ARS 7.1 p3, RH Linux server, Oracle 10.2 db) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
Martin, Unless I have missed something all these years, there is no way a user that does not have an entry in the User form can have any sort of a 'write' license be it Fixed or Floating. You cannot even grant that user a Read-Restricted license, and the only license that a user automatically gets is a Read license if he/she has no entry in the User form. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martin, Robert Sent: Thursday, January 21, 2010 9:53 AM To: arslist@ARSLIST.ORG Subject: Allocating floating license to unregistered users ** Dear List, I am pretty sure we had our system set up to allocate a floating license to a user who logged into the system without an entry in the User form. But now I am finding that such users are getting a read-only license. Am I mis-remembering, or is there a way to allow unregistered users to get floating licenses? I can't find it in the documentation, but perhaps I just haven't looked in the right place. Dwayne Martin James Madison University (ARS 7.1 p3, RH Linux server, Oracle 10.2 db) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
IF, and that's a big IF I remember correctlywhen you authenticate unregistered users through the AREA. In the bottom half of the 'AREA LDAP Configuration' form, there are settings on how you can get the various values for various attributes from the LDAP server, and a section named 'Default Value if not found in LDAP'Based on what I remember you can specify any of the license types other than Fixed, but you should be able to allocate a floating license as default if not found. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martin, Robert Sent: Thursday, January 21, 2010 7:53 AM To: arslist@ARSLIST.ORG Subject: Allocating floating license to unregistered users ** Dear List, I am pretty sure we had our system set up to allocate a floating license to a user who logged into the system without an entry in the User form. But now I am finding that such users are getting a read-only license. Am I mis-remembering, or is there a way to allow unregistered users to get floating licenses? I can't find it in the documentation, but perhaps I just haven't looked in the right place. Dwayne Martin James Madison University (ARS 7.1 p3, RH Linux server, Oracle 10.2 db) _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
Thanks, Joe. Maybe I picked up some bad info years ago, and am just now discovering that it doesn't work. Dwayne From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:08 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** Martin, Unless I have missed something all these years, there is no way a user that does not have an entry in the User form can have any sort of a 'write' license be it Fixed or Floating. You cannot even grant that user a Read-Restricted license, and the only license that a user automatically gets is a Read license if he/she has no entry in the User form. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martin, Robert Sent: Thursday, January 21, 2010 9:53 AM To: arslist@ARSLIST.ORG Subject: Allocating floating license to unregistered users ** Dear List, I am pretty sure we had our system set up to allocate a floating license to a user who logged into the system without an entry in the User form. But now I am finding that such users are getting a read-only license. Am I mis-remembering, or is there a way to allow unregistered users to get floating licenses? I can't find it in the documentation, but perhaps I just haven't looked in the right place. Dwayne Martin James Madison University (ARS 7.1 p3, RH Linux server, Oracle 10.2 db) _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
Maybe this is the location you are talking about where you can allocate a write license if not authenticated??? [cid:image001.jpg@01CA9A83.7669A9F0] ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are inline: image001.jpg
sync=yes
Listers, I am currently troubleshooting an LDAP issue with BMC Support. They have told me that there is a filter with the people form to sync attributes between ctm:people and active directory. Within this filter, there is a setting I need to disable called Sync=Yes. I cannot find this 'filter' or setting. Does anyone know what/where I am supposed to look? ARS 7.1 - Win2003 - ITSM 7.0.03 Thank you, Marcelo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
Yes, that screen, but the field below it, not the one highlighted in yellow. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 9:21 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** Maybe this is the location you are talking about where you can allocate a write license if not authenticated??? _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are image001.jpg
Re: Allocating floating license to unregistered users
This is used only in case you are using LDAP. Its called license masking or something like that where you need to create these expected attributes in LDAP and then configure them in the AREA LDAP Configuration form. For it to work however you do require that user to have a record in the User form with a blank password. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:21 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** Maybe this is the location you are talking about where you can allocate a write license if not authenticated??? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are image001.jpg
Delete entry
Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK * This e-mail message, including any attachments, is for the sole use of the addressee(s) to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Dunkin' Brands Inc. makes no warranty that this e-mail is error or virus free.
Re: sync=yes
Marcelo, This must have been some customization done between some sort of a staging form that you might have created or the vendor form that views the LDAP information and your CTM:People form? To the best of my knowledge there is no vendor form available that automatically binds all the required information from LDAP to ARS. The vendor form has to be built by you. So I highly doubt that there is a OTB filter, its got to be some piece of customization in your house.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:26 AM To: arslist@ARSLIST.ORG Subject: sync=yes Listers, I am currently troubleshooting an LDAP issue with BMC Support. They have told me that there is a filter with the people form to sync attributes between ctm:people and active directory. Within this filter, there is a setting I need to disable called Sync=Yes. I cannot find this 'filter' or setting. Does anyone know what/where I am supposed to look? ARS 7.1 - Win2003 - ITSM 7.0.03 Thank you, Marcelo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Change Request Approval Mapping issue
Close-Down approvals, that get triggered when the change status is Completed do work well with ITSM 7.5.1. We actually use them a lot. If you have ITSM 7.0.x, you may want to look at the release notes to see if any bug has been fixed. Sorry I can't be of more help, but at least you can be assured that it works in 7.5.1 Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Wednesday, January 20, 2010 9:49 PM To: arslist@ARSLIST.ORG Subject: Change Request Approval Mapping issue ** We are attempting to use Approval Mappings that begin in the Completed Status. The approvals display where they should, but won't process due to apparently not having the back-end data in the AP-ChgSignatureDetail Join form. It's like the workflow created some of the approvals, but not all of them. My question is whether anyone has tried to overcome this, and what the design and intended function actually is, since it appears to mostly (but not completely) work. Rick _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
This looks right to me Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of John Kelley [john.kel...@dunkinbrands.com] Sent: Thursday, January 21, 2010 11:38 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK * This e-mail message, including any attachments, is for the sole use of the addressee(s) to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Dunkin' Brands Inc. makes no warranty that this e-mail is error or virus free. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Yes, Your qualification will select records where 'Submit Date' is earlier than 24 hours before the execution time of the escalation Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of John Kelley Sent: Thursday, January 21, 2010 10:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK
Hey Arslist, I forgot to mention...
** Dear Arslist,Oops!! I forgot to invite you to Just Dials Lucky Referrer Contest.The last months winners have won Samsung-LCD TV, Viao Laptop, Nokia phone and Ipods.Why dont you give it a shot? It took me just 2 minutes to play.You could be the next winner. Please click on the link www.justdial.com/contest.Best of Luck,@INVITER_NAMEClick Here to unsubscribe. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_
Re: Delete entry
John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK * This e-mail message, including any attachments, is for the sole use of the addressee(s) to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Dunkin' Brands Inc. makes no warranty that this e-mail is error or virus free. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
Are you sure about that Joe?I ask because there is the option to cross reference blank passwords, which is of course the user record with blank password, but there is also the 'authenticate unregistered users'...this option is available so that you can have users entirely NOT in Remedy but still grant them permissions and suchI've used this before. The only requirement to have them have a record in the user table is if you want to grant them a fixed license. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 9:39 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** This is used only in case you are using LDAP. Its called license masking or something like that where you need to create these expected attributes in LDAP and then configure them in the AREA LDAP Configuration form. For it to work however you do require that user to have a record in the User form with a blank password. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:21 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** Maybe this is the location you are talking about where you can allocate a write license if not authenticated??? _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are image001.jpg
Archive of Audit Forms?
Hello, I need to make the archive table of Audit form from HPD: Help Desk, but as dates from forms audits can not be upgraded, I haven't found a way to make this, someone have any tips? Hellyson helly...@gmail.com helly...@hotmail.com (msn) Brasil - Brazil Quando se sabe ouvir não precisam muitas palavras Edgard Scandurra ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Work Info History not Locked?
If you have access to an Admin tool you can set the default value for the lock field. You might have to look at workflow that opens various forms in case they set values before submission, but start with the field default. If you feel comfortable doing a 'modify all' operation, you just have to track down the form holding your work info records and then query for the ones you want to lock. If you have a large number of tickets you might want to break up the effort into time slots with your query so you don't set loose a big update when people are working. Alfred Differ Sr. Remedy Developer NDTI / NSWC PHD, CODE 210 805-228-6555 alfred.differ@navy.mil -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lateralus Sent: Thursday, January 21, 2010 6:08 To: arslist@ARSLIST.ORG Subject: Work Info History not Locked? ** Hi all, Long time listener, first time poster. I've somehow become the accidental administrator of our Remedy system despite my warnings. We have recently come under scruntiny as all of our Work Info Entries are Unlocked by default and can be edited/modified at any point in time. Is there some way I can enforce the Locked status for a Work Info entry? Bonus points if I'm able to retro-actively set this field to locked for all historical records as well. Cheers! Scott. ARServer 7.0.01 patch 002 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are smime.p7s Description: S/MIME cryptographic signature
Re: Delete entry
Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: sync=yes
Hey Joe, According to the BMC Support person, this is contained in an OOTB filter. I have checked the vendor form created by the previous developer (I did not have Remedy when it was implemented, and no documentation was left for me) and I cannot find this Sync anywhere.. My issue is that every 2 weeks or so, the Remedy service has to be restarted b/c users are unable to login. ARS cannot authenticate users thru LDAP. I suspect a memory leak in the ARPLUGIN.Exe (it grows to 1.8GB). I also notice many LDAP errors in the arerrlog file. After support reviewed my logs they have me chasing this sync attribute that I cannot find for the life in me.. I just wanted to see if anyone out there knew of a Sync field related to LDAP. Thanks, Marcelo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:41 AM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Marcelo, This must have been some customization done between some sort of a staging form that you might have created or the vendor form that views the LDAP information and your CTM:People form? To the best of my knowledge there is no vendor form available that automatically binds all the required information from LDAP to ARS. The vendor form has to be built by you. So I highly doubt that there is a OTB filter, its got to be some piece of customization in your house.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:26 AM To: arslist@ARSLIST.ORG Subject: sync=yes Listers, I am currently troubleshooting an LDAP issue with BMC Support. They have told me that there is a filter with the people form to sync attributes between ctm:people and active directory. Within this filter, there is a setting I need to disable called Sync=Yes. I cannot find this 'filter' or setting. Does anyone know what/where I am supposed to look? ARS 7.1 - Win2003 - ITSM 7.0.03 Thank you, Marcelo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Just a thought on that though. I in the past also preferred the set a field and have filter do the delete, but think about this. If you do an 'Application-Delete-Entry' run process, the only workflow that fires on the affected record is that that is set to fire on delete. If you do a setfield on the record and use a filter, ALL filter workflow that fires on modify of that record fires, thus increasing the load on your App server, in addition to that, being the delete occurs in phase 3 of processing you will be executing all of the SQL to update the last mod by and last mod date of the record for each record affected, thus increasing the load on the db server. Simply deleting the record with a delete process is cleaner, crisper and eliminates load on the app and db serverjust something to think about. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 10:16 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: sync=yes
If this is indeed and OOB filter, then BMC should know the exact name of the filter for you to change, and you should be able to go directly to it. Note also that in the admin tool, you can search for filters by pressing F3 when you are viewing the list of filters. You can enter all or part of the filter name to search. It will go to the first match it finds, but you can look for other matches by clicking Find Again (or something like that - it's been a while since I looked at it). Lyle -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 10:21 AM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Hey Joe, According to the BMC Support person, this is contained in an OOTB filter. I have checked the vendor form created by the previous developer (I did not have Remedy when it was implemented, and no documentation was left for me) and I cannot find this Sync anywhere.. My issue is that every 2 weeks or so, the Remedy service has to be restarted b/c users are unable to login. ARS cannot authenticate users thru LDAP. I suspect a memory leak in the ARPLUGIN.Exe (it grows to 1.8GB). I also notice many LDAP errors in the arerrlog file. After support reviewed my logs they have me chasing this sync attribute that I cannot find for the life in me.. I just wanted to see if anyone out there knew of a Sync field related to LDAP. Thanks, Marcelo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:41 AM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Marcelo, This must have been some customization done between some sort of a staging form that you might have created or the vendor form that views the LDAP information and your CTM:People form? To the best of my knowledge there is no vendor form available that automatically binds all the required information from LDAP to ARS. The vendor form has to be built by you. So I highly doubt that there is a OTB filter, its got to be some piece of customization in your house.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:26 AM To: arslist@ARSLIST.ORG Subject: sync=yes Listers, I am currently troubleshooting an LDAP issue with BMC Support. They have told me that there is a filter with the people form to sync attributes between ctm:people and active directory. Within this filter, there is a setting I need to disable called Sync=Yes. I cannot find this 'filter' or setting. Does anyone know what/where I am supposed to look? ARS 7.1 - Win2003 - ITSM 7.0.03 Thank you, Marcelo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Why not use the Archive for the form. There is an option called Delete from Source. Set time to run, give it a qualifier, be done with it. Grooms, Frederick W wrote: Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Joe, Even though the different operations occur in different phases, won't the escalation thread still be held up until all phases have completed? So, even though the set fields can happen in phase 1, the thread won't be released until the filters fire and deletes the marked records. Lyle -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: sync=yes
Maybe you are on a version of ARS that may have a memory issue? What version are you on? You might want to check for open issues on that version with BMC support with respect to the plugin server.. And honestly I do not recall any OTB filters that would sync the two data repositories.. Try filtering all AREA and ARDBC related forms and check the workflow and I don't think you will find any filter that may be doing this. I do not have a ready system in front of me right now or I'd check for you. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 12:21 PM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Hey Joe, According to the BMC Support person, this is contained in an OOTB filter. I have checked the vendor form created by the previous developer (I did not have Remedy when it was implemented, and no documentation was left for me) and I cannot find this Sync anywhere.. My issue is that every 2 weeks or so, the Remedy service has to be restarted b/c users are unable to login. ARS cannot authenticate users thru LDAP. I suspect a memory leak in the ARPLUGIN.Exe (it grows to 1.8GB). I also notice many LDAP errors in the arerrlog file. After support reviewed my logs they have me chasing this sync attribute that I cannot find for the life in me.. I just wanted to see if anyone out there knew of a Sync field related to LDAP. Thanks, Marcelo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:41 AM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Marcelo, This must have been some customization done between some sort of a staging form that you might have created or the vendor form that views the LDAP information and your CTM:People form? To the best of my knowledge there is no vendor form available that automatically binds all the required information from LDAP to ARS. The vendor form has to be built by you. So I highly doubt that there is a OTB filter, its got to be some piece of customization in your house.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:26 AM To: arslist@ARSLIST.ORG Subject: sync=yes Listers, I am currently troubleshooting an LDAP issue with BMC Support. They have told me that there is a filter with the people form to sync attributes between ctm:people and active directory. Within this filter, there is a setting I need to disable called Sync=Yes. I cannot find this 'filter' or setting. Does anyone know what/where I am supposed to look? ARS 7.1 - Win2003 - ITSM 7.0.03 Thank you, Marcelo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Work Info History not Locked?
Thank you sooo much for the response, and for validating the path I've already started down. I've attempted setting defaults, but there must indeed be some workflow setting it before hand as it seems to always revert back to No. I'm now picking through the workflow logging with Hoo WinTail to track down what exactly is happening. Again, thanks! This mailing list is definately the best Remedy resource I've been able to find thus far :-D Cheers, Scott. On Thu, Jan 21, 2010 at 1:07 PM, Differ, Alfred W CTR NAVSEA, 210 alfred.differ@navy.mil wrote: If you have access to an Admin tool you can set the default value for the lock field. You might have to look at workflow that opens various forms in case they set values before submission, but start with the field default. If you feel comfortable doing a 'modify all' operation, you just have to track down the form holding your work info records and then query for the ones you want to lock. If you have a large number of tickets you might want to break up the effort into time slots with your query so you don't set loose a big update when people are working. Alfred Differ Sr. Remedy Developer NDTI / NSWC PHD, CODE 210 805-228-6555 alfred.differ@navy.mil -Original Message- From: Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] On Behalf Of Lateralus Sent: Thursday, January 21, 2010 6:08 To: arslist@ARSLIST.ORG Subject: Work Info History not Locked? ** Hi all, Long time listener, first time poster. I've somehow become the accidental administrator of our Remedy system despite my warnings. We have recently come under scruntiny as all of our Work Info Entries are Unlocked by default and can be edited/modified at any point in time. Is there some way I can enforce the Locked status for a Work Info entry? Bonus points if I'm able to retro-actively set this field to locked for all historical records as well. Cheers! Scott. ARServer 7.0.01 patch 002 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.netsponsor%3armisoluti...@verizon.netARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Work Info History not Locked?
Setting the ITSM WorkLog to default to Locked is notoriously difficult. There is OOB workflow that wants to force Locked to be No regardless of the user's choice. What we did to accomplish this is: 1. Set the default to the Locked field (z1D_Secure_Log) to Yes on HPD:Help Desk, or wherever. 2. Disable the OOB AL that wants to force them all to unlocked: SHR:SHR:NewLogNotEqualSecure_101 3. For good measure we added a filter to HPD:WorkLog (and others) that sets 'Secure Work Log' = Yes on Submit. We did this because there seemed to be some hard to pin down scenarios where just disabling the above AL did not seem to work. This may be overkill for you. This was with ARS 7.x and ITSM 7.0.3 various patches. Regards, Chuck Baldi On Thu, Jan 21, 2010 at 12:07 PM, Differ, Alfred W CTR NAVSEA, 210 alfred.differ@navy.mil wrote: If you have access to an Admin tool you can set the default value for the lock field. You might have to look at workflow that opens various forms in case they set values before submission, but start with the field default. If you feel comfortable doing a 'modify all' operation, you just have to track down the form holding your work info records and then query for the ones you want to lock. If you have a large number of tickets you might want to break up the effort into time slots with your query so you don't set loose a big update when people are working. Alfred Differ Sr. Remedy Developer NDTI / NSWC PHD, CODE 210 805-228-6555 alfred.differ@navy.mil -Original Message- From: Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] On Behalf Of Lateralus Sent: Thursday, January 21, 2010 6:08 To: arslist@ARSLIST.ORG Subject: Work Info History not Locked? ** Hi all, Long time listener, first time poster. I've somehow become the accidental administrator of our Remedy system despite my warnings. We have recently come under scruntiny as all of our Work Info Entries are Unlocked by default and can be edited/modified at any point in time. Is there some way I can enforce the Locked status for a Work Info entry? Bonus points if I'm able to retro-actively set this field to locked for all historical records as well. Cheers! Scott. ARServer 7.0.01 patch 002 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.netsponsor%3armisoluti...@verizon.netARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: sync=yes
ARS 7.1 Patch7 - Backline has the ticket now and is investigating I do not think this sync=yes exists. At least in my environment. I'll just wait for BMC's response. Thanks guys! -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 11:31 AM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Maybe you are on a version of ARS that may have a memory issue? What version are you on? You might want to check for open issues on that version with BMC support with respect to the plugin server.. And honestly I do not recall any OTB filters that would sync the two data repositories.. Try filtering all AREA and ARDBC related forms and check the workflow and I don't think you will find any filter that may be doing this. I do not have a ready system in front of me right now or I'd check for you. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 12:21 PM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Hey Joe, According to the BMC Support person, this is contained in an OOTB filter. I have checked the vendor form created by the previous developer (I did not have Remedy when it was implemented, and no documentation was left for me) and I cannot find this Sync anywhere.. My issue is that every 2 weeks or so, the Remedy service has to be restarted b/c users are unable to login. ARS cannot authenticate users thru LDAP. I suspect a memory leak in the ARPLUGIN.Exe (it grows to 1.8GB). I also notice many LDAP errors in the arerrlog file. After support reviewed my logs they have me chasing this sync attribute that I cannot find for the life in me.. I just wanted to see if anyone out there knew of a Sync field related to LDAP. Thanks, Marcelo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:41 AM To: arslist@ARSLIST.ORG Subject: Re: sync=yes Marcelo, This must have been some customization done between some sort of a staging form that you might have created or the vendor form that views the LDAP information and your CTM:People form? To the best of my knowledge there is no vendor form available that automatically binds all the required information from LDAP to ARS. The vendor form has to be built by you. So I highly doubt that there is a OTB filter, its got to be some piece of customization in your house.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:26 AM To: arslist@ARSLIST.ORG Subject: sync=yes Listers, I am currently troubleshooting an LDAP issue with BMC Support. They have told me that there is a filter with the people form to sync attributes between ctm:people and active directory. Within this filter, there is a setting I need to disable called Sync=Yes. I cannot find this 'filter' or setting. Does anyone know what/where I am supposed to look? ARS 7.1 - Win2003 - ITSM 7.0.03 Thank you, Marcelo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: 7.1 MidTier on 64 Bit Windows
There was a very recent thread on this same topic with detailed instructions for what was necessary to make this work. Wes's response was part of that solution. I would recommend searching the archive for the prior post. I think it was within the last couple weeks or so. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Frank Caruso Sent: Thursday, January 21, 2010 6:29 AM To: arslist@ARSLIST.ORG Subject: 7.1 MidTier on 64 Bit Windows ** Can anybody tell me whether the following will work. The compatibility matrix leads me to think that it is supported: Windows 2003 64 Bit 32 Bit JVM (5.14) MidTier 7.1 p5 Everything appears to install without issue but I cannot get Remedy pages to load. Also, after MidTier install, I cannot get a simple test.html page to load (before MidTier install test.html worked). The one issue I see is that with IIS I cannot get the jakarta re director to load under the ISAPI Filters tab. It lets me add it but it never says its UP. Thank you Frank Caruso _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Lyle, They (filter actions triggered by escalations) do not hold the Escalation thread to ransom.. That's the simplest way to put it Even if there is a process time out, the escalation does what it has to do by setting fields and exits making the Escalation thread available for the next set of escalations to fire.. The filter would time out if there is a time out during the actual delete.. This doesn't cause the escalation to fail.. Even if there is an error during the delete, this error is handled by the Filter thread, and not by the Escalation. That's the whole purpose of using what's known as a 'data driven' Escalation. You let data drive what needs to be done.. Sometimes as in this case its not the best idea to let the Escalation directly do a 2nd or 3rd stage action but let data drive that action and have a modify filter triggered when $USER$ = AR_ESCALATOR perform that action. Joe PS: Something tells me this is gonna be a long thread :-) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Lyle Taylor Sent: Thursday, January 21, 2010 12:30 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Joe, Even though the different operations occur in different phases, won't the escalation thread still be held up until all phases have completed? So, even though the set fields can happen in phase 1, the thread won't be released until the filters fire and deletes the marked records. Lyle -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Allocating floating license to unregistered users
I completely forgot about that recently added option to authenticate unregistered users, so yes you may be right about that. I haven't really had to use that option so am unable to comment about my experiences with that. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:05 PM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** Are you sure about that Joe?I ask because there is the option to cross reference blank passwords, which is of course the user record with blank password, but there is also the 'authenticate unregistered users'...this option is available so that you can have users entirely NOT in Remedy but still grant them permissions and suchI've used this before. The only requirement to have them have a record in the user table is if you want to grant them a fixed license. -- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 9:39 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** This is used only in case you are using LDAP. Its called license masking or something like that where you need to create these expected attributes in LDAP and then configure them in the AREA LDAP Configuration form. For it to work however you do require that user to have a record in the User form with a blank password. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Martinez, Marcelo A Sent: Thursday, January 21, 2010 11:21 AM To: arslist@ARSLIST.ORG Subject: Re: Allocating floating license to unregistered users ** Maybe this is the location you are talking about where you can allocate a write license if not authenticated??? _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are image001.jpg
Re: Delete entry (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE PS: Something tells me this is gonna be a long thread :-) Speaking as someone who has only just begun to venture into the rabbit hole that is ARS/Remedy... Good :-) This kind of discussion is invaluable and a wonderful insight into the inner workings of ARS. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 12:48 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Lyle, They (filter actions triggered by escalations) do not hold the Escalation thread to ransom.. That's the simplest way to put it Even if there is a process time out, the escalation does what it has to do by setting fields and exits making the Escalation thread available for the next set of escalations to fire.. The filter would time out if there is a time out during the actual delete.. This doesn't cause the escalation to fail.. Even if there is an error during the delete, this error is handled by the Filter thread, and not by the Escalation. That's the whole purpose of using what's known as a 'data driven' Escalation. You let data drive what needs to be done.. Sometimes as in this case its not the best idea to let the Escalation directly do a 2nd or 3rd stage action but let data drive that action and have a modify filter triggered when $USER$ = AR_ESCALATOR perform that action. Joe PS: Something tells me this is gonna be a long thread :-) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Lyle Taylor Sent: Thursday, January 21, 2010 12:30 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Joe, Even though the different operations occur in different phases, won't the escalation thread still be held up until all phases have completed? So, even though the set fields can happen in phase 1, the thread won't be released until the filters fire and deletes the marked records. Lyle -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010 11:39 AM To: arslist@ARSLIST.ORG Subject: Delete entry Hi All Brain cramp today Can someone confirm that this statement is true! I am performing a delete action in an escalation for deleting all items in a form 24 hours and beyond. Let me rephrase I want to leave items in the form for 24 hours from the submit date. 'Submit Date' ( $TIMESTAMP$ - 86400) Sys:Action ARS 7.1 Thanks JK ___ UNSUBSCRIBE or access ARSlist Archives at
Resolved: 7.1 MidTier on 64 Bit Windows
I found the post. Looks like I was getting closer with enabling 32 Bit compatibility in IIS but there was another step I was missing. However, I was under a tight time frame so I had the VM team build out a 32 bit host instead. I had the host built and Remedy installed in less than 45 minutes! Thank you for your help. On Thu, Jan 21, 2010 at 8:38 PM, Lyle Taylor tayl...@ldschurch.org wrote: ** There was a very recent thread on this same topic with detailed instructions for what was necessary to make this work. Wes’s response was part of that solution. I would recommend searching the archive for the prior post. I think it was within the last couple weeks or so. Lyle *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Frank Caruso *Sent:* Thursday, January 21, 2010 6:29 AM *To:* arslist@ARSLIST.ORG *Subject:* 7.1 MidTier on 64 Bit Windows ** Can anybody tell me whether the following will work. The compatibility matrix leads me to think that it is supported: Windows 2003 64 Bit 32 Bit JVM (5.14) MidTier 7.1 p5 Everything appears to install without issue but I cannot get Remedy pages to load. Also, after MidTier install, I cannot get a simple test.html page to load (before MidTier install test.html worked). The one issue I see is that with IIS I cannot get the jakarta re director to load under the ISAPI Filters tab. It lets me add it but it never says its UP. Thank you Frank Caruso _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the
Re: Delete entry
If there were thousands of items in the form created every day then I would take another route. But I decided to set the escalation to run off hours so it shouldn't cause performance problems. Thanks for the thread's talk I forgot about that aspect. JK Hermann, John N Mr CTR USA TRADOC john.herma...@us.army.mil Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 01/21/2010 12:53 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Delete entry (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE PS: Something tells me this is gonna be a long thread :-) Speaking as someone who has only just begun to venture into the rabbit hole that is ARS/Remedy... Good :-) This kind of discussion is invaluable and a wonderful insight into the inner workings of ARS. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 12:48 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Lyle, They (filter actions triggered by escalations) do not hold the Escalation thread to ransom.. That's the simplest way to put it Even if there is a process time out, the escalation does what it has to do by setting fields and exits making the Escalation thread available for the next set of escalations to fire.. The filter would time out if there is a time out during the actual delete.. This doesn't cause the escalation to fail.. Even if there is an error during the delete, this error is handled by the Filter thread, and not by the Escalation. That's the whole purpose of using what's known as a 'data driven' Escalation. You let data drive what needs to be done.. Sometimes as in this case its not the best idea to let the Escalation directly do a 2nd or 3rd stage action but let data drive that action and have a modify filter triggered when $USER$ = AR_ESCALATOR perform that action. Joe PS: Something tells me this is gonna be a long thread :-) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Lyle Taylor Sent: Thursday, January 21, 2010 12:30 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Joe, Even though the different operations occur in different phases, won't the escalation thread still be held up until all phases have completed? So, even though the set fields can happen in phase 1, the thread won't be released until the filters fire and deletes the marked records. Lyle -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called ztmpDeleteTime. Set the time $TIMESTAMP$ + 86400 to it using a filter.. Then have the Escalation check 'ztmpDeleteTime' $TIMESTAMP$ and mark the record for deletion using another temp field that you have that escalation set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for the purpose of not choking the escalation thread. Have a filter that performs that delete when the record is marked for deletion and the $USER$ is the escalation user. It would be more efficient especially over a large number of records.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Kelley Sent: Thursday, January 21, 2010
FW: Resolved vs.Closed Incidents
Resolved means the customer still has a chance to re-open the ticket. No one should be able to re-open a Closed ticket. -Original Message- From: SUBSCRIBE arslist Melissa [mailto:melissa.r...@stls.frb.org] Sent: Wednesday, January 20, 2010 3:56 PM Subject: Re: Resolved vs.Closed Incidents ** I believe the ITIL process says something about verifying with the customer that everything is resolved before closing it. That way if there are still issues, it can be put back into in progress status and continued to be worked. From: Jase Brandon jasebran...@gmail.com To: arslist@ARSLIST.ORG Date: 01/20/2010 03:54 PM Subject: Resolved vs.Closed Incidents Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** Hello All, I know this is probably an easy question, but I couldn't give an answer other than that's how we have always done it Someone asked me today to justify why we go from Resolved to Closed, instead of directly to Closed. I answered with the escalation closes after INC has been resolved for X amount of time, etc.. but couldn't give a concrete answer as to why the process is to set to Resolved first. I seem to remember this is just ITIL - can anyone enlighten me with a quick blurb? Thanks, Jase Brandon Quality Technology Services ARS 7.1 Windows 2003 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Here is an example from a Filter log file (ARS 7.1.0 Patch 007) showing the Filter doing the delete. FLTR TID: 06 RPC ID: 002826 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Thu Jan 21 2010 04:22:41.1471 */ Checking Freds Test Filter FLTR TID: 06 RPC ID: 002826 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) 0: Process FLTR TID: 06 RPC ID: 002826 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1)Application-Delete-Entry 01:CA:RecordLocks LCK07380319 Looking at the Escalation Log it definitely waited until all Filter actions completed before moving on to the next record. Actually if you have a lot of records to delete I would make the escalation run in its own thread pool (AR System Administration Console - System - General - Server Information - Ports and Queues tab Set an RPC Prog Number of 390603, Min Threads and Max threads to however many escalation threads you want. When you define your escalation select a separate pool for this escalation. If no pool is selected then the escalation will run in Pool 1. FYI: Application-Query-Delete-Entry does each delete in a separate transaction. You can see it do an individual select for each record to delete by watching the SQL log. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 1:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM
Re: Delete entry
Joe, Let me just say I love academic topics like this:) Here is my setup. I created a form and added a 'wait' selection field to it. I added a filter that fires when that wait field is set to Yes. It's only action is to do a DB wait action of 5 seconds. I created 5 records in the form and added an escalation that fires with no qual that sets the wait flag to Yes. The end result of this is I have 5 records that will each wait 5 seconds to process, thus causing the escalation to run for 25 seconds every 5 min's. I then turned on Escalation and Filter logs into the same file. Attached are the def of these 3 objects and the log of the events. What I see is a single thread on a single RPC ID performing updates to 5 records and that thread handles the filter actions of that modify in the same way. My direct SQL gets deferred to Phase 2, whereas in our original topic the delete would get done in Phase 3, but either way the Escalation thread waits for all phase of processing to finish before it continues to the next record. In this scenario I chose 5 seconds to give sufficient time for the escalation thread to 'move on' if it was going toit didn't. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:44 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:51 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry ** John, Should work but I'd make the process a little more data driven.. Instead of having the escalation calculate all this and chocking an escalation thread, I'd set that delete time to a temp field at the time of submitting the record. For e.g.. create a temp field called
Re: Delete entry
I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any
Re: Delete entry
This is interesting. I wonder if anyone out there still are on a version 4 server to try something similar to see if it had been the same back then. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 2:09 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Joe, Let me just say I love academic topics like this:) Here is my setup. I created a form and added a 'wait' selection field to it. I added a filter that fires when that wait field is set to Yes. It's only action is to do a DB wait action of 5 seconds. I created 5 records in the form and added an escalation that fires with no qual that sets the wait flag to Yes. The end result of this is I have 5 records that will each wait 5 seconds to process, thus causing the escalation to run for 25 seconds every 5 min's. I then turned on Escalation and Filter logs into the same file. Attached are the def of these 3 objects and the log of the events. What I see is a single thread on a single RPC ID performing updates to 5 records and that thread handles the filter actions of that modify in the same way. My direct SQL gets deferred to Phase 2, whereas in our original topic the delete would get done in Phase 3, but either way the Escalation thread waits for all phase of processing to finish before it continues to the next record. In this scenario I chose 5 seconds to give sufficient time for the escalation thread to 'move on' if it was going toit didn't. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:44 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is a better approach as set fields is a fast operation that happens on the first phase of the transaction.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W Sent: Thursday, January 21, 2010 12:16 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Since it is on the right side of the equation and not using any fields from the form the Escalation should only do the calculation once. As for setting a field and having a Filter do the delete, that is my preferred method as well Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent:
Re: Delete entry
Well, hopefully THE MAN (i.e Doug Mueller) will chime in, to clarify this topic. Maybe the ARS server has been redesigned/improved in this area after all Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Joe D'Souza [jdso...@shyle.net] Sent: Thursday, January 21, 2010 2:12 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are right in that calculation-wise it will not really have any benefit. But doing a delete in an escalation is not the best way - Delete is a 2nd phase operation and is queued. You do not want to hold the escalation thread longer than it should for this queue to complete. So having a filter aid the escalation to actually do the delete and the escalation only to mark the record to be deleted is
Re: Delete entry
Paging Mr Mueller Paging Mr. Doug Mueller... Please come to the ARS List rescue once again Thank you, Pascale Boyer Remedy Technical Lead Developer Daimler Trucks North America LLC Montgomery Park, 9th floor Portland, OR 97210 U.S.A Phone:503-745-6569 Email:pascale.bo...@daimler.com http://www.daimler-trucksnorthamerica.com guilla...@dcshq.com Sent by: arslist@ARSLIST.ORG 01/21/2010 11:24 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Delete entry Well, hopefully THE MAN (i.e Doug Mueller) will chime in, to clarify this topic. Maybe the ARS server has been redesigned/improved in this area after all Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Joe D'Souza [jdso...@shyle.net] Sent: Thursday, January 21, 2010 2:12 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe
Re: Delete entry
I just went and looked at my 4.5 manuals (yes I still have them). It looks like 4.5 is when a separate Escalation thread (390603) was added to the system. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Thursday, January 21, 2010 1:24 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Well, hopefully THE MAN (i.e Doug Mueller) will chime in, to clarify this topic. Maybe the ARS server has been redesigned/improved in this area after all Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Joe D'Souza [jdso...@shyle.net] Sent: Thursday, January 21, 2010 2:12 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates its job and exits.. and it runs with a specific thread ID (I do not recall it by memory what that ID is but its something like 600630??). But that's besides the point.. The filter that actually does the delete does not use the same thread number as the escalation (try thread logging and you will see this). So when you have an escalation do what it has to do, namely the first phase operation of Set Fields, it does that and it doesn't really care if the Filter does or does not execute the operations defined to fire on Modify when the $USER$ is the escalation user.. Filters when triggered fire and utilize a different thread. So the deletes that would be triggered as a result of the Modify operation by the Escalation will be independent of that Escalation thread, and the escalation thread exits before all of the deleted occur, thus being available to any other escalations that may be designed to immediately follow.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing Sent: Thursday, January 21, 2010 12:31 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry But Joe, yes the set field happens in phase 1, but the delete action happening on the record itself is still a phase 3 action. Either way the Escalation has to wait for each record to 'process' before it goes onto the next record, so delete from the escalation vs delete from a filter on the record will cause the escalation thread to still wait, so I'm not sure I agree with your statements. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Fred, You are
Re: Delete entry
Folks, No need really for me to address this topic since those of you in the community have already addressed it. When escalations run, any filters they trigger run IN LINE. They do in 7.5, they do in 7.1 and 7.0. They did in 6.3, 6.0, 5.1, 5.0, 4.5, 4.0, 3.xx, 3.0, 2.x and all the way back to whatever release escalations were added in. There has been no change in behaviour or action since the beginning. Joe -- someone simply gave you incorrect information in your training class. Many ideas were shared during the discussion. All had valid points and some good reasoning for doing things in various ways and ideas around alternatives. If there is a concept of deleting, I always like to have a way to trigger things through a set fields (generally using a command field that I can send a specific value) and have filters that do the work. Now, if you want to do cleanup like was described in the initial request, you can have an escalation trigger the operation. My vote push fields to the command word. Why? Well, if I wanted to have logic on the delete that did checking or auditing or notifiation or whatever, that workflow would have been defined with filters when I defined the ability to have a command field with a specific value trigger a delete. Now, if I wanted to delete a specific entry, I could just send the command word. If I wanted escalations do the work, I could have the escalation send the command word. Now, all logic is localized and focussed and defined one time for this operation. No risk of inconsistency depending on how I deleted or anything else. If there is other logic that runs on modify, you can always skip it using the go to statement. On the other hand, if the only reason every and only mechanism ever to delete the entry was the escalation, I could do it direct and put any processing logic on the escalation. This is viable, but it is defining into your system that the only way to delete is through escalation. The key here is to decide whether the operation should be available one off as well as through escalation or not. Again, this is just restating things that others have already stated (well, the statement that filters have always been in line in escalations may be a clarification that others could not offer). Generally, there is no need to offer followup comments because the group here generally gets the answer for each other without assistance. Doug -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 11:13 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' ( $TIMESTAMP$ - 86400) I would then have a single run-process action to do the: Application-Delete-Entry $SCHEMA$ $1$ Each delete will then take place in a separate transaction. If you do an Application-Query-Delete-Entry that handles multiple deletes, it will take place inside a single transaction that will be rolled back if any of the deletes fail. This use a lot of resources, especially if you have attachments on the form. I would suggest that you put an index on the field, and that you run it as often as possible. Maybe each hour or so, or maybe even every 7 minutes if you have a lot of records to delete. This will minimize the impact on other escalations, as each run will take less time. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. That's actually not true.. Filters use a different thread than Escalations.. Let me explain further what I learnt in a performance tuning class years ago (version 4 days) and I do not think this has changed with the later versions.. When an escalation does what it has to do, it terminates
Re: 7.5 Installation Problems (of course!)
I believe it was ARERR 8761: An invalid password has been used for access to the plug-in server. Contact your AR System Administrator for assistance. We restored our server to what it was yesterday morning and we are going to try again tomorrow morning. Lisa From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, January 20, 2010 5:18 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** What are the errors? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Kemes, Lisa Sent: Wednesday, January 20, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** We tried this and now we are getting different errors. (again with having to do with the plug in). Lisa From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, January 20, 2010 2:42 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** Try starting the plugin server manually and see what you get.. You can steal the syntax for starting it from the armonitor.cfg file. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Kemes, Lisa Sent: Wednesday, January 20, 2010 2:22 PM To: arslist@ARSLIST.ORG Subject: 7.5 Installation Problems (of course!) ** Just did an upgrade from ARS 7.1 p7 to 7.5 p3. We have Windows 2003 server and a separate Oracle 10g server. When trying to get into AR System Console/System/General/Server Information and getting ARERR [8760] Cannot establish a network connection to the AR System Plug-In server : ars-dev (5214) : RPC: Miscellaneous tli error - System error (Connection refused). Checked on ARERR 8760 and it has to do with the Plug in Server. Checked arplugin.exe and it is not running. Checked armonitor.log and it is not in there either. Can't turn on Plug-In Server logging (I believe) because we can't get into the Server Information. Has anyone else come across this at all? Lisa Kemes AR System Developer Tyco Electronics 717-810-2408 tel 717-810-2124 fax lisa.ke...@tycoelectronics.com _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: 7.5 Installation Problems (of course!)
The plugin password is set from the AR Server Information configuration interface. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Kemes, Lisa Sent: Thursday, January 21, 2010 3:17 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** I believe it was ARERR 8761: An invalid password has been used for access to the plug-in server. Contact your AR System Administrator for assistance. We restored our server to what it was yesterday morning and we are going to try again tomorrow morning. Lisa -- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, January 20, 2010 5:18 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** What are the errors? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Kemes, Lisa Sent: Wednesday, January 20, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** We tried this and now we are getting different errors. (again with having to do with the plug in). Lisa From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, January 20, 2010 2:42 PM To: arslist@ARSLIST.ORG Subject: Re: 7.5 Installation Problems (of course!) ** Try starting the plugin server manually and see what you get.. You can steal the syntax for starting it from the armonitor.cfg file. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Kemes, Lisa Sent: Wednesday, January 20, 2010 2:22 PM To: arslist@ARSLIST.ORG Subject: 7.5 Installation Problems (of course!) ** Just did an upgrade from ARS 7.1 p7 to 7.5 p3. We have Windows 2003 server and a separate Oracle 10g server. When trying to get into AR System Console/System/General/Server Information and getting ARERR [8760] Cannot establish a network connection to the AR System Plug-In server : ars-dev (5214) : RPC: Miscellaneous tli error - System error (Connection refused). Checked on ARERR 8760 and it has to do with the Plug in Server. Checked arplugin.exe and it is not running. Checked armonitor.log and it is not in there either. Can't turn on Plug-In Server logging (I believe) because we can't get into the Server Information. Has anyone else come across this at all? Lisa Kemes AR System Developer Tyco Electronics 717-810-2408 tel 717-810-2124 fax lisa.ke...@tycoelectronics.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Delete entry
Doug, Thank you for chiming in and clarifying this for us. I never fail to read your emails to the list :-) This is what I remember from that training class years ago held at Bracknell, UK.. The example used was the notify action. This was during the time when the notification process used to be handled by the notification server which was independent of the AR system process. We were given the example of the notification action using escalations to be a bad idea, as if the notification server choked for whatever reasons, the escalation process would also choke. So having escalations to set a flag using set fields and have filters carry that notification action after checking for the flag would avoid this.. And then we were told that the same is the case for all 2nd and 3rd phase actions. I actually vaguely remember a topic called something like 'Data driven escalations' during which the instructor had discussed this. I had basically used that as the 'word from the Bible' all these years without really questioning it... So this was wrongly conveyed to us? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Mueller, Doug Sent: Thursday, January 21, 2010 3:07 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Folks, No need really for me to address this topic since those of you in the community have already addressed it. When escalations run, any filters they trigger run IN LINE. They do in 7.5, they do in 7.1 and 7.0. They did in 6.3, 6.0, 5.1, 5.0, 4.5, 4.0, 3.xx, 3.0, 2.x and all the way back to whatever release escalations were added in. There has been no change in behaviour or action since the beginning. Joe -- someone simply gave you incorrect information in your training class. Many ideas were shared during the discussion. All had valid points and some good reasoning for doing things in various ways and ideas around alternatives. If there is a concept of deleting, I always like to have a way to trigger things through a set fields (generally using a command field that I can send a specific value) and have filters that do the work. Now, if you want to do cleanup like was described in the initial request, you can have an escalation trigger the operation. My vote push fields to the command word. Why? Well, if I wanted to have logic on the delete that did checking or auditing or notifiation or whatever, that workflow would have been defined with filters when I defined the ability to have a command field with a specific value trigger a delete. Now, if I wanted to delete a specific entry, I could just send the command word. If I wanted escalations do the work, I could have the escalation send the command word. Now, all logic is localized and focussed and defined one time for this operation. No risk of inconsistency depending on how I deleted or anything else. If there is other logic that runs on modify, you can always skip it using the go to statement. On the other hand, if the only reason every and only mechanism ever to delete the entry was the escalation, I could do it direct and put any processing logic on the escalation. This is viable, but it is defining into your system that the only way to delete is through escalation. The key here is to decide whether the operation should be available one off as well as through escalation or not. Again, this is just restating things that others have already stated (well, the statement that filters have always been in line in escalations may be a clarification that others could not offer). Generally, there is no need to offer followup comments because the group here generally gets the answer for each other without assistance. Doug -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 11:13 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Hi Joe, I have to disagree with you here. Any filter-actions resulting from an Escalation Set-Fields/Push-Fields operation will be performed in the same thread. I have seen hundreds of log files to prove this. I would use the exact same escalation qualification as JK suggested: 'Submit Date' (
Re: Work Info History not Locked?
I think I might have this beat. I found I also had to modify: SHR:SHR:OnDisplay_050_SetActivityFields It also has a Set Fields action that switches the z1D_Secure_Log to No. I have simply flipped it to Yes and I'm testing now. I'm also going to export all definitions for the HPD:Help Desk form and try to track down any other references to this field to try and understand anywhere else it's being manipulated. BTW - What methods do you use to do development/testing. I don't recall it being THIS painful (it's been awhile since I've worked with it). After each change I want to test, I have to: - Close Administrator - Ensure I have no active user sessions (close all User instances)\ - Delete everything from my local /Documents and Settings\user\Application Data\AR System\HOME folder - Punt the Remedy Server service on the (Windows) server. - Reopen User and Administrator tools to continue. If I DON'T do this... I get these strange User does not have AR Write license (or something like that...) when testing. Am I missing something here? Thanks again for all the excellent help! Scott. On Thu, Jan 21, 2010 at 1:37 PM, Charles Baldi charles.ba...@gmail.comwrote: ** Setting the ITSM WorkLog to default to Locked is notoriously difficult. There is OOB workflow that wants to force Locked to be No regardless of the user's choice. What we did to accomplish this is: 1. Set the default to the Locked field (z1D_Secure_Log) to Yes on HPD:Help Desk, or wherever. 2. Disable the OOB AL that wants to force them all to unlocked: SHR:SHR:NewLogNotEqualSecure_101 3. For good measure we added a filter to HPD:WorkLog (and others) that sets 'Secure Work Log' = Yes on Submit. We did this because there seemed to be some hard to pin down scenarios where just disabling the above AL did not seem to work. This may be overkill for you. This was with ARS 7.x and ITSM 7.0.3 various patches. Regards, Chuck Baldi On Thu, Jan 21, 2010 at 12:07 PM, Differ, Alfred W CTR NAVSEA, 210 alfred.differ@navy.mil wrote: If you have access to an Admin tool you can set the default value for the lock field. You might have to look at workflow that opens various forms in case they set values before submission, but start with the field default. If you feel comfortable doing a 'modify all' operation, you just have to track down the form holding your work info records and then query for the ones you want to lock. If you have a large number of tickets you might want to break up the effort into time slots with your query so you don't set loose a big update when people are working. Alfred Differ Sr. Remedy Developer NDTI / NSWC PHD, CODE 210 805-228-6555 alfred.differ@navy.mil -Original Message- From: Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] On Behalf Of Lateralus Sent: Thursday, January 21, 2010 6:08 To: arslist@ARSLIST.ORG Subject: Work Info History not Locked? ** Hi all, Long time listener, first time poster. I've somehow become the accidental administrator of our Remedy system despite my warnings. We have recently come under scruntiny as all of our Work Info Entries are Unlocked by default and can be edited/modified at any point in time. Is there some way I can enforce the Locked status for a Work Info entry? Bonus points if I'm able to retro-actively set this field to locked for all historical records as well. Cheers! Scott. ARServer 7.0.01 patch 002 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.netsponsor%3armisoluti...@verizon.netARSlist: Where the Answers Are _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Work Info History not Locked?
Wow, I'm not sure what's up there, but I've never had to go through all that to test. Assuming this is a development environment you're working on, all I've had to do is make sure that Development Cache Mode is on (I always have it on in development), save my changes in the Admin tool, close any instances of the affected form in the User tool, and then reopen the form which loads the updated definitions including any affected active links. I've rarely ever had to remove all the ARV files, etc. I have never had to close the Admin tool, and I have never had to bounce the AR server after making the change. Odd... Good luck, Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lateralus Sent: Thursday, January 21, 2010 2:25 PM To: arslist@ARSLIST.ORG Subject: Re: Work Info History not Locked? ** I think I might have this beat. I found I also had to modify: SHR:SHR:OnDisplay_050_SetActivityFields It also has a Set Fields action that switches the z1D_Secure_Log to No. I have simply flipped it to Yes and I'm testing now. I'm also going to export all definitions for the HPD:Help Desk form and try to track down any other references to this field to try and understand anywhere else it's being manipulated. BTW - What methods do you use to do development/testing. I don't recall it being THIS painful (it's been awhile since I've worked with it). After each change I want to test, I have to: - Close Administrator - Ensure I have no active user sessions (close all User instances)\ - Delete everything from my local /Documents and Settings\user\Application Data\AR System\HOME folder - Punt the Remedy Server service on the (Windows) server. - Reopen User and Administrator tools to continue. If I DON'T do this... I get these strange User does not have AR Write license (or something like that...) when testing. Am I missing something here? Thanks again for all the excellent help! Scott. On Thu, Jan 21, 2010 at 1:37 PM, Charles Baldi charles.ba...@gmail.commailto:charles.ba...@gmail.com wrote: ** Setting the ITSM WorkLog to default to Locked is notoriously difficult. There is OOB workflow that wants to force Locked to be No regardless of the user's choice. What we did to accomplish this is: 1. Set the default to the Locked field (z1D_Secure_Log) to Yes on HPD:Help Desk, or wherever. 2. Disable the OOB AL that wants to force them all to unlocked: SHR:SHR:NewLogNotEqualSecure_101 3. For good measure we added a filter to HPD:WorkLog (and others) that sets 'Secure Work Log' = Yes on Submit. We did this because there seemed to be some hard to pin down scenarios where just disabling the above AL did not seem to work. This may be overkill for you. This was with ARS 7.x and ITSM 7.0.3 various patches. Regards, Chuck Baldi On Thu, Jan 21, 2010 at 12:07 PM, Differ, Alfred W CTR NAVSEA, 210 alfred.differ@navy.milmailto:alfred.differ@navy.mil wrote: If you have access to an Admin tool you can set the default value for the lock field. You might have to look at workflow that opens various forms in case they set values before submission, but start with the field default. If you feel comfortable doing a 'modify all' operation, you just have to track down the form holding your work info records and then query for the ones you want to lock. If you have a large number of tickets you might want to break up the effort into time slots with your query so you don't set loose a big update when people are working. Alfred Differ Sr. Remedy Developer NDTI / NSWC PHD, CODE 210 805-228-6555 alfred.differ@navy.milmailto:alfred.differ@navy.mil -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Lateralus Sent: Thursday, January 21, 2010 6:08 To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Work Info History not Locked? ** Hi all, Long time listener, first time poster. I've somehow become the accidental administrator of our Remedy system despite my warnings. We have recently come under scruntiny as all of our Work Info Entries are Unlocked by default and can be edited/modified at any point in time. Is there some way I can enforce the Locked status for a Work Info entry? Bonus points if I'm able to retro-actively set this field to locked for all historical records as well. Cheers! Scott. ARServer 7.0.01 patch 002 _Platinum Sponsor: rmisoluti...@verizon.netmailto:rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.orghttp://www.arslist.org/ Platinum Sponsor:rmisoluti...@verizon.netmailto:sponsor%3armisoluti...@verizon.net ARSlist: Where the Answers Are _Platinum Sponsor: rmisoluti...@verizon.netmailto:rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor:
Re: Delete entry
My coworker David Hutchinson tried to reply to this but his email didn't make it for whatever reason. His statement: You can use the Archive for the form. There is an option called Delete from Source. Set time to run, give it a qualifier, be done with it. The AR System server has a special user called AR_ARCHIVER to perform data; if you run a filter log file, you can see this entry in the log file. The AR System server also reserves an internal thread for archiving. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 4:00 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Doug, Thank you for chiming in and clarifying this for us. I never fail to read your emails to the list :-) This is what I remember from that training class years ago held at Bracknell, UK.. The example used was the notify action. This was during the time when the notification process used to be handled by the notification server which was independent of the AR system process. We were given the example of the notification action using escalations to be a bad idea, as if the notification server choked for whatever reasons, the escalation process would also choke. So having escalations to set a flag using set fields and have filters carry that notification action after checking for the flag would avoid this.. And then we were told that the same is the case for all 2nd and 3rd phase actions. I actually vaguely remember a topic called something like 'Data driven escalations' during which the instructor had discussed this. I had basically used that as the 'word from the Bible' all these years without really questioning it... So this was wrongly conveyed to us? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Mueller, Doug Sent: Thursday, January 21, 2010 3:07 PM To: arslist@ARSLIST.ORG Subject: Re: Delete entry Folks, No need really for me to address this topic since those of you in the community have already addressed it. When escalations run, any filters they trigger run IN LINE. They do in 7.5, they do in 7.1 and 7.0. They did in 6.3, 6.0, 5.1, 5.0, 4.5, 4.0, 3.xx, 3.0, 2.x and all the way back to whatever release escalations were added in. There has been no change in behaviour or action since the beginning. Joe -- someone simply gave you incorrect information in your training class. Many ideas were shared during the discussion. All had valid points and some good reasoning for doing things in various ways and ideas around alternatives. If there is a concept of deleting, I always like to have a way to trigger things through a set fields (generally using a command field that I can send a specific value) and have filters that do the work. Now, if you want to do cleanup like was described in the initial request, you can have an escalation trigger the operation. My vote push fields to the command word. Why? Well, if I wanted to have logic on the delete that did checking or auditing or notifiation or whatever, that workflow would have been defined with filters when I defined the ability to have a command field with a specific value trigger a delete. Now, if I wanted to delete a specific entry, I could just send the command word. If I wanted escalations do the work, I could have the escalation send the command word. Now, all logic is localized and focussed and defined one time for this operation. No risk of inconsistency depending on how I deleted or anything else. If there is other logic that runs on modify, you can always skip it using the go to statement. On the other hand, if the only reason every and only mechanism ever to delete the entry was the escalation, I could do it direct and put any processing logic on the escalation. This is viable, but it is defining into your system that the only way to delete is through escalation. The key here is to decide whether the operation should be available one off as well as through escalation or not. Again, this is just restating things that others have already stated (well, the statement that filters have always been in line in escalations may be a clarification that others could not offer). Generally, there is no need to offer followup comments because the group here generally gets the answer for each other without assistance. Doug -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Thursday, January 21, 2010 11:13 AM To: arslist@ARSLIST.ORG Subject: Re: Delete entry I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say.
JSS SSO - danger bug
Hello, I found some bug in Single Sign On from JSS. We considered in my company to buy this plugin but my security specialist did not accept this plugin. Because If you installing plugin for BMC Remedy User, you can easy extract universal password from the windows register where the plugin is installed. If you have this universal password you can log-in to remedy for any username. I contacted with producer of this plugin, but he not respond. I don't want to public how extract this password, But if you are interested please contact with me to my email. Cheers Fedor ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
[no subject]
http://sites.google.com/site/mfcexunotf/bxdp9krzlg ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Best practice for Oracle ARCHIVELOG versus NOARCHIVELOG?
1) Is there a best practice for Oracle ARCHIVELOG versus NOARCHIVELOG? BMC wasn't much help on this issue. 2) Do Oracle shops that run with NOARCHIVELOG down their arserver during nightly backups, or bounce it when the backups are done? It turns out the site I'm working at has been in NOARCHIVELOG the whole time I've been there (~10 months) with no scheduled bounce for arserver (7.1 on windows) and I never realized it, because miraculously the server manages to reconnect itself JUST well enough for people to enter tickets the next day without noticing anything. I only started noticing it when I needed to create some new forms (editing existing ones worked fine) and I always got ARERR 55 and couldn't create any until I bounced the service. This problem was 100% repeatable and always worked in the evening when I left and failed in the morning when I came back :) Alan ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
RKM No Suitable Driver
I am installing RKM 7.2 on a Windows 2003 server, MS SQL 2005 DB with Tomcat and IIS and Remedy Mid-tier 7.1 Patch 8 (although there appears to be remnants of a 7.0.x install). Mid-tier works. the .jar files are in the tomcat common lib folder. I keep getting an error when trying to create the rkm database using the RKM Config Wizard: ERROR: Diagnostics: Failed to create database connection: Cannot create JDBC driver of class 'com.microsoft.sqlserver.jdbc.SQLServerDriver' for connect URL 'jdbc:microsoft:sqlserver://remote server:1433' ERROR: kms.sql.SQLServer: Failed to create database objects: No suitable driver I have a classpath that points to the sqljdbc.jar. It is the 1.2 version of the JDBC driver. I am not getting a login failure so I don't think that is the reason. I am stumped. I am about ready to wipe the whole server and start over, but I am not sure if that is the solution. Would hate to do all that and still get the same problem. Below is the details of the log file. Bruce Sisk 21-Jan-10 22:03:25 * ERROR: Diagnostics: Failed to create database connection: Cannot create JDBC driver of class 'com.microsoft.sqlserver.jdbc.SQLServerDriver' for connect URL 'jdbc:microsoft:sqlserver://xxx:1433' 21-Jan-10 22:03:25INFO: Diagnostics: Code version: 7.2.00.1521 21-Jan-10 22:03:25INFO: Diagnostics: Config version: 7.2.00.1521 21-Jan-10 22:03:25 DEBUG: HomeFinder: Creating SearchServer connection pool... 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer driver: jdbc.searchserver.SSDriver 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer URL: jdbc:searchserver:SearchServer_5.4 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer active: 1 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer max idle: 1 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer min idle: 0 21-Jan-10 22:03:25INFO: HomeFinder: SearchServer properties file not specified, using defaults 21-Jan-10 22:03:25INFO: AppConfig: Configuration settings successfully loaded. 21-Jan-10 22:03:25 DEBUG: HomeFinder: Creating raw database connection... 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database driver: com.microsoft.sqlserver.jdbc.SQLServerDriver 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database URL: jdbc:microsoft:sqlserver://xxx:1433 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database user: xxx 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database password: 21-Jan-10 22:03:25 * ERROR: kms.sql.SQLServer: Failed to create database objects: No suitable driver 21-Jan-10 22:03:31 DEBUG: AppConfig: kms.authentication.SystemConfigurationAuthenticator created. PeoplePC Online A better way to Internet http://www.peoplepc.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: RKM No Suitable Driver
Bruce, Have you installed the 2005 SQL client? It's not a thick client as it used to be in the past but just a few dll files etc that get installed. If so, can you resolve / ping the SQL server by the remote server name you have provided? Maybe it requires a FQDN in case you are supplying just the machine name. Also the default port that you are using 1433, is that what the SQL server is configured to use or have the defaults been changed? I know you said you aren't getting a login failure so if any of the above didn't check correctly, that is what you would be getting. But I just thought you could check that anyways just in case the error reporting was faulty. Does the system and application event log throw anything more that may be of interest to you? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of bruce sisk Sent: Thursday, January 21, 2010 10:16 PM To: arslist@ARSLIST.ORG Subject: RKM No Suitable Driver I am installing RKM 7.2 on a Windows 2003 server, MS SQL 2005 DB with Tomcat and IIS and Remedy Mid-tier 7.1 Patch 8 (although there appears to be remnants of a 7.0.x install). Mid-tier works. the .jar files are in the tomcat common lib folder. I keep getting an error when trying to create the rkm database using the RKM Config Wizard: ERROR: Diagnostics: Failed to create database connection: Cannot create JDBC driver of class 'com.microsoft.sqlserver.jdbc.SQLServerDriver' for connect URL 'jdbc:microsoft:sqlserver://remote server:1433' ERROR: kms.sql.SQLServer: Failed to create database objects: No suitable driver I have a classpath that points to the sqljdbc.jar. It is the 1.2 version of the JDBC driver. I am not getting a login failure so I don't think that is the reason. I am stumped. I am about ready to wipe the whole server and start over, but I am not sure if that is the solution. Would hate to do all that and still get the same problem. Below is the details of the log file. Bruce Sisk 21-Jan-10 22:03:25 * ERROR: Diagnostics: Failed to create database connection: Cannot create JDBC driver of class 'com.microsoft.sqlserver.jdbc.SQLServerDriver' for connect URL 'jdbc:microsoft:sqlserver://xxx:1433' 21-Jan-10 22:03:25INFO: Diagnostics: Code version: 7.2.00.1521 21-Jan-10 22:03:25INFO: Diagnostics: Config version: 7.2.00.1521 21-Jan-10 22:03:25 DEBUG: HomeFinder: Creating SearchServer connection pool... 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer driver: jdbc.searchserver.SSDriver 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer URL: jdbc:searchserver:SearchServer_5.4 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer active: 1 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer max idle: 1 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer min idle: 0 21-Jan-10 22:03:25INFO: HomeFinder: SearchServer properties file not specified, using defaults 21-Jan-10 22:03:25INFO: AppConfig: Configuration settings successfully loaded. 21-Jan-10 22:03:25 DEBUG: HomeFinder: Creating raw database connection... 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database driver: com.microsoft.sqlserver.jdbc.SQLServerDriver 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database URL: jdbc:microsoft:sqlserver://xxx:1433 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database user: xxx 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database password: 21-Jan-10 22:03:25 * ERROR: kms.sql.SQLServer: Failed to create database objects: No suitable driver 21-Jan-10 22:03:31 DEBUG: AppConfig: kms.authentication.SystemConfigurationAuthenticator created. PeoplePC Online A better way to Internet http://www.peoplepc.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: RKM No Suitable Driver
To set the database driver for MS-SQL 2005 Open the kms_config.xml file . The kms_config.xml file is located in the following deffault folder: \BMC Remedy Knowledge Management\data\kms_conf Locate the database driver element. It is similar to the following statement: database driver=com.microsoft.jdbc.sqlserver.SQLServerDriver initial=0 max-active=75 max-idle=25 min-idle=0 password=password url=jdbc:microsoft:sqlserver://server:1433 user=RKM_Admin/ Make the following changes: Change the driver attribute to the following value: database driver=com.microsoft.sqlserver.jdbc.SQLServerDriver Change the url attribute to the following value: url=jdbc:sqlserver://server:1433 The database driver element should be similar to the following statement: database driver=com.microsoft.sqlserver.jdbc.SQLServerDriver initial=0 max-active=75 max-idle=25 min-idle=0 password=password url=jdbc:sqlserver://server:1433 user=RKM_Admin/ Save the kms_config.xml file. Restart web services. For Apache Tomcat, stop and start the Apache Tomcat service. Thanks Regards, Mahendra Mahalkar On Fri, Jan 22, 2010 at 12:04 PM, Joe D'Souza jdso...@shyle.net wrote: Bruce, Have you installed the 2005 SQL client? It's not a thick client as it used to be in the past but just a few dll files etc that get installed. If so, can you resolve / ping the SQL server by the remote server name you have provided? Maybe it requires a FQDN in case you are supplying just the machine name. Also the default port that you are using 1433, is that what the SQL server is configured to use or have the defaults been changed? I know you said you aren't getting a login failure so if any of the above didn't check correctly, that is what you would be getting. But I just thought you could check that anyways just in case the error reporting was faulty. Does the system and application event log throw anything more that may be of interest to you? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of bruce sisk Sent: Thursday, January 21, 2010 10:16 PM To: arslist@ARSLIST.ORG Subject: RKM No Suitable Driver I am installing RKM 7.2 on a Windows 2003 server, MS SQL 2005 DB with Tomcat and IIS and Remedy Mid-tier 7.1 Patch 8 (although there appears to be remnants of a 7.0.x install). Mid-tier works. the .jar files are in the tomcat common lib folder. I keep getting an error when trying to create the rkm database using the RKM Config Wizard: ERROR: Diagnostics: Failed to create database connection: Cannot create JDBC driver of class 'com.microsoft.sqlserver.jdbc.SQLServerDriver' for connect URL 'jdbc:microsoft:sqlserver://remote server:1433' ERROR: kms.sql.SQLServer: Failed to create database objects: No suitable driver I have a classpath that points to the sqljdbc.jar. It is the 1.2 version of the JDBC driver. I am not getting a login failure so I don't think that is the reason. I am stumped. I am about ready to wipe the whole server and start over, but I am not sure if that is the solution. Would hate to do all that and still get the same problem. Below is the details of the log file. Bruce Sisk 21-Jan-10 22:03:25 * ERROR: Diagnostics: Failed to create database connection: Cannot create JDBC driver of class 'com.microsoft.sqlserver.jdbc.SQLServerDriver' for connect URL 'jdbc:microsoft:sqlserver://xxx:1433' 21-Jan-10 22:03:25INFO: Diagnostics: Code version: 7.2.00.1521 21-Jan-10 22:03:25INFO: Diagnostics: Config version: 7.2.00.1521 21-Jan-10 22:03:25 DEBUG: HomeFinder: Creating SearchServer connection pool... 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer driver: jdbc.searchserver.SSDriver 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer URL: jdbc:searchserver:SearchServer_5.4 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer active: 1 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer max idle: 1 21-Jan-10 22:03:25 DEBUG: HomeFinder: SearchServer min idle: 0 21-Jan-10 22:03:25INFO: HomeFinder: SearchServer properties file not specified, using defaults 21-Jan-10 22:03:25INFO: AppConfig: Configuration settings successfully loaded. 21-Jan-10 22:03:25 DEBUG: HomeFinder: Creating raw database connection... 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database driver: com.microsoft.sqlserver.jdbc.SQLServerDriver 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database URL: jdbc:microsoft:sqlserver://xxx:1433 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database user: xxx 21-Jan-10 22:03:25 DEBUG: HomeFinder: Database password: 21-Jan-10 22:03:25 * ERROR: kms.sql.SQLServer: Failed to create database objects: No suitable driver 21-Jan-10 22:03:31 DEBUG: AppConfig: kms.authentication.SystemConfigurationAuthenticator created. PeoplePC Online A better way to Internet http://www.peoplepc.com
Spoof email from my email address
Hi Guys you might have received this email coming from my email address, this was spoofed and was not really from me. I am trying to take actions that this does not happen again. Will update you shortly. thanks Shafqat Ayaz --- On Fri, 1/22/10, Shawn Kristoferu skristof...@yahoo.com wrote: From: Shawn Kristoferu skristof...@yahoo.com Subject: Re: To: Shafqat Ayaz shafq...@yahoo.com Date: Friday, January 22, 2010, 6:39 AM Looks like your account has been hacked. Respectfully Yours,Shawn Kristoferu From: Shafqat Ayaz shafq...@yahoo.com To: ak...@cmango.com; malikhur...@hotmail.com; mark.kierst...@xinify.com; skristof...@yahoo.com; arv...@okayainfo.com; arslist@ARSLIST.ORG; ross.mcma...@openspaces.co.uk; smir...@hotmail.com; christopher.mo...@unisys.com; pardi...@yahoo.com Sent: Thu, January 21, 2010 6:20:42 PM Subject: http://sites.google.com/site/mfcexunotf/bxdp9krzlg ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
