On 2017-12-12, at 01:37:14, Rob van der Heij wrote:. >> > Indeed, sequence numbers are used in UPDATE. This all comes from the days > where you would not dream of keeping a stack of cards with another copy > when there were only a few lines changed. And we still have processes and > tools that handle the base and individual updates to see different versions > of the source or merge updates in. To me the only reason to stick with it > is not to break all things and lose history. > Only slightly more recently, I participated in a team developed shareware project (Charlotte). Various contributors submitted UPDATE files to the coordinator who merget them and reflected a single UPDATE file at each point release. The language was Rexx/Pipelines. There's a utiity that cleans up sequence numbers for EXECs.
I found that SuperC produced cleaner UPDATE files than XEDIT. > ..., though I could certainly generate individual > update files again like SUPERC would create them. > One might postprocess the output of diff -u. Or just use the diff output as input to patch. I've done the latter with Lynx and Xterm. > It would be liberating to write HLASM wider than 61 columns, especially > when doing structured assembler. It's an easy pipeline to fold the lines > into 71+ for HLASM which could put the original line number * 100 or so as > sequence numbers. I normally assemble within XEDIT using the listing to > steer the editor to the first line causing the error. > Can you share? Can it be adapted for ISPF Edit? -- gil
