z/OS Explorer and File Locking
JoeWinchester 110000DQA0 Comments (2) Visits (3900)
One of the things we're pretty proud of that you can do with the z/OS Explorer is edit files - these can be PDS members, Sequential data sets, or UNIX Files. You navigate to the file you want to open and double click it, or us the pop-up menu option helpfully called open. One of the questions we get asked quite often is what happens if more than one user tries to edit the same file at the same time - is there the possibility that data can be lost ? This blog entry is going to discuss that, so if you're one of the folks who worries about data integrity then read on my friend. If you're not worried, then you possibly should be, so either way you're going to find this blog entry useful.
So, back to the file you opened by navigating to it and opening - If you make a change to the file's contents in the editor area - such as enter new text or delete some characters - we detect this and put an asterisk symbol * next to the editor title bar which is also helpfully showing the name of the file you've opened.
The figure below shows the z/OS Explorer perspective with the pop-up menu and the Open action against the file WINC
You're probably thinking "Joe - that is so obvious you're probably going to boast about the fact what when I press Ctl+S or the cute save icon in the toolbar the z/OS Explorer will save the file replacing the contents of the data set member".
Actually - you're right - I was going to boast about that - there's quite a lot of nifty code to make it all hang together - but I won't dwell on that and say on point for the blog title - what if more than one person tries to edit the file at once.
The scenario we want to avoid is this - fictional user Bob opens the data set member and starts to make some changes. He then goes to lunch, or off for a run, or to take a nap, or whatever else Bob feels like doing. Fictional user Fred then opens the same data set member before Bob has saved his changes. Bob comes back from lunch - continues to make his changes and press save. If the save went ahead then Fred's changes would be lost because Bob didn't start with edit with the same version that Fred saved - it was pre-Fred. Fred is going to be mad at Bob - and we don't want that to happen. This is a picture of Fred mad at Bob - or more likely Bob and Fred both mad at IBM for building software that allowed this to happen.
We need some way to prevent overwrites of files when using the z/OS Explorer.
With ISPF what happened was that Fred was unable to open the file - Bob's TSO session held a lock on the file preventing Fred from getting an edit session. This is what folks sometimes call a pessimistic lock - the pessimistic reference being that it's assumed that a clash will occur and exclusive locks are created in anticipation of this. If Fred comes along to try to edit the file while Bob's ISPF editor was still open, then they'll get told that the file is locked.
This message is basically a "No Entry" dialog - Fred can't edit the file because Bob is editing it. When Bob has exited his ISPF edit session the lock is released.
Life is a bit different however with the z/OS Explorer. If Bob had opened the file using the z/OS Explorer editor we don't lock it in the same way as ISPF. This is for a number of reasons - some technical - but also for usability, and consistency with other PC based applications where opening a file for edit and establishing a lock is a bit - well - pessimistic.
We're optimistic folks in z/OS Explorer land - and to keep in character we instead use optimistic locking. An optimistic lock is one where no lock is created on data - both users have the chance to edit if they wish to - but any clashes are detected and users are informed. This is what the z/OS Explorer does - it allows Fred to open the edit session, however at save time it checks to make sure that the file it's about to overwrite is the same one that it opened. It uses a combination of properties including dates and size which vary depending on the kind of file and what data is available. Having realized that the file on disk isn't the one it opened it knows that someone, or something, else has updated the file.
The user saving the file is given the option of doing a Save - which would overwrite the file on disk with their changes - a Cancel which would not perform a save and revert the editor to their contents - or Details>> which gives a more detailed explanation and probably a better job than I've done in this blog to explain things.
If Fred thinks "oh no - I don't want to lose my changes but I don't want to splat what someone else has changed underneath me" - then they can take the Cancel button - copy their file contents to the clipboard and into somewhere like notepad - close the file without saving it and reopen it to see the most current changes on disk - eyeball things to see what's gone on and add their changes if necessary and proceed as normal.
I hope this makes sense - the function is only available with z/OS Explorer 2.1, which is included with CICS Explorer 5.1.1 and the rest of the z/OS Explorer 2.1 family of products. It's something new we added in direct response to users who were worried about data being lost by multiple users editing the same file, and it's a little different to how ISPF lets you explicitly open files and establish locks.
Let us know if you're happy with this solution - or if you're not happy let us know as well. Either way - we love hearing from you !