Thanks for your response.

From here, it does seem as if there is a preceding read, namely a
CKREADBYKEY. Some perspective:

Program maintains a "claimant" ksam file, interactively; file has multiple
keys, two of which are Social Security # and Name; SSN must be unique, Name
can have duplicates.
Very old program, original programmer no longer with company. Said
programmer never understood file locking, so some of the CKLOCK
instructions in the program are largely gratuitous - though the CKLOCK
which preceded the abort was necessary - it just probably should have
preceded the CKREADBYKEY. (I am assuming that a CKLOCK does not alter the
pointer).
Scenerio:
  1.)User enters SSN and correct record appears on screen. User modifies
claimant address, specifies saving the data, and the record is successfully
(re)placed in the KSAM file.
  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.

To help eliminate some possibilities I did the following:
1.) Compiled the routine into a native mode library and compiled a native
mode standalone program to call the routine.
2.) Tested scenerio #2 (above) and got the exact same abort as originally
reported.
3.) Compiled the routine into a segmented library and compiled the same
standalone program from step #1 as a compatability mode program.
4.) Tested scenerio #2 again - this time no abort.

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?