REXX pgm calling another REXX pgm not on the PATH - REXX

John Small wrote:
> The calling program knows the location of the called program but this
> location is not on the PATH.
>
> Is this possible? If yes, how?

Huh? Is the first sentence, which is a statement, supposed to be a question?

> I have tried the following:
> While the calling program is running it adds the directory of called
> program to the PATH using the VALUE function. This seems to allow
> successful calls to the called program but it also seems to screw up
> the PATH in a way that causes failure in any external programs run
> though the command processor. For example:
> 'MODE 80,25'
> fails with:
> SYS1041: The name mode is not recognized as an
> internal or external command, operable program or batch file.
>
> If I don't modify the PATH "on the fly", then the external programs
> run without problems.

This sounds as though you have *replaced* the PATH, not appended to it.
Did you get the existing value of PATH, append your bit to it, then set
the whole thing into PATH?

Graham.

Graham.

In comp.lang.rexx Graham wrote:

> John Small wrote:
>> The calling program knows the location of the called program
>> but this location is not on the PATH.
>>
>> Is this possible? If yes, how?

OP, What REXX, what OS?

You are trying to use a Fully Qualified Path to the called
routine? (quoted FQP?)

> Huh? Is the first sentence, which is a statement, supposed to be
> a question?
>
>> I have tried the following:
>> While the calling program is running it adds the directory of
>> called
>> program to the PATH using the VALUE function. This seems to
>> allow successful calls to the called program but it also seems
>> to screw up the PATH in a way that causes failure in any
>> external programs run though the command processor. For
>> example:
>> 'MODE 80,25'
>> fails with:
>> SYS1041: The name mode is not recognized as an
>> internal or external command, operable program or batch file.
>>
>> If I don't modify the PATH "on the fly", then the external
>> programs run without problems.
>
> This sounds as though you have *replaced* the PATH, not appended
> to it. Did you get the existing value of PATH, append your bit
> to it, then set the whole thing into PATH?

Agree.

On Sun, 14 May 2006 03:09:10 UTC, Graham
<norrisg@spam_free.linkline.com> wrote:

> John Small wrote:
> > The calling program knows the location of the called program but this
> > location is not on the PATH.
> >
> > Is this possible? If yes, how?
>
> Huh? Is the first sentence, which is a statement, supposed to be a question?

The subject was intedned as the primary question. I should hav emade
this clear.

>
> > I have tried the following:
> > While the calling program is running it adds the directory of called
> > program to the PATH using the VALUE function. This seems to allow
> > successful calls to the called program but it also seems to screw up
> > the PATH in a way that causes failure in any external programs run
> > though the command processor. For example:
> > 'MODE 80,25'
> > fails with:
> > SYS1041: The name mode is not recognized as an
> > internal or external command, operable program or batch file.
> >
> > If I don't modify the PATH "on the fly", then the external programs
> > run without problems.
>
> This sounds as though you have *replaced* the PATH, not appended to it.
> Did you get the existing value of PATH, append your bit to it, then set
> the whole thing into PATH?

I thought so, too. Do I added code to test this. The code looked
like:
trace 'i'
newpath = value('PATH',,env)
newpath = subroutine_dir || ';' || newpath
call value 'PATH', newpath, env
newpath = value('PATH',,env') /* Debug: See if it is set
correctly */
'PATH' /* Debug: See if it
is set correctly */

The trace showed that everything (env, subroutine_dir, return values
from both calls to value()) looked correct up to the last statement.
The output of the 'PATH' command was 'PATH=(null)'

How the immediately preceding call to VALUE could show a fairly long
and presumably correct PATH and then 'PATH' show nothing I don't
understand. And how could either setting of PATH cause 'MODE ...' to
fail but a call to the REXX subroutine (which was not previously on
the PATH) succeed, baffles me too.

In any event the whole mystery has become less urgent since I
originally posted. I opened a new window and the very same code
worked as it should. Somehow something about the other window was
corrupted and caused such bizarre behavior.

So the question has changed from "How do you do call another REXX pgm
not on the PATH (since the code which should work doesn't seem to
work)?" to "How could the state/environment of a window get so
corrupted to cause such strange misbehavior?"

--

John Small

(remove the z's for email address)

On Sun, 14 May 2006 15:09:10 UTC, Mark V <notvalid@invalid.nul> wrote:

> In comp.lang.rexx Graham wrote:
>
> > John Small wrote:
> >> The calling program knows the location of the called program
> >> but this location is not on the PATH.
> >>
> >> Is this possible? If yes, how?
>
> OP, What REXX, what OS?

OBJREXX 6.00 18 May 1999 on eCS 1.13

> You are trying to use a Fully Qualified Path to the called
> routine? (quoted FQP?)

I am adding the fully qualified directory name to the PATH using the
VALUE function.

> > This sounds as though you have *replaced* the PATH, not appended
> > to it. Did you get the existing value of PATH, append your bit
> > to it, then set the whole thing into PATH?
>
> Agree.

See my reply to Graham for an update on this issue.

--

John Small

(remove the z's for email address)

In article <4rkzjBzzMnpe-pn2-BrRE5P2IdIRI@09-104.158.popsite.net>,
zjsmallz@toast.net says...

>
> So the question has changed from "How do you do call another REXX pgm
> not on the PATH (since the code which should work doesn't seem to
> work)?" to "How could the state/environment of a window get so
> corrupted to cause such strange misbehavior?"
>
>

One risk you take in the supplied code is using the variable env in your
code. I would use the string 'ENVIRONMENT'. Using the variable env could
lead to unexpected results if this variable is set 'by accident'.

On Mon, 15 May 2006 13:16:39 UTC, Gert van der Kooij
<nomail@nl.invalid> wrote:


> One risk you take in the supplied code is using the variable env in your
> code. I would use the string 'ENVIRONMENT'. Using the variable env could
> lead to unexpected results if this variable is set 'by accident'.

I decided to use a variable as a probably feeble attempt to allow my
program to run on multiple platforms. I set the variable based on
what is returned by 'parse source'.

Which raises the question: If one wants to query the current
environment, will 'ENVIRONMENT' work on all platforms as a third
parameter to the VALUE function? If not, what other 3rd parameters to
VALUE() are used on which platforms?

--

John Small

(remove the z's for email address)

in 34259 20060515 235004 "John Small" <zjsmallz@toast.net> wrote:

>Which raises the question: If one wants to query the current
>environment, will 'ENVIRONMENT' work on all platforms as a third
>parameter to the VALUE function?

Dunno about all platforms, but it works ok on OS/2, Linux and Windoze.