I am new to Rexx/Regina on Linux/Windows/... The problem I want to solve is having an interface via Rexx from one application A to another application B. For example A could be a text editor with freely definable menu items that call a shell script (or a Rexx script). B is the application I am writing and would be running in the background waiting for requests from a Rexx script (e.g. B is a database server). B provides new commands to the Rexx script (e.g. for retrieving values of a record). How can I extend B such that it provides functions for such a Rexx script? I have read most of the API documentation on how to interface Rexx to other applications (Chapter 8) but I am still missing the point. I can start a Rexx interpreter within B but I don't see how this could be interacting with the rexx script started by A. Somehow the rexx script started by A would have to connect to B (via the ADRESS command?) and commands from Rexx would have to be revceived by B, executed, and results send back to Rexx. Is this possible?
If you are familiar with ARexx (a variant of Rexx that is common on AmigaOS) then you probably understand where I am aiming at.
I can see there are possibilities with the regutil functions.
The server side can wait on an event semaphore and be posted by the client part.
The client would put data on an external queue, post the server and optionally wait (using another event semaphore) for a result.
The server would wake up, read the external queue and process. When finished it could put a response on a separate external queue, and then post the client.
If the requirement has the client and server on separate machines, then you might prefer to use the rxsock functions - this then uses tcpip which would be much more flexible.
thanks for your quick reply. I am happy to see that my question was not complete non-sense and people actually understand the problem. Well, I just started reading chapter 7 about the stack and these queues. I guess this is part of the mechanism you are talking about?
Well, I would prefer a solution that makes more use of Rexx' abilities to extend the language using the sub command handler or external handler facilities as described in Chapter 8. For example, let's look at an example Rexx script that I want the client to use:
The 'ADDRESS MUIbase' command would 'somehow' connect to the database server which defines the environment 'MUIbase' and defines the commands 'CONNECT' and 'EVAL' in this environment. The Rexx script can then make use of these new commands.
I was hoping that Rexx somehow can make such connections when using the 'ADDRESS' clause (in ARexx it actually works like this). What actually happens when issuing the ADDRESS clause?
While thinking about this problem a bit, how about the following idea:
The data base server allows a tcp/ip communication using some protocol. I write a loadable library that can be loaded into a Rexx script (or use the CGI interface) which defines the MUIbase environment and extends the interpreter with the new commands in this environment. The library connects to the data base server using the tcp/ip protocol and does all the sending/receiving of messages bewteen Rexx and the database using the tcp/ip protocol.
Would that make sense?
How are the existing Rexx interfaces to SQL databases implemented?
I think you could make this work. The environment named "MUIbase" would have to be established before the REXX script is run, perhaps by the special editor you were referring to. The if the editor also established an environment for itself named "SGedit", then the REXX script could choose which environment to send commands to.
Be careful about how you specify the subcommands issued to an environment, though. You had given the example of:
However, if CONNECT is also a variable symbol in the REXX program, you will get a substitution, rather than the CONNECT subcommand. The same is true for EVAL. A better way to code this would be:
This assumes that "mydatabase" doesn't need to be enclosed in quotes (it wouldn't have been when the original code was executed. This also assumes that "Person.Name" is also a literal string. If you had intended it as a variable, then:
would be correct. The former would send the string "EVAL Person.Name" to MUIbase for evaluation, whereas the latter would send "EVAL " concatenated with the *value* of the REXX variable Person.Name
The environment logic you code would have to be able to process two subcommands: CONNECT and EVAL. It would have to be able to parse the subcommand, and execute appropriate logic (you proposed to use TCP/IP, but CORBA or REXEC or anything else you like would work).
I hope that helps.
I'm not sure if creating an environment is necessary in this case - a new loadable function module may be sufficient.
I've only create a rexx environment under MVS (IBM mainframe) and it was quite easy, but there is a fair amount of work involved. If you want to call out to rexx from an editor, then this may be the way to go - THE (from Mark Hessling) might be a good starting point.
I have created a new program to call rexx (as a service under Windows) which is fairly easy - although not really a full environment as such. Look at Patrick J McPhee's wegina for a useful example. I can provide mine if it helps.
Making a simple loadable function dll is the easiest way I would think. I have created a libdes interface that way, and I've made changes to rxdial, rxsock and regutil.
So a function package might include
dbhandle = MUIbaseInit(target)
connhandle = MUIbsaeConnect(dbhandle)
call EVAL "Person.Name ", "OUTSTEM."
then outstem.0 would get the count, and outstem.1 the first line etc.
All the hard work would be in the loadable package - this would be c code and be able to use standard calls or tcpip.
I've not really looked at the sql package.
I have used the rxsock package a fair bit - this is pretty good if you can use plain sockets connections.
Thanks for all the comments and hints, also about the syntax of clausses. I was a bit sloppy with the syntax of function calls.
It seems that one way to do what I am looking for is to write an executable simular to rexx or regina that registers environment and sub commands to rexx and then starts the interpreter for executing commands from a file or a command line. This new executable could then be started from an external program (e.g. by invocation of a menu item in an editor) and execute rexx scripts that indlude the new sub commands for talking to the data base server via tcp/ip (or named pipes, rexec, ...).
It doesn't look very difficult to do all this. I am just wondering if this is the way programs that support Rexx are supposed to communicate with each other? I was thinking of Rexx as being the glue between applications for exchanging data. I was hoping that environments (ADDRESS clause) would make automatic connections between programs, i.e. environments would be global. For example when calling
rexx would try to find a system global resource that is associated with the MUIbase environment and sub commands would be send in some format to the application that registered the environment. The application would have to react on received rexx messages (sub commands), handle them and reply to the caller.
But it seems the concept of Rexx does not go that far and environments are always local to the calling program. Commincation is only possible by queues or tcp/ip.
But then Rexx becomes just another scripting language and I wonder what are the benefits from using it instead of python, perl or simply sh?
I regret the last comment I made about Rexx. It is defeniately an improvement over other languages like python or perl since Rexx offers subcommand handlers and such for enriching the language with own constructs. I think that's much harder to do when using other languages than Rexx.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.