EntireX RPC Server Code 02150254 / Ping

,
1

We use .NET applications to connect to the Broker and RPC Servers on the mainframe.

Case 1:
We had to restart very often our RPC Servers because they ended after non-activities.
To avoid this situation, we now ping every minute the server to keep it up.
During a presentation, SAG told us that this is not necessary.

M *** Initialize a Natural RPC server at 2008-08-25 06:05:07
M *** with name STDEVL
M *** on host SY2
M *** under z/OS 01.09.00
M *** Natural nucleus version : 4.2.3
M *** Natural system file version : 4.2.3 service pack 3
M *** Natural RPC version : 6.2.3 update level 1
M *** Highest supported RPC protocol: 2020
M *** SYSIDL version : 6.1.1.8
M *** Natural server library : WKES01
M *** Natural server user ID : STRPCH
M *** Natural security activated : Yes
M *** Logon data required (LOGONRQ) : Yes
M *** System file settings
M *** FUSER = ( 112 , 205 )
M *** FNAT = ( 226 , 54 )
M *** FSEC = ( 112 , 204 )
M *** Steplib settings
M *** WKES01 ( 112 , 205 )
M *** DLSTMAIN ( 112 , 205 )
M *** DLSTSYS ( 112 , 205 )
M *** DLSTCST ( 112 , 205 )
M *** SYSCST ( 226 , 54 )
M *** SYSEXT ( 226 , 54 )
M *** SYSLIBS ( 226 , 54 )
M *** SYSLIB ( 226 , 54 )
M *** SYSIDL ( 226 , 54 )
M *** SYSTEM ( 112 , 205 )
M *** SYSTEM ( 226 , 54 )
M *** Natural security settings according to RPC server profile
M *** Timestamp related ETID : N
M *** Parameters for transport
M *** Server (SRVNAME) : STDEVL
M *** Node (SRVNODE) : ETB212
M *** User ID (SRVUSER) : *NSC
M *** Buffer (MAXBUFF) : 30720 bytes
M *** Version (ACIVERS) : 7
M *** Code page (CPRPC) : N/A
M EntireX Broker Stub Version=7.2.1.92, Highest API Supported=8
M *** Natural server environment successfully initialized at 06:05:07
M *** LOGON to Broker ETB212 at 06:05:07
M *** Initialization of transport successful at 06:05:07
M *** Server STDEVL is up at 06:05:07

Does someone have a replacement for our ping solution?
Maybe set all non-activity time-window parameters to high-value?
Does a new version fix this problem?

Case2:
Since we ping, from time to time the servers terminate:

********** USER-ID: STRPCH LIB : WKES01
B *** Return from listen at 2008-08-27 05:18:08
FUNCTION: L RC: 3 SERVER: STDEVL
02150254 NET: Connection error subcode 30C00003
SEND-LEN: 30720 REC-LEN: 0
M *** RC 3 from listen request. Server terminates
MC *** Server is terminated at 2008-08-27 05:18:08

I cannot find the response code 02150254
Can someone help or have ideas?

Thanks,
Dieter Storr

2

You were indeed told correctly - you should not have to use the “ping” to keep the servers up. Is the error you get when the servers terminate the same whether or not you ping them?

The 0215 class errors are essentially Adabas response codes, since they come from the Adabas SVC. So a response code 254 is CT parameter limit exceeded. Check your Broker job log for “user gone” messages that would correspond with the ADAM93 message.

This value is set in the Broker Attribute file as TIME= (in the DEFAULTS=NET section, next to ADASVC, IUBL, etc) - you probably need to increase this value. The default is 30, most sites I’ve seen need 60 or 120.

(You should upgrade your EntireX also - v7.2.1 is out of support!)

3

This behavior may be caused if the communication between the Natural RPC server and the EntireX Broker is via Entire Net-work. In this case the EntireX SERVER-NONACT time for the Natural RPC server must be less than the REPLYTIM in the Entire Net-Work NODE statement.
Please check.

4

Several reasons for our time-out problem:

  • Broker and Server didn’t have the same priority
  • The RPC Server jobs have been swapped out, when the time-out happened

The question came up whether to define the servers non-swappable - same as the Adabas nucleus?

5

interesting - I’ve encountered other sites with the same issue and they were also on v7.2.1. I haven’t seen this with sites on v7.3 or v8.0 (yet!). I haven’t encountered any sites that make their Natural RPC Server jobs non-swappable, although I do recommend that they run at a priority closer to online (since their function is conceptually similar to CICS in that they provide online services for many users) rather than standard batch priority.