When I had the pwd issues, I was going from Sun to Sun servers. If you're working (partially) in one direction, that segment of the passwords are probably good.
In general, the passwords in the conf file need to match up ServerA DSO-User-Password needs to match ServerB DSO-Target-Password. I had to do some manual cut and paste between the two to get them to line up. BMC (via a ticket I had opened) did acknowledge there is an issue with the DSO target passwords being encrypted in the Dev Studio (and apparently at least some versions of the admin tool). The workaround I found was to do the cut and paste. If you know you are communicating between servers (check each direction separately) then you're OK with the passwords. Could be you're on a patch on one of the servers that sets up the pwds OK. Also make sure the 'To server' designation in your mapping record is the same as what is in your conf file (i.e. if you have an IP address listed in the conf file, the to server mapping needs to use the ip address, if you have a servername set up, the mapping needs to use the servername). My guess is that the 'form not found' errors might actually be the fact that it isn't finding the server, or the password isn't matching up. For the direction where some of the fields are going over, you might want to check the custom mappings to make sure the fields are in the right order (especially if the field numbers are different). The mapping of the fields is all numeric - what I can tell from the mapping field the first parameter should be the field ID of the target server/form and the next to last is the field ID from the source. As an example if you want to move the Status field (field 7) on the form from Server A to field 1000000001 on the form on server B the line would look something like \1000000001\102\1\*\1\*\1\7\0\. We use DSO to move info between systems sometimes even into different forms, so it can all be mapped - when it's not like ID's it just gets a bit more difficult to match up; once the connections and mappings are set right it works like a charm. On Fri, 3 Sep 2010 14:54:30 -0400, Peter Westergaard <[email protected]> wrote: > Thanks (pri...@ptd), I really appreciate your post. > > I thought I had replied, but I don't see it in the list archives so maybe > something odd happened to it. Let me re-post my reply here and I hope I'm > not repeating myself. > > ~~~~ > > > The encrypted passwords don't seem to match (even though I have partial > tickets being sent reliably from Server A -> B). Let me paste them here > just to be sure I'm looking correctly. > > Server A: ARS 7.1, SunOS 9 > taken from: /usr/ar/rsd001/conf > DSO-Target-Password: > (ServerB):dkUkuJ2ynqjhy8kjDTuwZEPRvJFohvnOgrDlcSk+A+iX0WnN3jpL2dBe+9tK/zExTa > MfR0UXU4gnXNcShcsIs/+oQx6I1PT8MXSXpmhSRTTPNvf7riT3Og== > DSO-User-Password: > p2uuldJNOZ7c16QNrMGQ+1UrIND+O4XpZomkGKqRzG2zOzW6JJ9dLjrB/M/ndb1XAML8oM2xEbJO > lzyFLvUKgcWgnJJ4Avw9nPjMdqHkqeFOKq1qNkRLRA== > > Server B: ARS 7.5, Windows Server 2003 Enterprise SP2 > taken from: E:\Program Files\BMC Software\ARSystem\Conf > DSO-User-Password: > 4xJShm2ju7SkAtFLn+c9q8m2HXzjUDsJ6CGxaMu6JVMrmOX4uQlexrv/1ichCPKrltoOaEOX8b/L > QXzE6anlZ0e8b074UFHPd+YrgDybozdsYh6dID78+w== > DSO-Target-Password: > (ServerA):W90MOeK9xbwozXQbnIdz+WNqxVLAzBmSnKmh1UOyre13sRPcYN4fJaZHTfjy5kEAro > R9FlDo3EV53iI5gbmfyLkWYeublc/xvlOA5O4WD74Ct+jraGDlNg== > > I do notice that the DSO-Target-Password depends on exactly how the server > name is registered. If I use the IP instead of the server name, I get a > different encryption. (Neither one matches the DSO-User-Password on the > remote server though). So you're suggesting that the DSO-Target-Password > on > Server A should match the DSO-User-Password on Server B? > > For the rest of the questions... I'm using custom mappings, the fields all > exist, are Optional (not Display Only), and have Public change permission > on > them, on both servers. (They specifically have different field IDs because > we're doing a Proof-of-Concept of using DSO between non-congruent forms - > so > far, the concept isn't looking proven). I do intend to create an exact > copy of the source form onto the target server and see if Like IDs helps. > > I've tried setting the Duplicate Records setting to 'Overwrite' and 'Create > New' but changing the setting doesn't affect the outcome (in either > direction). > > I'll post more details when I perform a few more configuration tests. > Also, > I'll see what I can do about getting the encrypted passwords to match. > > _______________________________________________________________________________ > 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"
