Vincent (Bryan) Coen

On 12/10/2026 12:22, Simon Sobisch wrote: Haven't checked, but hopefully this is described in the PG under CANCEL statement as well :-) Yes under 7.8.6 CANCEL and 10.2.3 COB_PHYSICAL_CANCEL. .

On 12/10/2026 11:47, Eugenio Di Lorenzo wrote: Indeed, what we don't know are the reasons why they decided to add this new |'LOCK FILE file-name'|statement to the ISO COBOL standard. Can these reasons be found anywhere ? Yes, at least the obvious reason is on a multitasking system where a file cannot be read or written to by another as the file is in an update or write mode and that has to take place before the file or record can be released or unlocked. For a micro based platform this is more likely...

On 12/10/2026 02:33, Ralph Linkletter wrote: And now another? as proposed by new ISO standards - Why ? COBOL vendors other than IBM provide 2 forms of COBOL syntax to lock a file. 1) Lock mode exclusive 2) Share with no others IBM COBOL has neither of the above, instead a file disposition is provided by the JCLparameter DISP=OLD But that, just means the file already exists and nothing else. It has nothing to do with file/record locking, no ?

APPENDIX B to F

That in itself produced other errors now fixed.

1262 + other changes to fix bugs so caused

I think you will find that the CANCEL does nothing. e.g., it does NOT remove load module from memory. At least this was the position on older versions and I do not recall it ever being fixed.