× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, David:

I do not disagree with anything you said.

My main point was and is, whether using SEU, (as in the scenario I described), or using WDSCi or RDi or RDp, two (or more) developers could _sequentially_ make changes to the same source member, in rapid succession, without necessarily being aware that another developer is also working on the same source member, and each one can then potentially over-write some (or all) of the other's changes. *:-o*

The proposed enhancement addresses this issue, and at the same time eliminates the need for the *EXCL member locks.*;-)*

I was not trying to suggest that SEU should no longer issue the *EXCL member lock; that is fundamental to OS/400 data management.

I hope that helps to clarify what I am talking about.

Mark S. Waterbury

> On 7/29/2011 12:18 PM, David Gibbs wrote:
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)


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.