Re: Zowe for systems programmer ?

[scott Ford]

Jerry,

I am with you too. I will relate a story I started out as a VMer early ‘80s
and was taught to know the commands being issued versus using an exec or
clist to accomplish the same task. I am not much a fan of the PC slam dunk
artists who feel Java is the answer to everything. We use GIT also but it
has its own issues related to people’s expertise using it. If the folks
using it are experienced and careful and responsible , great , all for it.
We had to write a CI process because new deal with a lot of z/OS’s , so the
process was written in respec and is triggered off a GIT PR. This is also
Working well. I am all for easy as long as people hare careful.

Scott
An older t-Rex

On Wed, Sep 5, 2018 at 9:15 AM Sean Gleann  wrote:

> Jerry Callen jcal...@narsil.org via
> <https://support.google.com/mail/answer/1311182?hl=en-GB> ua.edu
> 13:38 (34 minutes ago)
> to IBM-MAIN
> On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:
>
> > 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.
>
> Or - maybe you are the target market, but don't yet know it.
>
> I *DO* have many years of experience with z/OS -- I learned to program in
> PL/I and assembler on OS/MVT in the early 1970s and was a systems
> programmer through the mid 1980s. I've worked on more modern z/OS systems
> for the past 4 years.
>
> I also have many years of experience with both Unix and Windows systems.
> It's that experience that makes me so excited about the potential of Zowe.
> It's providing a framework for bringing highly-evolved system management
> tools of all kinds to z/OS. This will ultimately make the systems
> programmer's job easier. That's not a bad thing.
>
> "...it's time for established z/OS programmers to start adopting tools and
> practices from other platforms, too."
>
>
> Well said, Jerry!
> ...and I'm glad I'm retiring soon... :)
>
> On Wed, 5 Sep 2018 at 14:10, Seymour J Metz  wrote:
>
> > I agree that programmers should adopt tools from other platforms, but
> only
> > when they are appropriate tools for the job at hand, not simply because
> > they are in style. A good hammer is an essential tool, but it's a
> terrible
> > screwdriver.
> >
> > When it comes to configuration control and serialization tools, the
> > infrastructure had better match the tool set or chaos will result. I'd
> > advise looking at things on a project by project basis and concentrate on
> > selecting appropriate tools for new projects rather than making
> disruptive
> > changes to old projects.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Jerry Callen 
> > Sent: Wednesday, September 5, 2018 8:37 AM
> > To: IBM-MAIN@listserv.ua.edu
> > Subject: Re: Zowe for systems programmer ?
> >
> > On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong 
> wrote:
> >
> > > 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.
> >
> > Or - maybe you are the target market, but don't yet know it.
> >
> > I *DO* have many years of experience with z/OS -- I learned to program in
> > PL/I and assembler on OS/MVT in the early 1970s and was a systems
> > programmer through the mid 1980s. I've worked on more modern z/OS systems
> > for the past 4 years.
> >
> > I also have many years of experience with both Unix and Windows systems.
> > It's that experience that makes me so excited about the potential of
> Zowe.
> > It's providing a framework for bringing highly-evolved system management
> > tools of all kinds to z/OS. This will ultimately make the systems
> > programmer's job easier. That's not a bad thing.
> >
> > It's not just that the "next gen" programmers need to learn z/OS -- it's
> > time for established z/OS programmers to start adopting tools and
> practices
> > from other platforms, too.
> >
> > -- Jerry
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the messag

Re: Zowe for systems programmer ?

[Sean Gleann]

Jerry Callen jcal...@narsil.org via
<https://support.google.com/mail/answer/1311182?hl=en-GB> ua.edu
13:38 (34 minutes ago)
to IBM-MAIN
On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> 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.

Or - maybe you are the target market, but don't yet know it.

I *DO* have many years of experience with z/OS -- I learned to program in
PL/I and assembler on OS/MVT in the early 1970s and was a systems
programmer through the mid 1980s. I've worked on more modern z/OS systems
for the past 4 years.

I also have many years of experience with both Unix and Windows systems.
It's that experience that makes me so excited about the potential of Zowe.
It's providing a framework for bringing highly-evolved system management
tools of all kinds to z/OS. This will ultimately make the systems
programmer's job easier. That's not a bad thing.

"...it's time for established z/OS programmers to start adopting tools and
practices from other platforms, too."


Well said, Jerry!
...and I'm glad I'm retiring soon... :)

On Wed, 5 Sep 2018 at 14:10, Seymour J Metz  wrote:

> I agree that programmers should adopt tools from other platforms, but only
> when they are appropriate tools for the job at hand, not simply because
> they are in style. A good hammer is an essential tool, but it's a terrible
> screwdriver.
>
> When it comes to configuration control and serialization tools, the
> infrastructure had better match the tool set or chaos will result. I'd
> advise looking at things on a project by project basis and concentrate on
> selecting appropriate tools for new projects rather than making disruptive
> changes to old projects.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jerry Callen 
> Sent: Wednesday, September 5, 2018 8:37 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Zowe for systems programmer ?
>
> On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:
>
> > 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.
>
> Or - maybe you are the target market, but don't yet know it.
>
> I *DO* have many years of experience with z/OS -- I learned to program in
> PL/I and assembler on OS/MVT in the early 1970s and was a systems
> programmer through the mid 1980s. I've worked on more modern z/OS systems
> for the past 4 years.
>
> I also have many years of experience with both Unix and Windows systems.
> It's that experience that makes me so excited about the potential of Zowe.
> It's providing a framework for bringing highly-evolved system management
> tools of all kinds to z/OS. This will ultimately make the systems
> programmer's job easier. That's not a bad thing.
>
> It's not just that the "next gen" programmers need to learn z/OS -- it's
> time for established z/OS programmers to start adopting tools and practices
> from other platforms, too.
>
> -- Jerry
>
> --
> 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

Re: Zowe for systems programmer ?

[Seymour J Metz]

I agree that programmers should adopt tools from other platforms, but only when 
they are appropriate tools for the job at hand, not simply because they are in 
style. A good hammer is an essential tool, but it's a terrible screwdriver.

When it comes to configuration control and serialization tools, the 
infrastructure had better match the tool set or chaos will result. I'd advise 
looking at things on a project by project basis and concentrate on selecting 
appropriate tools for new projects rather than making disruptive changes to old 
projects.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jerry Callen 
Sent: Wednesday, September 5, 2018 8:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Zowe for systems programmer ?

On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> 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.

Or - maybe you are the target market, but don't yet know it.

I *DO* have many years of experience with z/OS -- I learned to program in PL/I 
and assembler on OS/MVT in the early 1970s and was a systems programmer through 
the mid 1980s. I've worked on more modern z/OS systems for the past 4 years.

I also have many years of experience with both Unix and Windows systems. It's 
that experience that makes me so excited about the potential of Zowe. It's 
providing a framework for bringing highly-evolved system management tools of 
all kinds to z/OS. This will ultimately make the systems programmer's job 
easier. That's not a bad thing.

It's not just that the "next gen" programmers need to learn z/OS -- it's time 
for established z/OS programmers to start adopting tools and practices from 
other platforms, too.

-- Jerry

--
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

Re: Zowe for systems programmer ?

[Jerry Callen]

On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> 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.

Or - maybe you are the target market, but don't yet know it.

I *DO* have many years of experience with z/OS -- I learned to program in PL/I 
and assembler on OS/MVT in the early 1970s and was a systems programmer through 
the mid 1980s. I've worked on more modern z/OS systems for the past 4 years.

I also have many years of experience with both Unix and Windows systems. It's 
that experience that makes me so excited about the potential of Zowe. It's 
providing a framework for bringing highly-evolved system management tools of 
all kinds to z/OS. This will ultimately make the systems programmer's job 
easier. That's not a bad thing.

It's not just that the "next gen" programmers need to learn z/OS -- it's time 
for established z/OS programmers to start adopting tools and practices from 
other platforms, too.

-- Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Seymour J Metz]

The ENQ for program management is SYSIEWL not SPFEDIT, but it's similar logic.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Andrew Rowley 
Sent: Wednesday, September 5, 2018 12:16 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Zowe for systems programmer ?

On 5/09/2018 2:03 PM, Gord Tomlin wrote:
> Unlike SYSDSN, SPFEDIT is not taken care of by the system. There are
> plenty of IBM and non-IBM programs that do not follow the SPFEDIT ENQ
> conventions, and I don't think any product other than ISPF itself
> would be APARable for failing to do so. Since it is not universal, it
> does not carry the same level of reliability. It's like a gentlemen's
> agreement in a world where not all are gentlemen.
All serialization mechanisms are gentlemen's agreements. The system
doesn't really take care of SYSDSN - you are free to update a dataset
with DISP=SHR if that is what you specify.

