Re: Issues in DSO 7.6.04 SP2 Linux-Windows
Nathan, If you are using a portmapper, then that port should be open in the firewall. If you are using private ports, all the appropriate cross bounder addresses must also be opened through the firewall. Regards, Chad Whilding Senior Developer CSC 3560 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-7827 | f: | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Nathan Brandt nathanrbra...@gmail.com To: arslist@ARSLIST.ORG Date: 04/09/2013 11:24 PM Subject:Re: Issues in DSO 7.6.04 SP2 Linux-Windows Sent by:Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** Thanks guys for all the help. I am still trying to figure it out. One more question. When servers are geographically dispersed, how does this work? Typically only mid tier port would be exposed for outside, if at all. If servers are behind firewalls, do we have to go with Placeholder Server which has a public IP? ~ Nathan On Tue, Apr 9, 2013 at 6:32 PM, Chad M Whilding cwhild...@csc.com wrote: ** Nathan, If there is no conflict between your /etc/hosts and DNS, then double check the ar.cfg. There is also an IP-Name parameter that can be used for a server with multiple names. There are also some DSO specific name parameters. Double check that none of these are conflicting. Regards, Chad Whilding Senior Developer CSC 3560 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-7827 | f: | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From:Nathan Brandt nathanrbra...@gmail.com To:arslist@ARSLIST.ORG Date:04/09/2013 01:13 AM Subject:Issues in DSO 7.6.04 SP2 Linux-Windows Sent by:Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** We are trying to setup DSO between 2 AR servers. One is on RHEL 5.3, 7.6.04 SP2 and other is on Win 2k 8, 7.6.04 SP2 We enabled DSO on both the servers. Machines are in same network and accessible from one another using machine name (same as AR Server name). After making all configuration changes, we observe following 1. From Developer Studio, if we connect to Windows ARS, we are able to connect to Linux Server in one of the distributed mappings. Even here, there is small glitch, we need to specify IP address of Linux machine. It doesn't work with AR Server Name of Linux machine. 2. But from Developer Studio, if we connect to Linux ARS, no matter what we put we are not able to establish connection to Windows ARS server. When configuring DSO on both, we have used machine names (same as AR Server Alias Name) (and not FQDN) of the remote AR Server. Any clues what might be going wrong? ~ Nathan _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Issues in DSO 7.6.04 SP2 Linux-Windows
Nathan, If there is no conflict between your /etc/hosts and DNS, then double check the ar.cfg. There is also an IP-Name parameter that can be used for a server with multiple names. There are also some DSO specific name parameters. Double check that none of these are conflicting. Regards, Chad Whilding Senior Developer CSC 3560 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-7827 | f: | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Nathan Brandt nathanrbra...@gmail.com To: arslist@ARSLIST.ORG Date: 04/09/2013 01:13 AM Subject:Issues in DSO 7.6.04 SP2 Linux-Windows Sent by:Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** We are trying to setup DSO between 2 AR servers. One is on RHEL 5.3, 7.6.04 SP2 and other is on Win 2k 8, 7.6.04 SP2 We enabled DSO on both the servers. Machines are in same network and accessible from one another using machine name (same as AR Server name). After making all configuration changes, we observe following 1. From Developer Studio, if we connect to Windows ARS, we are able to connect to Linux Server in one of the distributed mappings. Even here, there is small glitch, we need to specify IP address of Linux machine. It doesn't work with AR Server Name of Linux machine. 2. But from Developer Studio, if we connect to Linux ARS, no matter what we put we are not able to establish connection to Windows ARS server. When configuring DSO on both, we have used machine names (same as AR Server Alias Name) (and not FQDN) of the remote AR Server. Any clues what might be going wrong? ~ Nathan _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: DSO - issues on 7.6.04?
Have you seen anything in DSO and Filter logging on the destination system? DSO logging is always a little tricky; sometimes the inbound side doesn't log and sometimes the outbound side doesn't log. But the filter always logs! I seem to remember filter problems on the destination leading me to believe there was a higher level problem. Regards, Chad Whilding Senior Developer CSC 3560 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-7827 | f: | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Dave Barber daddy.bar...@gmail.com To: arslist@arslist.org Date: 01/25/2013 05:28 AM Subject:Re: DSO - issues on 7.6.04? Sent by:Action Request System discussion list(ARSList) arslist@arslist.org ** I've been trying this - we have 5 test environments that are either running on 7.0.01 patch 012 or 7.6.04 patch 004, and I can't seem to get any form of DSO transaction running between them. The DSO passwords have all been set the same across environments, I have now tried copying the password via the configuration files and that makes no difference. G, very frustrating. Think I may start from scratch again, disable DSO, remove all config clean slate time. On 24 January 2013 11:53, Patrick Zandi remedy...@gmail.com wrote: ** It works for the email config as well, In case you needed to know Sent from my iPhone On Jan 24, 2013, at 3:39, Dave Barber daddy.bar...@gmail.com wrote: ** Doug/Ken, Many thanks - I'm sceptical of it being a password as such, as these are test servers on which I've set a generic (arsystem) DSO password. I'll follow through with the password copy on the ar.conf file, we too are on Solaris. Regards Dave On 24 January 2013 01:24, Ken Pritchard pri...@ptd.net wrote: ** One thing I found with earlier versions (might be corrected in V7.6.04) as recent as 7.6.03 was that the system sometimes didn't store (encrypt) the DSO password for the target machine correctly. A trick I found is to go into the ar.conf file (I'm on Solaris) and cut the DSO password for server A from the conf file on server A and paste it into the line of the server B conf file for the target DSO password for server A. Didn't even have to restart the DSO process - picked it right up and started transferring. Just passing that along as an option to try - only takes a minute to check. - Original Message - From: Mueller, Doug Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Sent: Wednesday, January 23, 2013 4:22 PM Subject: Re: DSO - issues on 7.6.04? ** Dave, Well the message says Access problem when trying to get the remote definition…. So, the question that immediately comes to mind is whether you have configured the appropriate passwords for the DSO user to be able to access the remote system? You can get from B to A but not from A to B. You can get from A to A and from B to B. Well, B has a DSO password and you have to configure A to have that password so that it can talk with B. I would check the configuration (configured on the Server Information form) on system A – the one you cannot call from – to make sure that system B is registered with a password. If there is a password, it will not show you the value so you might try entering the right value and saving just to be sure that you have the right value configured. Then, see where that leaves you. But, an error of an access problem is related to password problems or port configuration problems or something that prevents the DSO process on system A from accessing system B for interaction. Hopefully this gives a hint that helps in finding a solution, Doug Mueller From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Monday, January 21, 2013 7:10 AM To: arslist@ARSLIST.ORG Subject: DSO - issues on 7.6.04? ** All, We're not using DSO much - currently only for one transaction type, which is basically a password sync option between our (in house) incident system running on 7.0.01 and an ootb change management application running on 7.5 (incident and its server has always been the primary application) In the process of upgrading the 7.0.01 server to 7.6.04 patch 004, and I'm trying to replicate the DSO functionality between our test environments. Its licensed on all of them, but when trying to send a DSO transaction from 7.6.04 to either a 7.0.01 or 7.5 server I'm always getting : ** WARNING ** Access problem trying to get target form definition, later... (Mon
Re: Accessibility behavior with two keystrokes
. That should give you the most complete functionality and support and support for the version (at least 11 and I think it includes 12) of JAWS that you are using. The area of accessibility is a challenging one. There are may difficulties with dynamic screens and the use of various screen readers and the standards have not come together in the area of dynamic change. There is one caled ARIA that is moving along and trying to come up with things to address this area and we are tracking that standard. I hope this information is useful, Doug Mueller -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG] On Behalf Of Chad M Whilding Sent: Tuesday, February 01, 2011 5:25 AM To: arslist@ARSLIST.ORG Subject: Accessibility behavior with two keystrokes Dear arslisters, Looking for help from the collective experience of other users who have fiddled with JAWS and AR System. All help is appreciated. I've noticed that the CTRL+ALT+F6 toggle to the Results List doesn't actually speak anything when the toggle lands (so to speak) on the Results List. JAWS basically echoes the keystroke. When toggled to the details pane, the field with focus is spoken. In Virtual PC Cursor I can tab through the records in the Results List, but JAWS speaks nothing. In Forms Mode I can scroll through (Up and Down arrow) the Results List, but JAWS speaks nothing. Is there an inherent property that will make any of this more verbose? AR System 7.0.1 p9 Mid Tier 7.0.1 p9 Apache Tomcat 5.5.25 Windows Server 2003sp2 Java 1.5.0_12 I.E 7 JAWS 12...freshly update today Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Accessibility behavior with two keystrokes
Dear arslisters, Looking for help from the collective experience of other users who have fiddled with JAWS and AR System. All help is appreciated. I've noticed that the CTRL+ALT+F6 toggle to the Results List doesn't actually speak anything when the toggle lands (so to speak) on the Results List. JAWS basically echoes the keystroke. When toggled to the details pane, the field with focus is spoken. In Virtual PC Cursor I can tab through the records in the Results List, but JAWS speaks nothing. In Forms Mode I can scroll through (Up and Down arrow) the Results List, but JAWS speaks nothing. Is there an inherent property that will make any of this more verbose? AR System 7.0.1 p9 Mid Tier 7.0.1 p9 Apache Tomcat 5.5.25 Windows Server 2003sp2 Java 1.5.0_12 I.E 7 JAWS 12...freshly update today Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: How to find filters/escaltions with DSO action
You can use these sql calls. SELECT filter.name, filter_process.command FROM filter INNER JOIN filter_process ON filter_process.filterId = filter.filterId WHERE filter_process.command Like '%Distributed%' or filter_process.command Like '%ardist%' ORDER BY filter.Name SELECT escalation.name, filter_process.command FROM escalation INNER JOIN filter_process ON filter_process.filterId = escalation.escalationId WHERE filter_process.command Like '%Distributed%' or filter_process.command Like '%ardist%' ORDER BY escalation.Name Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. | | From: | | --| |urthebest theept...@gmail.com | --| | | To:| | --| |arslist@ARSLIST.ORG | --| | | Date: | | --| |09/16/2010 06:35 AM | --| | | Subject: | | --| |How to find filters/escaltions with DSO action | --| Hi Can some one help me how to search filters/escalations with DSO actions in them . its very urg -- View this message in context: http://old.nabble.com/How-to-find-filters-escaltions-with-DSO-action-tp29726776p29726776.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Working with JAWS screen reader and ARS
Dear list members, I am learning to use JAWS in an effort to provide support to a No Vision user. We hope to gain valuable lessons in making our application more navigable. I am focusing on access via the Mid-Tier, as this seems to be where JAWS provides the best navigation tricks. This task is quite an experience as I read BMC documentation, goto JAWS and struggle with what really works. I have found a few deficiencies, but am in no way hitting all aspects of our application. I have found the document 'Designing BMC Remedy applications for Section 508 compliance.pdf' quite valuable and at times confusing. If anyone has blazed this path before me and generated helpful tips in navigating objects like the Results List, Tables and Menu Lists, would you be willing to share? I haven't approached BMC yet concerning issues I found; that generally never goes well ;) Thanks for your time. Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: DSO question
Warren, Don't forget that newer versions (7.x range) require a password. Under connection settings in the AR System Administration: Console of newer 7.x versions. So make sure the 6.3 version can accept the password from a newer version and make sure the 6.3 can send a password to a newer version. There was a period where certain older versions just weren't compatible with newer versions because of this. Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. | | From: | | --| |Warren Baltimore warrenbaltim...@gmail.com | --| | | To:| | --| |arslist@ARSLIST.ORG | --| | | Date: | | --| |06/30/2010 02:30 PM | --| | | Subject: | | --| |DSO question | --| ** Good day fellow listers! I have a quick question for everyone. While I understand the purpose of DSO, I have never actually used it. If there are 2 system, one is ars 6.3 and the other is 7.5. Is there any reason that a DSO link could not be set up between the 2 systems (given the fact that there are field differences in the 2 setups). The desired affect is to allow tickets created on the 7.5 system to also show up on the 6.3 (and vice-versa). Warren -- Warren R. Baltimore II Remedy Developer 410-533-5367 _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Detect QBE Search
Dear arslisters, Loonnggg time lurker here, infrequent poster; needed to plug into the collective on this one. Goal: Determine when the user issues a QBE search. Customer Need: Recently added Oracle to the application mix and user's are having trouble remembering it is case sensitive. We store all data in uppercase...they are entering queries in lower-case. Not viable solution User caps lockcan't seem to get them to realize this simple solution Oracle case insensitivewe've been told this isn't an option at this time. I'm not the export nor responsible party. Plus this turned out to be a tricky one we wanted to figure out. ARS Platform ARS 7.1 p009 SQL Server on Window 2003 and up Oracle 10g on Solaris 5 Fat Client and Mid Tier in play; both at p009 Custom Application GUI Our Application Start control panel allows the user to run stored queries. We utilize the EXTERNAL feature in a Window Open Modify action to process the query and return results in Modify mode. We also allow them to open the form in a regular search window. What I thought was simplejust execute at On Search momentfrom search mode. However, our App Start stored query approach also processes through an On Search moment and we don't want to run this uppercase helper ALL the time; just from Ad Hoc QBE query. What I have discovered: Window Open Modify does not allow you to pass anything through to next window. Adding QueryBar (1005) field is detectable from an Active Link, when using advanced search bar. EXTERNAL doesn't pass the query through the QueryBar(1005) field object. 1st approach, tag a field when the form is opened from our App Start control panel and puts them in search mode, on search check tagged field for value; works great until the user performs a Clear All 2nd approach, Active Link execute On Search where Query Bar is Null. works great for QBE from search mode, but also runs from App Start Control Panel stored query design, so violates our development goal of only executing from Ad Hoc QBE Query. In reality, I did determine that this is really only setting a lot of null fields to uppercase...but the less processing the better. 3rd approach, check to see an arslister has determined how to detect usage of EXTERNAL at On Search moment or better yet...has a better idea If I can determine EXTERNAL usage, I can factor out the App Start stored query (EXTERNAL not null) and I can detect when the user is performing a QBE only search (QueryBar is null). Your help is appreciated. Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Detect QBE Search
Matt, Things are well.I see you pop-up on here on occasion, and wonder the same for you. Thanks for the input, I'm still digesting the first idea. One the second idea, the kicker is I can't pass anything to the 2nd window when the EXTERNAL is used to get me to Modfiy. And since both actions send me through the On Search mode of the tool, I am stuck trying to isolate both of them. EXTERNAL is processed completely hidden. Regards, Chad Whilding Engineer CSC 3725 Pentagon Blvd., Beavercreek, OH 45431-1706 North American Public Sector | p: +1-937.320-6342 | f:+1-937-320- | cwhild...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. | | From: | | | |Matthew Perrault matthew.perra...@genmills.com | | | | To:| | | |arslist@ARSLIST.ORG | | | | Date: | | | |06/22/2010 04:42 PM | | | | Subject: | | | |Re: Detect QBE Search | | CHAD!!! Long time man, hope things are going good for ya. This may not solve your issue, and it is kind of ugly, but, just to throw out an idea: How about on Window open, when $OPERATION$ = QUERY, (or through the Form itself, and unlock them on modify) SET ALL fields except the ones with the QBE match to Read-Only. Also, set an AL to fire if all those read-write QBE fields are NULL (prevents the Advanced Search 1 = 1 query), and throw an error. When they search on the form, have an active link that automatically does an UPPER on the field if there is a value in it. Then, on the server turn off unqualified searches. So clear All, and search throws the error. The only other way I can think to do what you are trying, is when you pass the EXTERNAL query through to the other form Set a Flag on the Form you're opening. This way you can differentiate between the External query, and the standard QBE search query. Then have the AL only fire on search if the field used in the External is NULL, and that other flag is set. Just some thoughts HTH Matt P. -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arsl...@arslist.org] On Behalf Of Chad M Whilding Sent: Tuesday, June 22, 2010 3:10 PM To: arslist@ARSLIST.ORG Subject: Detect QBE Search Dear arslisters, Loonnggg time lurker here, infrequent poster; needed to plug into the collective on this one. Goal: Determine when the user issues a QBE search. Customer Need: Recently added Oracle to the application mix and user's are having trouble remembering it is case sensitive. We store all data in uppercase...they are entering queries in lower-case. Not viable solution User caps lockcan't seem to get them to realize this simple solution Oracle case insensitivewe've been told this isn't an option at this time. I'm not the export nor responsible party. Plus this turned out to be a tricky one we wanted to figure out. ARS Platform ARS 7.1 p009 SQL Server on Window 2003 and up Oracle 10g
Re: arimportcmd error
Rick, Two problems my colleague Jayson has discovered If the encrypted password has a / in it, the import fails. There may be other potential characters that cause a problem. If the server is NOT registered with the portmapper and you try and us a mapping, the import fails. Regards, Chad Whilding 937-320-3475 Computer Sciences Corporation Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA Registered in USA No: C-489-59 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Roger Medsker [EMAIL PROTECTED] OMTo Sent by: Action arslist@ARSLIST.ORG Request System cc discussion list(ARSList)Subject [EMAIL PROTECTED] Re: arimportcmd error ORG 03/28/2008 08:52 AM Please respond to [EMAIL PROTECTED] RG ** Rick, Do you have a special character in the password? That may be throwing the command line interpreter off. I’ve gotten into the habit of always putting quotes around my password; even if it doesn’t have a special character. You might also try using the parameters to specify the mapping file and its directory separately (-m and –d) instead of the parameter to specify it all together (-M). Roger From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Thursday, March 27, 2008 11:24 PM To: arslist@ARSLIST.ORG Subject: Re: arimportcmd error ** Well, I’m not sure which tree we need to bark up. The command does not work either in workflow or on the command line. I’ll check the version tomorrow, but I had the same error last week and I KNOW the versions were the same, down to the patch. Wish I could remember what I did to resolve it last week. The only thing of which I am 100% sure is that the mapping file is good. Rick From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shafqat Ayaz Sent: Thursday, March 27, 2008 9:17 PM To: arslist@ARSLIST.ORG Subject: Re: arimportcmd error ** Hi Rick i maybe barking up the wrong tree altogether, but I have got a suspicion that your arimportcmd and the version of ARS are not the same. have you tried being in the directory that arimport.exe resides in and running the command? so go to the c:program files\arsystem\admin directory and try running the command from a DOS box, does that work properly? is so then there is a problem with your mapping file, try the command without a mapping file, you will need an arx or xml file for that, but it will at least tell you if there is a problem with the command itself or the format. let me know if you can generally if you have the command and associated files and the mapping file with the import file in the same directory and you run the import command from there, it should work thanks shafqat Rick Cook [EMAIL PROTECTED] wrote: ** Also tried this: C:\Program Files\AR System\Admin\arimportcmd -u user -p password -M
Re: Duplicate Emails Being sent
Brian, We had problems in 6.3. We installed patch 23 to fix the issue with multiple copies of the cache being loaded. I would hope that would be fixed in ARS 7.1. However, we also discovered that if you forced a notification filter to fire in phase 1 (`! naming convention) duplicate emails were received. We notified BMC of the issue but didn't push it because we really don't need to use it. Regards, Chad Whilding Computer Sciences Corporation Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA Registered in USA No: C-489-59 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Sokol, Brian [EMAIL PROTECTED] C.COM To Sent by: Action arslist@ARSLIST.ORG Request System cc discussion list(ARSList)Subject [EMAIL PROTECTED] Duplicate Emails Being sent ORG 11/14/2007 12:37 PM Please respond to [EMAIL PROTECTED] RG ** Occasionally an end user will get the same email from ARS twice. Has anyone seen this behavior before? Brian Sokol Manager, Desktop Services Scholastic Inc. 557 Broadway NY, NY 10012 (212) 343-6494 http://www.Scholastic.com __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Weird DSO Behavior
Norm, For every MERGE operation on the destination there is a corresponding MODIFY operation on the source. Make sure that is not triggering another DSO. Regards, Chad Whilding This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Kaiser Norm E CIV USAF 96 CS/SCCE [EMAIL PROTECTED] To N.AF.MIL arslist@ARSLIST.ORG Sent by: Action cc Request System discussionSubject list(ARSList)Re: Weird DSO Behavior [EMAIL PROTECTED] ORG 08/03/2007 08:47 AM Please respond to [EMAIL PROTECTED] RG Thanks. I know how DSO works as far as a row being fetched, a row being deleted, and a row being inserted. And we've turned on DSO, filter, and SQL logging when performing the troubleshooting. That's pretty much a given. The point is, there is ONE merge event that seems to be triggering a filter more than once. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Thursday, August 02, 2007 9:48 PM To: arslist@ARSLIST.ORG Subject: Re: Weird DSO Behavior Norm, I think your not seeing the whole picture here. You speak of filters and sql logs. Where is the filter logs in your analysis? Where are the filter/sql logs from both servers? (or maybe you just left that detail out?) Now with that aside... I am also confused about what transfer is the issue. Your question states more than a few back and forth transfers from two ARS servers. Can you help narrow down the point that is the problem? You also did not list the times/order that the ARS Server selected the record of interest. ( I think this is very important for you to figure out what the ARS server is really doing.) However in general you might want to know this too During a regular/ordinary merge event that updates an existing record the ARS server will: Get the record from the DB Delete the record from the DB Insert the record into the DB with the changes. It is my understanding that DSO uses merge to push data from server to server. If you track activities on both servers (and you likely want to make sure their system clocks are insync before you do that) then look at the order of filter operations starts and stops first then you should see the general flow of the data. [ How the ARS Server deals with the RDBMS may not answer your questions about why the filter is triggered twice. Even a simple Submit event might talk to the RDBMS several times to get all the data saved if multiple Filter Phases are involved. ] And I am guessing that the sql strangeness is a result of Merge logic internal to the ARS server. What I would be looking for, if I were you, is multiple Merge events being called from the sending DSO server to the target DSO. Maybe you are transferring the ticket multiple times? (once without ownership, and then finally once with ownership?) [Just a WAG.] HTH -- Carey Matthew
Re: DSO -- Distrib Delete is failing
Phani, Check filter logging on the destination end. If it was truly and Independent Copy, then I am not sure the first set of errors is for this ticket. Make sure there isn't a filter preventing the delete. If you are looking at logs on the source, then you won't see what is happening on the destination. Regards, Chad Whilding This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. HonnourPrahallad achar, PhaniRaja phaniraja.honnou To [EMAIL PROTECTED] arslist@ARSLIST.ORG OGICACMG.COM cc Sent by: Action Request SystemSubject discussionDSO -- Distrib Delete is failing list(ARSList) [EMAIL PROTECTED] ORG 03/27/2007 04:09 AM Please respond to [EMAIL PROTECTED] RG ** Hi Listers, We have a issue with the DSO on the SLA:Measurement form. When the SLA is deleted on our Source server, the DistribDelete is not working correctly ( as it is not deleting corresponding record at the destination server). DSO Setup: 1. DSO is configured to Archive the Data ( no chain relation ship) 2. HelpDesk Mapping : Independent Copy 3. SLA:Measurement mapping : Data Only Checked the log files it says: DSO Logs says: DIST Cannot update this entry -- this distributed entry is not the master copy (ARERR 376) DIST Cannot update this entry -- this distributed entry is not the master copy (ARERR 376) DSO's SLA pool log says(for the delete action) : DIST* Failure during delete attempt DIST-- To stage: 7 (of 8) Return Code: 2CANCEL The failure is happening only for the DistribDelete Filter actions. Point to be noted, DSO transfer happened successfully. DIST Processing item number 1 (Fri Mar 23 2007 11:25:15.3200) DISTPending type -- 1 DISTSource Form -- SLA:Measurement DISTSource ID -- 2001785 DISTPending Other -- DIST -m SLA:Measurement -s SLA:Measurement -x in-remedyams-03 -p SLA DISTGet source structure DISTUsing EXISTING cache definition for SLA:Measurement (in-remedyams-02) DISTHave source structure details, get entry DISTHave entry details, get mapping DIST Filter-specified mapping -- SLA:Measurement DIST Filter-specified to form -- SLA:Measurement DIST Filter-specified to server -- in-remedyams-03 DISTMapping name -- SLA:Measurement DISTTarget form -- SLA:Measurement DISTTarget server -- in-remedyams-03 DISTGet target structure DISTUsing EXISTING cache definition for SLA:Measurement (in-remedyams-03) DISTPerform mapping DISTTransfer successfully completed. New/overwritten entry 2001785 DISTMapping completed DIST-- To stage: 8 (of 8) Return Code: 0DONE Wondering when DSO stage 7 of 8 can happen for DSO Transfer, why not for DSO Delete when Mapping, Form are similar for both the action?? ARS Environment: = ARS 5.1.2 Windows 2000 Server ITSM 5.5 Any
Re: MidTier ?
Jamie, We ran into issues with workflow on Window Close in MidTier. With the browser, the window is gone before the Close Window workflow would fire. Trying a prompt to interrupt never worked for us, it just made the situation worse. This is a big behavior difference between the browser and the client tool. We always saw workflow firing in logging, but there was no window left for the workflow to act on. You could try firing something on Un-Display, as it will always fire before a window close in Modify Mode. The last time I tested this didn't work in Submit mode, but you never know when a subtle change is made that you can exploit. Unfortunately, Loose Focus doesn't usually work, but you could try that. On final thing you could try, send an event. Regards, Chad Whilding This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Carey Matthew Black [EMAIL PROTECTED] To COM arslist@ARSLIST.ORG Sent by: Action cc Request System discussionSubject list(ARSList)Re: MidTier ? [EMAIL PROTECTED] ORG 01/05/2007 09:57 AM Please respond to [EMAIL PROTECTED] RG Jamie, I think you could, on window close, check the dirty bit, if it is set then you could also check if all of the required fields/steps has been done on the form. If so then you can either prompt the user to Do you want to Submit this request at this time? or you can auto do it. ( I would prompt the user.) If they answer no then just let the window close. If they say yes then do the submit before the windows closes. And by Prompt I mean a modal dialog what a some text and a few buttons for the user to respond with. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 1/5/07, Blodgett, Jamie [EMAIL PROTECTED] wrote: On Midtier, is there a way to prevent a user from just clicking the 'X' to close an internet window? Possibly some code I could put in the header or footer? I have users that fill in online forms, then close the window without clicking on Submit. I'm hoping I'm just missing something simple. Thanks, Jamie Blodgett Rinker Materials Corp. ARS 6.3 p18 HPUX 11.11 Oracle 10g w/9i libraries Midtier 6.3 p18 Clients mixed 5.12 6.3 p18 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: DSO and $OPERATION$
Frank, If your problem is not intermittent, have you confirmed with logging,or some other method, that it is actually firing in Merge and not Modify. In my experience, the DSO transaction on the destination will first receive the Merge and then a follow-up Modify. So I am assuming the issue is on the destination end, since you mention MERGE. Even if the Run Process with keywords, is showing Merge, I wouldn't necessarily trust it, as that is also a Phase III operation and will fire the first time Phase III is processed and that could well be the Merge operation. A Phase III operation doesn't wait until the Phase I or Phase II that triggered it completes. A Phase III operation is an opportunistic little bugger, they fire as soon as any Phase III is initiated. All that being said, what does the filter logging show? Any chance that you have a MERGE operation that triggers a modify unto the record itself? Even via a third form? Hope this helps Chad This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Frank Caruso [EMAIL PROTECTED] IL.COMTo Sent by: Action arslist@ARSLIST.ORG Request System cc discussion list(ARSList)Subject [EMAIL PROTECTED] DSO and $OPERATION$ ORG 10/16/2006 10:11 AM Please respond to [EMAIL PROTECTED] RG ARS 5.01.02 p? Sybase on Solaris DSO Have a filter that runs on MODIFY only. However, have found instances where the filter is running on a MERGE action. So, I added a Run Process action to log to a file when the filter runs and am outputting the following: $USER$ $SERVER$ $SCHEMA$ $OPERATION$ $Request ID$ $TIMESTAMP$ What I am finding is that the user is Distributed Server and the Operation is MERGE, however, the filter is set to fire only on Modify. Any thought on how this could happen? Thank you. ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: DSO and $OPERATION$
in question that you want to make sure is never triggered by a DSO transaction. This way the workflow will function on an import merge, but not a DSO transfer/etc. -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 Chad M Whilding [EMAIL PROTECTED] Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 10/17/2006 01:17 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DSO and $OPERATION$ Frank, If your problem is not intermittent, have you confirmed with logging,or some other method, that it is actually firing in Merge and not Modify. In my experience, the DSO transaction on the destination will first receive the Merge and then a follow-up Modify. So I am assuming the issue is on the destination end, since you mention MERGE. Even if the Run Process with keywords, is showing Merge, I wouldn't necessarily trust it, as that is also a Phase III operation and will fire the first time Phase III is processed and that could well be the Merge operation. A Phase III operation doesn't wait until the Phase I or Phase II that triggered it completes. A Phase III operation is an opportunistic little bugger, they fire as soon as any Phase III is initiated. All that being said, what does the filter logging show? Any chance that you have a MERGE operation that triggers a modify unto the record itself? Even via a third form? Hope this helps Chad This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Frank Caruso [EMAIL PROTECTED] IL.COM To Sent by: Action arslist@ARSLIST.ORG Request System cc discussion list(ARSList) Subject [EMAIL PROTECTED] DSO and $OPERATION$ ORG 10/16/2006 10:11 AM Please respond to [EMAIL PROTECTED] RG ARS 5.01.02 p? Sybase on Solaris DSO Have a filter that runs on MODIFY only. However, have found instances where the filter is running on a MERGE action. So, I added a Run Process action to log to a file when the filter runs and am outputting the following: $USER$ $SERVER$ $SCHEMA$ $OPERATION$ $Request ID$ $TIMESTAMP$ What I am finding is that the user is Distributed Server and the Operation is MERGE, however, the filter is set to fire only on Modify. Any thought on how this could happen? Thank you. ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages to or from authorized Kohl's Associates at any time without any further consent. ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org -- Frank Caruso Specific Integration, Inc. Senior Remedy Engineer www.specificintegration.com 703-376-1249 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: DSO and $OPERATION$
Frank, I don't know if you are eluding to another transaction or not with this statement . The update of the Main Form causes the filter to fire which, thru a push fields action, is creating another record But the bottom line is the local MainForm should only be a Modify, AND the remote MainForm will see a Merge and a Modify. The tricky part through this whole thing is that the $USER$ value will be Distributed Server. So you could not use this in the qualification. Is there any field value on Modify on the local MainForm, that would not be detected on the remote MainForm Modify, after the merge operation? Might I suggest that as part of the Push Field action you set a Display Only scratch field and watch for $USER$ != Distributed Server on Create or Modify. Then fire you filter on this. The filter would never fire on the remote MainForm, because the Modify is from the DSO transaction and not the Push Field action. It works because the scratch field won't have a value in the DSO transaction. You may need to play with shifting to Phase 1 aka `! Chad This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Frank Caruso [EMAIL PROTECTED] IL.COMTo Sent by: Action arslist@ARSLIST.ORG Request System cc discussion list(ARSList)Subject [EMAIL PROTECTED] Re: DSO and $OPERATION$ ORG 10/17/2006 03:47 PM Please respond to [EMAIL PROTECTED] RG ** I would expect the filter to fire after Temp Form updates the Main Form. The update of the Main Form causes the filter to fire which, thru a push fields action, is creating another record. I think it would be #2. However, we do not want that filter that fired on modify of the Main Form on the prod server to run the replicate server. On 10/17/06, Chad M Whilding [EMAIL PROTECTED] wrote: Frank So after which action are your expecting the filter to fire? 1. UK dso into your TempForm You will see a MERGE by Distributed Server in your TempForm...AND...you will see a MODIFY by Distributed Server in your TempForm They will see a MODIFY by Distributed Server in their source form 2. Upon MERGE into TempForm, Push Field into MainForm You will see no MERGE at all for MainFormBUT...You will see a CREATE or MODIFY in MainForm **except if the MODIFY in step one occurs as a Phase II action, it could execute close to the RUN Process that you suggest. Hence logging and $OPERATION$ could be report the wrong thing, which is throwing your debugging off kilter. Heck, I have seen aspects of the DSO transaction that occur completely outside of the API, it cannot be detected with workflow...but it the data is saved. 3. Upon Modify into MainForm DSO on to another server. You will never see a MERGE by Distributed Server on MainForm...BUT...you will see a MODIFY by Distributed Server on MainForm 4. Upon Merge on remote server MainForm do nothing. You will see a MERGE by Distributed Server on remote
