Re: Source maintenance was Re: SEQUENCE NUMBERS



In a recent note, Art Celestini said:

Date: Mon, 31 Jul 2006 10:52:03 -0400

From what I am familiar with from the Linux world, the method does not
appear to be 100% bulletproof. Essentially, the "diff" program (e.g.
http://www.die.net/doc/linux/man/man1/diff.1.html) is used to create
a "patch" file by comparing the old and new source. Then the "patch"
program (e.g. http://www.die.net/doc/linux/man/man1/patch.1.html) can
be used to apply the changes to another copy of the old source.

You needn't search so far afield. Both are part of the base z/OS,
likely since MVS 5.2.2. But the GNU/Linux flavors have extensions
which I value, and which the open source community regularly
exploits.

The person who runs the "diff" program must ensure that the "context"
parameter specifies enough lines to ensure there are no ambiguities.
Problem is, there is no guarantee that ambiguities won't still exist
in different versions of the old source. I've seen claims that a
particular patch will apply to multiple versions of a target program,
but usually, the patch is documented as being applicable only to a
specific version.

And neither method protects against overlapping patches by different
developers. In fact, if two different developers insert similar
new code but the sequence numbers by happenstance are different
(perhaps differentiated by ISPF's use of 79-80 as a vesion
indicator), won't IEBUPDTE cheerfully interleave the patches with
nary a warning? patch-diff's verification of context will likely
result in at least a warning.

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.



Relevant Pages

  • Re: KEY8 CSA: Pro/JCL and Info/XE
    ... will be a sufficiently large sledgehammer. ... Cross-memory services are well enough developed that they should be embraced by developers. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: P390
    ... It would more interesting to have a z/OS calculation with IMS and DB2, because thats what would be required by most developers I know. ... Serving IBM Japan and IBM Asia-Pacific ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • =?iso-8859-1?Q?Re:_New_POO?=
    ... Warning - the above link may wrap. ... of Ops doc is available; but when I follow the link, ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: Patents, Copyrights, Profits, Flex and Hercules
    ... Clem Clarke wrote: ... It's a shame, but unless IBM does do a big rethink on this, and allows small developers some sort of inexpensive or free access to the mainframes, they will die. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • RE: Multiple TSO logons
    ... because the developers were too lazy/uneducated to do things the right ... That's why it is doubly frustrating to be taken to task for doing ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)