[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mumps-l
Subject:    Re: MSMAPI - hang problem
From:       Liz Marancik <LizM () Micronetics ! com>
Date:       1997-05-30 17:16:11
[Download RAW message or body]


ServerQ is a problem involving your muserver jobs on the UNIX system.
We did have a problem in this area which has been resolved in 4.3.  But
it is conceivable that you simply ran out of muservers - these are
necessary for HFS access and some %HOSTCMD functions, as well as the
socket connections necessary for the API, etc.

If this is a chronic problem, try increasing the number of muservers. Or
perhaps you should give us a call to see if continue to experience this.

Liz
Micronetics Design




        -----Original Message-----
        From:   Greg Shepherd [SMTP:gshepherd@metronet.de]
        Sent:   Tuesday, May 27, 1997 12:07 PM
        To:     Multiple recipients of list MUMPS-L
        Subject:        MSMAPI - hang problem

        Dear All,

        MSM Unix version 4.2.3
        MSM API v3
        TCPLOGIN partition size 96k
        %MSERVER partition size 25k

        Again somebody else's system I was asked to have a look at. The
TCPLOGIN
        job was running fine for a good 3 months with users logging
on/off
        throughout each workday. The Unix has 90+ partitions available,
box runs
        over users logging on via LAT. Normal use seems to be 50-60
partitions used
        at peak times.

        Last week the TCPLOGIN job hung with SERVERQ status showing in
%SS. Does
        anyone have an idea what could cause this? New %MSERVER jobs
were then
        hanging and eventually login was no longer possible. %MSERVER
jobs cannot
        be killed with ^KILLJOB. TCPLOGIN was able to be stopped using
the control
        from ^APIMGR and restarted, but problem was not cleared.

        Just in case you think I'm being lazy, I have had a think about
the problem
        :-) I can only think that the TCPLOGIN job was trying to stop a
%MSERVER
        job. Either the UNIX side had a problem or devices 63 and/or 52
were open,
        if the TCPLOGIN was stopping the jobs via KILL^KILLJOB.

        Thanks in anticipation.
        Greg Shepherd

        Quote for the day "Make it idiot-proof and someone will make a
better idiot"

[prev in list] [next in list] [prev in thread] [next in thread]