git, z/OS and COBOL

[Frank Swarbrick]

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

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

[Edgington, Jerry]

Frank,

I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here

There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.

From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.

Jerry Edgington

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

[Frank Swarbrick]

The reason I asked about the line numbers thing is that git seems to use a Unix compare utility that has no way (that I can tell) to ignore the line numbers. So if you insert a new line then the compare thinks that every line after that has changed, when truly only the line number has changed. If you have a way around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Edgington, Jerry <***@KROGER.COM>
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here

There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.

From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.

Jerry Edgington

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

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

[Edgington, Jerry]

Sure Frank. No problem with emailing privately. Happy to help, if I can.

From: Frank Swarbrick [mailto:***@outlook.com]
Sent: Tuesday, October 10, 2017 1:19 PM
To: Edgington, Jerry; IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix compare utility that has no way (that I can tell) to ignore the line numbers. So if you insert a new line then the compare thinks that every line after that has changed, when truly only the line number has changed. If you have a way around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU<mailto:IBM-***@LISTSERV.UA.EDU>> on behalf of Edgington, Jerry <***@KROGER.COM<mailto:***@KROGER.COM>>
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-***@LISTSERV.UA.EDU<mailto:IBM-***@LISTSERV.UA.EDU>
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here

There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.

From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.

Jerry Edgington

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-***@LISTSERV.UA.EDU<mailto:IBM-***@LISTSERV.UA.EDU>
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

[Edgington, Jerry]

Sorry Frank. Here is my email address at work

***@Kroger.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Edgington, Jerry
Sent: Tuesday, October 10, 2017 1:20 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Sure Frank. No problem with emailing privately. Happy to help, if I can.

From: Frank Swarbrick [mailto:***@outlook.com]
Sent: Tuesday, October 10, 2017 1:19 PM
To: Edgington, Jerry; IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix compare utility that has no way (that I can tell) to ignore the line numbers. So if you insert a new line then the compare thinks that every line after that has changed, when truly only the line number has changed. If you have a way around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU<mailto:IBM-***@LISTSERV.UA.EDU>> on behalf of Edgington, Jerry <***@KROGER.COM<mailto:***@KROGER.COM>>
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-***@LISTSERV.UA.EDU<mailto:IBM-***@LISTSERV.UA.EDU>
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply #1, if the z/OS batch compiler allows them, then no #2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking #3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example #5, using this setup, they will not know they are running on Unix on z/OS #6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality #7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here

There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.

From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.

Jerry Edgington

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-***@LISTSERV.UA.EDU<mailto:IBM-***@LISTSERV.UA.EDU>
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

[Farley, Peter x23353]

Frank,

The *ix compare utility is usually the "diff" command, and looking up the possible parameters for "diff" I don't see any options that would allow filtering the columns compared. It should be possible to craft a shell script to chop the line numbers off in temporary files and then do the compare with the chopped files, but the output would not, of course, reflect the line numbers in the difference listing (or "patch" compatible output file). Another possible issue would be whether it is even possible to make git use the shell script instead of "diff", and whether or not that is even desirable for any language but COBOL.

Looks like an opportunity for someone to contribute to the open-source community to implement a column filter for the "diff" and "patch" suite, and maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I use those (now just comment) COBOL line number columns to "tag" changed COBOL lines during maintenance edits to identify the project for which the change was done. I use ISPF "UNNUM" on all numbered source programs when I first edit them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the need/desire to use the COBOL line number columns for tags, but I can still see using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people are used to working.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 1:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix compare utility that has no way (that I can tell) to ignore the line numbers. So if you insert a new line then the compare thinks that every line after that has changed, when truly only the line number has changed. If you have a way around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Edgington, Jerry <***@KROGER.COM>
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here

There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.

From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.

Jerry Edgington

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

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

[Frank Swarbrick]

As far as I know the COBOL line numbers in cols 1-6 are just historical, and of no real value. I imagine we'd eliminate their usage via some mass conversion process at the time we load the source in to git.

It sounds like you are referring to columns 73-80, however. We use that for an 8 character 'work order number'. I don't think they will cause us any issues.
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <***@BROADRIDGE.COM>
Sent: Tuesday, October 10, 2017 11:50 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

The *ix compare utility is usually the "diff" command, and looking up the possible parameters for "diff" I don't see any options that would allow filtering the columns compared. It should be possible to craft a shell script to chop the line numbers off in temporary files and then do the compare with the chopped files, but the output would not, of course, reflect the line numbers in the difference listing (or "patch" compatible output file). Another possible issue would be whether it is even possible to make git use the shell script instead of "diff", and whether or not that is even desirable for any language but COBOL.

Looks like an opportunity for someone to contribute to the open-source community to implement a column filter for the "diff" and "patch" suite, and maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I use those (now just comment) COBOL line number columns to "tag" changed COBOL lines during maintenance edits to identify the project for which the change was done. I use ISPF "UNNUM" on all numbered source programs when I first edit them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the need/desire to use the COBOL line number columns for tags, but I can still see using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people are used to working.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 1:19 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix compare utility that has no way (that I can tell) to ignore the line numbers. So if you insert a new line then the compare thinks that every line after that has changed, when truly only the line number has changed. If you have a way around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Edgington, Jerry <***@KROGER.COM>
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here

There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.

From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.

Jerry Edgington

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

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

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

[Kirk Wolf]

Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
The SlickEdit Core ? Others?

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

[scott Ford]

Frank and Kirk:

Yes we are using Assembler and Cobol in GIT.

