On 11 December 2017 at 20:36, Dave Wade <[email protected]> wrote:
> As I generally only play with old versions of VM I don't have ISPF. In old > versions of VM and line numbers on the assembler source are integral to the > way the system is built. > So the build process keeps each change as a separate source update and the > base source is never updated. The VM UPDATE command uses the line numbers > to work out how to update and assemble the source.. > In later versions of VM XEDIT will handle all of this under the covers so > you just see the merged updates... > > 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. Suggesting anything but git as an alternative will probably make you a local attraction for folks visiting the site. I spent a Friday night moving the base and updates from a few 100K base and updates into git commits (dropping sequence numbers and update identifier from the files, and joining the continued lines into a single line). The result was elegant and pleasant to see with web-based repository tools like GitHub. Obviously that's a one-way process, though I could certainly generate individual update files again like SUPERC would create them. 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. Rob
