Re: CLP Question

On 27-Oct-2011 13:32 , CRPence wrote:

On 27-Oct-2011 11:55 , fbocch2595@xxxxxxx wrote:

Hi Folks, when I run this code;

<<SNIPped CLP source>>

I'm getting this after the code goes to DLY again;

3200 - DLTSPLF FILE(QPDSPMSG) SPLNBR(*LAST)
3400 - RCVF DEV(*FILE) RCDFMT(*FILE) WAIT(*YES) OPNID(*NONE)
File name is T2853PF. */
2400 - DLTF FILE(QTEMP/T2853PF)
Cannot do operation on file T2853PF in QTEMP.

What do I have to do to be able to DLTF the file?

Close the file. A database file can not be deleted while a database
file member is open. For a CLP, that means ensuring the CPF0864 gets
signaled.

As to the code... Ugh! Best to eliminate the indirection, and code
directly to what is desired; i.e. using RCVMSG MSGQ(QSYSOPR) to
locate the message-of-interest in the queue. Perhaps instead of
trying to get this CLP to function as expected, describe what task
is intended to be accomplished, and ask how best to code to automate
that task.

Regarding some replies given, suggesting to use CLRPFM...

Just like the DLTF fails with CPF3220 RC1 in the original CLP, a change to use CLRPFM would just fail with CPF3130. And, even the next invocation of CPYSPLF would presumably fail with CPF9845. The CPYSPLF command is shipped with default of MBROPT(*REPLACE), the MBROPT(*ADD) was not explicitly coded, and open-with-clear is not any more possible than a clear-physical-file-member against the member which is already open.

Regarding the too-generic message handling....

IMO the CLP remains a mess, even if all MONMSG handling were changed to be more specific monitors. The single RCVF after a CPYSPLF for example, gets a header record from the copied SPLF, not a row with any message identifier. Then even if the file does get closed by forcing the CLP to hit EOF, the CLP would no longer allow any more RCVF activity against that member; the reason Brian suggests a CLP specific to the DCLF and RCVF activity. The entire approach is questionable, and the coded requests and flow even more questionable. Even assuming the code gets the first message, by what expectation should that message always be the first; and if the last was intended, then even with rapid looping the desired message may since have become the second-to-last message or even older.? If the message must be caught\trapped, then a Break handling program [CHGMSGQ PGM()] as Paul suggests, or similar, might be an alternative.

Suggestions that the OP attempt incremental changes\corrections by implementing some half-baked and\or untested idea that might possibly assist to bypass a specific difficulty with the original poor implementation ignores the bigger issues with the original CLP snippet, and IMO does not seem very productive for either party.

Surely there is a better way\approach to effect what is desired.? Just to avoid having to cringe another time from seeing the original CLP source quoted in yet another reply, I would even consider writing some code for the OP, given the requirements can be well articulated.

Regards, Chuck