Either you sent that many SMSGs that CP's buffer of (255?) was
overflowed, either some of the SMSGs caused your server to execute a
command that uses VMCF, RAC and NETSTAT are just two examples. PIPE
VMC is another obvious example.
2009/4/23 Fran Hensler <f...@zvm.sru.edu>:
> On Thu, 23 Apr 2009 09:07:06 +0200 Kris Buelens said:
>>The DO QUEUED() is not required, there is only one stacked message for
>>an SMSG or IUCV event.
>
> You are correct Kris. I just ran a test where I flooded my WAKEUP
> with 10 SMSGs in quick succession. Tey were all processed one at a
> time.
>
> But I am SURE that when I first wrote my WAKEUP routine I was losing
> SMSGs. Could it be because they were RC=1? I don't know when I
> added: 'CP SET SMSG IUCV' to cause RC=5 on SMSG.
>
> I do not use WAKEUP's FILE option.
>
> /Fran
> ------------------------------------------------------------------------
>
>>If however you also use WAKEUP's FILE option, the WAKEUP file entry
>>that (could have) caused is **in all interrupt cases** stacked first
>>(before the entry of an SMSG for example).
>>If more SMSGs (or IUCVMSGs) were sent, CP or WAKEUP itself may have
>>queued some in their internal buffers while you handle the single one
>>placed in the CMS stack.
>>
>>Losing messages: we almost never lost messages. One exception: if you
>>send SMSG's to a server and the server issues a RACF or NETSTAT
>>command, all SMSGs queued by CP are "eaten" by the RACF/NETSTAT
>>command (both SMSG and RACF/NETSTAT use VMCF, which is limited to one
>>"path"). Solution: make WAKEUP handle the SMSGs via IUCV. From my
>>RxServer code:
>> WakeupOptions='IUCVMSG QUIET RDR'
>> /* To better co-exist with VMCF pgms like the RAC & NETSTAT command */
>> /* we will set SMSG to IUCV so WAKEUP no longer uses VMCF */
>> 'CP SET SMSG IUCV' /* ... grab SMSGs with WAKEUP's IUCV interface */
>>An SMSG will then make WAKEUP exit with RC=5 instead of 1.
>>
>>I recommend you have a look at the SERVER KERNEL file in my RxServer
>>package; subroutines PROCESS:, GOT_a_MSG, and GOT_a_SMSG: are
>>important here.
>>
>>2009/4/23 Fran Hensler <f...@zvm.sru.edu>
>>>
>>> Jim -
>>>
>>> I found out the hard way that when WAKEUP gives you RC=5 that there
>>> may be more then one message to be processed.
>>>
>>> When I wrote this EXEC I assumed that there was only one message and
>>> every once in a while I would lose one.
>>>
>>> Here is part of an EXEC:
>>>
>>> 'CP SET SMSG IUCV'
>>> Do Forever
>>> 'WAKEUP (CONS IUCVMSG RDR '
>>> Say 'Queued =' queued() ' Rc='Rc
>>> Select
>>> When RC = 1 then Call wakeup_smsg
>>> When RC = 2 Then Call wakeup_time
>>> When RC = 4 Then Call wakeup_rdr
>>> When RC = 5 Then Call wakeup_smsg
>>> When RC = 6 Then Call wakeup_cons
>>> Otherwise Say 'Unexpected RC='RC 'from WAKEUP.'
>>> End /* select */
>>> End /* Do */
>>> Exit
>>>
>>> {snip}
>>>
>>>
>>> wakeup_smsg:
>>> /* ================================================================== */
>>> /* Process SMSG */
>>> /* */
>>> Say 'Smsg queued =' queued()
>>> Do m = 1 to queued()
>>> Call process_smsg
>>> End
>>> Return
>>>
>>> process_smsg:
>>> Parse Upper Pull message
>>> say message
>>> If Word(message,3) = 'LOGOFF' then 'CP LOGOFF'
>>> /* Do some processing */
>>> Return
>>>
>>> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years
>>> mailto:f...@zvm.sru.edu http://zvm.sru.edu/~fjh +1.724.738.2153
>>> "Yes, Virginia, there is a Slippery Rock"
>>> --------------------------------------------------------------------------
>>
>>
>>
>>--
>>Kris Buelens,
>>IBM Belgium, VM customer support
>
--
Kris Buelens,
IBM Belgium, VM customer support
