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.
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