Which products request their own ENQs and update PDS members without
SPFEDIT or exclusive SYSDSN? I seem to recall that other components do
use SPFEDIT for member serialization - the linkage editor/binder comes
to mind.

--
Andrew Rowley
Black Hill Software

--
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

Re: Zowe for systems programmer ?

[Andrew Rowley]

On 5/09/2018 2:03 PM, Gord Tomlin wrote:
Unlike SYSDSN, SPFEDIT is not taken care of by the system. There are 
plenty of IBM and non-IBM programs that do not follow the SPFEDIT ENQ 
conventions, and I don't think any product other than ISPF itself 
would be APARable for failing to do so. Since it is not universal, it 
does not carry the same level of reliability. It's like a gentlemen's 
agreement in a world where not all are gentlemen.
All serialization mechanisms are gentlemen's agreements. The system 
doesn't really take care of SYSDSN - you are free to update a dataset 
with DISP=SHR if that is what you specify.


Which products request their own ENQs and update PDS members without 
SPFEDIT or exclusive SYSDSN? I seem to recall that other components do 
use SPFEDIT for member serialization - the linkage editor/binder comes 
to mind.


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Gord Tomlin]

On 2018-09-04 21:01, Andrew Rowley wrote:

ISPF also does a SYSDSN ENQ on the dataset.

IEBCOPY, IEBGENER etc. do not do ENQs - you write the JCL to do the ENQ. 
If you are updating a dataset you are supposed to use DISP=OLD, which 
will protect you against concurrent updates, including ISPF edit. Many 
use DISP=SHR because it is more convenient, but then it is your decision 
to give up the protection of DISP=OLD - whether it is from ISPF, or 
other instances of IEBCOPY, IEBGENER etc.


There are many examples where updates using DISP=SHR can cause problems 
including data loss. If the customer chooses to do that they own the 
problem.


Is there any IBM software that handles its own ENQs (as opposed to 
relying on what the customer codes in JCL) that is not compatible with 
ISPF and it's use of SYSDSN and SPFEDIT? My gut feeling is that if there 
was it would be APARable, but I don't know.


Absolutely, IEBCOPY, IEBGENER, et al, do not do their own SYSDSN ENQs. 
These are provided by the system based on what is coded in JCL or 
dynamic allocation, and that is what makes them reliable when used 
properly. Like you say, using DISP=SHR when it is not appropriate to do 
so is a great way to lose data.


Unlike SYSDSN, SPFEDIT is not taken care of by the system. There are 
plenty of IBM and non-IBM programs that do not follow the SPFEDIT ENQ 
conventions, and I don't think any product other than ISPF itself would 
be APARable for failing to do so. Since it is not universal, it does not 
carry the same level of reliability. It's like a gentlemen's agreement 
in a world where not all are gentlemen.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Rob Schramm]

There is a bank I know that puts a mod on iebcopy to make it use the
spfedit enq.  Works well..

Makes it so Disp=shr works for iebcopy.

IBM solution.. pdse which is a good and weird thing with enques

Rob Schramm

On Tue, Sep 4, 2018, 9:01 PM Andrew Rowley 
wrote:

> On 5/09/2018 5:31 AM, Gord Tomlin wrote:
> > This thread started off with a discussion regarding the use of
> > ISPF-style SPFEDIT ENQs for serialization. While those ENQs protect
> > against simultaneous updates by multiple ISPF users, they do not
> > protect against updates by other non-ISPF programs, such as IEBCOPY,
> > IEBGENER, or many others.
> >
> > Using SPFEDIT ENQs in Zowe would have the same strengths and
> > weaknesses as using those ENQs in ISPF.
> >
> > An ENQ convention can only truly be relied upon if all users of the
> > system follow that convention. SPFEDIT falls short in that.
>
> ISPF also does a SYSDSN ENQ on the dataset.
>
> IEBCOPY, IEBGENER etc. do not do ENQs - you write the JCL to do the ENQ.
> If you are updating a dataset you are supposed to use DISP=OLD, which
> will protect you against concurrent updates, including ISPF edit. Many
> use DISP=SHR because it is more convenient, but then it is your decision
> to give up the protection of DISP=OLD - whether it is from ISPF, or
> other instances of IEBCOPY, IEBGENER etc.
>
> There are many examples where updates using DISP=SHR can cause problems
> including data loss. If the customer chooses to do that they own the
> problem.
>
> Is there any IBM software that handles its own ENQs (as opposed to
> relying on what the customer codes in JCL) that is not compatible with
> ISPF and it's use of SYSDSN and SPFEDIT? My gut feeling is that if there
> was it would be APARable, but I don't know.
>
> --
> Andrew Rowley
> Black Hill Software
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Andrew Rowley]

On 5/09/2018 5:31 AM, Gord Tomlin wrote:
This thread started off with a discussion regarding the use of 
ISPF-style SPFEDIT ENQs for serialization. While those ENQs protect 
against simultaneous updates by multiple ISPF users, they do not 
protect against updates by other non-ISPF programs, such as IEBCOPY, 
IEBGENER, or many others.


Using SPFEDIT ENQs in Zowe would have the same strengths and 
weaknesses as using those ENQs in ISPF.


An ENQ convention can only truly be relied upon if all users of the 
system follow that convention. SPFEDIT falls short in that.


ISPF also does a SYSDSN ENQ on the dataset.

IEBCOPY, IEBGENER etc. do not do ENQs - you write the JCL to do the ENQ. 
If you are updating a dataset you are supposed to use DISP=OLD, which 
will protect you against concurrent updates, including ISPF edit. Many 
use DISP=SHR because it is more convenient, but then it is your decision 
to give up the protection of DISP=OLD - whether it is from ISPF, or 
other instances of IEBCOPY, IEBGENER etc.


There are many examples where updates using DISP=SHR can cause problems 
including data loss. If the customer chooses to do that they own the 
problem.


Is there any IBM software that handles its own ENQs (as opposed to 
relying on what the customer codes in JCL) that is not compatible with 
ISPF and it's use of SYSDSN and SPFEDIT? My gut feeling is that if there 
was it would be APARable, but I don't know.


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Matt Hogstrom]

Yes.  Sequence matters

Matt Hogstrom
+1 (919) 656-0564

