Sorry I have not been able to comment on each post - I get a lot of emails these days. I would like to make a point (and please understand I am trying to give a different view to cause people to realize the purpose behind Zowe). If you know what ISPF is and are happy with it ....you may not be the target market for Zowe. Zowe is primarily targeted for the "next gen" sysprog who does not have 30+ years of learning the the nuances of z/OS and ISPF. We debate what next gen really means - its the between skill level that is learning z/OS but not 100% skilled in all aspects of z/OW. New gen likely knows browsers, REST APIs, and command lines. Zowe includes 3270 emulation to bridge the ISPF world and web apps for z/OS. This is a journey and we are just getting started. Yes we need to worry about concurrent updates of datasets. Please consider joining the zowe project and contribute what the future will be. The next gen needs the expertise that uses this listserv.
Bruce Armstrong IBM System Z Offering Manager- zowe.org 4205 S MIAMI BLVD, DURHAM NC 27703-9141 Email: armst...@us.ibm.com Tel: 919-254-8773 Cell: 919-931-3132 From: "Alan(GMAIL)Watthey" <a.watt...@gmail.com> To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/02/2018 06:05 AM Subject: Re: Zowe for systems programmer ? Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
