Ralph Linkletter

You may also want to address whether subroutines that were called and the status of the subroutines after a cancel operation. Explain "logically unloaded" Explain "physically unloaded" The return-codes 02, 21, 31 seem unnecessary Why not keep it simple: 00 is ok 01 is not ok

You may also want to address whether subroutines that were called and the status of the subroutines after a cancel operation. Explain "logically unloaded" Explain "physically unloaded" The return-codes 02, 21, 31 seem unnecessary Why not 00 is ok 01 is not ok

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 Not my monkey - not my circus :-)

I disagree - lock managemnt is the purpose of the COBOL I-O statements. Concurrent access dictates the need for locking manangement. Concurrent access implies more than one LUW. A single user, that has exclusive ownership of the VSAMA dataset is going to use lock management for what purpose ? Other than to grant excusive ownership to the program at hand,. Again ISO extolling a solution to a problem solved several times over decades ago. Loco :-)

Perhaps LOCK is used a a global enqueue mechanism (a mutex of sorts) beyond file i-o. File level locking control is simple compared to record level locking. A standalone "LOCK" - Locks what ? IMO since Bill Klein's death all sorts of ISO guidance is unbridled - no guardrails, no practcality. Not my monkey - not my circus :-)

Locking is a feature of COBOL I-O. I do not believe there to be an explicit / standalone LOCK statement outside the purview of a COBOL I-O statement. LOCK contemplates record level locking and file level locking, An implied file lock in zOS is recognized with the DD statement DISP=OLD (any disposition other than SHR) COBOL record level locking / unlocking is dependent upon the file system deployed with COBOL . That is a RDMS, a VSAM file handler. In experimenting with various VSAM file handlers and...

Locking is a feature of COBOL I-O. I do not believe there to be an explicit / standalone LOCK statement outside the purview of a COBOL I-O statement. LOCK contemplates record level locking and file level locking, An implied file lock in zOS is recognized with the DD statement DISP=OLD (any disposition other than SHR) COBOL record level locking / unlocking is dependent upon the file system deployed with COBOL . That is a RDMS, a VSAM file handler. In experimenting with various VSAM file handlers and...

Being a wee bit red / green color blind it is not very useful to me :-) You could use EXTH, which would result in a single module to do the I-O without the need to recompile. Just specify the VSAM record length, key pos, key loc. Let EXTFH do the driving. I have a sampl;e of a universal ISAM / VSAM I-O module if you would like it. I think that EXTFH use would support BDB, VBISAM. VISAM, RTG with the same source code.