[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rocks::dec_edi

Title:DEC/EDI
Notice:DEC/EDI V2.1 - see note 2002
Moderator:METSYS::BABER
Created:Wed Jun 06 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3150
Total number of notes:13466

3114.0. "How get rid of DECEDI_IMO_IMPL servers?" by RULLE::KLASSON (Sven-Olof Klasson @GOO) Tue Apr 29 1997 19:46

Hi,

A customer has some trouble with DEC/EDI and Objectbroker. They have DEC/EDI 
V2.1D on VMS/Alpha and Objectbroker V2.7-10
When they issue a TRADE POST or TRADE FETCH command on the EDI server node 
they sometimes get the errormessage 
%DECEDI-E-NOFREEOBJ, No free server available

TRADE TRACK works fine. Also EDI clients on remote nodes works fine.

I noticed that the local node was registered in "edit config" with 
"Objectbroker required" set to YES. APPL/BROKER SHOW SERVER show me that there
is a DECEDI_IMO_IMPL server running on the EDI server node.
I assume DECEDI_IMO_IMPL is the server process that read/write files from the
users directory and should normally only be seen on remote client nodes 
(correct me if I'm wrong here).
To get around the NOFREEOBJ error the DECEDI_IMO_IMPL has to be stopped.

This might be a Objectbroker problem, but it's also a configuration problem
in DEC/EDI since the local node should not be registered with "Objectbroker 
required" set to YES.
I have changed this to NO, but the DECEDI_IMO_IMPL is still started on the 
local node. I have even restarted both Objectbroker and DEC/EDI.

It seems like if the local node once has been registered with 
"Objectbroker required" set to YES, it's does not matter if I set NO here.
DECEDI_IMO_IMPL will still be started.

How can I get rid of the DECEDI_IMO_IMPL server processes?
Do I have to delete the local node definition and all applications, and then 
reenter it all?
                                                  
Thanks,
Sven-Olof
T.RTitleUserPersonal
Name
DateLines
3114.1METSYS::THOMPSONTue Apr 29 1997 20:3818
Hi,

I wondered when this would come in :-(

The IMO server is the one that maintains a pool of "Initial Object References"
that it doles out to requesting clients. 

When you have more than 20 active requests simultaneously you
get this error.

Do you have more than 20 outstanding requests? i.e. 20 active IMF servers?

If you don't, then read the note I wrote about OpenVMS V7. In one of
the replies is a small ObjectBroker re-configuration that can help.

Otherwise $application/broker stop server <imo-process-instance-uuid>

Mark
3114.2RULLE::KLASSONSven-Olof Klasson @GOOWed Apr 30 1997 13:1335
Hi Mark,

> When you have more than 20 active requests simultaneously you
> get this error.
> 
> Do you have more than 20 outstanding requests? i.e. 20 active IMF servers?

This is seen on a test and development system. It's only used by a few 
developers. It's unlikly there will be more then one or possible two
simultanious requests.

APPL/BROKER SHOW SERVER show one DECEDI_IMF_IMPL, one DECEDI_IMO_IMPL and
one DECEDI_IMT_IMPL server. A total of three servers.

> The IMO server is the one that maintains a pool of "Initial Object References"
> that it doles out to requesting clients.

Is there any way to see if "Initial Object References" are not returned to the
pool after beeing used?

> If you don't, then read the note I wrote about OpenVMS V7. In one of
> the replies is a small ObjectBroker re-configuration that can help.

I found this in 2978.6

> For ObjectBroker V2.7. This is required for a mixed TCP DECnet system and
> it appears to work around a serious problem that affects DEC/EDI:
....
> OBB> modify configuration "DECnet-Only Configuration"  /ACCEPT_AUTHR_WO_AUTHN

Sorry, but I was wrong about the Objectbroker version in .0 This system has 
OBB v2.6. Is the above command still of interest for OBB v2.6?

Thanks,
Sven-Olof
3114.3METSYS::THOMPSONWed Apr 30 1997 14:4411
At the moment if the client experiences a communication failure after
it has started some operations, the IMO server is unaware that it
has gone away.

Another variant - does it fail after exactly 20 posts?


You could try that re-config on V2.6. 

M
3114.4RULLE::KLASSONSven-Olof Klasson @GOOFri May 02 1997 13:2745
> At the moment if the client experiences a communication failure after
> it has started some operations, the IMO server is unaware that it
> has gone away.

I'm getting worried now. This customer (Ericsson) is currently running V2.1C
and OBB V2.5B in their production environment. They have a quite large number
of clients, and this number is growing. I think they will have up to 50-100
clients connected to one EDI server. Some of them are connected via WAN 
connections were there from time to time are communication problems.

V2.1D and OBB V2.6 are planned to be installed on the production system in a 
few weeks. If "Initial Object References" are not returned to the pool by the
IMO server if a communication failure occurs I belive the IMO server will
run out of "Initial Object References" now and then.

Mark, can you comment this.

> Another variant - does it fail after exactly 20 posts?

I don't think so. But perhaps is it failing after 20 communication failures. 
While being logged on to the system I noticed one client has been connected
via a TCP/IP link most of the time.

UCX> SHOW DEVICE
....
  bg1946      STREAM    1161    2462                   osedt5.ericsson.se
....

Device BG1946 is owned by the DECEDI_IMF_IMPL server (when I have seen this,
this has been the only IMF server on the EDI server node).
$ SHOW DEVICE BG1946 /FULL shows that "Operations completed" only occasionly
increments.
Could this indicate a communication problem?
Or could be that the client is waiting for a document (TRADE FETCH/TIMEOUT=...)?


If the IMO server runs out of "Initial Object References" will any client
(local and remote) be able to post/fetch files? 
The customer has told me they have not seen any problem with remote clients 
to this system. I'm not 100% convinced this is true. I'll ask them to verify 
this.

Thanks,
Sven-Olof
                      
3114.5RULLE::KLASSONSven-Olof Klasson @GOOMon May 05 1997 17:2678
Hi Mark,

> OBB> modify configuration "DECnet-Only Configuration"  /ACCEPT_AUTHR_WO_AUTHN

This is allready set. OBB SHOW AGENT displays 
"Attributes: AuthrWOAuthn is ENABLED"

I belive this says /ACCEPT_AUTHR_WO_AUTHN has been set. 
On my test system I did set /NOaccept_authr_wo_authn. The OBB SHOW AGENT 
displayed "Attributes: AuthrWOAuthn is DISABLED" after that.


I read topic 2408 in OBJECTBROKER_DEVELOPMENT once again. You say that IMO
server does not know about servers that dies, and that this causes loss of
"Initial Object References" from the internal pool.
If a server had died would this mean I should see it on the EDI server node
with OBB SHOW SERVER as a server with status "died"?
Does it have to be on the EDI server node, or could servers have died on
EDI client nodes too?
I dont see any died OBB implementation servers on the EDI server node. See the
attached log.


This problem cause me problems. The customer want's to upgrade their production
system. But that's on hold until this problem is solved.
I might need to open a IPMT case on this.

Below is output from OBB SHOW AGENT and OBB SHOW SERVER when the problem is
seen. This is from the EDI server node.

Thanks,
Sven-Olof

EDITST>trade fetch anna dummy.file/link=dummy/typ=trans

%DECEDI-E-NOFREEOBJ, No free server available
%DECEDI-E-NOFREEOBJ, No free server available

EDITST>appl/broker sho agent

Agent on node: EDITST
  Version:      OBB V2.6-07
  Username:     system
  Time Started: Thu Apr 24 15:23:19 1997
  Pid:          00000EBF
  Log Filename: SYS$SPECIFIC:[OBB.SCRATCH.EDITST]OBB$AGENT.LOG;19
  Attributes:   AuthrWOAuthn is ENABLED
                Active transports are DECnet, TCPIP
                OrbV12 style Agent

EDITST>appl/broker sho server

Implementation Servers on node EDITST.

  Implementation Name                         Username      Status
  ------------------------------------------  ------------  ------
  DECEDI_IMF_IMPL                             decedi        Executing     
      Inst UUID:    7c3b7e871f40.0c.05.98.00.00.00.00.00    Pid: 00000E42
      Impl UUID:    68eb4b476f3b.0c.70.a9.00.00.00.00.00
      Registered at: Thu Apr 24 15:24:44 1997  

  Server has no attributes

  DECEDI_IMO_IMPL                             pvaseib       Executing     
      Inst UUID:    7c3b7cd86880.0c.39.04.00.00.00.00.00    Pid: 000041D3
      Impl UUID:    77b71d8d9182.0c.d0.a8.00.00.00.00.00
      Registered at: Thu Apr 24 15:29:22 1997  

  Server has no attributes

  DECEDI_IMT_IMPL                             edtoguz       Executing     
      Inst UUID:    7c3c296bd5df.0c.39.04.00.00.00.00.00    Pid: 00001CBC
      Impl UUID:    68eeba773e38.0c.70.a9.00.00.00.00.00
      Registered at: Thu Apr 24 18:35:59 1997  

  Server has no attributes

%OBB-I-CMD_NUMMSRVSFND, 3 servers found. 
3114.6METSYS::THOMPSONMon May 05 1997 19:268
Hi,

The server dieing is just one possible circumstance.

The other is client failure. Are the clients seeing any communication
errors?

M
3114.7RULLE::KLASSONSven-Olof Klasson @GOOMon May 05 1997 21:0827
Hi,

> The other is client failure. Are the clients seeing any communication
> errors?

I don't know. The problem here is that there are several clients in diffrent
countries. It's difficult to monitor all of them. It's not easy to tell all 
users either that they must tell us about communication problems.

I would guess that there are communications problems between the server and
the clients. I have seen problems with their network before when I have been 
logged on to their system. This has not caused any problems with EDI V2.1C 
and OBB V2.5B wich is their current production environment.
If DEC/EDI can't handle communication problems properly it's a show stopper
for upgrading the production environment.

I have asked the customer to verify if remote clients also see this problem.
No reports of problems has been received from remote clients, but I guess they
see problems too (perhaps the users on remote systems don't reports problems
if they belive it's the network...). Problem frequency is 1-2 times/week.

Mark, do you have any idea on how to find this problem?
What about a special IMO debug image that log information when giving a object
reference to a client, and return of it?


Sven-Olof
3114.8Current statusRULLE::KLASSONSven-Olof Klasson @GOOFri May 16 1997 18:4112
    Hi,
    
    In case anyone wonders......
    The problem has not been seen for a while. I don't know why.
    Nothing has been fixed.
    
    This is bad since the customer is afraid the the problem will come
    back (and so am I) and dare not to upgrade their production system.
    Something must be causing the problem. I wish I did not what....
    
    /Sven-Olof
              
3114.9METSYS::THOMPSONFri May 16 1997 19:557
We are doing a bit of re-design of the IMO server.

Basically it works well as long as there no communication problems.
We will make it more so shortly.

Mark