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
midrange.com
