Conference csc32::consolemanager

    Ross,
      Was there a new CONSOLE$LIB.OLB in that V1.6-127 saveset? If not then
    I suspect that is most of your problem. You would need a new object
    library as there were enough changes made to require a relink. The real
    ECO 2 kit will have a new object library.
    
    Regards,
       Dan

Dan,

� Was there a new CONSOLE$LIB.OLB in that V1.6-127 saveset?

   Er... seeing as you ask, no. Can I get one from somewhere ? (vax 6.1)

Ross

    Now... this may not be playing the game, and it's not that I'm ungrateful
    (far from it), but what if I were to extract the OLB from the ECO2 kit,
    and relink my application ? 

    Seeing the start of some possible problems with ECO2 makes me hold off
    installing it, and seeing as how I'm on a customer site and was nearly
    lynched when ECO1 had a 'few' bugs, I'm somewhat less than eager to 
    repeat things.

    Any views...?

Ross

    You can try it but I don't think your action routine will work
    properly.
    
    Regs,
      Dan

� You can try it but I don't think your action routine will work properly.

    Hmmm... well my test program seems happy enough. I'll try linking my
    PSW -> PCM feeder and see what happens.

    No warranty implied or expected, I'll just wing it and see how we go.

Thanks,
Ross

Hi,

    I never did get this to work again, but now I've installed ECO II and
am now running version v1.6-302 and still have the same problem. What does
error 203 mean ? Can I get this to work somehow ?

Thanks,
Ross

Hi,

    I've just done some debugging on my program again and have the following
results.

    During the testing, things worked fine. All the PSW 'events' were passed
correctly to the PCM system and appeared in multi-line displays. This seemed
to be working fine, and I did several 'stop consolidator' and 'start
consolidator' loops and all seemed well. I threw in some profile edits for
PSW while I was at it, and (I think), did some PSW reconfigs. All seemed OK.

    I then relinked my program without debug and it seemed fine. I then ran
it detached and, to start with, it seemed fine. Then, without stopping it,
I happened to do a PSW reconfig, and then all my sends to CM resulted in
error 203 (I have modified my code to send OPCOM messages if the return from
CMUserSendEvent() is not CM_NORMAL). Now, the reconfig may have been a
coincidence, I don't know.

    How can I find out what 203 means or what might be causing it ? I am 
using the following:

	PCM V1.6 + ECO II + 302 images
	CONSOLE$LIB.OLB (from ECO II ? - but predominantly 3rd March)

    My code doesn't do anything wierd, just...

	sys$crembx
	{
	  sys$qio (+ast with sys$wake)
	  {
	    sys$readef
	    sys$hiber
	  }
	  CMUserSendEvent (with context 0)
	} loop

    I can post the code if anyone would like, but it does work when I test it,
it just seems to fail after a while.

Any ideas ?

Thanks,
Ross

    Ross,
      Sorry to be so long in replying. In a nutshell the CMUsersendevent
    isn't able to get the socket(s) established between it and ENS. 
    
    To get a bit more debugging trail I would do the following from the
    process your going to run your application from:
    
    $ DEFINE CONSOLE$DEBUG "API,IPC"
    $ RUN your-application
    
    This will output quite a lot of info. You'll get an audit of any API
    related stuff and an audit of *all* interprocess-communication calls
    right down to the $crembx and qio's.
    
    Regs,
       Dan

Dan,

    thanks, I tried the logical thing, and received a log file with the 
following in it...


CMUserSendEvent: Enter
CMCreateEventPort: Opening local transport event port <ENS>
IPCInitialize: Setup of temporary lnm table status:: status = 1
IPCInitialize: sys$bintim status : status = 1
IPC Event flag will be       : 62
IPC mailbox size will be     : 5245
IPC connect timeout interval : 0000 00:00:30 {-300000000, -1}
TIMER     Queue list head is : 8328
HIGH   Priority list head is : 5200
MEDIUM Priority list head is : 7200
LOW    Priority list head is : 5632
IPCConnect: Translate listener logical name status: status = 1
IPCConnect: Client input MBX channel is 304
IPCConnect: get mailbox unit status: status = 1
IPCConnect: assign output channel status: status = 1
IPCConnect: Client output channel is 320
IPCConnect: ConnID is 3048816
IPCConnect: Performing ACCEPT negotiation
IPCConnect: Return mailbox will be <MBA5033:>
IPCConnect: Write mailbox unit to listener status: status = 1
IPCConnect: Read acknowledge from listener: status = 1
IPCConnect: Connection established
IPCConnect: Output mailbox device will be <MBA5034:>
IPCConnect: Deassign from listner status: status = 1
IPCConnect: Assign to new listener path status: status = 1
CMCreateEventPort: Open succeeded
IPCWrite: QIO status:: status = 1
CMUserSendEvent: Leave (Normal)
	:
	:
    {ditto about 6-7 times...}
	:
	:
CMUserSendEvent: Enter
CMCreateEventPort: Opening local transport event port <ENS>
IPCConnect: Translate listener logical name status: status = 1
IPCConnect: Create mailbox status: status = 10772
IPCAddWorkProc: Inserting LOW Priority Queue entry (3069240)
IPCAddWorkProc: Wake Status:: status = 1
CMCreateEventPort: Open failure
CMCloseEventPort: Closing Event Port <ENS>
CMUserSendEvent: Leave (Open Port Failed)
	:
	:
    {ditto to eof}

10772 = %SYSTEM-F-EXBYTLM, exceeded byte count quota

    ...which is, I suppose, a clue. My question would therefore be, what's
gobbling up my quota, and not releasing it ? 

My process is created by...

$ uic = "sns$watchdog"
$ run sys$system:sns$feed_pcm.exe -
          /uic=['uic'] -
          /process_name=sns$feed_pcm -
          /ast_limit=100 -
          /enqueue_limit=2048 -
          /io_buffered=8192 -
          /buffer_limit=2000 -		<-- this is probably the cause ?
          /file_limit=2000 -
          /queue_limit=256 -
          /working_set=1024 -
          /maximum_working_set=2048 -
          /page_file=200000 -
          /input=nl: -
          /output=sns$output:sns$feed_pcm.log -
          /error=sns$error:sns$feed_pcm.err

I inherited this run command, but I think that most of those qualifiers are
likely to make things worse, rather than better.

I'll try removing them or setting them to be quite a bit higher and see what
happens. 

Ross

    Ross,
      if you notice the size of the mailbox was set to @5K so it won't
    even run with a bytlm of only 2000. This means that the value of
    SYSGEN param PQL_MBYTLM is greater than 5K and since thats the minimum
    the system will allow thats what your getting (which is how it's even
    running and sending the first few events). Whats probably happening is
    that at some point what you need to handle the current messages exceeds
    what you have available. I would increase BYTLM to at least 100K
    and see how you do.
    
    Regs,
      Dan

Dan,

� I would increase BYTLM to at least 100K

Hmmm... it gets more curious by the minute. You were correct in that the 
pql parameter was set to 40000, but I removed most of the run-time qualifiers 
such that I just had the "/buffer_limit=100000". Restarted my process and, 
using amds and "sho proc/quo" noted that the quota was almost 100000. All
fair and well.

I then stopped and restarted the consolidator and the first few events went
through ok, but the "Buffered I/O byte count quota" from show proc dropped to
60000, there was a pause (possibly sns not writing to the mbx) then a few
more events went through, the quota dropped to 30000 and then down to 5000,
at which point I started getting 203s.

When watched from amds, it almost seemed as though the quota was being used, 
but where I expected to see it released again, the quota was reduced.
Now, with it not working, amds says that the quota is ~5000, with 0 in use.
Most odd. "Show proc/quo" agrees.

Perhaps I misunderstand the way that quota works, but I thought that I had a 
quota (100000) that would be consumed and released as things were queued up
(qios) but, with nothing happening, would return to around 100000.

Am I wrong ? Something is most odd.

Thanks,
Ross

    >Am I wrong?
    
    
    Nope! it sounds like you have found a bug in the API! I would bet that
    your process is "collecting" mailboxes. You can verify this by
    using SDA and doing a 
    SDA> SET PROC/ID=process-running-your-app
    SDA> SHO PROC/CHANNEL 
    
    and repeat the show proc/channel after each event.
    
    Also from another terminal do the following DCL command:
    
    $ SHO LOGICAL/TABLE=CONSOLE$LOGICAL_NAMES
    
    you may or may not see a logical name associated with each mailbox
    that your process has a channle assigned to. it would be interesting to
    know if you do and what the logical name is.
    
    Regs,
      dan

Dan,

� I would bet that your process is "collecting" mailboxes. 

    Hmmm... I'll make a note not to gamble against you.

    For each call of CMUserSendEvent(), my process looses about 5k from both
    BUFIO byte count/limit and gains channels to two mailboxes. Needless to
    say, after 20 messages I would have used up my 100k quota. For the
    mailboxes, I get logical names of the order...

 	"IPC_000000C4_00000007"

	...where C4 is the pid and the "007/8/9" is some kind of sequence 
    number.

� you may or may not see a logical name associated with each mailbox...

    The logical translates to the first of the two mailboxes created. Upon
    image rundown, the mailboxes and logicals go, and the quota comes back.
    
Thanks,
Ross

    >� I would bet that your process is "collecting" mailboxes.
    
    > Hmmm... I'll make a note not to gamble against you
    
    Since I have the source code the deck is stacked in my favor..:-}
    
    The info you have provided me with is excellent. We have a memory leak
    in the CMUserSendEvent or IPC routines.
    
    I've got a couple Mission Critical customers breathing down my neck so
    I'll work on this one when I get those off my desk. 
    
    Quite frankly, the CMuserSendEvent routine *needs* to be augmented or
    rewritten as it's not very efficient. Everytime you call it a new pair
    of IPC "sockets" is created and destroyed. What really should happen is
    the first call should setup the sockets and leave them there. 
    
    Regs,
      Dan

�    I've got a couple Mission Critical customers breathing down my neck so
�    I'll work on this one when I get those off my desk. 
    
    Whenever...

�    Quite frankly, the CMuserSendEvent routine *needs* to be augmented...

    Actually, it would be nice if it did something about telling C3 that
    an event had occurred, so that from C3, the user could see the event
    as part of the 'event history for the system'. Of course, I recognise
    that that would be way beyond fixing a memory leak.

    Thanks, once again, for your help and support.

Ross

    Actually, never having written something that had to run on a UNIX system,
    what stops the API routine from returning SS$_EXBYTLM or somesuch ?

Ross

    >Actually, it would be nice if it did something about telling C3 that
    > an event had occurred, so that from C3, the user could see the
    >event as part of the 'event history for the system'. Of course, I
    >recognise that that would be way beyond fixing a memory leak.
    
    The problem with this is that events generated via CMUserSendEvent are
    not logged anywhere (You probably already knew that). This is because 
    we the routine sends the event packet directly to the ENS Daemon and
    not a line controller. It's the line controllers job to log everything.
    
    I feel this is a neeeded feature though and it has been a suggested
    enhancement. It's just going to take some thought to design the best
    method to accomplish it.
    
    >why can't the routine retrun SS$_EXBYTLM or some such.
    
    Conceptually, there is no reason. The routine was designed to be
    portable hence it receives a known set of return codes from the underlying 
    platform-specific routines that handle the acutal interprocess 
    communication. These return codes cause the routine to spit out the
    201,202,203 etc. PCM return codes.
    
    Regs,
      Dan

Dan,

This problem with the memory leak has now been logged with the UK CSC and I
shall be sending an IPMT your way shortly ! 

Many thanks for the work you've done on it so far.

Regards,

Simon R. Mills,
OpenVMS Group, UK CSC

    Ummm... to be honest I have not even had a chance to give this issue a
    second thought. There have been numerous more critical problems that
    have taken up a great deal of time. I should have had the original
    poster of this problem IPMT it at the time. You did the best thing by
    doing so.
    
    Regs,
      Dan

Dan,

    my dial-in has been down for weeks but, with thanks to Simon, we have a 
'work-around' which has fixed the problem for us.

    Apparently, by changing my source code so that instead of...

	CMContext context = 0;

		...to...

	static CMContext context = 0;

    ...the problem no longer occurs. Fortunately, my code was very similar to
the example, so I could make a similar change. Odd to say the least. I take it
that by using the 'static' I get storage allocated in the image as opposed to
vm ? Oh well... 

Thanks for all your help with the last 20 odd replies, it was much appreciated.

Ross

    Ross,
      I figured that was your IPMT that the NSI team asked me about. They
    told me they had found the dynamically declared context in the loop and
    they thought it should be a "static" declaration. My response to them
    was that the declaration should be with the other data declarations as
    this variable only needs to be declared once. So what you were given 
    is really the solution and not a workaorund. Damned interesting
    side-effect you found though!!
    
    Regs,
       Dan