Hello John,


>Thanks for your response.
>
>>From here, it does seem as if there is a preceding read, namely a
>CKREADBYKEY. Some perspective:


<snip>

>  2.) User enters SSN and correct record appears on screen. User modifies
>claimant last name (a "key" field), specifies saving the data, and ...
>kabooom.
>Logic for #1 and #2 are virtually the same, exact same instructions
>executed til time to "replace" record.  At that point the original record
>is read again with a CKREADBYKEY. Then if no key data is changed, a
>CKREWRITE is done (scenerio #1) which succeeds. But, when the name is
>changed as in scenerio #2, the program wants to do a CKDELETE followed by a
>CKWRITE - and this is where the abort occurs.


<snip>

>There is a Cobol trace in the program and it indicates that both native and
>compatibilty mode versions took the same route to the CKDELETE.
>
>So, at this point, it seems to me to be a native mode issue - the exact
>same source files were used in the above tests. Are there any known issues
>with the KSAM intrinsics and native mode? (Such as alignment problems not
>flagged by the compiler?) Is there any way that a CKREADBYKEY could
>"succeed" but fail to set the pointer? Does the "ERROR 753 ILLEGAL KSAM
>OPERATION" only occur when the pointer has not been set prior to the
>CKDELETE?



Actually, you are correct, this is a native mode issue. And I should have mentioned
this particular foible of the CK intrinsics in my previous reply (sorry)! The sequence

    CKREAD, CKLOCK, CKDELETE, CKUNLOCK

will work if compiled in compatibility mode but it will not work if compiled in native
mode.  The sequence that does work in Native Mode is:

   CKLOCK, CKREAD, CKDELETE, CKUNLOCK

This is not a function of COBOL it is within the 'CK' intrinsics. The Native Mode
CK intrinsics enforce a particular calling sequence that the Compatibility Mode
intrinsics do not.

I wrote a COBOL progam to test the sequence and reproduced the error you see.
I then wrote a Pascal program to do the same. The CM program works, the NM
program produces the error. The intrinsic is just looking at the filetable and what
the 'PREV OP' is (as far as I can deduce not having access to the CK intrinsics
source but doing a little playing to reverse engineer the stuff).

So the most common cause for this type of error is using the formerly legal CM
sequence of READ, LOCK, DELETE, UNLOCK. Another more rare possibility
is that the 'PREV OP' field of the filetable variable is getting altered in between
the calls making it look to the CK intrinsics like you are not doing things they way
they think you should. In this scenario whether or not you get an error 753 or some
other error depends on what PREV OP winds up as. (Tested that too).

Note that the sequence of READ, LOCK, DELETE, UNLOCK is legal insofar as
the file system cares. I would not want to venture a guess as to why the Native
Mode "CK" intrinsics impose the other sequence.

Well, I hope this helps a bit more than my last reply!

Bill Cadier
HP/CSY