> On Sep 4, 2018, at 18:18, Seymour J Metz  wrote:
> 
> I hope that you mean that it will first successfully do the ENQ, *then* check 
> whether the member has changed and if not do the update.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Matt Hogstrom 
> Sent: Tuesday, September 4, 2018 3:45 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Zowe for systems programmer ?
> 
> This is a good discussion.  Our challenge is how to move forward that doesn’t 
> break the old ways of doing things but actually making forward progress.  
> Currently Zowe will read the data, allow it to be edited and then when 
> updating will check to see if the file is in unchanged.  If so, grab an ENQ 
> and make the update.  The editor and REST APIs are undergoing design now.  
> Give me a few days and I’ll provide a few scenarios and get your feedback on 
> what does and doesn’t work.
> 
> Matt Hogstrom
> m...@hogstrom.org
> +1-919-656-0564
> PGP Key: 0x90ECB270
> Facebook 
> <https://secure-web.cisco.com/1wwj_4l50d47CREhDoXSU8-FEAJyxD4VH8eHa3GENk0V0M_oZ6dXZ4trJan6s0CK-mazgPBVYxjU59H1Ty7ojmZuJxwHaSi_MEu5jt46bB9vD-xbbe0m8QM1aioLcSAHLpeO8jawFXZeMUk0xpCaJK1XpK7MJsDXaLVImikNlCkvY0z5_LZRbu8s5UO1fELc9_jHxq1S200i-shQjkMngwqQJ57FSwezHAjjIBH1TX2bPQLa7TBXtyAj9DtZOMAE69jB7NL529ZwVaawPTCi1mJAzoPYG1S8WLYtgZjHvZ6XBB4owCAHGoYhM320rIENqjRWnkrVxTzCDK_qM5Ix6mscef5Yj5th5KicaBgmuKClE9bVkBbWgnMisz_OpQYza/https%3A%2F%2Ffacebook.com%2Fmatt.hogstrom>
>   LinkedIn 
> <https://secure-web.cisco.com/19NczfTmcjt-r6CHjnj5vrZ3kLsSDR2Xxf5lIOSfiDOyohA8rgh_qnqXt4EtgS3iWxg1Pqw_xPWtsTgrpCwBzhsWTtEKu1wQOUIuqPpXtUNX8YWJbCy07q-cid74wN8ECCxIusiUQzguIUSUGZYQj2rU2rMCNbbxW2uUIJxe_3RegeIYxnf3HshGFlNo-w_LadEITRQCl8y6iRFvNjXR8KqHRXL2cQoTh3TQtwsgg8F5NJ6eMSgiqc9ce5_L_vZoPWHHMPGzkvdHgZbmRNTwylZRIkIJke5FYBGpzy68qY3Ni-LI0vGXAmTSjGL24U-qveUgZ-yD9f9t8fm5nKnREWd5XamKSmygjXKEKCOYbjXdBQvqWhLRbCYV6uHGEqA7R/https%3A%2F%2Flinkedin%2Fin%2Fmhogstrom>
>   Twitter 
> <https://secure-web.cisco.com/1ApjXAJeQhVaDNbaNgVvGAGCplOhKc17sac2xxXganIKEOYUyS2Gfddt_Y1CBEaDvcc_TCc8j5EpJwUS2bUyPdL5JU7RnPQjXi8Uuw1Q_mJhBxBnzKhk002b0dbmORHmN3bgFtBZUTN8XRrkvJe4kmgy7ds3tpZiTztmvvAFdO_ZbJRTecj4Q-dEpbSna3W2g9e783iyryn77RiTyX8p45iQt7BEh05SmabDRwEl7Y_u-NJXbVgqwMHyjKlbmJqEt9tJ7jW_32Og3xtfweuP4W_4aGEDOw0pvMCA6FPEutJW5UvrZ523etmFSOVb6foShxxdA_wVLpunKux-L9mPbcjm565H-MPEqSeReVl6bQAbB9TaPp9PfcHNQfggrhO32BcHRWCtnKJONcCdWxNhbLQ/https%3A%2F%2Ftwitter.com%2Fhogstrom>
> 
> “It may be cognitive, but, it ain’t intuitive."
> — Hogstrom
> 
>> On Sep 4, 2018, at 3:31 PM, Gord Tomlin  
>> wrote:
>> 
>> On 2018-09-04 11:08, Tom Marchant wrote:
>>>> On Fri, 31 Aug 2018 06:52:57 -0500, Jerry Callen  
>>>> wrote:
>>>> Andrew Rowley wrote:
>>>> 
>>>>> 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).
>>> Not if you have some other process, such as with Zowe, that does not use
>>> the ENQ that the system uses to prevent simultaneous updates.
>> 
>> This thread started off with a discussion regarding the use of ISPF-style 
>> SPFEDIT ENQs for serialization. While those ENQs protect against 
>> simultaneous updates by multiple ISPF users, they do not protect against 
>> updates by other non-ISPF programs, such as IEBCOPY, IEBGENER, or many 
>> others.
>> 
>> Using SPFEDIT ENQs in Zowe would have the same strengths and weaknesses as 
>> using those ENQs in ISPF.
>> 
>> An ENQ convention can only truly be relied upon if all users of the system 
>> follow that convention. SPFEDIT falls short in that.
>> 
>> --
>> 
>> Regards, Gord Tomlin
>> Action Software International
>> (a division of Mazda Computer Corporation)
>> Tel: (905) 470-7113, Fax: (905) 470-6507
>> Support: 
>> https://secure-web.cisco.com/1rOxo-_UJrGBqk1TwClT6uPWnoP0_jYxLCWLV6qn2nrfr63wtxdLa9DD9Xu4t3QTsCw301xZKiQ_ObYuJGgccKYuq2Nfr7iSs7l-ElEC8RwajnBVHvNjDYThrqU9I6fCQwd06AX_cQmXkOzFBwmnqxx3i8iK3UFuXbxZAOpZgrQItB1GOjMqvPdB4653N4njcX439yaaL8_OT6sC73SAsCQuW9A7A-FwNCU7R-lfmGo6CpMdeQ2P36gmxuTkylPZRhpNZTVRJgGSlrPzEzs4j2xSVD5uBlWboT1HPnfYwOowXQA4CJAfipk7pceydgkrQ9RsOaIQL_6MkHc8zMG8ZMBrWIXZUowJO5bDuLWICiaFFwBbKLnb4LYm7emUQcNcD/https%3A%2F%2Factionsoftware.com%2Fsupport%2F
>> 
>> --
>> For

Re: Zowe for systems programmer ?

[Seymour J Metz]

True, but there are other utilities that support the ISPF convention. At least 
using the convention lets you play well with them.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Gord Tomlin 
Sent: Tuesday, September 4, 2018 3:31 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Zowe for systems programmer ?

On 2018-09-04 11:08, Tom Marchant wrote:
> On Fri, 31 Aug 2018 06:52:57 -0500, Jerry Callen  wrote:
>
>> Andrew Rowley wrote:
>>
>>> 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).
> Not if you have some other process, such as with Zowe, that does not use
> the ENQ that the system uses to prevent simultaneous updates.
>

This thread started off with a discussion regarding the use of
ISPF-style SPFEDIT ENQs for serialization. While those ENQs protect
against simultaneous updates by multiple ISPF users, they do not protect
against updates by other non-ISPF programs, such as IEBCOPY, IEBGENER,
or many others.

Using SPFEDIT ENQs in Zowe would have the same strengths and weaknesses
as using those ENQs in ISPF.

An ENQ convention can only truly be relied upon if all users of the
system follow that convention. SPFEDIT falls short in that.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: 
https://secure-web.cisco.com/1wk_fK40tJnD49IlqpTSbT2kUgOFyxuko28zeIHXYway4_mk797YUHZxS9sqYkWiMwg9Lhc61tC4vhYcKlJoERKldbJMTmPbkLh2D2CleyI6hPZu7evyo8rnODdq6NQCWkq4KObJICHhCNUJVCq6zCSFri-lhpnnRTJuhY6ivXe6gQjWmsc8SCfjrtuIZUrzzjVYvByB5uGQOrLt5srKdSgaXYLVs_P9loOB48h3ATMrr7UDZ7TZcyJSbY92JZYvQRAVuI_XvD2JnyAv-aCtTMTSQYoHtv48Jj7PI4kKyOAAnhJOWNgq-SROIgHxP5t0MWvAMfiBrkYT29nwfXKhbwHTTfCOxNvBearweo11APh921e1XScVcUt2Vs6tg-5OVi5JJji0YB5s1tByxgB7xde_B0a84yEFratVJXlVGiwAKjO4yKY3P377GPuM8EIzp/https%3A%2F%2Factionsoftware.com%2Fsupport%2F

--
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

Re: Zowe for systems programmer ?

[Seymour J Metz]

I hope that you mean that it will first successfully do the ENQ, *then* check 
whether the member has changed and if not do the update.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Sent: Tuesday, September 4, 2018 3:45 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Zowe for systems programmer ?

This is a good discussion.  Our challenge is how to move forward that doesn’t 
break the old ways of doing things but actually making forward progress.  
Currently Zowe will read the data, allow it to be edited and then when updating 
will check to see if the file is in unchanged.  If so, grab an ENQ and make the 
update.  The editor and REST APIs are undergoing design now.  Give me a few 
days and I’ll provide a few scenarios and get your feedback on what does and 
doesn’t work.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook 
<https://secure-web.cisco.com/1wwj_4l50d47CREhDoXSU8-FEAJyxD4VH8eHa3GENk0V0M_oZ6dXZ4trJan6s0CK-mazgPBVYxjU59H1Ty7ojmZuJxwHaSi_MEu5jt46bB9vD-xbbe0m8QM1aioLcSAHLpeO8jawFXZeMUk0xpCaJK1XpK7MJsDXaLVImikNlCkvY0z5_LZRbu8s5UO1fELc9_jHxq1S200i-shQjkMngwqQJ57FSwezHAjjIBH1TX2bPQLa7TBXtyAj9DtZOMAE69jB7NL529ZwVaawPTCi1mJAzoPYG1S8WLYtgZjHvZ6XBB4owCAHGoYhM320rIENqjRWnkrVxTzCDK_qM5Ix6mscef5Yj5th5KicaBgmuKClE9bVkBbWgnMisz_OpQYza/https%3A%2F%2Ffacebook.com%2Fmatt.hogstrom>
  LinkedIn 
<https://secure-web.cisco.com/19NczfTmcjt-r6CHjnj5vrZ3kLsSDR2Xxf5lIOSfiDOyohA8rgh_qnqXt4EtgS3iWxg1Pqw_xPWtsTgrpCwBzhsWTtEKu1wQOUIuqPpXtUNX8YWJbCy07q-cid74wN8ECCxIusiUQzguIUSUGZYQj2rU2rMCNbbxW2uUIJxe_3RegeIYxnf3HshGFlNo-w_LadEITRQCl8y6iRFvNjXR8KqHRXL2cQoTh3TQtwsgg8F5NJ6eMSgiqc9ce5_L_vZoPWHHMPGzkvdHgZbmRNTwylZRIkIJke5FYBGpzy68qY3Ni-LI0vGXAmTSjGL24U-qveUgZ-yD9f9t8fm5nKnREWd5XamKSmygjXKEKCOYbjXdBQvqWhLRbCYV6uHGEqA7R/https%3A%2F%2Flinkedin%2Fin%2Fmhogstrom>
  Twitter 
