CPF5149 on Delete using SHARE(*YES)

170 pts.
Tags:
iSeries RPG programming
RPG
RPG Error Messages
RPGLE Program
I am receiving a CPF5149 error when trying to perform a delete of a record in a file that is defined as update/add in the F spec. Unfortuneately, the software package my company uses requires SHARE(*YES) on all database files. I am fairly sure that the problem is caused by the file being opened at another point without the update/add capability. However, I have tracked back the call stack and can find no other program that opens this file differently. I have also tested this issue on a newly started job to make sure there isn't any "left over" data paths that could be the issue. Does anyone know of a way to determine where/how a file is opened? All of our programs should be defined as update/add to avoid this issue, so if I can find the rogue program I should be able to fix this issue. Thanks in advance for any help.
Asked: Last updated:
Related Questions
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Just a shot here — perhaps a cl with DCLF ???
Phil

—————————————————–

Your Delete request doesn’t have a keyfield or klist?
Are you testing to see if the record was found after the chain?

Phil

______________________________________________________

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?
Phil

——————————————————-
——————————————————-

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

Phil

===============================================================================

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.

Phil

_____________________________________________
*********************************************

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?

Phil

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Teandy
    According to the help on the CRTPF SHARE *YES: <quote> Specifies whether the open data path (ODP) is shared with other programs in the same routing step. When an ODP is shared, the programs accessing the file share facilities such as the file status and the buffer. </quote> To me, this says that the offending program should be in the job stack. Since you have already verified that it is not, then we need to look elsewhere. The message text for CPF5149 also states: <quote> A read-by key was attempted on a non-keyed file. </quote> Make sure you have a K in the record address type (position 34 of the f specs).
    5,860 pointsBadges:
    report
  • Joy Stalnecker
    Thanks for your reply. The error occurs on the delete statement. Not on the Chain statement that comes before it, so I don't beleive that the issue is keyed vs. non-keyed access. I double checked and the Access path is Keyed and the Allow Delete parm on the file is set to *YES.
    170 pointsBadges:
    report
  • graybeard52
    Is is possible the CHIAN fails, and you try to DELETE anyway ?
    3,115 pointsBadges:
    report
  • Joy Stalnecker
    Here is the section of code in question: C ORDKY1 KLIST C KFLD SLSORD C KFLD OHLSUF C KFLD ITEM52 C ORDKY1 CHAIN OEAPL02 30 C IF *IN30 = *off C* If New Grp Requested, delete this group entry for this line C* then create a new group for this line alone C If NewGrp = 'Y' C DELETE XEAPP1 In order to hit the delete statement a record must be found. And if a record wasn't found I would get an update or delete without prior input error.
    170 pointsBadges:
    report
  • Joy Stalnecker
    1) OEAPL02 is a logical file. But it is not a joined or multi-format logical. 2) XEAPP1 is a renamed version of the record format - OEAPP1. I thought about this being a possible issue, but could not find a reason why it would be. 3) I have full authority to both the physical and logical I can run this program by a direct call and it works fine - no errors. However, when I access this program via another program I get the error. Which was why I was assumiung that the issue was due to the SHARE(*YES) option and the file being opened differently in another program. When I get the error there are is one entry in the job log before the error that I think is related: Open options ignored for shared open of member OEAPL02. Type code 1 - The input, output, update, or delete options are not the same as or a subset of those specified on the first open operation.
    170 pointsBadges:
    report
  • Yorkshireman
    Use WRKOBJLCK when you have the job in the failed state. Examine all locks. That should identify the rogue, wherever it is.
    6,085 pointsBadges:
    report
  • Joy Stalnecker
    Thanks for your help - Phil especially. Just to bring some closure to this, I wanted to post some other interesting information and what I finally decided to do to get around this issue. First, I did some more testing and found that when I changed the first program in the call stack to open the file as input only I got an error on my chain statement which comes before the delete. Basically my program was trying to read and lock a record in the file, but was not allowed to because the data path was input only. This makes sense until you think about the requirements for deleting a record, which are to have update access. So for some reason I can lock the record, but not delete it even though I should be able to do one if I can do the other. Once I can across this, I decided to cut my losses and create a work around. So I made the file usropn. I then added code in the init sub to override the file to SHARE(*NO) and open the file. Then before the program ends I delete my override and close the file. It works even if it doesn't solve the original problem.
    170 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: