Re: Refresh the member lock

On 7/29/2011 10:36 AM, Mark S. Waterbury wrote:

It really does not "make sense" (to me, at least) for WDSCi or RDi /
RDp to attempt to hold an *EXCL member lock on the source member for
the duration of the changes, because the source has been copied "off
platform" (to the PC), and who knows how long it may be before the
developer decides to "push" (copy) the changes back to the OS/400
resident source physical file member.

Mark:

I disagree ... it DOES make sense for RDp to hold the exclusive lock ... for the same reasons that SEU holds a lock when an item is being edited. To prevent two developers from editing the same source member at the same time ... thus preventing one developer from overwriting changes another developer just made.

Remember, every time you press the save button in RDp, the current version of the source in your editor are pushed up to the host. If an exclusive lock was not placed on the member, two developers could constantly be overwriting each others work. The exclusive lock is released when the editor is closed (or is disconnected). This is, at least in my opinion, the safest way of ensuring work is not lost.

IBM i developers don't work in a private sandbox (well, most of the time they don't) ... and changes made on their workstation do effect other developers.

Change control tools can control what developer has the ability to initiate an edit on a specific source member ... but if two developers have authority to the same source member, they both can initiate an edit. I don't know about other SCM tools, but I know that Implementer doesn't track if a source member is currently being edited. The information would be stale a significant amount of the time anyways.

The only time you are doing 100% local editing of a source member is when you are using IBM i Projects in RDp. In this case an exclusive lock is *NOT* placed on the source member being edited.

david
(Who works on Implementer, for MKS [a PTC company], in addition to running midrange.com)