I understand some transaction timeouts on entireX.
I have run a trace on the broker but could not find or see any error or time outs from the trace.
We have 3 environments running on the same broker and the time out only happens on one of them.
The problem is also random in that you will do one look up using entireX service which will then be successful and when you do the same look up again it gives an time out error.
I had the current software rolled back to the previous version but it still happens.
Does anyone have advice on how to track down the problem?
you need to give some more information - what are the partners (client, server), what platform and version are each of the pieces, are you using RPC or ACI?
What are the partners (client, server)
We make the call from the client to the server.
Server is a Natural RPC server on the Mainframe
What platform and version are each of the pieces
Entire X version 7.3.2 (Entire X Broker on the Mainframe)
Natural version 4.2.3 (Natural RPC server on the Mainframe)
Adabas SAF Security 8.1 2 2008-08-26
Adabas Fastpath 7.4 2 2005-06-11
Adabas Online System 8.1 2 2009-02-17
Adabas Transaction Manager 7.4 2 2005-06-11
Adabas Vista 7.4 2 2005-06-11
System Coordinator for Adabas Options 7.4 2 2005-06-11
Natural Construct 5.3 1 2010-08-06
Entire System Server 3.4 2 2009-03-08
Natural ISPF 2.6 3 2007-11-12
Natural Business Services 5.3 1 2010-08-06
Natural Com-plete Interface 4.2 3 2006-10-13
Natural Optimizer Compiler 4.2 3 2006-02-20
Natural Security 4.2 3 2007-12-18
Natural Connection 4.2 3 2006-02-20
Are you using RPC or ACI?
RPC
Just some more info on our environment.
We have vb.net front ends for the user, these front ends make call to Vb6 packers which then make the call to the entireX broker. On Natural we have driver subprograms to handle the request coming from the entireX broker and send the required information back.
There is currently 1 service running in the environment with the problem with a 10 min time out setting. The reason for this 1 service is it is not not a busy environment. We have started additional services but the problem still ocured.
Please let me know if you require more information.
Are you using the Natural RPC Server? I ask since you mention that you have “driver subprograms”…
I’m not familiar with a “Vb6 packer”. You can use the .Net Wrappers to make RPC calls from vb.net, which might help to eliminate a layer.
Tracing information for EntireX is described in the documentation. See the “Administraton under…” topics and look for the “Logging and Tracing” section.
For Natural RPC Server, you’ll need the Natural documentation. Add a TRACE= parameter and define the print file 10 (CMPRT10).
I’d check your Broker log first (trace level 1 should be sufficient): see if the calls are reaching the Broker from the client or not.
If your Vb6 client is the piece reporting the 00740074, the Broker stub trace and EntireX RPC traces are most likely to help you in locating the problem. Look for the environment variables ETB_STUBLOG and ERX_TRACELEVEL.