At least one person has said they are using git for source code management
of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
-- We dont use them
2) What do your developers use for their COBOL editor? ISPF? Off platform
IDE?
-- We upload to z/OS sandbox
-- JCL compile there
-- Unit tests
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between
z/OS and workstations?
-- GIT CLONE to Linux and FTP to z/OS
5) How much UNIX knowledge do your developers need to be productive in this
environment?
-- I am the only one with Unix knowledge, everyone else is not unix savy
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
-- see above
7) Do you use a GUI/visual merge product? How?
-- BeyondCompare
8) Anything else you'd like to add


HTH Frank and Kirk..

Scott

Post by Kirk Wolf
Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
The SlickEdit Core ? Others?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

***@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

[Clark Morris]

[Default] On 10 Oct 2017 10:48:59 -0700, in bit.listserv.ibm-main

Post by Edgington, Jerry
Frank,
The *ix compare utility is usually the "diff" command, and looking up the possible parameters for "diff" I don't see any options that would allow filtering the columns compared. It should be possible to craft a shell script to chop the line numbers off in temporary files and then do the compare with the chopped files, but the output would not, of course, reflect the line numbers in the difference listing (or "patch" compatible output file). Another possible issue would be whether it is even possible to make git use the shell script instead of "diff", and whether or not that is even desirable for any language but COBOL.
Looks like an opportunity for someone to contribute to the open-source community to implement a column filter for the "diff" and "patch" suite, and maybe "git" as well.
Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades.

Vendors which supply COBOL source probably use IEBUPDTE or their own
proprietary means of updating (and maybe even their own library
system) that depends on sequence numbers in columns 1 - 6. In the
1990s I had to deal with vendor source that was updated by their
system using sequence numbers. As I recall, JES2 and JES3 source
maintenance used IEBUPDTE and sequence numbers in 73 - 80 back in the
1980s when I was doing SMP/E work (I was at an installation that went
from HASP to JES3 to JES2).

Clark Morris

Post by Edgington, Jerry
I abandoned using any line numbers at all in any language many years ago, and I use those (now just comment) COBOL line number columns to "tag" changed COBOL lines during maintenance edits to identify the project for which the change was done. I use ISPF "UNNUM" on all numbered source programs when I first edit them to remove all line numbering.
COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the need/desire to use the COBOL line number columns for tags, but I can still see using them that way going forward.
YMMV of course, I realize that it is quite hard to change the ways that people are used to working.
Peter
-----Original Message-----
Sent: Tuesday, October 10, 2017 1:19 PM
Subject: Re: git, z/OS and COBOL
The reason I asked about the line numbers thing is that git seems to use a Unix compare utility that has no way (that I can tell) to ignore the line numbers. So if you insert a new line then the compare thinks that every line after that has changed, when truly only the line number has changed. If you have a way around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank
________________________________
Sent: Tuesday, October 10, 2017 10:47 AM
Subject: Re: git, z/OS and COBOL
Frank,
I have been working with several tools to build Cobol programs with as much open source as possible. Here is what I am using;
Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git. The git server is running off z/OS supported by another team
Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool
Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF. So, no Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically allocate the necessary files, then executing the compile. However, I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc. I am using what was built for the Java environment here
There are some differences that the developer will see, for example separating out the various types of sources, like Cobol, Copybooks, BMS, etc with different mime types. But, using Eclipse IDE, git and Jenkins, a developer can push code from the IDE to the git server, like Bitbucket, kick of Jenkins build, which will push/pull the source code from Bitbucket/git to zFS using git client and Jenkins slave. That is using all open source.
From there, something like DBBz, ANT script, possibly the mainframe SCM, or JCL to copy the source to PDS and compile the programs.
However, to do a full SCLM, like the current mainframe source management tools, you can forget about deployment or movement between environments.
Jerry Edgington
-----Original Message-----
Sent: Tuesday, October 10, 2017 11:49 AM
Subject: git, z/OS and COBOL
At least one person has said they are using git for source code management of their z/OS COBOL programs. A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
5) How much UNIX knowledge do your developers need to be productive in this environment?
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
7) Do you use a GUI/visual merge product? How?
8) Anything else you'd like to add!
Thanks, Frank

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

[s***@COPPER.NET]

Peter, et al:

I am quite interested in git. And so I thought I would address a statement made about COBOL Numbering, and "standard" numbering locations in source.

There are some products that ship source and do use COBOL numbering while others use the 73-80 numbering (both are COBOL based products). In either case, they are generally maintained by using IEBUPDTE to insert the maintenance and/or USER changes.

I know of some user source that is maintained that way because that source is used where different "mods" have to be applied (terminology not to imply any relationship to SMPE).

So, where I am working, I am given to understand that there is a POC going with git. If they do not understand our shop, this could cause a headache (the stripping or ignoring 1-6 and/or 73-80).

In source that I maintain, the change codes are in 73-80, while NUM COB is used (ISPF), I don't care about that information -- I care about the change codes for what I maintain.

But I am just waiting for the chance to use git for ISPF panels, skeletons, COBOL source, REXX and ALC code that I am responsible for.

I'd like to run into the problems before the applications people have a chance to hit it so we can head that all off.

And I'd love to know the answers to this before the POC dies. So I am very interested in this thread.

Regards,
Steve Thompson



--- ***@BROADRIDGE.COM wrote:

From: "Farley, Peter x23353" <***@BROADRIDGE.COM>
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] git, z/OS and COBOL
Date: Tue, 10 Oct 2017 17:50:10 +0000

Frank,

The *ix compare utility is usually the "diff" command, and looking up the possible parameters for "diff" I don't see any options that would allow filtering the columns compared. It should be possible to craft a shell script to chop the line numbers off in temporary files and then do the compare with the chopped files, but the output would not, of course, reflect the line numbers in the difference listing (or "patch" compatible output file). Another possible issue would be whether it is even possible to make git use the shell script instead of "diff", and whether or not that is even desirable for any language but COBOL.

