Tom,
I performed some more testing (see my response to Simon) based on
swapping the command and execsql environments. I see your documentation
references, but did not see Simon's in the programmer's guide or
reference. It does make sense based on active and alternate
environments.
As a shop convention, I explicitly state the REXX environment at the
beginning of the programs, to start in a known state.
Working on a new project with Rexx required me to mix command and SQL
environments, and I was experimenting with their interaction.
Loyd Goodbar
Senior programmer/analyst
BorgWarner
TS Water Valley
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tom Liotta
Sent: Wednesday, April 02, 2008 16:47
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Rexx address command versus execsql
lgoodbar wrote:
If I say "ADDRESS EXECSQL" at the top of a Rexx program, then I can
run
SQL statements fine. Prefixing i5/OS commands with ADDRESS COMMAND
works
well also.
However, if I use just ADDRESS COMMAND at the beginning of a program,
then ADDRESS EXECSQL statements return with RC(-10).
Interesting. I've not noticed this before, probably because I
couldn't think of any reason ever to put ADDRESS COMMAND as the
first ADDRESS statement. That sets the 'permanent' environment to
the environment that it's already set to. Except...
Then I thought in terms of multiple procs where COMMAND might not be
the current 'permanent' environment upon entry to some lower-level
procedure.
Hmmm...
In looking over the docs (REXX reference), I see:
"
With no arguments, commands are routed back to the environment that was
selected before the previous lasting change of environment was made, and
the current environment name is saved. After changing the environment,
repeated execution of ADDRESS alone, therefore, switches the command
destination between two environments alternately. A null string for the
environment name ("") is the same as the default environment COMMAND.
The two environment names are automatically saved across internal
and external subroutine and function calls. See the CALL
instruction (topic 3.3) for more details.
The address setting is the currently selected environment name. You
can retrieve the current address setting by using the
ADDRESS built-in function (see topic 4.3.3).
"
One thing that isn't clear to me is what happens when repeated
ADDRESS statements refer to the _same_ environment that is already
saved as the 'permanent' environment. I.e., what is the result of
saying ADDRESS COMMAND when COMMAND is already the environment? And
then what happens when a later ADDRESS EXECSQL is thrown in? And
what happens when the environment is reverted back to the previous?
I'm thinking that you might want to make use of the third paragraph.
Only specify ADDRESS COMMAND (or ADDRESS EXECSQL) when the ADDRESS
bif indicates that a change would make sense.
Maybe?
Tom Liotta
midrange.com
