Please check if you have configured the target server name, target server port configured correctly on the source server side. If this is not present in configuration it is assumed that port for source server and target server are same in DSO. Also check if the target server is reachable from source server. Even if target server is not reachable or if there is some connectivity issue DSO gives error that it is not able to access the target form because that is the first time it is trying to connect to the target server.
Thanks, Rajendra On Fri, Jan 25, 2013 at 3:58 PM, Dave Barber <[email protected]> wrote: > ** 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. Grrrr, 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> *Newsgroups:* public.remedy.arsystem.general >>> *To:* [email protected] >>> *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: >>> [email protected]] *On Behalf Of *Dave Barber >>> *Sent:* Monday, January 21, 2013 7:10 AM >>> *To:* [email protected] >>> *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 Jan 21 2013 14:40:40.9342) >>> >>> I've been able to issue DSO transactions the other way round, from 7.5 >>> or 7.0.01 to 7.6.04, but totally unable to send the other way. Is there an >>> issue using DSO transactions from a newer version to an older version? >>> >>> All servers are running on Solaris/Oracle, DSO is licensed on all >>> servers, and all servers can issue DSO transactions to themselves (ie. the >>> most basic DSO transaction works without issue). >>> >>> Regards >>> >>> Dave Barber >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ **** >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
