One thing that we all do when writing code is make mistakes. OK – so maybe that’s only me and a few of my associates and you don’t – but I’d bet you do as well.
Using ISPF Edit there is an easy way to determine what you changed recently by using the ISPF Edit command COMPARE.
Figure one is the code, JCL in this case, that has changed but we don’t recall what we changed.
Figure 1
Most of you know about using the compare command to compare the current edit data to data in another dataset, or PDS member.
To compare the data currently being edited to data in another dataset use:
compare data.set.name
And to compare the data currently being edited to data in a PDS member use:
compare pds.data.set
or
compare pds.data.set(member)
If the edit dataset is a PDS member, and the compare PDS member has the same member name, then no member name is required.
But the feature of the compare command that may be the one very few know, and which may be the most powerful, is the ability to see what has changed in the current Edit session, or since the last save command. And note that it does not matter what the ISPF Edit Recovery state is for this to work.
Using the command compare * x we can see what changed in figure 2.
Figure 2
The compare * will compare the contents of the member as it was when you started the edit session with the current state of the data, or since you last issued the save command.
In case you haven’t used the ISPF Edit Compare command before, the record number fields with the ====== are those records that do NOT exist in the current data and the record number fields with the .OAxxx are the records that have changed.
If you are editing a PDSE with member generations enabled, and if you are using the open-source PDSDEGEN (https://github.com/lbdyck/pdsegen) tool you can compare to prior generations using the command compare -n thus:
Figure 3
When using PDSEGEN you can compare the current member to any prior generation. It can be found at https://cbttape.org in file 969 or https://github.com/lbdyck/pdsegen.