Re: git, z/OS and COBOL
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 On Fri, Oct 13, 2017 at 8:40 AM David Crayford <dcrayf...@gmail.com> wrote: > 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. > > > On 12/10/2017 11:28 PM, Jesse 1 Robinson wrote: > > 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=AQFJkRF5baAZ4A=fromEmail=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 > > robin...@sce.com > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of David Crayford > > Sent: Thursday, October 12, 2017 3:56 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: git, z/OS and COBOL > > > > On 11/10/2017 9:48 PM, Pew, Curtis G wrote: > >>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
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. On 12/10/2017 11:28 PM, Jesse 1 Robinson wrote: 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=AQFJkRF5baAZ4A=fromEmail=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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, October 12, 2017 3:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: git, z/OS and COBOL On 11/10/2017 9:48 PM, Pew, Curtis G wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
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=AQFJkRF5baAZ4A=fromEmail=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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, October 12, 2017 3:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: git, z/OS and COBOL On 11/10/2017 9:48 PM, Pew, Curtis G wrote: >> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On 11/10/2017 9:48 PM, Pew, Curtis G wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On 11/10/2017 11:21 AM, ste...@copper.net wrote: 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). -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On Wed, 11 Oct 2017 12:01:19 -0700, Anne & Lynn Wheeler wrote: > >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? > ... 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: > 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
Re: git, z/OS and COBOL
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Wednesday, October 11, 2017 1:23 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU> on behalf of Jerry Callen <jcal...@narsil.org> Sent: Wednesday, October 11, 2017 11:14 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU> on behalf of Jerry Callen <jcal...@narsil.org> Sent: Wednesday, October 11, 2017 11:14 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On Wed, Oct 11, 2017 at 8:48 AM, Pew, Curtis Gwrote: > On Oct 10, 2017, at 6:04 PM, ste...@copper.net wrote: > > > > 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. > 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/ > > (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 > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On Oct 10, 2017, at 6:04 PM, ste...@copper.netwrote: > > 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.) -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Git, z/OS and Cobol
To all, Here is what is possible using only Open Source tools. - Eclipse based IDE, like the Java developers - Adding the IBM Aqua Eclipse plugin, here is a link https://developer.ibm.com/mainframe/products/downloads/ With the IBM plugin, you can do things like submit batch jobs, view the JES2 batch output, view the SYSLOG, view and edit USS directories or z/OS datasets and much more - Add the Jenkins Eclipse plugin - The GIT plugin would probably already be installed, if not install it - Build and install Jenkins - This can be installed on Linux on Z, Ubuntu is easier than Redhat, because of the Jenkins requirements. Haven't tried SUSE - Install the Jenkins Plugins for GIT, and whatever else you want, like ANT or Maven. There might be others - Download and install GIT for z/OS from Rocket Software - Unzip it and configure Now, from the IDE, you can add, delete, modify anything on z/OS and have it pushed to USS on z/OS. - this will not put the code into PDS or any other z/OS dataset - You can write an ANT or Groovy script to copy the code from USS to the proper location - Jenkins might be able to interface with mainframe SCLM tools - You can look at purchasing tools to build and deploy the code Suggestion, if you proceed is to add a mime type to each of the source code to identify the type, like *.cpy for Cobol copybook, or *.rex for REXX. Basically, any developer can use this layout to perform most, if not all their job functions, from the IDE, instead of using ISPF. That will save z/OS cycles, developer time and much more Jerry Edgington Project Manager for SHARE DevOps track 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
[Default] On 10 Oct 2017 20:18:32 -0700, in bit.listserv.ibm-main 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: >On Tue, 10 Oct 2017 19:17:25 -0700, ste...@copper.net wrote: >> >>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 > >Examples include diff3 and various GUI merge utilities. > >-- gil > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
> On Oct 10, 2017, at 9:17 PM, ste...@copper.net <ste...@copper.net> wrote: > > My comments are on the bottom because it made more sense to put them after > the question(s). > > --- cfmpub...@ns.sympatico.ca <mailto:cfmpub...@ns.sympatico.ca> wrote: > > From: Clark Morris <cfmpub...@ns.sympatico.ca > <mailto:cfmpub...@ns.sympatico.ca>> > To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@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 > peter.far...@broadridge.com <mailto:peter.far...@broadridge.com> (Farley, > Peter x23353) wrote: > >> Frank, >> > > >> 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 > I haven’t been exposed to them (Vendors who supplied source) in 4-5 years. The ones I have dealt with were payroll systems and accounting systems and SMF reporting systems. all used iebupdte and it really works well (for these systems). However some of their systems were lets say less than fool proof. They would send out updates to copybooks and not necessarily recompile the programs that used the copy books. When our person got an update for a copybook, he used fileaid to scan the source library and any source that used the copybook was recompiled, no matter what the vendor said. This is a second hand story. One day the person got an update for a copybook from the vendor and was told that only Program #1 & 3 4 6 7 10 needed to be recompiled. He did a scan for other programs that used the copy book and found 15. He called up the vendor and got into a heated discussion about the issue. The updates were really needed because of some tax thing. We went ahead and compiled 15 instead of the 6 that were called for. The update went well and the recompiles went well and moved into testing and ran well. Then they were moved into production and everything went well. The salesman for the product happened to be non and we asked for a quick meeting about this. The meeting took 30 minutes and the salesman came out and headed for a phone and we couldn’t hear the conversation other than it was animated lets say. The salesman took it to his boss and apparently it got the whole company involved. From then on when copybooks were updated *All* of the referencing programs got recompiled. The vendor was not a friend anymore and relationship got strained. We were no longer asked out for any dinners (boo hoo). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On Tue, 10 Oct 2017 19:17:25 -0700, ste...@copper.net wrote: > >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. Examples include diff3 and various GUI merge utilities. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
My comments are on the bottom because it made more sense to put them after the question(s). --- cfmpub...@ns.sympatico.ca wrote: From: Clark Morris <cfmpub...@ns.sympatico.ca> To: IBM-MAIN@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 peter.far...@broadridge.com (Farley, Peter x23353) wrote: >Frank, > >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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Distributing source maintenance without sequence numbers was Re: git, z/OS and COBOL
On Tue, 10 Oct 2017 21:59:54 -0300, Clark Morris wrote: > >>>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. >> >>>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? > "patch" works. It does not depend on sequence numbers. It's widely used. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Distributing source maintenance without sequence numbers was Re: git, z/OS and COBOL
[Default] On 10 Oct 2017 17:30:54 -0700, in bit.listserv.ibm-main 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: >On Tue, 10 Oct 2017 17:21:29 -0700, stevet wrote: >> >>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. > >>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 >-- gil > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
[Default] On 10 Oct 2017 10:48:59 -0700, in bit.listserv.ibm-main peter.far...@broadridge.com (Farley, Peter x23353) wrote: >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 > >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-MAIN@LISTSERV.UA.EDU] On >Behalf Of Frank Swarbrick >Sent: Tuesday, October 10, 2017 1:19 PM >To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU> on behalf of >Edgington, Jerry <jerry.edging...@kroger.com> >Sent: Tuesday, October 10, 2017 10:47 AM >To: IBM-MAIN@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 conne
Re: git, z/OS and COBOL
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 On Oct 10, 2017, 7:35 PM -0400, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>, wrote: > On Tue, 10 Oct 2017 23:19:38 +, Farley, Peter x23353 wrote: > > > > 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, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
On Tue, 10 Oct 2017 23:19:38 +, Farley, Peter x23353 wrote: > >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, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
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-MAIN@LISTSERV.UA.EDU] On Behalf Of ste...@copper.net Sent: Tuesday, October 10, 2017 7:05 PM To: IBM-MAIN@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 --- peter.far...@broadridge.com wrote: From: "Farley, Peter x23353" <peter.far...@broadridge.com> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] git, z/OS and COBOL Date: Tue, 10 Oct 2017 17:50:10 + 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 re
Re: git, z/OS and COBOL
Thanks Scott. So you do all of your source code editing on z/OS? Do you use GIT on z/OS for any of this? From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of scott Ford <idfli...@gmail.com> Sent: Tuesday, October 10, 2017 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: git, z/OS and COBOL Frank: We have a Develop Branch ...and when we put in a fix for example. ...1. Created a GIT branch off Dev ..we have an internal fix number. ...2 My GIT Repo is on my ldaptop. ...3 I then upload either via FTP or IND$FILE to my Sandbox ...4 Make the changes on my Sandbox, compile, link and unit test ...5 when everything looks good, download source to my Laptop ...6 Commit the source ...7 Push the source .. 8 When we merge after approval, this kicksoff our CI process which clones the source, does a complete build of our product ... All this is done with CI-Jenkins ... HTH Scott On Tue, Oct 10, 2017 at 4:37 PM, Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Thanks Scott. Let me see if I understand this. It sounds like your > developers, when starting changes for a program, use git to "check out" the > source code to their workstation. Do they make changes, save locally, FTP > to z/OS and then compile on z/OS? Are these last two steps (assuming I am > understanding you) "automated" in any manner? Or do they have to "manually > FTP" and then manually submit the compile job? > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of scott Ford <idfli...@gmail.com> > Sent: Tuesday, October 10, 2017 1:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: git, z/OS and COBOL > > 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 > > On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf <k...@dovetail.com> wrote: > > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > > > > *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<http://www.idmworks.com> > > scott.f...@idmworks.com > > Blog: > www.idmworks.com/blog<http://www.idmworks.com/blog<http://www.idmworks.com/blog<http://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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM
Re: git, z/OS and COBOL
Frank: We have a Develop Branch ...and when we put in a fix for example. ...1. Created a GIT branch off Dev ..we have an internal fix number. ...2 My GIT Repo is on my ldaptop. ...3 I then upload either via FTP or IND$FILE to my Sandbox ...4 Make the changes on my Sandbox, compile, link and unit test ...5 when everything looks good, download source to my Laptop ...6 Commit the source ...7 Push the source .. 8 When we merge after approval, this kicksoff our CI process which clones the source, does a complete build of our product ... All this is done with CI-Jenkins ... HTH Scott On Tue, Oct 10, 2017 at 4:37 PM, Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Thanks Scott. Let me see if I understand this. It sounds like your > developers, when starting changes for a program, use git to "check out" the > source code to their workstation. Do they make changes, save locally, FTP > to z/OS and then compile on z/OS? Are these last two steps (assuming I am > understanding you) "automated" in any manner? Or do they have to "manually > FTP" and then manually submit the compile job? > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of scott Ford <idfli...@gmail.com> > Sent: Tuesday, October 10, 2017 1:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: git, z/OS and COBOL > > 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 > > On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf <k...@dovetail.com> wrote: > > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > > > > *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<http://www.idmworks.com> > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog<http://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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *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 scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protecte
Re: git, z/OS and COBOL
Thanks Scott. Let me see if I understand this. It sounds like your developers, when starting changes for a program, use git to "check out" the source code to their workstation. Do they make changes, save locally, FTP to z/OS and then compile on z/OS? Are these last two steps (assuming I am understanding you) "automated" in any manner? Or do they have to "manually FTP" and then manually submit the compile job? From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of scott Ford <idfli...@gmail.com> Sent: Tuesday, October 10, 2017 1:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: git, z/OS and COBOL 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 On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf <k...@dovetail.com> wrote: > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *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<http://www.idmworks.com> scott.f...@idmworks.com Blog: www.idmworks.com/blog<http://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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
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 On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolfwrote: > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *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 scott.f...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
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-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Tuesday, October 10, 2017 11:50 AM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, October 10, 2017 1:19 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU> on behalf of Edgington, Jerry <jerry.edging...@kroger.com> Sent: Tuesday, October 10, 2017 10:47 AM To: IBM-MAIN@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, B
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, October 10, 2017 1:19 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU> on behalf of Edgington, Jerry <jerry.edging...@kroger.com> Sent: Tuesday, October 10, 2017 10:47 AM To: IBM-MAIN@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
Re: git, z/OS and COBOL
On Tue, 10 Oct 2017 17:18:44 +, Frank Swarbrick wrote: >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. > Turn AUTONUMBER off in your editor. If your lines are numbered consecutively, re-number with an interval of 100 or more so there's slack for insertions. What editor are you using? What others are available? >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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: git, z/OS and COBOL
Sorry Frank. Here is my email address at work jerry.edging...@kroger.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edgington, Jerry Sent: Tuesday, October 10, 2017 1:20 PM To: IBM-MAIN@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:frank.swarbr...@outlook.com] Sent: Tuesday, October 10, 2017 1:19 PM To: Edgington, Jerry; IBM-MAIN@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-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Edgington, Jerry <jerry.edging...@kroger.com<mailto:jerry.edging...@kroger.com>> Sent: Tuesday, October 10, 2017 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, October 10, 2017 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@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 lists...@listserv.ua.edu<mailto:lists...@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
Re: git, z/OS and COBOL
Sure Frank. No problem with emailing privately. Happy to help, if I can. From: Frank Swarbrick [mailto:frank.swarbr...@outlook.com] Sent: Tuesday, October 10, 2017 1:19 PM To: Edgington, Jerry; IBM-MAIN@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-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Edgington, Jerry <jerry.edging...@kroger.com<mailto:jerry.edging...@kroger.com>> Sent: Tuesday, October 10, 2017 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, October 10, 2017 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@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 lists...@listserv.ua.edu<mailto:lists...@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 inst
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-MAIN@LISTSERV.UA.EDU> on behalf of Edgington, Jerry <jerry.edging...@kroger.com> Sent: Tuesday, October 10, 2017 10:47 AM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, October 10, 2017 11:49 AM To: IBM-MAIN@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 lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, October 10, 2017 11:49 AM To: IBM-MAIN@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 lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN