NonStop Servers
1753719 Members
4901 Online
108799 Solutions
New Discussion

Let's share our knowledge since KBNS is gone, let's post our questions here and provide answers

 
SOLVED
Go to solution
hectorgull
Advisor

Let's share our knowledge since KBNS is gone, let's post our questions here and provide answers

I have 20 years of NonStop experince from VLX to Blades Hardware (ex-HP CE in Toronto) and Software as System Operations/Administration for 3 major Banks in Toronto, Canada. also some profesional services for a number of Customers in Canada.

 

Like most of us, I still come across issues never experience before like this one:

 

Interprocess Communications on $RECEIVE  C 06 05 WRITE, Error #30, file $<processes name>

 

error 30

 

Message system is unable to obtain memory because either no entry is
 available in the message block pool or the maximum number of RECEIVE or
 SEND message blocks are already in use.

 

Have any of you seen the error 30 above?

what counter will provide me with the max number of blocks been used, I will search the manuals but anyone knows what is the max number of send message blocks?

 

 

4 REPLIES 4
hectorgull
Advisor

Re: Let's share our knowledge since KBNS is gone, let's post our questions here and provide answers

ok I found the issue in the new KBNS after a good 30 minutes.

 

SYMPTOM:Error 30 received by application on call to WRITE.SYMPTOM:Error 0030 message system is unable to obtain memory

SYMPTOM:File System Error 30

SYMPTOM:User written event collector is fed by a great number of application processes nowaited WRITEs.SYMPTOM:Stopping and restarting the customer written event collector clears the problem.

CAUSE:If a process can't send any more message to $RECEIVE of another process because the queue is full, this will result in error 30 returned to the sending process.

Answer/Solution

FIX:Change the application to handle $RECEIVE as fast as possible.

Another option is for the customer application to implement a wait timer on receiving an error 30 and then retry the write.

Implement a process internal queuing mechanism if required.

A temporary solution might be to increase the queue length for $RECEIVE with a call to procedure CONTROLMESSAGESYSTEM ( 0, n ) where n can be used to increase the number of messages being queued to 4095

 

 

hectorgull
Advisor

Re: Let's share our knowledge since KBNS is gone, let's post our questions here and provide answers

Ok found the problem, I had already checked the MQC and it was not an issue, so the issue maybe with application process not handling $RECEIVE fast enaugh or simply not sending messages and it's receive buffer getting full.

TimeLord
Occasional Advisor
Solution

Re: Let's share our knowledge since KBNS is gone, let's post our questions here and provide answers

I must say my first impression with the new system was not really a thrill, but to be honest, I have also changed my mind since. I have searched the new for something system and was happy to find  a KBNS solution three pointers to manuals that discussed the topic for different versions of the software.

 

I also have to say that the old KBNS required some trial and error to find the correct keywords.

So I tried your query. and I used the following search term: (which is not too weird a search phrase for your problem)

 

nonstop write on $RECEIVE , Error #30

 

The top 2 results were:

Title: Error 30 received by application on call to WRITE.

Title: What caused a Receive file Error 30?

 

Not too bad. It did not take 30 minutes to find (writing this and copy/paste took longer than finding the results).

 

Let's help eachother finding our way through the new system by providing the terms that work. We will figure out how to phrase right to get good answers!

 

 

 

 

hectorgull
Advisor

Re: Let's share our knowledge since KBNS is gone, let's post our questions here and provide answers

Yo are correct, the key is to use NONSTOP at the begining of the query

 

My success rate is increasing and since there is no going back it will have to do.

 

Now there is no denying  that the OLD KBNS was FAST and SIMPLE, the way I wish my company network was.

 

by the way, looking for information on SS7TE1/2/3, compatibility, will the same firmware file version work and the sort.

 

I can find it just fine on KBNS, but it won't let me read it and ask me to register in the eService portal as Telco, well I'm so I think somehow is not linking my profile properly.