Teandy   3250 pts.  |   Jul 6 2009  7:21PM GMT

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).

Joy Stalnecker   120 pts.  |   Jul 6 2009  7:33PM GMT

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.

Graybeard52   2435 pts.  |   Jul 7 2009  11:57AM GMT

Is is possible the CHIAN fails, and you try to DELETE anyway ?

Joy Stalnecker   120 pts.  |   Jul 7 2009  12:05PM GMT

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.

Joy Stalnecker   120 pts.  |   Jul 7 2009  1:49PM GMT

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.

Yorkshireman   3200 pts.  |   Jul 7 2009  2:13PM GMT

Use WRKOBJLCK when you have the job in the failed state. Examine all locks.

That should identify the rogue, wherever it is.

Joy Stalnecker   120 pts.  |   Jul 8 2009  5:56PM GMT

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.