× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



David,

REXX on the "i" has three command environments: command (for CL
commands), execsql (for SQL statements) and cpicomm (for SAA
environments). By default, REXX uses the "command" environment to
execute statements it doesn't understand. REXX also supports custom
command environments, but I have not needed to learn about them.

Regardless of the default command setting, you can explicitly specify
the environment used to process a statement by prefixing it with
"address _environment_".

When you specify a default environment, statements the REXX processor
doesn't understand are sent to that environment. If the default
environment is "command" or "*command", one simply writes in REXX:
"clrpfm file(myfile)"
...and REXX knows it should be sent to the i5/OS command processor.

If the default environment is *command and I need to run a SQL
statement, I can temporarily "override" the environment by specifying
the environment before the statement:
Address execsql "execsql set option naming=*sys;"

Many REXX programmers accept the default used when compiling the command
or starting the REXX procedure. Both CRTCMD and STRREXPRC default to the
*COMMAND environment, so the programmer doesn't do anything special to
execute i5/OS commands.

However, if the first interpretable line in the program is address
_environment_, then this overrides the CRTCMD or STRREXPRC default. This
environment is used for the rest of the program, or whenever another
address _environment_ is encountered.

I like to explicitly specify the default environment in my REXX
procedures. If I need to call additional REXX procedures from here, I do
not worry about having the "correct" environment set - it is set in the
procedure.

I explicitly specified the environments as not to assume which one was
in effect. You certainly do not need to do this in your code, except
when you have one environment in effect and need to use another.

The execsql environment is special - search the archives for "execsql"
for a conversation between me and Simon Coulter. Even if the default
environment is set to execsql, you must STILL specify "execsql" as part
of any SQL statements you run. It's a silly and non-conforming
requirement, but that's the way it is.
Example:
Address execsql /* Set default environment */
"set option commit=*none;" /* Does not work. */
"execsql set option commit=*none;" /* Works. */
Address execsql "execsql set option naming=*sys;" /* Works. */

The IBM example you mentioned assumes a default environment of *execsql.
As above, when you need to temporarily override the default environment,
you explicitly specify the environment prior to the command. A better
alternative is to "swap" environments. In conversing with Simon, I
learned that REXX remembers two environments during script execution,
and allows you to swap between them:

/* Set default environment. */
Address command
"clrpfm file(myfile)"
/* Set environment, now command is alternate */
Address execsql
"execsql set option naming=*sys;"
"execsql insert into myfile (myfield) values('Yes');"
/* When used by itself, address swaps to the previous environment. */
/* Now *command is active again. */
Address
"runqry *n myfile"

REXX allows "exit codes" to be sent to the calling program. In your
example, exit rc will send the value of rc back to the caller. What
called the REXX procedure determines how the exit code is returned. If
the caller was another REXX procedure, the exit code is stored in the
RESULT special variable, or the value of a function. If called on the
command line, the return code is sent in message CPF7CFF.

If you haven't already, download the REXX Reference and the REXX
Programmer's Guide for more information. REXX is a powerful tool worth
investigating.

Loyd Goodbar
Business Systems
BorgWarner Shared Services
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Tuesday, April 22, 2008 3:22 AM
To: Midrange Systems Technical Discussion
Subject: RE: Examples of REXX I'm thinking about putting on some site

I am truly grateful for all the input to this subject.

But it's making me feel as thick as 2 short planks.

Lloyd wrote :
Address execsql "execsql set option commit=*none;"
if rc <> '0' then do
msgid = "SQL"right(strip(abs(sqlcode)),4,'0')
address command "sndpgmmsg msgid(&msgid) msgf(qsqlmsg)
msgdta(&sqlerrmc)"
End

But in the example below I read
exit rc

How dos that work ?

I have the IBM guides but not finding them very easy to follow.

This IBM link I find very frustrating :
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/r
zajp/rzajpssrexx.htm

Why does it use that messy <ADDRESS '*COMMAND'> every time ? ( in
Lloyd's example it's <address command> )
Joe didn't use this in his example, only for SQL commands.
Does RC have to be set to 0?
What the **** is 11EXECSQL, 12EXECSQL, etc?




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.