<https://secure-web.cisco.com/1ApjXAJeQhVaDNbaNgVvGAGCplOhKc17sac2xxXganIKEOYUyS2Gfddt_Y1CBEaDvcc_TCc8j5EpJwUS2bUyPdL5JU7RnPQjXi8Uuw1Q_mJhBxBnzKhk002b0dbmORHmN3bgFtBZUTN8XRrkvJe4kmgy7ds3tpZiTztmvvAFdO_ZbJRTecj4Q-dEpbSna3W2g9e783iyryn77RiTyX8p45iQt7BEh05SmabDRwEl7Y_u-NJXbVgqwMHyjKlbmJqEt9tJ7jW_32Og3xtfweuP4W_4aGEDOw0pvMCA6FPEutJW5UvrZ523etmFSOVb6foShxxdA_wVLpunKux-L9mPbcjm565H-MPEqSeReVl6bQAbB9TaPp9PfcHNQfggrhO32BcHRWCtnKJONcCdWxNhbLQ/https%3A%2F%2Ftwitter.com%2Fhogstrom>

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Sep 4, 2018, at 3:31 PM, Gord Tomlin  
> wrote:
>
> On 2018-09-04 11:08, Tom Marchant wrote:
>> On Fri, 31 Aug 2018 06:52:57 -0500, Jerry Callen  wrote:
>>> Andrew Rowley wrote:
>>>
>>>> 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).
>> Not if you have some other process, such as with Zowe, that does not use
>> the ENQ that the system uses to prevent simultaneous updates.
>
> This thread started off with a discussion regarding the use of ISPF-style 
> SPFEDIT ENQs for serialization. While those ENQs protect against simultaneous 
> updates by multiple ISPF users, they do not protect against updates by other 
> non-ISPF programs, such as IEBCOPY, IEBGENER, or many others.
>
> Using SPFEDIT ENQs in Zowe would have the same strengths and weaknesses as 
> using those ENQs in ISPF.
>
> An ENQ convention can only truly be relied upon if all users of the system 
> follow that convention. SPFEDIT falls short in that.
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: 
> https://secure-web.cisco.com/1rOxo-_UJrGBqk1TwClT6uPWnoP0_jYxLCWLV6qn2nrfr63wtxdLa9DD9Xu4t3QTsCw301xZKiQ_ObYuJGgccKYuq2Nfr7iSs7l-ElEC8RwajnBVHvNjDYThrqU9I6fCQwd06AX_cQmXkOzFBwmnqxx3i8iK3UFuXbxZAOpZgrQItB1GOjMqvPdB4653N4njcX439yaaL8_OT6sC73SAsCQuW9A7A-FwNCU7R-lfmGo6CpMdeQ2P36gmxuTkylPZRhpNZTVRJgGSlrPzEzs4j2xSVD5uBlWboT1HPnfYwOowXQA4CJAfipk7pceydgkrQ9RsOaIQL_6MkHc8zMG8ZMBrWIXZUowJO5bDuLWICiaFFwBbKLnb4LYm7emUQcNcD/https%3A%2F%2Factionsoftware.com%2Fsupport%2F
>
> --
> 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

Re: Zowe for systems programmer ?

[Tom Marchant]

On Tue, 4 Sep 2018 15:45:03 -0400, Matt Hogstrom wrote:

>This is a good discussion.  Our challenge is how to move forward 
>that doesn’t break the old ways of doing things but actually making 
>forward progress.  

Indeed. I'm glad you are considering that.

>Currently Zowe will read the data, allow it to be edited and then when 
>updating will check to see if the file is in unchanged.  
>If so, grab an ENQ and make the update.

I think you mean that it will attempt to obtain the (exclusive) ENQ. 
Have you considered what to do if it is not currently available?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Matt Hogstrom]

This is a good discussion.  Our challenge is how to move forward that doesn’t 
break the old ways of doing things but actually making forward progress.  
Currently Zowe will read the data, allow it to be edited and then when updating 
will check to see if the file is in unchanged.  If so, grab an ENQ and make the 
update.  The editor and REST APIs are undergoing design now.  Give me a few 
days and I’ll provide a few scenarios and get your feedback on what does and 
doesn’t work.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Sep 4, 2018, at 3:31 PM, Gord Tomlin  
> wrote:
> 
> On 2018-09-04 11:08, Tom Marchant wrote:
>> On Fri, 31 Aug 2018 06:52:57 -0500, Jerry Callen  wrote:
>>> Andrew Rowley wrote:
>>> 
 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).
>> Not if you have some other process, such as with Zowe, that does not use
>> the ENQ that the system uses to prevent simultaneous updates.
> 
> This thread started off with a discussion regarding the use of ISPF-style 
> SPFEDIT ENQs for serialization. While those ENQs protect against simultaneous 
> updates by multiple ISPF users, they do not protect against updates by other 
> non-ISPF programs, such as IEBCOPY, IEBGENER, or many others.
> 
> Using SPFEDIT ENQs in Zowe would have the same strengths and weaknesses as 
> using those ENQs in ISPF.
> 
> An ENQ convention can only truly be relied upon if all users of the system 
> follow that convention. SPFEDIT falls short in that.
> 
> --
> 
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/
> 
> --
> 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

Re: Zowe for systems programmer ?

[Gord Tomlin]

On 2018-09-04 11:08, Tom Marchant wrote:

On Fri, 31 Aug 2018 06:52:57 -0500, Jerry Callen  wrote:


Andrew Rowley wrote:


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).

Not if you have some other process, such as with Zowe, that does not use
the ENQ that the system uses to prevent simultaneous updates.



This thread started off with a discussion regarding the use of 
ISPF-style SPFEDIT ENQs for serialization. While those ENQs protect 
against simultaneous updates by multiple ISPF users, they do not protect 
against updates by other non-ISPF programs, such as IEBCOPY, IEBGENER, 
or many others.


Using SPFEDIT ENQs in Zowe would have the same strengths and weaknesses 
as using those ENQs in ISPF.


An ENQ convention can only truly be relied upon if all users of the 
system follow that convention. SPFEDIT falls short in that.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Tom Marchant]

On Fri, 31 Aug 2018 06:52:57 -0500, Jerry Callen  wrote:

>Andrew Rowley wrote:
>
>> 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).

Not if you have some other process, such as with Zowe, that does not use 
the ENQ that the system uses to prevent simultaneous updates.

>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.

I remain skeptical that an automated process can in all cases resolve the 
updates that were made by more than one person to a single element.

There have been cases where I have made changes to a source module 
and had to consult with someone else who was also making changes to 
that same element in order to resolve the differences. That after having 
determined exactly what changes the other person had made.

And sometimes two people can solve the same problem in a module in 
different ways

>> 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. 

The problem was solved by the use of ENQ over 50 years ago. 
If Zowe does not always use the enqueues, it breaks that solution, and 
those proposals cannot solve the problem at all, let alone in a better 
way unless either:

1. Everyone who uses ISPF or batch processes to update data sets is 
compelled to immediately change to use Zowe, and there is some 
mechanism to enforce that, or

2. ISPF and batch processes are updated to use the same procedures 
that are used by Zowe, and those updates are installed on all systems 
that have the potential to update these data sets. Has anyone even 
submitted an RFE to try to get such changes made? Not that I would 
guess that there is much likelihood that such an RFE would be accepted.

Note that for case 1, you have painted yourself into a corner where a set 
of changes that cause an IPL to fail can result in the inability to recover.

The insistence that we should do things a "better way" without 
maintaining compatibility is short-sighted at best.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Rob Schramm]

It's not that the old way isn't fun, but I am all for making it easier.
Not replacing one version of difficult with another.  And open source
source is always attractive instead of object only.

Rob Schramm

On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> 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
> <https://maps.google.com/?q=4205+S+MIAMI+BLVD,+DURHAM+NC+27703=gmail=g>
> -9141
> Email: armst...@us.ibm.com
> Tel: 919-254-8773
> Cell: 919-931-3132
>
>
>
>
>
>
> From:   "Alan(GMAIL)Watthey" 
> 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 
>
>
>
> 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 
> 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.
>

Re: Zowe for systems programmer ?

[Bruce Armstrong]

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" 
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 



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  
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

Re: Zowe for systems programmer ?

[Alan(GMAIL)Watthey]

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  
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

Re: Zowe for systems programmer ?

[David Crayford]

On 31/08/2018 7:52 PM, Jerry Callen wrote:

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.


On our z/OS system our systems programmer keeps a backup of config 
files. This is an anachronism that's solved by Git.


DOC:/u/doc: >ll /etc/profile*
-rwxr-xr-x   1 BPXROOT  2611   18639 Mar  7 16:20 /etc/profile
-rwxr-xr-x   1 BPXROOT  2611   14678 Sep 17  2010 /etc/profile.2020
-rwxr-xr-x   1 BPXROOT  2611   15736 Mar 28  2016 /etc/profile.20160329
-rwxr-xr-x   1 BPXROOT  2611   16227 Mar 29  2016 
/etc/profile.2016_04_06
-rwxr-xr-x   1 BPXROOT  2611   16484 Apr  6  2016 
/etc/profile.2016_05_19
-rwxr-xr-x   1 BPXROOT  2611   16641 May 19  2016 
/etc/profile.2016_06_10
-rwxr-xr-x   1 BPXROOT  2611   16913 Oct 25  2016 
/etc/profile.2016_11_23

-rwxr-xr-x   1 BPXROOT  2611   14678 Sep 17  2010 /etc/profile.d2008
-rwxr-xr-x   1 BPXROOT  2611   14752 Nov 20  2011 /etc/profile.d20120324
-rwxr-xr-x   1 BPXROOT  2611   15435 Mar 21  2014 
/etc/profile.d2015_08_07

-rwxr-xr-x   1 BPXROOT  2611   15508 Aug  7  2015 /etc/profile.d20160321
-rwxr-xr-x   1 BPXROOT  2611   16808 Jun 10  2016 
/etc/profile.d2016_10_25
-rwxr-xr-x   1 BPXROOT  2611   16993 Nov 23  2016 
/etc/profile.d2017_05_29
-rwxr-xr-x   1 BPXROOT  2611   17342 May 29  2017 
/etc/profile.d2017_08_17

-rwxr-xr-x   1 BPXROOT  ZOSMF@G    18227 Mar  7 16:15 /etc/profile.db2v11
-rwxr-xr-x   1 BPXROOT  2611   14944 Mar 25  2012 /etc/profile.db2v9
-rwxr-xr-x   1 BPXROOT  2611   14755 Nov  1  2011 
/etc/profile67174559.d2001
-rwxr-xr-x   1 BPXROOT  2611   15356 Nov 30  2012 
/etc/profile_d2014_0321
-rwxr-xr-x   1 BPXROOT  2611   17427 Aug 17  2017 
/etc/profile_d2017_10_17


Another anachronism is annotating source lines of code when fixing bugs 
or adding new features.  I hate that! It hangs around like
old smelly laundry soiling the source code. I don't care what happened 
ten years ago I only care about the present. History should be

kept in source control and not code.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Rob Schramm]

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  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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Jerry Callen]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[David Crayford]

Git detects merge conflicts and will reject push requests. Our git 
repositories are in Bitbucket and we use pull requests. Nothing gets 
merged into master without going through a code review. I can assure you 
that the quality of our development process
has gone up exponentially with the adoption of tools like Git/Bitbucket. 
Bitbucket integrates with our Jira system so each feature branch in Git 
has an associated Jira ticket which when integrated with
Bitbucket can track every line of code that has been changed. I still 
have to work on projects that use our traditional mainframe VCS and PDS 
data sets and it really does feel like rubbing two sticks together!



On 31/08/2018 12:21 PM, Andrew Rowley wrote:

On 31/08/2018 1:45 PM, David Crayford wrote:


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.


I bet git still has code and conventions to prevent 2 people 
committing or pushing to the same repository/branch/etc 
simultaneously, and things could break if you removed them.


I'm still learning git but have come across a number of situations 
where they say "don't do this or you'll break things for everybody 
else" so I'm not sure it should be a model solution.


And "everybody has their own copy" isn't a solution for everything - 
typically at some point you have to agree on this is THE one true copy 
(a system configuration file, a software release etc.) at which point 
you're back to making sure that 2 people don't update at the same time.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Andrew Rowley]

On 31/08/2018 1:45 PM, David Crayford wrote:


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.


I bet git still has code and conventions to prevent 2 people committing 
or pushing to the same repository/branch/etc simultaneously, and things 
could break if you removed them.


I'm still learning git but have come across a number of situations where 
they say "don't do this or you'll break things for everybody else" so 
I'm not sure it should be a model solution.


And "everybody has their own copy" isn't a solution for everything - 
typically at some point you have to agree on this is THE one true copy 
(a system configuration file, a software release etc.) at which point 
you're back to making sure that 2 people don't update at the same time.


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[David Crayford]

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

Re: Zowe for systems programmer ?

[Andrew Rowley]

On 31/08/2018 3:05 AM, Jerry Callen 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.



No. It's trivial to save my copy of the file with another name, load the other 
guy's changes, and merge them. Of course, that's because I use emacs. Your 
mileage (with less capable editors) may vary.
Merging may or may not be simple. Most people on z/OS do not use emacs, 
and the editor is not the big issue anyway - it is conflicting changes. 
But Zowe is open source so I guess you are free to incorporate emacs as 
an editor option if that helps.



Here's the dirty little secret: simultaneous edits of the exact same file (in 
non-z/OS contexts) are uncommon. I'll go out on a limb and bet that even in 
z/OS, simultaneous edits of even the exact same file are uncommon.
Uncommon happens surprisingly often. 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.


Yes, source control would be useful. You have no idea how often I wished 
for a source control merge function while I entered someone else's 
changes in SYS1.PARMLIB. When I heard about git for z/OS my first 
question was can it handle z/OS datasets like SYS1.PARMLIB, answer: no. 
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.


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?


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Kirk Wolf]

FYI - the z/OSMF REST Files PUT supports updating text files with UNIX
"diff -e" format, which I suppose is handy for updating huge files.
Mix this with the "If-Match Etag" and you have a safe way of updating using
diffs without holding SPFEDIT ENQs.

X-IBM-Data-TypeThis header is optional; use it to indicate whether data
conversion is to be performed on the request body.textWhen set to text,
data conversion is performed. The data transfer process converts each
record from the charset specified on the "Content-Type" header of the
request. If no charset is specified, the default is ISO8859-1. Each line of
data, delimited by a Line Feed in the request charset, is converted to
EBCDIC and written as a record to the data set or member. (The line feed
character is removed from the data, and the data is padded with the space
character to the end of the record if it is a fixed record size data set.
For variable record size data sets, the record is written without padding.)
If the record size of the data set is smaller than any line of text, an
HTTP 400 is returned with a JSON error document indicating that not all
data was written.
Note: When set to 'text' and "Content-Type" is "application/x-ibm-diff-e",
the input consists of commands in the same format as produced by the z/OS
UNIX 'diff -e' command. These commands are used to add, replace and delete
lines in the target data set. The following commands are supported:

a

c

d

s/.//

opt : g|, g means global

n means search and replace  times

Each command may be optionally preceded by a line or line range, as allowed
by the z/OS UNIX 'ed' command. If an error is detected while processing a
command,status code 500 is returned with an exception.
binaryWhen set to binary, no data conversion is performed. The data is
written to the data set without respect to record boundaries. All records
will be written at their maximum record length and for fixed length record
data sets, the last record will be padded with nulls if required.recordWhen
set to record, no data conversion is performed. Each logical record is
preceded by the 4-byte big endian record length of the record that follows.
This length does not include the prefix length. For example: a zero-length
record would be 4 bytes of zeros with nothing following.

If you omit this header, the default is text; the request body is converted.



On Thu, Aug 30, 2018 at 12:18 PM Jerry Callen  wrote:

> > Question for y’all.  I would like to do a diff on the modified file and
> present the user with the changes.
> > They could REPLACE the file with the editor contents, MERGE them which
> would be something they
> > would do after a review of the diff, ABANDON them or save them somewhere
> else.  Does this strategy
> > sound acceptable ?
>
> Sounds completely awesome.
>
> -- Jerry
>
> --
> 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

Re: Zowe for systems programmer ?

[Jerry Callen]

> Question for y’all.  I would like to do a diff on the modified file and 
> present the user with the changes.
> They could REPLACE the file with the editor contents, MERGE them which would 
> be something they 
> would do after a review of the diff, ABANDON them or save them somewhere 
> else.  Does this strategy 
> sound acceptable ?

Sounds completely awesome.

-- Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Jerry Callen]

On Aug 29, 2018, at 8:20 PM, Andrew Rowley  wrote:
> 
> On 30/08/2018 12:16 AM, Jerry Callen wrote:
>> The whole idea of holding a lock on a file while a human being slowly edits 
>> it is so 1960s.
>> 
>> Since at least the mid 1970s, editors like emacs have loaded the file for 
>> editing and noted the timestamp. 
>> When the user attempts to save the file. the timestamp is checked again, and 
>> if it changed, the user is asked what to do.

> I always thought this was a result of being unable to effectively prevent 
> simultaneous edits, not a feature.

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.

> The user is asked what to do - do you want to throw away your changes or the 
> other guy's changes? 
> The answer is always the other guy's changes, right?

No. It's trivial to save my copy of the file with another name, load the other 
guy's changes, and merge them. Of course, that's because I use emacs. Your 
mileage (with less capable editors) may vary.