Looks like an opportunity for someone to contribute to the open-source community to implement a column filter for the "diff" and "patch" suite, and maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I use those (now just comment) COBOL line number columns to "tag" changed COBOL lines during maintenance edits to identify the project for which the change was done. I use ISPF "UNNUM" on all numbered source programs when I first edit them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the need/desire to use the COBOL line number columns for tags, but I can still see using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people are used to working.

Peter

<snippage>

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

[Farley, Peter x23353]

Steve,

Once you start using git (or for that matter any of the *ix-based source repository utilities) for mainframe source maintenance, you stop using IEBUPDTE (or any other sequence-number-based source update process) and start using the "patch" utility. The input to "patch" is the output from "diff" (when properly configured with options, as is done inside of git and other source repository utilities).

The "diff" and "patch" utilities could care less what is on each line. They just compare lines and try to find the maximal number of non-differences (sets of matching lines) between the minimal number of difference lines. It's an art, but it mostly works.

Any kind of sequence numbering in the source lines defeats "diff" entirely and everything after an insert looks like it changed.

So if you plan to move to git or one of its predecessors, plan to eliminate all sequence numbering in the source when you first move it into the repository.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ***@copper.net
Sent: Tuesday, October 10, 2017 7:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Peter, et al:

I am quite interested in git. And so I thought I would address a statement made about COBOL Numbering, and "standard" numbering locations in source.

There are some products that ship source and do use COBOL numbering while others use the 73-80 numbering (both are COBOL based products). In either case, they are generally maintained by using IEBUPDTE to insert the maintenance and/or USER changes.

I know of some user source that is maintained that way because that source is used where different "mods" have to be applied (terminology not to imply any relationship to SMPE).

So, where I am working, I am given to understand that there is a POC going with git. If they do not understand our shop, this could cause a headache (the stripping or ignoring 1-6 and/or 73-80).

In source that I maintain, the change codes are in 73-80, while NUM COB is used (ISPF), I don't care about that information -- I care about the change codes for what I maintain.

But I am just waiting for the chance to use git for ISPF panels, skeletons, COBOL source, REXX and ALC code that I am responsible for.

I'd like to run into the problems before the applications people have a chance to hit it so we can head that all off.

And I'd love to know the answers to this before the POC dies. So I am very interested in this thread.

Regards,
Steve Thompson



--- ***@BROADRIDGE.COM wrote:

From: "Farley, Peter x23353" <***@BROADRIDGE.COM>
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] git, z/OS and COBOL
Date: Tue, 10 Oct 2017 17:50:10 +0000

Frank,

The *ix compare utility is usually the "diff" command, and looking up the possible parameters for "diff" I don't see any options that would allow filtering the columns compared. It should be possible to craft a shell script to chop the line numbers off in temporary files and then do the compare with the chopped files, but the output would not, of course, reflect the line numbers in the difference listing (or "patch" compatible output file). Another possible issue would be whether it is even possible to make git use the shell script instead of "diff", and whether or not that is even desirable for any language but COBOL.

Looks like an opportunity for someone to contribute to the open-source community to implement a column filter for the "diff" and "patch" suite, and maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I use those (now just comment) COBOL line number columns to "tag" changed COBOL lines during maintenance edits to identify the project for which the change was done. I use ISPF "UNNUM" on all numbered source programs when I first edit them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the need/desire to use the COBOL line number columns for tags, but I can still see using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people are used to working.

Peter
--


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


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

[Pew, Curtis G]

Post by s***@COPPER.NET
I am quite interested in git. And so I thought I would address a statement made about COBOL Numbering, and "standard" numbering locations in source.
There are some products that ship source and do use COBOL numbering while others use the 73-80 numbering (both are COBOL based products). In either case, they are generally maintained by using IEBUPDTE to insert the maintenance and/or USER changes.
I know of some user source that is maintained that way because that source is used where different "mods" have to be applied (terminology not to imply any relationship to SMPE).
So, where I am working, I am given to understand that there is a POC going with git. If they do not understand our shop, this could cause a headache (the stripping or ignoring 1-6 and/or 73-80).
In source that I maintain, the change codes are in 73-80, while NUM COB is used (ISPF), I don't care about that information -- I care about the change codes for what I maintain.
But I am just waiting for the chance to use git for ISPF panels, skeletons, COBOL source, REXX and ALC code that I am responsible for.
I'd like to run into the problems before the applications people have a chance to hit it so we can head that all off.
And I'd love to know the answers to this before the POC dies. So I am very interested in this thread.

I think all the discussion of line numbering is a bit of a red herring. You can still use git on files that have line numbers. It may have to keep track of “changes” that don’t really change anything, and it may require additional storage and processing, but git still works.

In most cases line numbers imbedded in files are relics of older technologies, and you’re better off eliminating them. But if there’s a case where you do still need them, it won’t prevent current technology from doing its thing.

(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone who embraces it will regret it.)

[John McKown]

Post by s***@COPPER.NET

Post by s***@COPPER.NET
I am quite interested in git. And so I thought I would address a

statement made about COBOL Numbering, and "standard" numbering locations in
source.

Post by s***@COPPER.NET
There are some products that ship source and do use COBOL numbering

while others use the 73-80 numbering (both are COBOL based products). In
either case, they are generally maintained by using IEBUPDTE to insert the
maintenance and/or USER changes.

Post by s***@COPPER.NET
I know of some user source that is maintained that way because that

source is used where different "mods" have to be applied (terminology not
to imply any relationship to SMPE).

Post by s***@COPPER.NET
So, where I am working, I am given to understand that there is a POC

going with git. If they do not understand our shop, this could cause a
headache (the stripping or ignoring 1-6 and/or 73-80).

Post by s***@COPPER.NET
In source that I maintain, the change codes are in 73-80, while NUM COB

is used (ISPF), I don't care about that information -- I care about the
change codes for what I maintain.

Post by s***@COPPER.NET
But I am just waiting for the chance to use git for ISPF panels,

skeletons, COBOL source, REXX and ALC code that I am responsible for.

Post by s***@COPPER.NET
I'd like to run into the problems before the applications people have a

chance to hit it so we can head that all off.

Post by s***@COPPER.NET
And I'd love to know the answers to this before the POC dies. So I am

very interested in this thread.
I think all the discussion of line numbering is a bit of a red herring.
You can still use git on files that have line numbers. It may have to keep
track of “changes” that don’t really change anything, and it may require
additional storage and processing, but git still works.
In most cases line numbers imbedded in files are relics of older
technologies, and you’re better off eliminating them. But if there’s a case
where you do still need them, it won’t prevent current technology from
doing its thing.

​There is also the "git difftool" facility within git (
https://git-scm.com/docs/git-difftool ). I've not used it myself. But from
my reading, it is a way to have a specialized "diff" function. So you
could, possibly, write a "cobol-diff" which basically only compared columns
7-72. As an example of this, using BASH & process redirection. I can do
this using the GNU diff command like: diff​ -Z <(cut -b 7-72 file-one.cbl)
<(cut -b 7-72 file-two.cbl)

Some other interesting, to me, article on this:

http://jeetworks.org/setting-up-git-to-use-your-diff-viewer-or-editor-of-choice/

Post by s***@COPPER.NET
(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone who
embraces it will regret it.)
--
Pew, Curtis G
ITS Systems/Core/Administrative Services
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
I just child proofed my house.
But the kids still manage to get in.


Maranatha! <><
John McKown

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

[David Crayford]

Post by Pew, Curtis G

Post by s***@COPPER.NET
I'd like to run into the problems before the applications people have a chance to hit it so we can head that all off.
And I'd love to know the answers to this before the POC dies. So I am very interested in this thread.

I think all the discussion of line numbering is a bit of a red herring. You can still use git on files that have line numbers. It may have to keep track of “changes” that don’t really change anything, and it may require additional storage and processing, but git still works.
In most cases line numbers imbedded in files are relics of older technologies, and you’re better off eliminating them. But if there’s a case where you do still need them, it won’t prevent current technology from doing its thing.
(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone who embraces it will regret it.)

Indeed! If you can ditch those relics all the better. I'm a big fan of
git too. It's revolutionized our workflows on z/OS. We use bitbucket and
Jira from Atlassian which integrate beautifully. We use agile and raise
a Jira for each feature branch. This gives us visibility to every line
of code that has been changed for each feature. We do code reviews on
pull requests which is great for QA. Code reviews find bugs early and
we've found find more bugs than systems testing.

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

[Paul Gilmartin]

Post by Farley, Peter x23353
Once you start using git (or for that matter any of the *ix-based source repository utilities) for mainframe source maintenance, you stop using IEBUPDTE (or any other sequence-number-based source update process) and start using the "patch" utility. The input to "patch" is the output from "diff" (when properly configured with options, as is done inside of git and other source repository utilities).

The input to IEBUPDTE is the output from "SuperC" (when properly configured with options).
The glaring restriction of IEBUPDTE is that it chokes on an apparent IEBUPTDE command
appearing as a data line, as might happen in a JCL member invoking an IEBUPDTE step.

And Fixed-80.

Post by Farley, Peter x23353
The "diff" and "patch" utilities could care less what is on each line. They just compare lines and try to find the maximal number of non-differences (sets of matching lines) between the minimal number of difference lines. It's an art, but it mostly works.

SuperC appears to use a similar algorithm.

Post by Farley, Peter x23353
Any kind of sequence numbering in the source lines defeats "diff" entirely and everything after an insert looks like it changed.

Only if you are so foolish as to configure your editor to renumber in each session.

Post by Farley, Peter x23353
So if you plan to move to git or one of its predecessors, plan to eliminate all sequence numbering in the source when you first move it into the repository.

Or don't renumber. I once wrote a utility using SuperC and IEBUPDTE to repair
carelessly modified sequence numbers.

-- gil

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

[scott Ford]

Frank,

I do all my editing up on z/OS, the other developers, Java guys do it via desktop. We don't use GIT on z/OS yet.

Scott

Post by Paul Gilmartin

Once you start using git (or for that matter any of the *ix-based source repository utilities) for mainframe source maintenance, you stop using IEBUPDTE (or any other sequence-number-based source update process) and start using the "patch" utility. The input to "patch" is the output from "diff" (when properly configured with options, as is done inside of git and other source repository utilities).

The input to IEBUPDTE is the output from "SuperC" (when properly configured with options).
The glaring restriction of IEBUPDTE is that it chokes on an apparent IEBUPTDE command
appearing as a data line, as might happen in a JCL member invoking an IEBUPDTE step.
And Fixed-80.

The "diff" and "patch" utilities could care less what is on each line. They just compare lines and try to find the maximal number of non-differences (sets of matching lines) between the minimal number of difference lines. It's an art, but it mostly works.

SuperC appears to use a similar algorithm.

Any kind of sequence numbering in the source lines defeats "diff" entirely and everything after an insert looks like it changed.

Only if you are so foolish as to configure your editor to renumber in each session.

So if you plan to move to git or one of its predecessors, plan to eliminate all sequence numbering in the source when you first move it into the repository.

Or don't renumber. I once wrote a utility using SuperC and IEBUPDTE to repair
carelessly modified sequence numbers.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

[s***@COPPER.NET]

--- ***@BROADRIDGE.COM wrote:

From: "Farley, Peter x23353" <***@BROADRIDGE.COM>
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] git, z/OS and COBOL
Date: Tue, 10 Oct 2017 23:19:38 +0000

Steve,

Once you start using git (or for that matter any of the *ix-based source repository utilities) for mainframe source maintenance, you stop using IEBUPDTE (or any other sequence-number-based source update process) and start using the "patch" utility. The input to "patch" is the output from "diff" (when properly configured with options, as is done inside of git and other source repository utilities).

The "diff" and "patch" utilities could care less what is on each line. They just compare lines and try to find the maximal number of non-differences (sets of matching lines) between the minimal number of difference lines. It's an art, but it mostly works.

Any kind of sequence numbering in the source lines defeats "diff" entirely and everything after an insert looks like it changed.

So if you plan to move to git or one of its predecessors, plan to eliminate all sequence numbering in the source when you first move it into the repository.

<snippage>

So how does one merge fixes into source if the "source" numbering is removed? The fixes may issue delete of lines, addition of lines and replace of lines and there may be multiple delta decks to be applied anytime one wants to do changes to the source. This is not a spec I'm providing, this is a requirement I would have to live with.

From what you say, diff and patch will not know or understand where the source being supplied to update the original source goes.

So, I don't think your method is going to fly with source coming from a vendor that has to be updated via IEBUPDTE, nor is it going to fly with one of our groups that uses IEBUPDTE to update their source...

This is the kind of show stopper that we need to find a solution for, because it will be the DEATH of the POC. That is, git will be DBA -- Dead Before Arrival if there is no way to solve this.

Regards,
Steve Thompson

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

[Andrew Rowley]

Post by s***@COPPER.NET
So how does one merge fixes into source if the "source" numbering is removed? The fixes may issue delete of lines, addition of lines and replace of lines and there may be multiple delta decks to be applied anytime one wants to do changes to the source. This is not a spec I'm providing, this is a requirement I would have to live with.
From what you say, diff and patch will not know or understand where the source being supplied to update the original source goes.

If you are using IEBUPDTE to merge files I would expect your numbering
would be very stable, so there would not be many updates due to renumbering.

But git isn't an update tool, it is a tool to store revisions of files.
Updating (whether via manual edit, IEBUPDTE or any other process) is
done outside of git and then the change is committed to git.

You can then retrieve previous versions, compare the current version to
any previous version etc. If you distribute changes via IEBUPDTE, you
could get any 2 versions out of git and generate an IEBUPDTE deck to go
from one to the other.

You can generate patches, but I think it would be unusual because the
patch is very dependent on being applied to a specific revision of the
source, and manual patching makes tracking revisions a manual process.
You have the same problem with IEBUPDTE - you need an external way to
track the version of the file you are applying the update to (e.g. SMP/E).

[Paul Gilmartin]

Post by s***@COPPER.NET
So how does one merge fixes into source if the "source" numbering is removed? The fixes may issue delete of lines, addition of lines and replace of lines and there may be multiple delta decks to be applied anytime one wants to do changes to the source. This is not a spec I'm providing, this is a requirement I would have to live with.
From what you say, diff and patch will not know or understand where the source being supplied to update the original source goes.

Patch uses a combination of relative line numbers and context lines (such as appear
in a SuperC listing). It works.

Post by s***@COPPER.NET
So, I don't think your method is going to fly with source coming from a vendor that has to be updated via IEBUPDTE, nor is it going to fly with one of our groups that uses IEBUPDTE to update their source...

Do those groups create their IEBUPDTE command files by hand?

-- gil

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

[Clark Morris]

[Default] On 10 Oct 2017 17:30:54 -0700, in bit.listserv.ibm-main

Post by Paul Gilmartin

Post by s***@COPPER.NET
So how does one merge fixes into source if the "source" numbering is removed? The fixes may issue delete of lines, addition of lines and replace of lines and there may be multiple delta decks to be applied anytime one wants to do changes to the source. This is not a spec I'm providing, this is a requirement I would have to live with.
From what you say, diff and patch will not know or understand where the source being supplied to update the original source goes.

Patch uses a combination of relative line numbers and context lines (such as appear
in a SuperC listing). It works.

Post by s***@COPPER.NET
So, I don't think your method is going to fly with source coming from a vendor that has to be updated via IEBUPDTE, nor is it going to fly with one of our groups that uses IEBUPDTE to update their source...

Do those groups create their IEBUPDTE command files by hand?

Other than by total replacement, how would you distribute source
maintenance other than by an IEBUPDTE like maintenance mechanism that
depends on sequence numbers?

Clark Morris

Post by Paul Gilmartin
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

[s***@COPPER.NET]

My comments are on the bottom because it made more sense to put them after the question(s).

--- ***@NS.SYMPATICO.CA wrote:

From: Clark Morris <***@NS.SYMPATICO.CA>
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] git, z/OS and COBOL
Date: Tue, 10 Oct 2017 21:56:34 -0300

[Default] On 10 Oct 2017 10:48:59 -0700, in bit.listserv.ibm-main

Post by Edgington, Jerry
Frank,

<SNIP>

Post by Edgington, Jerry
Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades.

Vendors which supply COBOL source probably use IEBUPDTE or their own
proprietary means of updating (and maybe even their own library
system) that depends on sequence numbers in columns 1 - 6. In the
1990s I had to deal with vendor source that was updated by their
system using sequence numbers. As I recall, JES2 and JES3 source
maintenance used IEBUPDTE and sequence numbers in 73 - 80 back in the
1980s when I was doing SMP/E work (I was at an installation that went
from HASP to JES3 to JES2).

Clark Morris
<snippage>

And as I recall, that was still true of JES2/3 macros at OS/390 V2R4. I haven't paid any attention to them in that way since then. I haven't touched much in JES2 or JES3 since I stopped working on OBS/ACS/WYLBUR.


Paul:

Your question had to do with manually doing IEBUPDTE commands. The users where I am probably do, but I honestly don't know. The ISV(s) that provide source maint; I have no clue how they do theirs.

If you need me to answer anything else on this, have some patience, I probably won't get back to this until next week when I am back in my office.

Regards,
Steve Thompson

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

[Paul Gilmartin]

This post might be inappropriate. Click to display it.

[Clark Morris]

[Default] On 10 Oct 2017 20:18:32 -0700, in bit.listserv.ibm-main

Post by Paul Gilmartin

Post by s***@COPPER.NET
Your question had to do with manually doing IEBUPDTE commands. The users where I am probably do, but I honestly don't know. The ISV(s) that provide source maint; I have no clue how they do theirs.

I have not used IEBUPDTE extensively. When I contributed to Charlotte, I made
more use of CMS UPDATE, which is similar to IEBUPDTE, but with further features
useful for source code control. XEDIT can generate CMS UPDATE control files,
but they contain some noise which I filtered out with a final pass through SuperC.
There are more powerful tools than IEBUPDTE. Embrace them.

It's not I but the vendors who have to embrace them and supply them.
The using organization has to use the vendor's method to apply
maintenance and updates. Does your organization supply source to its
customers and what updating method does it use?

Clark Morris

Post by Paul Gilmartin
Examples include diff3 and various GUI merge utilities.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

[Anne & Lynn Wheeler]

Post by Paul Gilmartin
I have not used IEBUPDTE extensively. When I contributed to
Charlotte, I made more use of CMS UPDATE, which is similar to
IEBUPDTE, but with further features useful for source code control.
XEDIT can generate CMS UPDATE control files, but they contain some
noise which I filtered out with a final pass through SuperC.
There are more powerful tools than IEBUPDTE. Embrace them.
Examples include diff3 and various GUI merge utilities.

original CMS UPDATE was single level (mid-60s) ... much more akin to
IEBUPDATE. As undergraduate in the 60s, I did preprocessor to CMS UPDATE
that support "$" which would do the sequence numbering on the inserted
source cards ... eliminating having to manually add them to each one.

Later at the science center there was joint project with Endicott for
modifications to CP/67 to support 370 virtual memory virtual machines
(in addition to 360/67 virtual memory virtual machines) ... aka
simulating 370 virtual memory architecture on real 360/67.

This was originally implemented all in EXEC ... repeatedly processing
CNTRL files and multiple levels of update files.

Originally had three levels ... "L" updates to CP/67 (my enhancements to
base product CP/67), "H" udpates to CP/67 to provide 370 virtual
machines.

The combination of "L" & "H" updated CP/67 then ran regularly on
production 360/67. Lots of 370 operating system softwarre started
development in "H" 370 virtual machines.

Then the "I" updates to CP/67 to change from running 360/67 architecture
to running 370 architecture ... build typically required applying "L",
"H", & "I". This was running regularly in "H" 370 virtual machines a
year before the first 370/145 engineering machine supporting virtual
memory was operational (and long before 370 virtual memory was
announced). In fact, the first 370/145 engineering machine used an "I"
level system as early software to test operation of the machine.

trivia: initial "I" system IPL failed. It turned out that they had
reversed the B2 op-codes for RRB & PTLB ... quickly diagnosed the
problem and zap'ed the kernel to correspond with the "incorrect"
implementation (they eventually corrected the hardware).

trivia: the person responsible for Internet DNS system had been MIT
student at the time working at the science center and did some of the
original CMS multi-level source update implementation.

past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

Later some San Jose engineers added support for 3330s & 2305s device for
CP/67-SJ. This ran production internally on most of the 370 systems for
quite some time.

Later the multi-level update support was added to both standard UPDATE
and eventually XEDIT.

I had kept archives of much of the science center files on tapes. In
mid-80s, when Melinda Varian was doing her VM History ... she contacted
me about getting copies of the original multi-level source update
implementation in EXEC. It was fortunate timing ... IBM Almaden Research
was starting to have datacenter operational problem (operators were
mounting random tapes as scratch), and even tho I had replicated the
archives on three different tapes ... they were all in the IBM Almaden
Research tape library ... and operators managed to mount all three
archive tapes (and several of my other tapes) as scratch. They never got
around to notifying users until long after the damage was done.

some old email exchange with Melinda (some repeat and not all about
multi-level update
http://www.garlic.com/~lynn/2011c.html#email850820
http://www.garlic.com/~lynn/2006w.html#email850906
http://www.garlic.com/~lynn/2006w.html#email850906b
http://www.garlic.com/~lynn/2006w.html#email850908
http://www.garlic.com/~lynn/2011c.html#email850908
http://www.garlic.com/~lynn/2014e.html#email850908
http://www.garlic.com/~lynn/2007b.html#email860111
http://www.garlic.com/~lynn/2011c.html#email860111
http://www.garlic.com/~lynn/2011b.html#email860217
http://www.garlic.com/~lynn/2011b.html#email860217b
http://www.garlic.com/~lynn/2011c.html#email860407

other trivia: much of internal software development was then being done
using CMS and CMS multi-level update ... including MVS components like
JES2 ... then when came time for release ... they had to port to
standard MVS source distribution process.

One of the VM/370 issues was even though (originally CP/67) maintenance
distribution was all done using the CMS multi-level source ... every new
release ... they would permanently apply all maintenance & development
updates and resequence each module. Lots of internal sites and customers
had developed extensive source updates (some claim there was more source
updates on the VM/370 SHARE Waterloo tape than in the base system).

The release-to-release resequencing became something of hassle ... so in
the late 70s, I wrote a couple programs ... one would take a previous
release with all maintenance applied and the new resequenced release and
generate an update that represented the change (mostly development) from
the old release to the new release, but using the previous release
sequence numbers. It was then became a simpler issue to resolve
conflicts with local updates and an update that converted to the latest
release. Then another program would resequence the resolved local
updates from the previous release sequence numbers to the current
release sequence numbers.

[Jerry Callen]

Regarding line numbering: git has the ability to run complementary "clean" and "smudge" filters to be used when moving source between the repo and the working directory; these might prove useful. See https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes for more information.

That said - I agree that if you CAN move away from line numbering, you SHOULD.

(Shameless plug...) BTW, if anyone has git questions specific to the z/OS port of git from Rocket, please ask them on Rocket's open source forum at https://forum.rocketsoftware.com/c/rocket-z-os-open-source-languages-tools. I (and other Rocket employees) monitor it regularly.

-- Jerry

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

[Frank Swarbrick]

This looks interesting. Do you know of a UNIX utility that would replace the first 6 characters with spaces?
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Jerry Callen <***@NARSIL.ORG>
Sent: Wednesday, October 11, 2017 11:14 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Regarding line numbering: git has the ability to run complementary "clean" and "smudge" filters to be used when moving source between the repo and the working directory; these might prove useful. See https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes for more information.

That said - I agree that if you CAN move away from line numbering, you SHOULD.

(Shameless plug...) BTW, if anyone has git questions specific to the z/OS port of git from Rocket, please ask them on Rocket's open source forum at https://forum.rocketsoftware.com/c/rocket-z-os-open-source-languages-tools. I (and other Rocket employees) monitor it regularly.

-- Jerry

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

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

[Farley, Peter x23353]

The gawk or awk (either one should work here) script utility could do it:

awk -e '{ print " " substr($0, 7) }' < input.file > output.file

Note single quotes (apostrophes) surrounding the script, double quotes within for the 6 blanks.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Wednesday, October 11, 2017 1:23 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

This looks interesting. Do you know of a UNIX utility that would replace the first 6 characters with spaces?
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Jerry Callen <***@NARSIL.ORG>
Sent: Wednesday, October 11, 2017 11:14 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Regarding line numbering: git has the ability to run complementary "clean" and "smudge" filters to be used when moving source between the repo and the working directory; these might prove useful. See https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes for more information.

That said - I agree that if you CAN move away from line numbering, you SHOULD.

(Shameless plug...) BTW, if anyone has git questions specific to the z/OS port of git from Rocket, please ask them on Rocket's open source forum at https://forum.rocketsoftware.com/c/rocket-z-os-open-source-languages-tools. I (and other Rocket employees) monitor it regularly.

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

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

[Paul Gilmartin]

Post by Anne & Lynn Wheeler
One of the VM/370 issues was even though (originally CP/67) maintenance
distribution was all done using the CMS multi-level source ... every new
release ... they would permanently apply all maintenance & development
updates and resequence each module. ...

Why?

Post by Anne & Lynn Wheeler
... Lots of internal sites and customers
had developed extensive source updates (some claim there was more source
updates on the VM/370 SHARE Waterloo tape than in the base system).
The release-to-release resequencing became something of hassle ... so in
the late 70s, I wrote a couple programs ... one would take a previous
release with all maintenance applied and the new resequenced release and
generate an update that represented the change (mostly development) from
the old release to the new release, but using the previous release
sequence numbers.

Nowadays, SuperC will do that for you.

-- gil

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

[Jesse 1 Robinson]

Today LinkedIn news note points to an article on Git for z/OS by Rosalind Radcliffe, who has been speaking at SHARE for some time on its virtues. This very long URL goes through LinkedIn.

https://www.linkedin.com/pulse/git-zos-development-how-do-you-build-now-can-rosalind-radcliffe/?trk=eml-email_feed_ecosystem_digest_01-recommended_articles-7-PBYN&midToken=AQFJkRF5baAZ4A&fromEmail=fromEmail&ut=3GEOaGOlxTtnY1

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Crayford
Sent: Thursday, October 12, 2017 3:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: git, z/OS and COBOL

Post by Pew, Curtis G

Post by s***@COPPER.NET
I'd like to run into the problems before the applications people have a chance to hit it so we can head that all off.
And I'd love to know the answers to this before the POC dies. So I am very interested in this thread.

I think all the discussion of line numbering is a bit of a red herring. You can still use git on files that have line numbers. It may have to keep track of “changes” that don’t really change anything, and it may require additional storage and processing, but git still works.
In most cases line numbers imbedded in files are relics of older technologies, and you’re better off eliminating them. But if there’s a case where you do still need them, it won’t prevent current technology from doing its thing.
(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone
who embraces it will regret it.)

Indeed! If you can ditch those relics all the better. I'm a big fan of git too. It's revolutionized our workflows on z/OS. We use bitbucket and Jira from Atlassian which integrate beautifully. We use agile and raise a Jira for each feature branch. This gives us visibility to every line of code that has been changed for each feature. We do code reviews on pull requests which is great for QA. Code reviews find bugs early and we've found find more bugs than systems testing.


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

[David Crayford]

Thanks Jesse,

That's great stuff! The README.TXT gave me directions on how to setup a
Jenkins slave on z/OS. We're going to use this starting next week.

Post by Jesse 1 Robinson
Today LinkedIn news note points to an article on Git for z/OS by Rosalind Radcliffe, who has been speaking at SHARE for some time on its virtues. This very long URL goes through LinkedIn.
https://www.linkedin.com/pulse/git-zos-development-how-do-you-build-now-can-rosalind-radcliffe/?trk=eml-email_feed_ecosystem_digest_01-recommended_articles-7-PBYN&midToken=AQFJkRF5baAZ4A&fromEmail=fromEmail&ut=3GEOaGOlxTtnY1
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----
Sent: Thursday, October 12, 2017 3:56 AM
Subject: (External):Re: git, z/OS and COBOL

Post by Pew, Curtis G

Post by s***@COPPER.NET
I'd like to run into the problems before the applications people have a chance to hit it so we can head that all off.
And I'd love to know the answers to this before the POC dies. So I am very interested in this thread.

I think all the discussion of line numbering is a bit of a red herring. You can still use git on files that have line numbers. It may have to keep track of “changes” that don’t really change anything, and it may require additional storage and processing, but git still works.
In most cases line numbers imbedded in files are relics of older technologies, and you’re better off eliminating them. But if there’s a case where you do still need them, it won’t prevent current technology from doing its thing.
(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone
who embraces it will regret it.)

Indeed! If you can ditch those relics all the better. I'm a big fan of git too. It's revolutionized our workflows on z/OS. We use bitbucket and Jira from Atlassian which integrate beautifully. We use agile and raise a Jira for each feature branch. This gives us visibility to every line of code that has been changed for each feature. We do code reviews on pull requests which is great for QA. Code reviews find bugs early and we've found find more bugs than systems testing.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

[scott Ford]

We use GIT for source as I stated above. I feel the learning curve is a bit
much.
But there are a couple interactive learning tutorials that a feel are good.

The 'fly in the ointment' is when you have done a 'commit,push' and have
one approval for a pull request.
Like any other source mgmt system you have to know how to back out a PR for
example. I am still learning.

The diff and blame functions using GIT with Bitbucket are great...


Scott

Post by David Crayford
Thanks Jesse,
That's great stuff! The README.TXT gave me directions on how to setup a
Jenkins slave on z/OS. We're going to use this starting next week.

Post by Jesse 1 Robinson
Today LinkedIn news note points to an article on Git for z/OS by

Rosalind Radcliffe, who has been speaking at SHARE for some time on its
virtues. This very long URL goes through LinkedIn.
https://www.linkedin.com/pulse/git-zos-development-how-do-you-build-now-can-rosalind-radcliffe/?trk=eml-email_feed_ecosystem_digest_01-recommended_articles-7-PBYN&midToken=AQFJkRF5baAZ4A&fromEmail=fromEmail&ut=3GEOaGOlxTtnY1

Post by Jesse 1 Robinson
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----

On Behalf Of David Crayford

Post by Jesse 1 Robinson
Sent: Thursday, October 12, 2017 3:56 AM
Subject: (External):Re: git, z/OS and COBOL

Post by Pew, Curtis G

Post by s***@COPPER.NET
I'd like to run into the problems before the applications people have

a chance to hit it so we can head that all off.

Post by Jesse 1 Robinson

Post by Pew, Curtis G

Post by s***@COPPER.NET
And I'd love to know the answers to this before the POC dies. So I am

very interested in this thread.

Post by Jesse 1 Robinson

Post by Pew, Curtis G
I think all the discussion of line numbering is a bit of a red herring.

You can still use git on files that have line numbers. It may have to keep
track of “changes” that don’t really change anything, and it may require
additional storage and processing, but git still works.

Post by Jesse 1 Robinson

Post by Pew, Curtis G
In most cases line numbers imbedded in files are relics of older

technologies, and you’re better off eliminating them. But if there’s a case
where you do still need them, it won’t prevent current technology from
doing its thing.

Post by Jesse 1 Robinson

Post by Pew, Curtis G
(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone
who embraces it will regret it.)

Indeed! If you can ditch those relics all the better. I'm a big fan of

git too. It's revolutionized our workflows on z/OS. We use bitbucket and
Jira from Atlassian which integrate beautifully. We use agile and raise a
Jira for each feature branch. This gives us visibility to every line of
code that has been changed for each feature. We do code reviews on pull
requests which is great for QA. Code reviews find bugs early and we've
found find more bugs than systems testing.

Post by Jesse 1 Robinson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

[Frank Myers]

1) no
2) Ispf on Z/OS, JEDIT on other platforms
3) unix
4) no
5) monimal
6) usually ssh, and tn3270
7) it varies
8) no

[e***@gmail.com]

Frank, I didn't see your post until now. :(. But, I will try to answer some of your questions.


1) Did you have to eliminate the line numbers in columns 1-6?
- No, in my case, I FTP'ed the source from the PDS to my workstation, copied them to a package in my Eclipse workspace, then save them to the Git server
2) What do your developers use for their COBOL editor? ISPF? Off platform IDE?
- IBM has just developed an ISPF interface to use a Git client. So, ISPF and an IDE, like Eclipse
3) Do you compile using JCL or UNIX?
- the zJenkins code on Github, using Groovy with DBB APIs to preform the compiles under USS
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS and workstations?
- No, with zJenkins code, the workstation saves the source code to the Git server, and zJenkins uses the Git client on z/OS to pull the source code. Jenkins has a SSH connection to run a Jenkins z/OS slave
5) How much UNIX knowledge do your developers need to be productive in this environment?
- For this configuration, using zJenkins, none. The developers only deal with Eclipse and pushing the source code to Git
6) How do you connect to z/OS UNIX? ssh? TSO OMVS?
- Jenkins connects to z/OS using SSH and the UserID needs to have an OMVS, with enough memory to perform its functions
7) Do you use a GUI/visual merge product? How?
- Git has the ability to merge source code, and show the differences.
8) Anything else you'd like to add!
- More information about zJenkins is on Github, and hopefully I will presenting a how to session for zJenkins at SHARE in Pittsburgh in August, 2019

[n***@gmail.com]

For anyone interested in a free light weight Git to ISPF tool check out