Re: git, z/OS and COBOL

[scott Ford]

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

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

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


Scott

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

[David Crayford]

Thanks Jesse,

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



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

[Jesse 1 Robinson]

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

https://www.linkedin.com/pulse/git-zos-development-how-do-you-build-now-can-rosalind-radcliffe/?trk=eml-email_feed_ecosystem_digest_01-recommended_articles-7-PBYN=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

[David Crayford]

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

[Andrew Rowley]

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

[Paul Gilmartin]

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

[Anne & Lynn Wheeler]

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

[Farley, Peter x23353]

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

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

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

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-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

[Frank Swarbrick]

This looks interesting.  Do you know of a UNIX utility that would replace the 
first 6 characters with spaces?

From: IBM Mainframe Discussion List <IBM-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

[Jerry Callen]

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

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

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

-- Jerry

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

Re: git, z/OS and COBOL

[John McKown]

On Wed, Oct 11, 2017 at 8:48 AM, Pew, Curtis G  wrote:

> 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

[Pew, Curtis G]

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.

(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

Re: git, z/OS and COBOL

[Clark Morris]

[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

[Edward Gould]

> On Oct 10, 2017, at 9:17 PM, 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  wrote:
> 
> From: Clark Morris  >
> 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
> 
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

[Paul Gilmartin]

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

[ste...@copper.net]

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

[Paul Gilmartin]

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

[Clark Morris]

[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

[Clark Morris]

[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

[scott Ford]

Frank,

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

Scott

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

[Paul Gilmartin]

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

[Farley, Peter x23353]

Steve,

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

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

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

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

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-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

[Frank Swarbrick]

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

[scott Ford]

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

[Frank Swarbrick]

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

[scott Ford]

Frank and Kirk:

Yes we are using Assembler and Cobol in GIT.

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


HTH Frank and Kirk..

Scott

On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf  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

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

[Kirk Wolf]

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

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

Re: git, z/OS and COBOL

[Frank Swarbrick]

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

It sounds like you are referring to columns 73-80, however.  We use that for an 
8 character 'work order number'.  I don't think they will cause us any issues.

From: IBM Mainframe Discussion List <IBM-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

[Farley, Peter x23353]

Frank,

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

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

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

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

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

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

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-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

[Paul Gilmartin]

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

[Edgington, Jerry]

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

[Edgington, Jerry]

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

[Frank Swarbrick]

The reason I asked about the line numbers thing is that git seems to use a Unix 
compare utility that has no way (that I can tell) to ignore the line numbers.  
So if you insert a new line then the compare thinks that every line after that 
has changed, when truly only the line number has changed.  If you have a way 
around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to 
do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank

From: IBM Mainframe Discussion List <IBM-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

[Edgington, Jerry]

Frank,

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

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

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

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

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

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

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

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-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