Allocate problem with DSPFD *MBRLIST

[Guest.Visitor]

You could do a DSPFD with *BASATR. That would give you a count of the number of members in the file. If the number of records returned by a DSPFD with *MBRLIST is under the member count, someone has a lock on your file. Steve

[R.Daugherty]

Allocate problem with DSPFD *MBRLIST

Assuming the purpose for the MONMSG was to ensure you had a complete list of members, you should do allocate exclusive on the file first, then if unable to get exclusive lock, submit yourself with a scheduled time x minutes later and retry. If your MONMSG was for any other reason following the DSPFD failure, it would be difficult to understand why a MONMSG for the error given in the job log would not work. I would do a MONMSG CPF000 following the DSPFD instead and when it catches the failure do more detailed analysis at that point. rd

[Guest.Visitor]

Allocate problem with DSPFD *MBRLIST

Do a RCVMSG after the DSPFD to see if there was a CPF5729? (I don't have access to source at the moment to tell you what that might look like. And what does the joblog look like if there were multiple members that couldn't be allocated?)

[joanzen]

Allocate problem with DSPFD *MBRLIST

I've attached a section of the joblog so you can see what it looks like when multiple members of the file are in use. Even though this occurs, the DSPFD completes 'normally' and includes the member(s) (in this case, 1) that were not allocated.

DSPFD joblog.doc

[joanzen]

Allocate problem with DSPFD *MBRLIST

I'll give that a try. Thanks.

[joanzen]

Allocate problem with DSPFD *MBRLIST

I was hoping to not have to get an exclusive lock on the file. It would be nearly impossible to do since the file is pretty much constantly in use. Although, determining after the fact that the file is in use and not providing a complete member list is just as restricting. I should have mentioned earlier that I also tried CPF0000 (global and command level), and it didn't capture the message either.

[R.Daugherty]

Allocate problem with DSPFD *MBRLIST

CPF5729 is not listed as escape message for DSPFD in the CL manual, so I guess it has to be considered informational. rd

[qgenesist]

Allocate problem with DSPFD *MBRLIST

If you rcvmsg, it looks like the 3018 message tells you the member that is locked, you could do your business from there by cutting up that message. You could wrkobjlck via *outfile (or even slicker) via API and do whatever, from there, having the member name. Or just stick it in the file along with the others. Anything for a laugh, right? Ron

[howsys]

Allocate problem with DSPFD *MBRLIST

You might try the QUSLMBR API.

[joanzen]

Allocate problem with DSPFD *MBRLIST

Thanks for the responses. Actually, this is exactly what I ended up doing. I should've posted before. I execute a RCVMSG for 3018 and substring the member name out. That really gave me all I needed. If the 3018 isn't received, I continue processing the outfile from dspfd, since I know it's a 'good' file.

[joanzen]

Allocate problem with DSPFD *MBRLIST

I have a CL using DSPFD with *MBRLIST. I am running into a problem when another process may have a member within my file open. The message CPF5729 (Not able to allocate object). The problem is that the DSPFD continues normally and creates the *OUTFILE. The *OUTFILE contains all the members except the one listed in the CPF5729 message. I have tried MONMSG for CPF5729, but it doesn't work. I've tried the monitor message at the global as well as command level. Any thoughts as to how I might handle this situation? Thanks.

[Guest.Visitor]

Allocate problem with DSPFD *MBRLIST

FWIW: A brief test that I tried indicated that having the member open, e.g., with SEU, doesn't cause any problem, because the member is allocted *EXCLRD. It is when the member is allocated *EXCL that DSPFD has problems. Is it necessary that the other application(s) have the member *EXCL? *EXCLRD will stop concurrent updating just as well as *EXCL. Sam