Hi, I've been reading this thread with some interest and it's easy to come up with loads of arguments why updating datasets with ISPF is better as it works and has been the way it's been done since before I started in the seventies. Likewise for VM and VSE although I haven't had contact with those for many a year. However, this is usually not the best argument for anything and denies progress.
For me, I guess at the end of the day it doesn't matter on the technicalities so long as I can do the equivalent of the ISPF COMP command with MD/MDD/D/DD. This shows me what changes I am about to make and whether they really are the changes I meant to make This covers others updating the dataset as well as my own typos. Even with ISPF locking on the dataset, sometimes I've made updates to copies of many members in many PDS's days in advance of a really big change so it can happen that someone else has made a change in the intervening time. COMP will detect that so I can add other's changes to mine at the last minute. I'd also need to be able to get back to the earlier versions without actually having a network. When we test we can sometimes find the OSA consoles the only thing working. A quick ISPF edit plus IPL can usually correct such issues. Imagine messing up some of the main system PROCs such as VTAM. I'd need to edit the pack from another system. All is possible with ISPF. Regards, Alan Watthey -----Original Message----- From: David Crayford <dcrayf...@gmail.com> Sent: 31 August 2018 6:45 am Subject: Re: Zowe for systems programmer ? On 31/08/2018 8:21 AM, Andrew Rowley wrote: >> Of course it's possible to prevent simultaneous edits, at least to >> the extent that you claim ISPF does. ISPF doesn't REALLY prevent >> simultaneous edits; it relies on a convention, and you have to hope >> that everyone follows the convention. That's the issue that started >> this thread. In Unix that's traditionally been done with a lock >> directory playing the role of an ENQ, but it can be done. It's just >> that -- no one does, because source control is a better solution. > Everyone has to follow the convention, and on z/OS they largely do. > Many think that new z/OS applications should continue to follow the > convention, regardless of what people on other platforms do. > > Source control is not a better solution, it is a solution to a > slightly different problem. When using source control you STILL need > to make sure that 2 people are not updating the same file at the same > time - it is just the window that is smaller. Using a distributed VCS like Git everybody has their own copy of the source code so there is never a case off two people updating the same file at the same time. Conflicts are detected when pushing changes and that's when merging kicks in. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
