Posted: Thu Mar 19, 2009 12:05 pm Post subject: IRXEXEC and ispexec
I am using Endevor in FG. I have a BAL Endevor exit program that links to IRXEXEC. I use a simple rexx program to decide whether an Endevor package can be approved. However, I am trying to use the rexx program for another purpose: to display an ISPF panel so the end user can enter data. The ISPF panel variables are not being passed back to the IRXEXEC environment, so I can't capture the data. Also, the second pass through the same exit logic gets this response from IRXEXEC:
Invalid or missing EXECBLK parameter passed to the exec load routine.
Joined: 03 Dec 2002 Posts: 114 Topics: 0 Location: Sydney, Australia
Posted: Wed Mar 25, 2009 4:16 pm Post subject:
What pool are you putting the variables into? I'd suggest using the profile pool, they would then be available to different sessions (it that's the correct term).
Have you tried using VGET or are you just expecting the variables to be present? try using VGET if you haven't been using it.
Note that it's been years since I've updated myself with the latest ISPF/Rexx info so there may well be better different ways, even diffferent variable pools.
An alternative could be to use Table services (this methodology has the advantage that tables are userid independent). Another way could be to write the data to a dataset and then read it.
With regard to EXECBLK, if memory serves me well (and it may not), this is built by the invoking program to pass parameters to Rexx. It may well be that the lack of ISF variables is the cause of this issue. _________________ Regards,
Mike.
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Wed Mar 25, 2009 7:58 pm Post subject:
IRXEXEC does not set up a valid ISPF environment. In fact, any switching between programs and Rexx environments or different task levels (attach) etc that ISPF is not involved in, such as a TSO CALL statement, invocation of IRXEXEC, an ATTACH, etc will cause the ISPF environment to be unavailable. Unless Endevor is called with ISPEXEC SELECT and it in turn calls your exec with ISPEXEC SELECT, ISPF services will not be available. _________________ New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.
The rather criptic remark in IBM manual TSO/E REXX Programming Services page 257 "There are cases where a REXX exec invoked using the programming routines IRXJCL and IRXEXEC does not have access to ISPF variables. For more information about ISPF variables, see z/OS ISPF Services Guide" The later manual wasn't too helpful.
What is not valid about the ISPF environment? My rexx invoked with a link to IRXEXEC successfully displays an ISPF panel. Endevor is invoked with an ISPEXEC SELECT. It appears that an ISPF environment is available, but the variables are not available to the IRXEXEC environment. I did try all 3 variable pools, and vget/vput's without success.
What is more troubling is the "2nd time thru" issue: to invoke the IRXEXEC environment in the BAL exit a second time, requires exiting from the Endevor session.
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Thu Mar 26, 2009 10:44 am Post subject:
The problem is most likely switching between a Rexx environment and a compiled program environment. When ISPF access variables, it does so in one of 2 ways. If it knows it is running under a command environment (Rexx in this case), then it allows Rexx to manage the variable storage and calls TSO facilities to get and put variables to the function pool. If it knows that it is running under a compiled program, then ISPF manages its own storage for variables. The problem occurs when a program running under ISPF does not tell ISPF that the variable access environment is switching. So, for example, when a BAL program is running and the environment is all good, ISPF manages its own storage. If the BAL program then starts IRXEXEC directly, and the Rexx program makes ISPF calls, ISPF still thinks that variables should come from its own managed storage, and Rexx variables are not used. There are quite a few permutations on this theme, but in this case, the BAL program should invoke the program via ISPEXEC SELECT CMD(...) instead of calling IRXJCL or IRXEXEC. The other main case is going the other way where a working Rexx program calls a compiled program using a TSO call statement or just as a TSO command. Again, ISPF has no way of knowing the variable access environment changed, and again, the right way to do it is SELECT PGM(...). One last area worth mentioning is so called compiled Rexx where the Rexx program is a load module. There is a keyword on SELECT, LANG(CREX) I think, that is used in that case. I seem to recall that recent versions of ISPF might not require that any more, but I haven't verified that. _________________ New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum