Menu
▾
▴
#1055 REXX queues not accessible across different users
Hi,
I've been a long time user of ooREXX 3.1 on Windows x86 platforms. I'm creating some scripts on Windows 2008 x64 with ooREXX 4.1.0 and have hit a problem. I'm not sure if this is a bug, a possible security feature or something to do with Windows 2008.
It appears that the REXX queues cannot be accessed across different userids.
Example, I can have a REXX script 'listening' on a queue started as one user account:
call rxqueue 'create','newqueue'
call rxqueue 'set','newqueue'
data=linein("queue:")
say data
WIth a different Windows user account, I want to send data to that queue from the command line using the external RXQUEUE command:
echo test|rxqueue newqueue /fifo
I get error:
REX999010: The queue newqueue does not exist.
If I try this with the same user account that created the queue in the first place, this works correctly.
This isn't unique to the RXQUEUE command. If I run the following as user2, this also fails:
call rxqueue 'set','newqueue'
Error 48.1: Failure in system service: SYSTEM QUEUE
RXAPI is correctly running as a service prior to create any queues.
Any ideas?
Discussion
Anonymous
On doing some more reading, looking at the source code and browsing old oorexx-devel archives, this appears to be a case of working as designed. It appears that sometime around ooREXX jumping from 3.x -> 4.x, the external data queues are now created on a per userid basis. This seems to conflict with the REXX Reference guide which states:
'Named queues are available across the entire system'
I can also understand why it might be considered a good thing, though not in my case!
Two questions:
Appreciate any suggestions anyone may have.
Thanks.
Richard
Does windows support named pipes?
Thanks for the suggestion. There's a function called 'SysWaitNamedPipe' but little information on how to use it. It also seems that it will wait on a pipe and report the return code but I'm not sure how it would be used (by another REXX script) to actually send some data.
This is now a "wild suggestion", which you may safely ignore, but maybe it serves a little bit.
At <wi.wu.ac.at rgf="" tmp="" dbus="" onthefly=""/> you will find a pdf-file "201112-DBus4ooRexx-article.pdf" describing an external ooRexx function library for D-Bus which is also available there for Linux, MacOSX and Windows.
D-Bus is an infrastructure that allows programs in different processes to interact with each other and exchange data. Just skim through the article to see what this is about and whether it might help solve your problem.
If it does then you need to know that D-Bus is usually available on Linux, but ports for Windows and MacOSX exist. You would have to locate the D-Bus for Windows (not sure whether this one works, you could try: http://code.google.com/p/dbus-windows-installer/downloads/list, otherwise you need to locate a newer version.
Usually, after installing, you can test the D-Bus installation with supplied command-line tools like dbus-send.exe and the like. If it works then you enter ooRexx and use the external ooRexx function library to use D-Bus for your own purposes.
At least it may be interesting for you to explore that option. (And if you create Rexx programs, then they should run unchanged on Linux and MacOSX in addition, exchangng all sort of data.)
One word of warning though: the ooRexx function library seems to be stable, but is still regarded to be at beta-status.
I did some checking in Wikipedia and Windows has supported something like named pipes since Win95. The problem is that this is only suitable for synchronous communications because there is no queueing.
Rony, that sounds like a pretty good suggestion to me.
Thanks for the suggestion. I've skimmed through the D-Bus document and I'm not scared off yet - maybe an in-depth read will do that! :-)
On the named pipe front, I've seen some examples for OS/2 where you simply open a pipe as if it was a normal stream file and apparently write to it. That seems pretty simple on the face of it though I'm sure there's more to it than that. What's the impact with the synchronous comms; does that mean that your 'sender' will only be able to write to the pipe if the 'listener' is actually there and listening, and it won't queue up waiting? That likely would be something to consider as in my current scenario, the sender can just queue messages on the stack and the listener can pull them at leisure.
Named Pipes.
Yes that is what I meant by synchronous. Asynchronous message delivery is what you are doing when you queue a bunch do data a queue, and then a process reads that data at a later time.
synchronous = telephone, chat
asynchronous = voicemail, email.
Then there are persistent queues and transient queues. Transient queues will lose all the data across system restarts, persistent queues won't.
To be honest I don't remember what happens if you try to write to a named pipe, which hasn't been opened for reading. You either get a "NOT READY" which would be good, or you block, which would be bad. This is on *NIX, windows would probably be different.
Depending on the volume of data to be passed between processes and how fast that needs to happen you could do worse than merely have a shared folder and write files containing data to it, eg under one file name (or using one file extension). Close & rename it (to another extension perhaps) to have it seen & read by the other process.
I think under Windows you can use WMI to 'watch' a folder and tell you when something's changed in it, or a certain type of file has arrived there.
Such a mechansim has the advantage of persistence and simplicity. Anyone looking at the folder can (assuming they have the authority to do so) see its current contents, whereas debugging contents of queues must be much harder.
That's a good suggestion and simple to follow. The actual data volumes aren't high (just messages to be logged or parameters for another script to do something with).
The beauty of push/pulling with the external data queue is that it's simple and instant. Although there are some good suggestions here, my ideal solution would be something that's a simple as one script pushing to a queue and the other pulling when it's ready, having a persistent queue which survives reboots (or RXAPI restarts anyway) and probably some security feature to designate who/what can use the queues - I'm guessing it's the lack of this that meant that although the external data queue worked across different users previously, it was seen as too much of a security risk which I can appreciate.
Anyway... as this ideal solution probably doesn't currently exist, I'll be looking at all of the suggestions and see which one works best.
Many thanks for all your suggestions; by all means keep 'em coming!
I've thought of a variation on the writing files to a directory approach. This is to use semaphores which I've seen described previously but never really understood what they were for. The 'sending' script will write to a file and post a semaphore that the 'listener' is waiting on. I've tested using the example from http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.rexx/2008-12/msg00013.html and can confirm that semaphores can be posted between different userids.
This will let me have a persistent asynchronous queue and the listener doesn't have to check that data it waiting for it; it simply waits on the semaphore being 'posted' (or whatever the correct terminology is!).
Right, time to get coding... thanks for your help guys.
Just for info, the WMI approach is demonstrated in file File events.zip mentioned on this website:
http://pragmaticlee.safedataisp.net/
Lots of otehr interesting examples, though note there's a comment saying they might not work on more recent examples of Windows. However bear in mind that armed with an older example one can usually find more recent doc of WMI classes etc on MSDN.
Thanks Jeremy. I've had a look at the example you've indicated. I can think of some instance where I might use that but for the current one, I need more of an instant approach where doing something in one exec immediately causes another one do something else. The 'receiving' exec can't constantly be polling for work either; it needs to sit there waiting using up no resources.
Nice website and there are lots of interesting examples on it.
Having had a better look at WMI, I've adapted my scripts to use this. Contrary to my last reply, it is more or less event driven and works well in my scenario.
I'll close this bug report as the original reported issue is not in fact a bug.