Just a shot here — perhaps a cl with DCLF ???
Your Delete request doesn’t have a keyfield or klist?
Are you testing to see if the record was found after the chain?
More obvious questions —
OEAPL02 is a logical file??? This isn’t a join logical??? a multi-format logical???
Record Format name for this logical is, XEAPP1, and it isn’t renamed?
User has delete authority to the logical and physical file?
I totally agree with your analysis – one of the programs called is opening the file without
add authority and either not closing it or there is an ovrdbf share(*YES) check the level of the override.
OPNQRYF, F-Spec’s, COBOL — check the call stack when it fails for programs
If there is an OVRDBF *SHARE, as you described, .. then the first open rules even if it “closes”.
Even a called program that opened it and didn’t close it .. *INLR wasn’t turned on — this guy won’t be in the call stack.
Calls can be CALL, CALLB, CALLP or QCMDEXE
Why do a Chain when you can do a keyed Delete?
Ohhhhhh, sure, we were so busy debating what was happening that we never answered your question.
Here’s another approach – find which programs could be suspects.
This might help – it will allow you to search all the ‘F-spec’ type accesses.
run dsppgmref — you can run it over an entire library of your programs and output to an outfile
Then query the outfile for your Physical file.
Great, thanks Joy — want to try something — might be useful down the road
I think the RENAME in your program desn’t work when the path is already open…
Compiles fine — got a rename and deletes based on that name
Runs fine stand-alone – renames record as it opens the path and deletes it
Another program opens file/path — path stays open rename cannot be applied
– delete fails
Can you remove the rename or put it on another path?