The 'lscm diff' to that changeset from which the file was loaded is what I'm searching for.  But how do I know which changeset that was?  Does 'lscm load' store this information like in the .jazz5 sub directory?  And if so, how do I access this information?

Yes, I know that my sandbox is out of sync.  That is why I need to load those changes done somewhere else.  But I don't want to loose my changes.  So I first need to find out what I changed, then to 'lscm load' the changes that were done elsewhere and then apply my changes in order to have both: my changes and the chnages done somewhere else.

The metadata information in not exposed in the clients.

I want to merge my changes with the Unix command 'patch'.  So I need to know the changes I did.  If I would use the difference between the local file and the file in RTC as it is at the current moment, I would reverse the changes that others did.  Here is an example what would happen:
- I load the file and add, say, line 10
- Someone else loads the file and adds, say, line 20 and delivers this change
- I do a 'diff' between my local file and the current version in RTC.  The difference is: line 10 added, line 20 removed (because my local file doesn't yet have line 20)
- I load the current file and 'patch' the difference:  It will add line 10 and remove line 20.

As a result I reversed the change that someone else did. That is not what I want to do.  Instead I want to keep all changes already delivered by others and put my changes on top.

What I want to achieve is what the decades old library system cvs does with a simple 'cvs update'.  Not only that RTC isn't offering that out of the box.  I even can't write a script to do that, because I can't find out what the file looked like when it was loaded.

I read the description of work item 344701.  If I understood it right I'm not sure if I want to support that work item.  It seems to suggest to block parallel check-ins to the work space.  But that makes using the library more complicated not better.  I'm more interested in how to deal with parallel releases to the library.
As I already wrote I'm searching for the functionality of 'cvs update' of the decades old library 'cvs'.  If I change, say, line 10 and someone else changes, say, line 20 in the same file and delivers it, that is not a conflict, at least not a conflict that needs the attention of the user.  That can be merged by tools.  Only if I change line 10 and someone else changes line 11, that needs user attention and is a conflict.
Other than blocking check-ins as suggested in work item 344701 I rather think that in the sandbox the information is needed from what version of the file (from what change set) it was loaded into the sandbox.  With this information the merging by tools can be implemented.  Because then one can find out what actually the own changes are and apply them to the newest version of the file.

What part of the description of 344701 led you to believe that it would block parallel check-ins?  To the contrary, the change set that would be created is what captures the parallel check-ins.

But more importantly, what is the use case you are trying to implement?   Parallel development is completely automated with RTC (branching, merging, conflict detection, etc.).   There is no need to worry about the low level operations being discussed in this thread unless you are doing something unusual, like working on the same workspace in two different sandboxes (which there is no reason to do, but the tool doesn't prevent you from doing it, so if you do it by mistake, you would want the enhancement described in work item 344701).   In particular, is your use case maintaining two releases of a library within RTC, one release in RTC and another in a different SCM system, or something else?

This part of the description:
'In addition, it would be desirable to give a warning if you are de-synchronizing a workspace component from a sandbox that has unresolved changes to that component.  ...  Any attempt to modify that workspace component from a client that is not connected to that sandbox would produce a warning (or error), indicating the local pathname of the sandbox that contains those unresolved changes.'

If I get an error, that means, I'll not be able to do this?  And 'de-synchronizing a workspace' with ' unresolved changes' sounded to me like the situation I was thinking of.

No, I don't want to maintain two releases of a library or with a different SCM system.

Here is the use case:
I 'lscm load' a file because I'm working to implement a new feature. So I start and do some changes to it in the sandbox 1.
Now a defect comes in which is more urgent than the new feature. Both, the new feature and the urgent defect to be fixed, are on the same stream
So I 'lscm load' the unchanged file again from the same stream into a new sandbox 2.
I fix the urgent defect in sandbox 2, check it in, deliver it to the stream.
Now I go back to sandbox 1 to continue working on the new feature.  The version of the file in sandbox 1 has half of the implementation of the new feature, but it is missing the urgent fix.  So I want to merge now or at the end of implementing the new feature the two changes: The urgent fix with the new feature.
I just check-in and deliver the new feature?  No, this overwrites the urgent fix.
I 'lscm load' the urgent fix?  No, this overwrites my new feature changes in sandbox 1.

And, yes, I tried to do this through one RTC server workspace.

I tried to do this through one RTC server workspace as I didn't see the need for using more than one workspace.  To me that seemed to be cluttering the server with lots of workspaces.  And there are commands 'lscm deregister' and 'lscm register' that seemed to be made for exactly this purpose to bind the current sandbox to the RTC server workspace.

But meanwhile I'm intending to do this via an own workspace for each sandbox.  As the own workspace is unchanged, I can find out the changes between sandbox and own workspace.  Then remove the local file, 'lscm load' the original file in order to be in sync (accept needs this).  'lscm accept' to get the new version into the workspace.  Remove the local file again. 'lscm load' the new version.  And finally apply the changes that were originally done in sandbox 1 and were saved at the beginning with the Unix command 'patch'.