Two RPC services can't co-exist without one of them issuing 3009 errors

Have tried different ADM2 plus ETID values in NatSec to no avail
Both run fine as standalones (without the other). No consistency
in which service will produce the 3009s

ADA854, NAT912, ENTIREX 10.9, NDV912

‘NAT3009 Last transaction backed out of database 78. Subcode 66’ for all transactions

Hi Andy - this is a known “feature” - and solved by applying NATRPC39
Finn
See full doc here

Avoiding Error Message NAT3009 from Server Program

If a server application program does not issue a database call during a longer period of time, the next database call might return a NAT3009 error message.

To avoid this problem, the optional user exit NATRPC39 is provided. This exit is called in the following cases:

  1. After a Ping command;
  2. In case of communication via the EntireX Broker: each time the SERVER-NONACT time is exceeded.

Start of instruction setTo activate the user exit NATRPC39

  1. Copy the sample exit NATRPC39 from library SYSRPC to library SYSTEM on system file FUSER.The steplib concatenation of the library to which the server currently is logged on is not evaluated.
  2. Adapt the database ID which is assigned to field ACB-RSP to your needs.
  3. Add additional CALL 'CMADA' statements, which reference additional database IDs to your NATRPC39 if more than one Adabas database is involved.

Apologies, forgot to mention this is already in place. Thanks anyway

Interesting, there is no subcode 6 for a Rsp 9 …

What ETID settings have you tried ? F or S should work as they include a timestamp in the actual ETID.

As requested Wolfgang. Thanks
- Preset User Values -

ETID … U

   ETID

Default … *USER

So does it work when you change it to an “F” ?

Thanks for the response.
We dare not use ‘F’ due to it’s similar functionality to ‘S’ which messed up our ETIDs whilst using DPS
Apologies but the Subcode is a 66.
Incidentally, we’re zIIP enabled

Here’s an update just in case anybody encounters the same issue, a workaround of amending the RPC PROC and adding parameter ‘DBOPEN=ON’ seems to have worked. Any comments why that would work would be appreciated. SAG investigations ongoing

Hi Andy ,

What is the path of the RPC PROC?

image002.jpg

image001_cccd2bf4-c3e0-4c96-b556-98cf81244cdf.png

image004_138bdf32-6aba-4681-ad4f-53daa86ec9e9.png

image005_23761c5f-d053-49df-925a-4e1797e33662.png

image006_856dd121-bc28-4c4f-9ffe-0137aa2ba9e1.png

image002_e53bb60d-f059-4fa4-a953-c4665e2c6914.png

image018_5be77e41-1272-444f-9c7d-e42a7e25e9d7.png

Hi Leon, PROC is in SYS3.PROCLIB, is that what u meant?

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.