Conversational RPC with java example?

, ,
1

Hi,

Does anyone have an example of conversational RPC using java? We’re using EntireX Workbench 7.1.1.30 to generate our java helper classes.

To give you a small snippet of how I call the services now (assuming the name of the subprogram on the mainframe side is SGN006C1):

Broker broker = new Broker();
OurService service = new OurService(broker);
service.sgn006c1();
logoff(broker);
</pre><BR>Given the above code snippet, how would I make this conversational? In case you're wondering, I'm contemplating conversational because the data being transferred will be more than the internal limit for RPC. Rather than attempt some kind of kludge to make multiple calls in the above fashion, I would like to do this the right way and do it with conversational RPC. Haven't found much in the docs, hence posting here.<BR><BR>To be honest, I also haven't tried writing any conversational code yet. Just wanted to make sure, I was on the right track before proceeding.<BR><BR>Some random thoughts are below:<BR><BR>If I create a Conversation object, e.g.: <pre class="ip-ubbcode-code-pre">Conversation conv = new Conversation(service);</pre><BR>and then use it with my service:<BR> <pre class="ip-ubbcode-code-pre">service.setConversation(service);



A little help is greatly appreciated. In addition, it would help to know if I’m barking up the wrong tree. Writing code in ACI could also be considered as a last resort.

2
quote:
If I create a Conversation object, e.g.: [code] Conversation conv = new Conversation(service);
and then use it with my service:
service.setConversation(service);

Hi Haroon,
welcome to the forum.

You outlined exactly how to do it. Don't forget to call 
service.closeConversation();
or 
service.closeConversationCommit();
[/code]
 to finsh the conversation.

Kind regards,
Rolf
3
quote:

[code] service.setConversation(service);

Oops.. that should have been 
service.setConversation(conv);
by the way.

In any case, Rolf, thanks for the reply. I was pretty much taking a shot in the dark. I'm glad that I was on target :p

Somehow, I had this notion of "send and receive" in a while loop. I saw some ACI code which went as follows: 
conv.send(request);
do {
   reply = conv.receive();
   // do something with the reply
   // e.g., keep adding to a StringBuffer
   sb.append(reply.toString());
} while( reply != null );
[/code]


What would be the equivalent of this "while loop" on the conversational RPC side? Remember, all I'm interested in is to bypass the 32K limit and do multiple trips using the same conversation. How do I keep adding to the data retrieved in the same conversation? Is there an example for that?

A few more conceptual questions? (I'm a pure java programmer and rely on other people on my team to do the mainframe work - NATURAL subprograms)

I know that using conversational will tie up a server to a client until end of conversation. A suggested work-around is to increase NTASKS, I suppose.

Does it even make sense to use conversational when all I'm trying to do is to get around the RPC internal limit (32K??)? I could accomplish the same thing using my current approach and adding some navigational parameters so that the data transfer can happen at increments (where to start/stop - where did I leave it off in the last trip, etc). Pros? Cons?

Thanks in advance
4

Haroon - I’d be glad to outline some approaches. I’m assuming the data transfer is from Natural to Java rather than the other way around.

On the Natural side, the called subprogram(s) may need to use “DEFINE DATA CONTEXT” to keep track of how much data has been sent already. As each RPC call to a subprogram invokes the subprogram again, you can’t just send all the data from a database access loop.

So, in either case, to use RPC, either the server needs to keep track of where it left off or the data being sent back and forth between the client and server needs to include restart information.

A web based transaction will often include something similar to this. For example, we browse the “employees” file by name, starting with a user-supplied value (“SMITH”). A “page” of names is sent in the first reply, along with some restart values (last name sent and ISN of record). When the web user presses “next”, the subprogram does a new READ LOGICAL that includes the last name and starting ISN.

This “stateless” model is appropriate if there is user interaction between each “page” (as users can abandon a page, it would leave a “conversation” hanging until it timed out, tying up a server). If there is no user interaction, then the subprogram could use the CONTEXT data to track the restart point, but the restart logic would be about the same as for the stateless version. From my point of view, there is not much advantage to the conversational, stateful approach over the stateless approach, besides a modest simplification on the client side.

The one case where a conversation is helpful: if you are doing an series of RPC calls that update the database. When the client commits the conversation, Natural issues an “end transaction” to commit the updates to the database.

I’ve enclosed an example of a Java program calling a Natural program with a conversation. It uses the demo “Employees” file on the Natural side - although written in Natural for Windows, it should work in Natural 3 or above on the mainframe.

The EMPLISTN.txt is the subprogram to be called (EMPLISTP.txt is a driver program to test the subprogram on the mainframe Natural side). Open the emplistn.idl in the EntireX Workbench, adjust the properties for your environment (broker, server address, etc) and generate the Java client. Modify the source for “Emplist.java” to set your RPC properties as appropriate.

Douglas Kelly,
Principal Consultant
Software AG, Inc
Sacramento, California
RPC_Conv.zip (4.84 KB)

5


There is no 32k limit for RPC ! I remember a German customer doing RPC calls with up to 6 MB message length. To get rid of the 32k limitation you need to check the following:

  • Use TCP/IP as transport for communication from both client and server to the Broker. Only Entire Net-work and Adabas SVC have a 32k limit.
  • Check your Natural version. Newer versions support more then 32k. AFAIK this is possible with Natural 3.1.6 or higher (on the mainframe).
And then you don’t need to worry about conversational RPCs :wink:

Kind regards,
Rolf

6

Gentlemen,

Thanks for your replies. I wasn’t ignoring you. For some reason the “notify” feature did not email me this time (alerting me of a response). I will look at both of the suggestions offered and will reply soon in a short of period of time.

Regards.