Conference ucrow::desktop_acms

Dave,

We have seen this error occur on V2.0/V2.2 when using large
optimized workspaces (total count / task call >32k).  We
have an ECO kit that corrects this error.

Outside of the ECO scenerio above, you may have a resource shortage, 
that only system tuning and monitoring of systems resources would 
reveal. 

If you determine that none of the above situations address the
problem, please submit an IPMT case, so that we may properly
address the problem.

Thanks,

Colette

>>                      <<< Note 845.0 by CSC32::D_BUTLER >>>
>>             -< INSFMEM error in ACMSDI$SERVER - System problem? >-

I have some updated information on this.  Perhaps it will help.

First of all, versions are:

acmsdi v2.2, acms v4.1, vax, openvms v6.1, tgv multinet, appletalk

The user is adding users to their system.  They began seeing the problem
as the number of users connecting to the di server increased.  Doubling
pgflquo seems to have solved one problem, but has moved them to the
next one, which is the insfmem error.

From what I can gather, one likely source of this error is the sysgen
parameter CTLPAGES being set too low.  They have this value set at
100 (default?), so this might be it.  However, the information I have
been able to glean also states that the most likely cause for
exhausting ctlpage is creating logical names.  Does the desktop
server do a lot of this?

Another piece of information is that this insfmem error is accompanied
by a %acmsdi-e-errdursignin error.  So, it appears that whatever resource
is being exhausted is one that is used when signing users in.

There are also occasional 

%acmsdi-f-internal, internal acmsdi rpc error.  Call to close socket
failed: 14

FWIW, the C errno value 14 is EFAULT /* bad address */, which doesn't
make a lot of sense in this setting (at least not to me).

I have posted the socket error information to possibly tie this
to something else.  Most of their users are coming in over their tcp/ip
connection.  There are a few mac/appletalk users, but it's mostly tcp/ip.
In one of Digital's earlier version of UCX, the INSFMEM error could
occur when creating sockets if certain buffer parameters were too low.
I can probably provide details if it will help.  

Could this problem be caused by Multinet's tcp/ip layer running out of 
some resource?  Does anyone have any experience with this?  I have asked 
the customer to check their network and ask TGV if they are aware of any 
resource issues which will lead to this error.

That's all for now.

Thanks,

Jerry

>From what I can gather, one likely source of this error is the sysgen
>parameter CTLPAGES being set too low.  They have this value set at
>100 (default?), so this might be it.  However, the information I have
>been able to glean also states that the most likely cause for
>exhausting ctlpage is creating logical names.  Does the desktop
>server do a lot of this?

The Desktop server does not create a *lot* of logicals, just 3
as far as I can tell from studying the code. The logicals are
defined at server startup time.


>There are also occasional 
>
>%acmsdi-f-internal, internal acmsdi rpc error.  Call to close socket
>failed: 14

These errors messages are more 'noise' than value and usaually are
preceded by "unexpected deletion of client" errors.  These extra
messages have been cleaned up in the V2.2 ECO2 kit.  But the
more important question is why is the client being disconnected 
unexpectedly?

>Could this problem be caused by Multinet's tcp/ip layer running out of 
>some resource?  Does anyone have any experience with this?  I have asked 
>the customer to check their network and ask TGV if they are aware of any 
>resource issues which will lead to this error.

The resource problem sounds suspect.  We have not seen this condition
specific to TGV. In general our experience with TGV is that it behaves
very much the same as UCX during testing etc.

Colette

I have an update on this.  I just spoke with the customer, and
have a rather lengthy tale to tell.

She had earlier applied eco 1 and upgraded openvms v6.1 to v6.2 (vax)
at the same time.  When she did this, the di server began
logging %system-f-deadlock errors on user sign in.  This was on
a 3 node cluster, with approximately 600 total users logged in
to all three nodes.

Thinking that eco 1 was at the root of this, she backed it out and
fell back to acmsdi v2.2.  This did not help.  So, after a lot
of investigation on my part and her part, she decided that she had
messed up the upgrade, and simply dropped back to ovms v6.1.

Since then, they have not had the deadlock or the insfmem problem.
The only change that they have made was to run the di server from
a new account that mimics system.  I'm not sure why this would make
a difference, but so far it has.

At this time, the customer is watching to see what happens, and will
let me know if there are new developments.

Also, regarding the deadlock problem, I have some additional information.
The most suggested solution I have found in here to fix this problem
was to apply vaxsys15_061.  On this customer's v6.1 system, this eco
was applied in November 1995, and they have never experienced the
deadlock problem on that system.  When they upgraded, they did not
apply the v6.2 equivalent (vaxsys02_062), and had the deadlock problem.
I had suggested that they apply this eco, but they never did because
they discovered other problems with the upgrade and decided to
drop back to v6.1.  I don't know if the eco resolves the deadlock
problem, but it appears to me that it does.

Jerry

SS$_INSFMEM resolved by increasing sysgen parameters
CTLPAGES and PIOPAGES.

Deadlock error resolved by installing LMF patch on
VMS 6.2 system.

Thanks Jerry!!

Colette