Under OS/2 it was possible - and extremely useful and handy - in a Rexx program/
'procedure' to 'call in' the results / outputs of another program - through lines
of code somewhat like this:
newQ = 'FCTQ'
'@CALL E:\dirm1\fctvals' 2 45 '|RXQUEUE/fifo' newQ
Then the output from fctvals (in casu for arguments 2 45) would be stored in the
(global/external) queue named FCTQ (provided already created).
And you could then utilize its contents the usual way:
...
origQ = RxQueue('Set', newQ)
qlines = Queued()
DO ii = 1 TO qlines
Parse Pull lin
(use lin to somthing)
END
...
...
B U T : In ooRexx 3.1.1 (under Windows NT4.0) RXQUEUE seems unable to 'take up'
the results of calling the output-results of procedure/program 'fctvals.REX'
It does take up results from 'operating system commands' (like DIR and VER), and
also from (some?) .exe (C++)programs. - But that is, I think, not good enough.
- Having written well over hundred Rexx 'procedures' within OS/2 applying this
piping facility, it would be very tedious to re-write a whole bunch of these.
Any solution in sight / in preparation ????
Anyone notifying the ooRexx developers of this problem (- seemingly) ?
Bjarni.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for responding, William (mrumunhum).
File extension, however, i s included (as '.REX'). As you see. Or Isn't that
what you mean ?
Yes, the extension seems to matter in some cases, where it does not so in OS/2(Warp). So - usually I just include it with and within ooRexx programs.
I suspect, that there is something (wrong(?)) with the piping ('|') in ooRexx.
For example: It tends to refuse to work in the command ('MS DOS'-) window.
As does putting redirection ('>') after ooRexx programs (command).
While that is not a problem in NT with non-ooRexx programs.
Didn't the ooRexx reference promiss, that the non-object oriented part of ooRexx
should work in the usual way as Standard-Rexx?! And that 'standard', what else
could that be than just Rexx in its 'home land', OS/2 (- as you mention) ?
So - I am still hoping for a solution - perhaps someone knows how to contact
or question the ooRexx developer team ???
Bjarni.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ooRexx does not implement piping, that's handled by the OS command shell. It's difficult to assist you without having more information about what's going wrong. What's the exact instruction you are trying to execute when this fails? Just saying that something "doesn't work" isn't very useful. What is the exact failure you receive when you try to do this (and also show the exact instruction). Command piping with RXQUEUE most certainly does work, so it's likely you are doing something else wrong.
Rick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Under OS/2 it was possible - and extremely useful and handy - in a Rexx program/
'procedure' to 'call in' the results / outputs of another program - through lines
of code somewhat like this:
newQ = 'FCTQ'
'@CALL E:\dirm1\fctvals' 2 45 '|RXQUEUE/fifo' newQ
Then the output from fctvals (in casu for arguments 2 45) would be stored in the
(global/external) queue named FCTQ (provided already created).
And you could then utilize its contents the usual way:
...
origQ = RxQueue('Set', newQ)
qlines = Queued()
DO ii = 1 TO qlines
Parse Pull lin
(use lin to somthing)
END
...
...
B U T : In ooRexx 3.1.1 (under Windows NT4.0) RXQUEUE seems unable to 'take up'
the results of calling the output-results of procedure/program 'fctvals.REX'
It does take up results from 'operating system commands' (like DIR and VER), and
also from (some?) .exe (C++)programs. - But that is, I think, not good enough.
- Having written well over hundred Rexx 'procedures' within OS/2 applying this
piping facility, it would be very tedious to re-write a whole bunch of these.
Any solution in sight / in preparation ????
Anyone notifying the ooRexx developers of this problem (- seemingly) ?
Bjarni.
Thanks for responding, William (mrumunhum).
File extension, however, i s included (as '.REX'). As you see. Or Isn't that
what you mean ?
Yes, the extension seems to matter in some cases, where it does not so in OS/2(Warp). So - usually I just include it with and within ooRexx programs.
I suspect, that there is something (wrong(?)) with the piping ('|') in ooRexx.
For example: It tends to refuse to work in the command ('MS DOS'-) window.
As does putting redirection ('>') after ooRexx programs (command).
While that is not a problem in NT with non-ooRexx programs.
Didn't the ooRexx reference promiss, that the non-object oriented part of ooRexx
should work in the usual way as Standard-Rexx?! And that 'standard', what else
could that be than just Rexx in its 'home land', OS/2 (- as you mention) ?
So - I am still hoping for a solution - perhaps someone knows how to contact
or question the ooRexx developer team ???
Bjarni.
ooRexx does not implement piping, that's handled by the OS command shell. It's difficult to assist you without having more information about what's going wrong. What's the exact instruction you are trying to execute when this fails? Just saying that something "doesn't work" isn't very useful. What is the exact failure you receive when you try to do this (and also show the exact instruction). Command piping with RXQUEUE most certainly does work, so it's likely you are doing something else wrong.
Rick
It's been a while since I used Rexx in NT but I think you need to add the file extention to the call. Rexx is native in OS/2 but not NT.
'@CALL E:\dirm1\fctvals.rex' 2 45 '|RXQUEUE/fifo' newQ
Just a thought.