00030010: EOC due to DEREGISTER of partner.

Hello All!

Once the Entire-X service is started and a couple of Entire-X calls are made, I receive this message which takes down the Entire-X Service. Any idea what the cause of this might be?

I am using SoftwareAG.EntireX.NETWrapper.Runtime.dll version ( This project was on the shelf for a few months. It worked fine before that and now this error is appearing and shutting down the service.

Thanks for any help with this.

what are you using for the client and server components? Is the backend server being called by the .Net Wrapper? If so, what errors are happening on the server side?

Typically, a client failure / unexpected logoff could cause the server to report this error, but is unlikely to cause the server to shut down. More likely is that something in the server code is failing, causing it to logoff from Broker unexpectedly.

If the server is .Net, check for unhandled exceptions.

I work with Jay and here are the details.

We have mainframe broker and rpc jobs to talk to Natural as a server.

I have a sample trace. Call one is the most recent call from a .NET program to a Natural subprogram through Broker and then a RPC job. This is the call:

W00/ETBXWKR Jan-23-2007 07:40:33 ETBD0282 SPFX Values:
Prefix = 8000051C000001760000001C00000000000001E1000001ED03000000
Unique-ID = 424853462D54544E2D2D30303030303844342D2D3030303030464338
Bin string: 04000800F6E890F0A95D1524

The above seems like a normal call to retrieve data, but the next log entry shows a DEREGISTER:

W00/ETBXWKR Jan-23-2007 07:40:33 ETBD0282 SPFX Values:
Prefix = 22010318000000180000000000000000000000000000005A
Unique-ID = 000115C220640000404040404040404000F6DE80C00B86E8D2AA1600

And after this, the RPC job goes down and the service is not available. I don’t know if this is because of a Natural error, or something.

The RPC job shows this:

Page 1 01/23/07 07:39:54
NAT0082 Invalid command, or Program SCNERP does not exist in library.

However, program SCNERP is in this library, so it is not missing. And I’m not sure if this error is causing the RPC to go down.

Any ideas?

Looks like you are showing the CMPRINT output, not the RPC trace RPC=(TRACE=1) that will show up in CMPRT10. That trace will show the details of the RPC calls and CALLNATs made from the server. If you use TRACE=2, you will see the buffers being received and returned and Broker errors encountered.

At a guess, from the output you are showing, the program called was attempting to do an INPUT and there was nothing in the stack for it to input, so it tried to call SCNERP, which wasn’t available. Generally, INPUT statements are not advisable for subprograms called from RPC Server. A FETCH may also bring down the RPC Server.

Are you using Natural Security? Is the client using NaturalLogon=true? If so, is the client program logging on to a different Natural library than SCNERP is in? The RPC TRACE will show what LOGONs are being performed to what library, so maybe you will find some more information if you turn on that trace.

You may also want to investigate the called subprogram’s ON ERROR statement to see if it is doing something inappropriate for a service subprogram (e.g. FETCH, TERMINATE, STOP)