On Wed, Oct 11, 2017 at 8:48 AM, Pew, Curtis G <curtis....@austin.utexas.edu > wrote:
> On Oct 10, 2017, at 6:04 PM, ste...@copper.net <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