[Discussion of merging and its perils elided]

Here's the dirty little secret: simultaneous edits of the exact same file (in 
non-z/OS contexts) are uncommon. I'll go out on a limb and bet that even in 
z/OS, simultaneous edits of even the exact same file are uncommon. If you're 
not using source control system, then, yes, preventing those rare occurrences 
is a big deal.

What IS common is simultaneous edits to COPIES of the same file (in user 
sandboxes), and that's why merge tools exist. 

But - why not use a source control system and prohibit direct editing-in-place 
of critical things libraries like PARMLIBs, PROCLIBs, etc? You already have 
many system libraries under SMP control; no direct changes to, say, 
SYS1.LINKLIB. You COULD put everything else under SMP, but the effort to do so 
is just too high. This is where modern source control systems come in - 
control, with minimal pain.

I keep hammering on this because I think it really MATTERS. If you're a systems 
programmer, you ought to be at the head of line when it comes to adopting tools 
that allow you to bring consistency and order to system maintenance. 

It's early days for Zowe. The crucial first step was to get a framework in 
place into which. Zowe builds on the back-end framework of ZOSMF and similar 
services and provides a modern, responsive web UI for those services. What 
comes next is, to some extent, up to all of us. Remember when OS/360 was open 
source, and brought us things like HASP? Zowe is a return to those roots.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Matt Hogstrom]

right now Zowe is using the REST API to retrieve the dataset and expose it in 
an editor (No ENQ).  When the user wants to save it it checks to see if the 
file changed and prompts the user how they want to proceed.

Question for y’all.  I would like to do a diff on the modified file and present 
the user with the changes.  They could REPLACE the file with the editor 
contents, MERGE them which would be something they would do after a review of 
the diff, ABANDON them or save them somewhere else.  Does this strategy sound 
acceptable ?

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 30, 2018, at 9:42 AM, Kirk Wolf  wrote:
> 
> The z/OSMF Rest files APIs just offer the same SPFEDIT ENQ support that you
> get with ISPF EDIT.   Makes sense to have it if you want to play in that
> world, but it's use is completely optional.
> It fully supports a client that wants to detect changes and merge updates
> in the manners described on this thread.   The Put / Get data set services
> support standard If-None-Match/If-Match request headers and Etag response
> headers, which provide you with tokens (hashes) so that you can easily have
> clients deal with detection of changed data, merging, etc.
> 
> See:
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_GetReadDataSet.htm
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_PutWriteDataSet.htm
> 
> Does Zowe expose this functionality?  I don't know.
> 
> Other thoughts -
> - IMO, source code is better in zFS filesystems, not PDS data sets.   Maybe
> only on zFS for building.
> - The best place to merge is via your favorite SCCS.   The stuff that your
> interactively "edit" should be your own copy.
> 
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
> 
> --
> 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

Re: Zowe for systems programmer ?

[Kirk Wolf]

The z/OSMF Rest files APIs just offer the same SPFEDIT ENQ support that you
get with ISPF EDIT.   Makes sense to have it if you want to play in that
world, but it's use is completely optional.
It fully supports a client that wants to detect changes and merge updates
in the manners described on this thread.   The Put / Get data set services
support standard If-None-Match/If-Match request headers and Etag response
headers, which provide you with tokens (hashes) so that you can easily have
clients deal with detection of changed data, merging, etc.

See:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_GetReadDataSet.htm
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_PutWriteDataSet.htm

Does Zowe expose this functionality?  I don't know.

Other thoughts -
- IMO, source code is better in zFS filesystems, not PDS data sets.   Maybe
only on zFS for building.
- The best place to merge is via your favorite SCCS.   The stuff that your
interactively "edit" should be your own copy.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Matt Hogstrom]

Merging is not magic.  Where I see the biggest risk is merging items like 
IEASYS00 or other critical members where a review is needed to ensure the 
system comes up versus I’ve merged code changes and are less likely to have an 
impact.  So, I agree with your statements below … not magic, but requires an 
adult for certain merges.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2018, at 8:20 PM, Andrew Rowley  
> wrote:
> 
> On 30/08/2018 12:16 AM, Jerry Callen wrote:
>> The whole idea of holding a lock on a file while a human being slowly edits 
>> it is so 1960s.
>> 
>> Since at least the mid 1970s, editors like emacs have loaded the file for 
>> editing and noted the timestamp. When the user attempts to save the file. 
>> the timestamp is checked again, and if it changed, the user is asked what to 
>> do.
> I always thought this was a result of being unable to effectively prevent 
> simultaneous edits, not a feature. The user is asked what to do - do you want 
> to throw away your changes or the other guy's changes? The answer is always 
> the other guy's changes, right?
>> And, of course, if you use a distributed source control system like git, 
>> handling merge conflicts is a built-in and normal part of the process.
> You can of course do this on z/OS if you want to.
> 
> I have been using source control for long enough that making any change 
> without source control feels like climbing without a rope. But merging isn't 
> magic.
> 
> Merging:
> 1) Gives you a version that has never been verified by a human. The people 
> who wrote the merge process assumed the person doing the merge will verify it 
> is correct. The people doing the merge far too often assume the merged 
> version is correct. Merging is OK for compiled code where the compiler does a 
> lot of verification. For something like SYS1.PARMLIB I'm not so sure.
> 2) Often you get versions that cannot be automatically merged. Sorting out 
> these issues can be a monumental mess. Particularly if one or both of the 
> merged versions were themselves the result of a merge, it can be difficult to 
> which conflicting pieces are required. In this situation you wish for the 
> simplicity of a single thread of sequential changes.
> 
> Merging is necessary and useful when you have multiple branches of 
> development. It's not a substitute for the prevention of simultaneous edits.
> 
> 
> -- 
> 
> Andrew Rowley
> Black Hill Software
> 
> --
> 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

Re: Zowe for systems programmer ?

[Andrew Rowley]

On 30/08/2018 12:16 AM, Jerry Callen wrote:

The whole idea of holding a lock on a file while a human being slowly edits it 
is so 1960s.

Since at least the mid 1970s, editors like emacs have loaded the file for 
editing and noted the timestamp. When the user attempts to save the file. the 
timestamp is checked again, and if it changed, the user is asked what to do.
I always thought this was a result of being unable to effectively 
prevent simultaneous edits, not a feature. The user is asked what to do 
- do you want to throw away your changes or the other guy's changes? The 
answer is always the other guy's changes, right?

And, of course, if you use a distributed source control system like git, 
handling merge conflicts is a built-in and normal part of the process.

You can of course do this on z/OS if you want to.

I have been using source control for long enough that making any change 
without source control feels like climbing without a rope. But merging 
isn't magic.


Merging:
1) Gives you a version that has never been verified by a human. The 
people who wrote the merge process assumed the person doing the merge 
will verify it is correct. The people doing the merge far too often 
assume the merged version is correct. Merging is OK for compiled code 
where the compiler does a lot of verification. For something like 
SYS1.PARMLIB I'm not so sure.
2) Often you get versions that cannot be automatically merged. Sorting 
out these issues can be a monumental mess. Particularly if one or both 
of the merged versions were themselves the result of a merge, it can be 
difficult to which conflicting pieces are required. In this situation 
you wish for the simplicity of a single thread of sequential changes.


Merging is necessary and useful when you have multiple branches of 
development. It's not a substitute for the prevention of simultaneous edits.



--

Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Matt Hogstrom]

This is a good point.  For PDS what would be ideal is that you checkout a 
member and when saving it perform a diff / merge (while holding the ENQ) for a 
short period of time.  Not a long hold that will eventually cause issues with 
ENQs that were requested and not released in a timely manner.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2018, at 7:16 AM, Jerry Callen  wrote:
> 
> 
> 
> The whole idea of holding a lock on a file while a human being slowly edits 
> it is so 1960s. 
> 
> Since at least the mid 1970s, editors like emacs have loaded the file for 
> editing and noted the timestamp. When the user attempts to save the file. the 
> timestamp is checked again, and if it changed, the user is asked what to do.
> 
> And, of course, if you use a distributed source control system like git, 
> handling merge conflicts is a built-in and normal part of the process.
> 
> It's very easy to imagine a zowe plugin that backs a source PDS with a git 
> repo on a server (GitHub/BitBucket) and integrates editing with the whole git 
> ecosystem of branches and pull requests. 
> 
> I say again: z/OS systems are too complex and mission-critical for us to 
> continue using outdated tooling and engineering processes to maintain them.
> 
> 
> 
> --
> 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

Re: Zowe for systems programmer ?

[Jerry Callen]

The whole idea of holding a lock on a file while a human being slowly edits it 
is so 1960s. 

Since at least the mid 1970s, editors like emacs have loaded the file for 
editing and noted the timestamp. When the user attempts to save the file. the 
timestamp is checked again, and if it changed, the user is asked what to do.

