suspected bug in lscm changeset associate command - looking for workaround

I have a couple of lscm commands I use in my migration tools, I operate by firing an scm daemon for the sandbox then firing lscm commands and processing the error codes. For some odd reason the associate command now try's to use a different server to the one I log on to, looks like a bug, or perhaps I am doing something wrong

I have a fairly complicated migration script that is now being used quite extensively. Note that this problem has only just started happening, have used exactly the same command for a number of previous migrations with no issue

C:\PROGRA~2\IBM\TEAMCO~1\scmtools\eclipse\lscm login -r https://prodServerName/ccm -n ThisConnection -u myUser -P myPass
C:\PROGRA~2\IBM\TEAMCO~1\scmtools\eclipse\lscm -u yes changeset associate -r https://prodServerName/ccm -u myUser -P myPass _gQEN4JTwEeWE7K32ubefvA 1257
Password (myUser @ https://DevServerName:9443/ccm/):

Note my original second line was: -

C:\PROGRA~2\IBM\TEAMCO~1\scmtools\eclipse\lscm -u yes changeset associate -r ThisConnection _gQEN4JTwEeWE7K32ubefvA 1257

but I thought I'd try giving the associate all the connection details directly. Note sandbox has been successfully checked into the repository workspace. I am using RTC 5.0.2, no prospect of updating any time soon. Stuck - please help ;-)

Sorry - I need to be more explicit. Why is the changeset associate command trying to use a server I have not referenced in my login command or the changeset associate command, I should not be being asked to provide a password to an RTC instance I have no interest in! - seems very odd - note the server that it is trying to connect to is the last one that was installed if that makes any difference, suspect it might be something to do with using the internal changeset GUID.