Hi,

in our customer scenario we have Natural / Adabas / EntireX Broker on mainframe (OS/390) and a new Java-Frontend with servlets and XSL stylesheets on linux with non-conversational communication (stateless) to the rpc server.

Up to now we did not need any transaction logic because we always updated a single record for each db action and had our own business logic to make sure that one record was only updated by one user.

But in the next project phase we have to realize much more complicated database activities → so we will need transaction logic.

So here my questions:

1.) Is it true that all rpc calls from java to natural work with the same natural-userid = sysrpc ?
2.) Is it therefore true that one isn’t able to use the user-dependent natural *-variables like *user etc ?
3.) What happens if we use transaction logic from natural / adabas, all users work with the same userid + etid (?) and one user submits an ET ? Are then all open transactions closed or just this one ?
4.) Is it somehow possible to transport a user-specific etid between java and rpc ?
4.) Do we have to program all the transaction logic done by natural / adabas “manually” ??
5.) Do we have to use conversational communication between java and the natural rpc server to be sure that we are identified correctly by natural and to use the natural / adabas transaction logic ? But this seems not really an alternative because the system has 3500 concurrent users (do we then need several hundred parallel rpc instances ??)


Thanks for any answer.

Regards


Dirk Holbeck

The following answer is from an internal SAG list where this question was cross-posted:

1 & 2) if you use LOGONRQ=ON, then *USER shows the logged-on Natural Security userid.
3) Configure your RPC server to use ETID=’ ’ (blank). Each server replicate is independent: you cannot have two replicates running with the same ETID - Adabas won’t allow it. When one replicate does an ET, it applies only to that server replicate.
4) there are options to have ET’s take place on close of conversation.
5) If you are going to do a group of related updates across several RPC calls, then you must use conversations to tie the updates together and to the same RPC server replicate. If you do not use conversations, then you must do end of transaction on each call or nothing will make sense. As to how many server replicates you need: this depends on how long the transactions are likely to run and how active your concurrent users are. As with online Natural / Adabas transactions, you want to avoid having transactions span any user interactions as there is no guarantee as to when the user will return to complete the transaction. You can use the Natural RPC Server’s NTASKS option to configure up to 99 servers in one batch address space (use shared nucleus and either global buffer pool or shared local buffer pool and tune the various buffer sizes (esize, fsize, etc) for efficient memory usage).

If you are having problems due to the size of the message, consider using the BKIMBTSO interface with Natural (TCP/IP interface), which will let you send/receive as large a message as Natural can define. This may allow you to do your transaction in one call.


Kind regards,
Rolf

Rolf Bahlke
Software AG Research and Development.