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 +0000 Frank, The *ix compare utility is usually the "diff" command, and looking up the possible parameters for "diff" I don't see any options that would allow filtering the columns compared. It should be possible to craft a shell script to chop the line numbers off in temporary files and then do the compare with the chopped files, but the output would not, of course, reflect the line numbers in the difference listing (or "patch" compatible output file). Another possible issue would be whether it is even possible to make git use the shell script instead of "diff", and whether or not that is even desirable for any language but COBOL. Looks like an opportunity for someone to contribute to the open-source community to implement a column filter for the "diff" and "patch" suite, and maybe "git" as well. Alternatively, do your programmers really make any sensible real-world use of COBOL line numbers in columns 1-6, or is it just "tradition"? After all, no one has had to use a card sorter to re-order a program source whose card tray was dropped on the floor for some decades. I abandoned using any line numbers at all in any language many years ago, and I use those (now just comment) COBOL line number columns to "tag" changed COBOL lines during maintenance edits to identify the project for which the change was done. I use ISPF "UNNUM" on all numbered source programs when I first edit them to remove all line numbering. COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the need/desire to use the COBOL line number columns for tags, but I can still see using them that way going forward. YMMV of course, I realize that it is quite hard to change the ways that people are used to working. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
