Hi Guys,
I was wondering if we can invoke a word processor application from within a mainframe NATURAL program through an RPC call in order to enter a narrative text, spell check and return the result back to the calling program via RPC interface (PDA) for further processing such as storing in ADABAS.
FYI, I have already tried invoking a windows application from a mainframe Natural program using Entire Connection (download command etc).
Thanks
Bijan
In order to have mainframe Natural invoke a PC program on the same machine as the Natural terminal emulation session is running, you need to have some way to identify which machine that is since the typical Terminal Emulation session address is dynamic and the mainframe session does not know which PC called it.
In this case, the Natural mainframe program is the RPC client and needs to call an RPC Server. However, for that RPC Server to invoke Word on the user’s PC would require an RPC Server to be running on every PC that could invoke Word, and each PC would require a unique RPC Server name that can be derived in the mainframe session. If there are more than a few users that would be doing this, it quickly becomes a headache: you have to define each Server Name to the Broker Attribute file and servers use more resources than clients on the Broker - lots of servers causes lots of resource usage.
An approach I used once before was to run a daemon client program that registered with an ACI server on the mainframe, passing in the client identification (their mainframe user id, obtained from a .ini file - you could also use a table to map network id to mainframe id). When the mainframe needed to invoke Word, the mainframe called another service on the same ACI server, passing a small set of data to identify the document being requested. The mainframe ACI server then matched the mainframe client request with the PC client requests outstanding and replied to the client request, passing on the information received. This triggered the PC client program to initiate Word, again passing on the information from the mainframe client. Word macros then initiated ACI calls (I’d use RPC now for this part) to a mainframe RPC Server, using the passed information to obtain template and data from Adabas and to store the composed document back in Adabas once completed.
Not exactly, we have done this for numerous customers over here, a RPC server, as you say, sitting on every PC, with certain functions like opening Word, writing or reading a PC file etc. etc.
One can, however, define the servers generically to EntireX Broker, you don’t have to define every single one (but of course you can, if you want to, for security reasons, for example).
(ok…I know I didn’t hit submit twice…the forum software has a problem causing duplicate entries!)
tricky part for generically defining servers is that you can only do it at a whole level - the entire piece of the trinity (class/server/serice), but not a portion of any - so for RPC, which is RPC/servername/CALLNAT, you can only define RPC//CALLNAT, not RPC/WORD/CALLNAT: it is essentially an all or nothing proposition for RPC servers.
If EntireX Security is involved, it gets somewhat more complex also.
In some testing with earlier versions of EntireX (about v6, I think), I did find that servers consumed more resources than clients. I’ll have to look into the details if I can find them - I recall it being a memory multiplier: you need to tailor the servers to essentially only deal with one or two clients, otherwise the memory allocation gets large. (The application I worked with was dealing with hundreds to thousands of users and the difference in using clients instead of servers was considerable).
Gentlemen,
Thanks a lot for your feedback. Great experience.
Having client/server app dev experience using EntireX ACI, I think Doug’s proposed approach is technically feasible but operationally unsustainable for various reasons including the mapping of IDs and ACI programming challenges. Having said this, I would like to try this approach but not sure if I know how to make it happen as I see some challenges ahead in gluing discrete conversations initiated by daemon and the M/F client together.
Back to my question re using RPC, actually, I was thinking of the famous SAG module mentioned in SYSRPC doco called CALC - that is apparently a non-Natural code (java else) that could be called from a mainframe Natural program to do some math and return the results.
I thought what if the CALC was a service in charge of throwing a window on the callers
Calc is a sample program that is called by an RPC server. There is no relationship between “calc” and a specific user’s machine where you can start a desktop application.
The hard part is the “throw a window on the caller’s desktop directly” - you need something running on the user’s machine and you need to know how to address that something. Wolfgang’s approach was to put an RPC server on each machine; mine was to put a client daemon on each. Knowing the network user id alone is not sufficient: there has to be something to connect the mainframe session (which knows nothing about the PC it is invoked from) with the same machine as the user is running on.