Re: KLIST question

On 05-Dec-2011 11:12 , jmmckee wrote:

One program writes/updates or deletes records. I know a record was
supposed to be added. And, as far as I can tell, the add/update
logic is working. But, a specific record was not to be deleted, and
yet it is not there. I jumped on the KLIST and field differences as
a possible issue.

I do not recall any resolution so I offer FWiW:

Be sure to review for any suppression\ignoring of errors on or after the write. A permanent or [query] temporary index might preclude an insert of the data; e.g. a case where the specific data would have been inserted except when either the key values already exist and a unique key\access path prevents [CPF5009], or a value can not be mapped into the attributes of the derived key\access path [CPD4001]. Similarly any non-key data mapping error [CPF5035] could cause the insert to fail.

For mention of different length values for the keys, IIRC if data is "moved" and decimal truncation [of significant digits] is allowed by [or irrespective of any] compiler specifications, whatever key value was presumed to have been added may be different than logged\expected by the application. For example the value 987654321 moved into an 8-digit variable might produce the value 87654321 which is then used for the inserted value into the key field; the original value might be what was logged, obscuring the effect. A *BEFORE trigger could have a similar effect.

The first file is a daily file. I can backtrack through a log file
and see the history for a given account. No record should have been
deleted from the second file.

The STRJRNPF provides a[nother] log. The journal will reflect what actually transpired for data in the member according to the database, versus what logging by the application might imply had transpired. As I recall, an indicator suggests if a trigger was in effect for the I\O that is recorded; and which trigger program.? Application-level logging could imply the write was done, merely reflecting an intent, rather than the actual effect by the database.

Regards, Chuck