And, of course, if you use a distributed source control system like git, 
handling merge conflicts is a built-in and normal part of the process.

It's very easy to imagine a zowe plugin that backs a source PDS with a git repo 
on a server (GitHub/BitBucket) and integrates editing with the whole git 
ecosystem of branches and pull requests. 

I say again: z/OS systems are too complex and mission-critical for us to 
continue using outdated tooling and engineering processes to maintain them.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Tom Marchant]

On Tue, 28 Aug 2018 16:41:40 -0400, Gord Tomlin wrote:

>"plays well with the other children, iff requested to do so."

That is the question. Does Zowe request that it do so?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Mike Schwab]

Until your TSO session times out or is cancelled?  15 or 30 minutes or no limit?

I was once asked how to solve a problem where two users updating the
same screen ended up creating invalid keys with some data from each
screen (a base record and one record per text line).  My suggestion
was to place the last update time stamp in hidden fields on the
screen.  When the second update was attempted, the time stamp no
longer matched and the update was not posted.  They didn't like
loosing the update but at least the records didn't have to be fixed by
a programmer.
On Tue, Aug 28, 2018 at 5:42 PM Andrew Rowley
 wrote:
>
> On 29/08/2018 6:41 AM, Gord Tomlin wrote:
> > It would appear that the answer to your question is here:
> > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_PutWriteDataSet.htm
> >
> >
> > Under "Custom headers":
> >
> > X-IBM-Obtain-ENQ
> > This header is optional; set it to one of the following values to
> > request that a system ENQ be obtained and held after the completion of
> > this request. If not specified, then no ENQs will be held after the
> > completion of this request.
>
> Of course you need to obtain the ENQ when you do the read to start the
> edit session, it looks like the equivalent header exists on GET so
> that's OK.
>
> I wonder how long the ENQ persists if I start editing then close my
> browser, or if I just take a long time to complete the edit? If I close
> my browser and try again to edit I suspect I will be locked out for a
> period of time...
>
> --
> Andrew Rowley
> Black Hill Software
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Andrew Rowley]

On 29/08/2018 6:41 AM, Gord Tomlin wrote:

It would appear that the answer to your question is here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_PutWriteDataSet.htm 



Under "Custom headers":

X-IBM-Obtain-ENQ
    This header is optional; set it to one of the following values to 
request that a system ENQ be obtained and held after the completion of 
this request. If not specified, then no ENQs will be held after the 
completion of this request.


Of course you need to obtain the ENQ when you do the read to start the 
edit session, it looks like the equivalent header exists on GET so 
that's OK.


I wonder how long the ENQ persists if I start editing then close my 
browser, or if I just take a long time to complete the edit? If I close 
my browser and try again to edit I suspect I will be locked out for a 
period of time...


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Gord Tomlin]

On 2018-08-28 16:18, Tom Marchant wrote:

On Fri, 24 Aug 2018 11:25:57 -0400, Matt Hogstrom wrote:


The question about serialization is up to the consumer of the
REST interface.  For instance, if editing a dataset the caller
can request that the ENQ on the dataset be held to keep
others from editing the file.

This still doesn't answer the question. Does Zowe obtain the
ENQ, or is it up to the user whether the ENQ is acquired?


It would appear that the answer to your question is here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_PutWriteDataSet.htm

Under "Custom headers":

X-IBM-Obtain-ENQ
This header is optional; set it to one of the following values to 
request that a system ENQ be obtained and held after the completion of 
this request. If not specified, then no ENQs will be held after the 
completion of this request.


EXCL
a SYSDSN/Exclusive ENQ will be held on the data set
SHRW
a SYSDSN/SHR ENQ will be held on the data set, and a 
SPFEDIT/EXCL ENQ will be held on the data set, including the member name 
if this is a request for a PDS member.


A successful response will include an X-IBM-Session-Ref response 
header that can be added as a request header to subsequent requests to 
specify affinity to the TSO address space holding this ENQ.


In other words, "plays well with the other children, iff requested to do 
so."


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Tom Marchant]

On Fri, 24 Aug 2018 11:25:57 -0400, Matt Hogstrom wrote:

>The question about serialization is up to the consumer of the 
>REST interface.  For instance, if editing a dataset the caller 
>can request that the ENQ on the dataset be held to keep 
>others from editing the file.

This still doesn't answer the question. Does Zowe obtain the 
ENQ, or is it up to the user whether the ENQ is acquired?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Matt Hogstrom]

The current implementation of file access uses two sets of APIs.  The first is 
the Explorer APIs so that we can use web-based editors (context sensitive) in 
order to access the data.  So for example, JCL, COBOL, Java grammar assists are 
available.  The Explorer APIs allow us to deliver a stable user interface.  
Currently the project is using the z/OSMF APIs for file access.  So, 
Authentication is SAF based, Authorization is SAF based.  The question about 
serialization is up to the consumer of the REST interface.  For instance, if 
editing a dataset the caller can request that the ENQ on the dataset be held to 
keep others from editing the file.

Here is a reference to the current REST APIs for data set access in z/OSMF.  
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/IZUHPINFO_API_GetReadDataSet.htm
 
<https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/IZUHPINFO_API_GetReadDataSet.htm>

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook <https://facebook.com/matt.hogstrom>  LinkedIn 
<https://linkedin/in/mhogstrom>  Twitter <https://twitter.com/hogstrom>

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 24, 2018, at 10:51 AM, Bruce Armstrong  wrote:
> 
> Tom - I don't know - I will find an answer. In the examples of using web 
> ui and cli, it has been limited to the files owned by a given user. 
> 
> Zowe is using z/OS services thru z/OSMF REST APIs...if you are 
> invoking a command or service that does an ENQ then I would say "yes". If 
> Zowe is invoking a command/service that does not do ENQ then "no". 
> 
> 
> 
> 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:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   08/24/2018 10:25 AM
> Subject:Re: Zowe for systems programmer ?
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> On Fri, 24 Aug 2018 10:10:45 -0400, Bruce Armstrong wrote:
> 
>> Zowe (either cli or web ui) is still using your SAF access controls via 
>> the z/OSMF REST APIs so I will say no there is not magic file sharing 
>> logic in Zowe itself. 
> 
> That doesn't answer the question that I asked. SAF determines 
> whether I can access the data set. ENQ ensures that no one else 
> can have it while I am updating it.
> 
> Does Zowe cause an appropriate ENQ to be issued?
> 
> -- 
> Tom Marchant
> 
>> From:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date:   08/24/2018 08:21 AM
>> 
>> Will it do so while providing integrity so that two users can't edit the 
>> same data 
>> set (or member) at the same time, whether using Zowe or ISPF?
> 
> --
> 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

Re: Zowe for systems programmer ?

[Bruce Armstrong]

Tom - I don't know - I will find an answer. In the examples of using web 
ui and cli, it has been limited to the files owned by a given user. 

 Zowe is using z/OS services thru z/OSMF REST APIs...if you are 
invoking a command or service that does an ENQ then I would say "yes". If 
Zowe is invoking a command/service that does not do ENQ then "no". 


 
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:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/24/2018 10:25 AM
Subject:    Re: Zowe for systems programmer ?
Sent by:IBM Mainframe Discussion List 



On Fri, 24 Aug 2018 10:10:45 -0400, Bruce Armstrong wrote:

>Zowe (either cli or web ui) is still using your SAF access controls via 
>the z/OSMF REST APIs so I will say no there is not magic file sharing 
>logic in Zowe itself. 

That doesn't answer the question that I asked. SAF determines 
whether I can access the data set. ENQ ensures that no one else 
can have it while I am updating it.

Does Zowe cause an appropriate ENQ to be issued?

-- 
Tom Marchant

>From:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
>To: IBM-MAIN@LISTSERV.UA.EDU
>Date:   08/24/2018 08:21 AM
>
>Will it do so while providing integrity so that two users can't edit the 
>same data 
>set (or member) at the same time, whether using Zowe or ISPF?

--
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

Re: Zowe for systems programmer ?

[Bruce Armstrong]

We (the Zowe project) understand the need to have z/OS open sandboxes to 
encourage developing, testing, innovation. 

 
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:   Jake Anderson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/24/2018 10:34 AM
Subject:Re: Zowe for systems programmer ?
Sent by:IBM Mainframe Discussion List 



'Open Mainframe Project for sharing of code much like the smart phones 
have
today '

I don't think it works like anyother open-source project ? The person who
contributes or finds a solution for a bug needs to have a Mainframe, So 
the
number of contributor will be restricted to only those who have mainframe
access and which ofcourse he/she has to use her own facility ?

