I'm working on getting a multi-platform build going which is using RTC
to drive Build Forge builds through the RTC-BF integration. The Build
Forge project in turn executes build steps in parallel across build machines
for various OS'es (Windows, Linux, Solaris, AIX, zLinux, ...) some of
which involve the scm command line. I understand the scm command
line as shipped doesn't support platforms other than Windows and Linux,
but following this tech note, I've got it mostly working:

http://www-01.ibm.com/support/docview.wss?uid=swg21417308

Using scm.sh in place of scm (linux binary) seems to work for the most
part, but startup is slow due to launching a new jvm for every scm
invocation and on Solaris, due to not having an IBM JDK, the following
error is thrown each time scm.sh is invoked:

The IBM Class Sharing Adaptor will not work in this configuration.
You are not running on J9

The lscm script is supposed to address both these issues by launching
a single jvm to act as a server/daemon for subsequent scm command
line invocations and it seems to work, except... Once I run lscm on
one machine, it won't work from any of the others in my build farm.
Once lscm is running on one system, attempts to run in on other
systems results in the following java stack trace:

$ /opt/RTC-2.0.0.2/scmtools/eclipse/lscm -v
java.net.ConnectException: A remote host refused an attempted connect operation.
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:391)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:252)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:239)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:389)
at java.net.Socket.connect(Socket.java:556)
at java.net.Socket.connect(Socket.java:504)
at java.net.Socket.<init>(Socket.java:412)
at java.net.Socket.<init>(Socket.java:226)
at com.ibm.team.filesystem.cli.minimal.client.HttpSwitchingClient.negotiate(HttpSwitchingClient.java:88)
at com.ibm.team.filesystem.cli.minimal.client.FrontEndClient.run(FrontEndClient.java:299)
at com.ibm.team.filesystem.cli.minimal.client.FrontEndClient.run(FrontEndClient.java:125)
at com.ibm.team.filesystem.cli.minimal.client.FrontEndClient.main(FrontEndClient.java:236)

After some investigation, I found what I think is the smoking gun but
don't know what to do about it. Our *nix accounts have a common
nfs auto-mounted home directory and in it, I found that lscm seems
to create a subdirectory in ~/.jazz-scm/daemons which apparently holds
state information about the scm daemon process. The existence of
this information seems to confuse attempts to launch lscm on other
systems which share this home directory.

Is there some way to direct lscm to store this state information either
in a local directory (/tmp?) or use a per-machine sub-directory in
~/.jazz-scm/daemons so we can have multiple lscm daemon
processes active for a single user (on different machines) at the
same time?

I noticed from some RTC work items, there seems to be a plan to
support the scm command line on more platforms eventually -- is
there any ETA on that?