Re: Refresh the member lock

*THE PROBLEM*
With only 5250-based ("green-screen") developers using SEU, there is NOTHING to _prevent_ two developers from making changes to the same source member, serially (one right after the other). For example:

Joe opens source member "AAAAAAAAAA" and makes some changes, saves the changes and exits SEU.
Next, Bob opens the same member "AAAAAAAAAA" in the same source file, makes his changes, saves the changes and exits SEU.
(Potentially, Bob might have altered or deleted some of Joe's recent changes.)

SEU, using only member locks, can do absolutely NOTHING to prevent this scenario. (That is what change management tools are for.) The _only_ thing member locks do is to prevent two or more users from opening the same member for "edit" _at the same time_.


Now, add to the mix a PC-based development tool, such as WDSCi or RDi / RDp, which are all based on Eclipse (or any other PC-based tools).

The Eclipse platform architecture _always_ copies any artifacts you want to work on to the PC platform and you work on a _local copy_ (on your PC hard drive). This is fundamental to the design of Eclipse since "day one." So there is little that WDSCi and RDi / RDp can do to change this underlying architecture.

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.

Of course, any decent change management product or tool, used properly, should be capable of preventing the problem scenarios described above. However, many IBM i shops have elected not to invest in such tools. So, then, what to do?


*THE (PROPOSED) SOLUTION*
What is needed is a way to "mark" a source member as "checked out" to a given user, similar to the way the OS/400 IFS CHKOUT and CHKIN commands work, such that only the user who "checked out" the source member can update it. Such a feature enhancement would need to be implemented within OS/400 data management, and is not something that can easily be "grafted on" by external tools such as SEU or WDSCi or RDi or RDp. (There should also be a way to "remove" this CHKOUT lock, for example, in the event the person who checked-out a member has gone on vacation, or is "out sick" etc., and someone else now needs to update that same source member.)

The proposed enhancement would provide the necessary infrastructure to allow tools like SEU, and WDSCi, RDi or RDp (or any other tools) to use the new capability to implement a reliable "protocol" to prevent users from overlaying each others' changes. Change management tools vendors would be compelled (or at least encouraged) to take advantage of this new infrastructure, to ensure that their software cooperates with and does not circumvent the new "protocol."

In this way, tools like SEU, WDSCi, RDi / RDp etc. can permit developers to "safely" make changes without interfering with one another.


*SUMMARY*
There is _no_ quick or easy "fix" for the problems described above, because the problem is _fundamental_ to the underlying architecture and infrastructure that is in place.

I would like to hear what others think about this.

Mark S. Waterbury