On Fri 24 Aug, 2018, 6:24 PM Tom Marchant, <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 24 Aug 2018 10:10:45 -0400, Bruce Armstrong wrote:
>
> >Zowe (either cli or web ui) is still using your SAF access controls via
> >the z/OSMF REST APIs so I will say no there is not magic file sharing
> >logic in Zowe itself.
>
> That doesn't answer the question that I asked. SAF determines
> whether I can access the data set. ENQ ensures that no one else
> can have it while I am updating it.
>
> Does Zowe cause an appropriate ENQ to be issued?
>
> --
> Tom Marchant
>
> >From:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Date:   08/24/2018 08:21 AM
> >
> >Will it do so while providing integrity so that two users can't edit 
the
> >same data
> >set (or member) at the same time, whether using Zowe or ISPF?
>
> --
> 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

Re: Zowe for systems programmer ?

[Jake Anderson]

'Open Mainframe Project for sharing of code much like the smart phones have
today '

I don't think it works like anyother open-source project ? The person who
contributes or finds a solution for a bug needs to have a Mainframe, So the
number of contributor will be restricted to only those who have mainframe
access and which ofcourse he/she has to use her own facility ?

On Fri 24 Aug, 2018, 6:24 PM Tom Marchant, <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 24 Aug 2018 10:10:45 -0400, Bruce Armstrong wrote:
>
> >Zowe (either cli or web ui) is still using your SAF access controls via
> >the z/OSMF REST APIs so I will say no there is not magic file sharing
> >logic in Zowe itself.
>
> That doesn't answer the question that I asked. SAF determines
> whether I can access the data set. ENQ ensures that no one else
> can have it while I am updating it.
>
> Does Zowe cause an appropriate ENQ to be issued?
>
> --
> Tom Marchant
>
> >From:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Date:   08/24/2018 08:21 AM
> >
> >Will it do so while providing integrity so that two users can't edit the
> >same data
> >set (or member) at the same time, whether using Zowe or ISPF?
>
> --
> 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

Re: Zowe for systems programmer ?

[Tom Marchant]

On Fri, 24 Aug 2018 10:10:45 -0400, Bruce Armstrong wrote:

>Zowe (either cli or web ui) is still using your SAF access controls via 
>the z/OSMF REST APIs so I will say no there is not magic file sharing 
>logic in Zowe itself. 

That doesn't answer the question that I asked. SAF determines 
whether I can access the data set. ENQ ensures that no one else 
can have it while I am updating it.

Does Zowe cause an appropriate ENQ to be issued?

-- 
Tom Marchant

>From:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
>To: IBM-MAIN@LISTSERV.UA.EDU
>Date:   08/24/2018 08:21 AM
>
>Will it do so while providing integrity so that two users can't edit the 
>same data 
>set (or member) at the same time, whether using Zowe or ISPF?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Bruce Armstrong]

Tom - If you like ISPF stay with ISPF - there is no forced march 
here...by the way Zowe web ui includes a 3270 emulator so you can do 
ISPF through the browser. One of the demo we have shown is right mouse 
click from 3270 to involve another web app. 

Zowe (either cli or web ui) is still using your SAF access controls via 
the z/OSMF REST APIs so I will say no there is not magic file sharing 
logic in Zowe itself. 

 
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:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/24/2018 08:21 AM
Subject:    Re: Zowe for systems programmer ?
Sent by:IBM Mainframe Discussion List 



On Fri, 24 Aug 2018 06:35:41 -0400, Bruce Armstrong wrote:

>You may 
>have your favorite editor on your laptop for editing files and you don't 
>like having to switch to ISPF to edit something on z/OS..

Assuming that your favorite editor is not the ISPF editor.

>via the Zowe 
>command line you can stay in the laptop context and Zowe will fetch a 
data 
>set behind the scene, allow it to be edited by your favorite editor and 
>save back to z/OS transparently.

Will it do so while providing integrity so that two users can't edit the 
same data 
set (or member) at the same time, whether using Zowe or ISPF?

-- 
Tom Marchant

--
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

Re: Zowe for systems programmer ?

[Jerry Callen]

On Fri, 24 Aug 2018 07:20:24 -0500, Tom Marchant wrote:

>> via the Zowe command line you can stay in the laptop context
>> and Zowe will fetch a data set behind the scene, allow it to
>> be edited by your favorite editor and save back to z/OS
>> transparently.

> Will it do so while providing integrity so that two users can't
> edit the same data set (or member) at the same time, whether
> using Zowe or ISPF?

I would argue that shared files that might be updated by multiple
users simultaneously should be in a source control system anyway. If
the files MUST wind up in a PDS (parmlib members, anyone?), that
staging should happen in a controlled manner.

So - keep your text files in the Unix file system under the control of
git. ISPF will happily edit USS files -- no need to copy them to a
PDS.  You can keep your parmlib members in an off-mainframe server
(like an on-premises github or bitbucket server), have your changes
code-reviewed by your fellow sysprogs, committed, and pushed to the
parmlib via a deployment mechanism like Jenkins. All that stuff is
accessed via the browser.

You think that's crazy? It's how the off-mainframe world has been
working for the past decade, at least. With the proper tools, and the
willingness to learn to use them well, it improves productivity and
reduces errors.

IMO, it's time to start treating the mainframe like the complex,
mission-critical embedded system that it is, and use modern tools
to manage it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Tom Marchant]

On Fri, 24 Aug 2018 06:35:41 -0400, Bruce Armstrong wrote:

>You may 
>have your favorite editor on your laptop for editing files and you don't 
>like having to switch to ISPF to edit something on z/OS..

Assuming that your favorite editor is not the ISPF editor.

>via the Zowe 
>command line you can stay in the laptop context and Zowe will fetch a data 
>set behind the scene, allow it to be edited by your favorite editor and 
>save back to z/OS transparently.

Will it do so while providing integrity so that two users can't edit the same 
data 
set (or member) at the same time, whether using Zowe or ISPF?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Zowe for systems programmer ?

[Bruce Armstrong]

Hey Jake - let me try to explain some different ways Zowe is intended to 
help a system programmer. "Is it going to act like a GUI to perform all 
the system related activities?" - short answer is yes over time but don't 
think of just GUI as the way to interact with z/OS. 

The web user interface is intended to be a new platform for better 
visualization of z/OS resources. You likely use web technology for 
interacting with so many other systems in your life - email, bank, cloud, 
etc. - why not use same technology for z/OS? Browser skills are pervasive 
- they don't require additional software installed on your laptop/desktop. 
Web provides better use of graphics, more "right click" capabilities, and 
more end to end views can be written with fast path to system details. 
Over the years z/OS based products have generally been built as silos or 
swim lanes of expertise and not enough cross product sharing of data. One 
aspect of the web UI is "app to app" communication in the web meaning one 
app can invoke another, feed data to another to provide new ways of 
linking applications. 

System programmer productivity is another aspect. For example using the 
new Zowe command line. There are many different use cases here for a power 
user that wants to quickly edit a data set, submit a job, etc. You may 
have your favorite editor on your laptop for editing files and you don't 
like having to switch to ISPF to edit something on z/OS..via the Zowe 
command line you can stay in the laptop context and Zowe will fetch a data 
set behind the scene, allow it to be edited by your favorite editor and 
save back to z/OS transparently. The "real" power of the command line is 
being able to script commands to perform a set of actions on z/OS - using 
the script language of your choice. A common use case for script is Devops 
pipelines where z/OS can participate like any other platform in your 
environment. 

There are many other aspects that I won't ramble on about but just mention 
- increase the use of today's z/OS REST APIs, extend those APIs in new 
ways, encourage z/OS product teams to provide APIs as the way to interact 
with their, provide a catalog of the z/OS APIs, make z/OS resources more 
discoverable, .

Part of the reason for Zowe being open source is to pool the skills of 
system programmers across the industry and share both the pain points for 
z/OS administration and operation plus find ways to address the issues by 
sharing expertise, code and experience. If someone uses the command line 
to script a common task on z/OS we what to have that contributed for 
others to use. If someone has written web app that links two products 
together in an innovative way we hope they will contribute to the Zowe 
code base. We hope to have a Zowe "app store" in 2019 with the help of the 
Open Mainframe Project for sharing of code much like the smart phones have 
today - yes there are issues to be worked out on knowing the apps are safe 
and trusted but the point is Zowe is not just technology - it is the 
community to cause innovation. 

Sorry for long post ...hope this helps 

 
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:   Jake Anderson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/24/2018 03:17 AM
Subject:Zowe for systems programmer ?
Sent by:IBM Mainframe Discussion List 



Hi Group

I have got a novice questions about zowe.

I am still trying to understand how zowe is going to help the system
programmer and does anyone have any idea or any insight.

Is it going to act like a GUI to perform all the system related activities
?

Jake

--
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

Zowe for systems programmer ?

[Jake Anderson]

Hi Group

I have got a novice questions about zowe.

I am still trying to understand how zowe is going to help the system
programmer and does anyone have any idea or any insight.

Is it going to act like a GUI to perform all the system related activities
?

Jake

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN