I agree "better" should be the way. Disp=old is not the way.
Either propagate ispf edit enque or offer some sort of EASY extensible option to add something like git to handle member changes. Rob On Fri, Aug 31, 2018, 7:53 AM Jerry Callen <[email protected]> wrote: > Andrew Rowley wrote: > > On 31/08/2018 3:05 AM, Jerry Callen wrote: > > > Everyone has to follow the convention, and on z/OS they LARGELY do. > > (Emphasis added) > > I rest my case. :-) > > > Source control is not a better solution, it is a solution > > to a slightly different problem. > > Fair enough. > > > 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. > > On z/OS you could solve that with DISP=OLD (though that's not practical > in all situations). I would argue that the right solution is to lock > your critical datasets down tightly with SAF and automated procedures > such that direct, uncontrolled updates become a firing offense. > > > When I have worked at larger sites, there might be 5-10 systems > > programmers with changes scheduled for a weekend IPL. When the IPL was > > confirmed, typically there were multiple people who needed to update > > the same members of SYS1.PARMLIB. We did have manual processes to > > coordinate updates (typically they were all funneled through a > > designated person) but without that offline manual process it would be > > likely that there were multiple people trying to update the same file > > at the same time. > > This is precisely the situation where you want source control, with code > review and a single controlled update. As others have noted, the "pull > request" idiom used by systems like GitHub and BitBucket are ideally > suited to this situation. Everyone puts their needed changes on a branch, > the branches are merged, humans review the result, and ONE person or > automated process deploys the change. > > > When I heard about git for z/OS my first question was can it handle > > z/OS datasets like SYS1.PARMLIB, answer: no. > > Sure it can, just not in the obvious manner. You have to be willing > to stop treating the PDS as the "repository of record" and instead > treat it as a deployed resource. Your git server becomes the canonical > reference, and you update the PDS (via an automated process) when > changes are merged into the "master" branch by that server. > > > We are where we are - it is important that existing functions continue > > to work as expected. So, please, make Zowe edit compatible with ISPF > > edit serialization. > > I think the proposals by Matt Hogstrom and Kirk Wolf solve the same > problem in a better way. I don't think Zowe should perpetuate a > practice that, IMO, is actually broken. > > > Do other platforms really use source control for everything? How many > > unix systems have you encountered where /etc is under source control, > > people have their own copies and merge changes into the real /etc? Any? > > Not to air dirty laundry, but some places I've worked have done this, > others not. :-/ In any case, it's not unheard of, and becoming the norm. > > What I keep coming back to is this: we now have better tools for > system management. Why WOULDN'T we use them? It won't happen > overnight, but this is surely the direction we should be heading. > > -- Jerry > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
