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.