I find it much easier to use subcommand enviromments
http://users.tpg.com.au/crayford/rexxre.txt.
I setup the CEEPIPI environment in RTKSUBCM, allocate all the memory I
need for the command processor routines (saveareas etc) and store a
control block in the SUBCOMTB_TOKEN field.
When the command handler gets called I grab the control block from R1
(no need to GETMAIN storage areas) and forward the call to the LE
routines via PIPI. Those cost of parsing the command
string is significantly less than the overhead of GETMAIN and
name/token services calls.
On 11/07/2013 1:38 AM, John McKown wrote:
I think you were referring to the CEEPIPI functions named "call_sub" and
"call_sub_addr". "call_sub" is the CEEPIPI subfunction which calls a LE
enabled routine by symbolic name (like LINK does). Where "call_sub_addr" is
the CEEPIPI subfunction which calls an LE enabled routine by its load point
address (like SYNC does).
In either case, REXX itself will "somehow" (LINKPGM or otherwise) give
control over to my routine which will set up things, then invoke the PCRE
appropriate subroutine(s) as needed, and finally "somehow" pass back the
results (likely via REXX variables the way ISPF does) back to the REXX
program.
On Wed, Jul 10, 2013 at 12:00 PM, Sam Siegel <[email protected]> wrote:
On Wed, Jul 10, 2013 at 8:32 AM, Farley, Peter x23353 <
[email protected]> wrote:
Sam, what do you mean by "call sub addr" vs "call sub" from the Rexx
point
of view? AFAIK there is no capability in z/OS Rexx to call a subroutine
by
address.
I'm clearly showing off my deep and extensive REXX knowledge. ;-)
John, I strongly suspect that the efficiency of a CEEPIPI setup will more
than pay you back for the complexity of the setup for all but a very few
calls to the PCRE subroutines, i.e. in all but the very simplest of use
cases.
I would set up the CEEPIPI environment and store the returned token in a
suitably "obscure" named Rexx variable (like ___C_E_E_P_I_P_I___) and
retrieve that variable on each call to the PCRE functions. Use the token
value if it is there and set up CEEPIPI if it is not yet there.
Or you could require a Rexx variable to be passed as the first argument
to
all functions in which you store the CEEPIPI token value, putting the
burden on the programmer to keep it intact and pass you the right value
every time.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Sam Siegel
Sent: Wednesday, July 10, 2013 10:00 AM
To: [email protected]
Subject: Re: REXX and CEEPIPI questions.
On Wed, Jul 10, 2013 at 6:30 AM, John McKown
<[email protected]>wrote:
I am trying to look at how to use the PCRE from Ze'ev Atlas in a REXX
program in a "REXXish" way. PCRE is written in C and is basically
implemented as a bunch of subroutines. Being in C means this requires
LE. I
could just write my code to be LE compliant and then invoke it from
REXX
via a LINKPGM, or similar, method. I could pass the results back by
having
my routine use IRXEXCOM to create specific REXX variables which could
then
be used in the rest of the script. Yes, there are better ways, but I'm
just
thinking out loud right now.
I was also looking at using CEEPIPI somehow to establish an LE
environment
which would last across calls to my PCRE functions. I have been reading
the
books. But I can't find the answer to my first question. Which is: "If
I
call an HLASM routine which: (1) is not LE compliant; (2) uses CEEPIPI
function "init_sub" to set up LE environment for calling subroutines;
(3)
returns to REXX. Will the LE environment stay around? If it does, could
it
cause problems with REXX or even TSO itself? Could it cause problems if
the
user were to invoke an LE enabled main routine (written in C, COBOL,
...)
via a TSO CALL or ADDRESS LINK type invocation? If the user does invoke
an
LE program, will that affect the CEEPIPI set up environment (as in
terminate it)? Instead of "init_sub", should I use "init_sub_dp"? It
seems
to have some advantages, but is more restrictive. Mainly it seems to
be a
way to avoid the possible "problems" of leaving an LE environment
active.
CEEPIPI init sub creates an LE environment and returns a token to the
same.
The token is passed to the ceepipi call sub function along with other
parms. The LE environment represented by the token is usable on that tcb
until destroyed by using ceepipi term function.
init sub dp allows you to create multiple LE independent environments
under
the same tcb. verify your need before using this.
best performance in calling the subroutine is to use is to use call sub
addr. This called the subroutine by address instead of name. if you are
going rexx->pipi->subroutine in high volume, call sub addr is worthwhile.
If you are going rexx->pipi->subroutine just once or twice then call sub
is
fine.
init sub dp has other characteristics that are useful in a multi-tcb
environment.
Also, I am not totally sold on having an LE environment "hang around".
I
do
know that it saves on start up and shut down time. But I don't know if
it
is worth the effort because I don't really have a handle on how many
PCRE
invocations are going to be done in a single execution of a REXX
program.
--
This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and
confidential.
If the reader of the message is not the intended recipient or an
authorized
representative of the intended recipient, you are hereby notified that
any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
e-mail and delete the message and any attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
