IRX0812E Exec variables were being accessed while the exec was executing

IRX0812E Exec variables were being accessed while the exec was executing

Post by tim.nauman » Fri, 10 Mar 2006 00:40:33


Could someone give me a hint or point me into the direction of some doc
that will explain what this message is trying to tell me. I took the
xephon WAITREXX example and modified it to where I could pass 3 types
of wait times(Bintvl, Dintvl, and LT). I'm using CIB processing to
check for modify commands against the REXX running as a STC. In the
original REXX, there is a loop that runs until the STOP command is
recognized. I installed the WAITREXX process and run it and it runs
fine. When I try to run my ABRXCOMM, whether in a loop or as 2
consecutive commands, I always receive the following message on the
second function call:

IRX0812E Exec variables were being accessed while the exec was
executing

eg.
do until PopCommand = 'STOP'
say 'Time = 'TIME('N')
Command = ABRXCOMM(b,6000)
parse var Command . . PopCommand
say 'Time = 'TIME('N')
say '...'Command
end

say 'Time = 'TIME('N')
Command = ABRXCOMM(b,3000)
parse var Command . . PopCommand
say 'Time = 'TIME('N')
say '...'Command
Command = ABRXCOMM(b,3000)

Again, could someone tell me where my problem lies. Is it in the REXX
function processing, the CSCL/CIB processing, or is there some deep
hidden gotcha that I don't know about or haven't read in the REXX
function programming section. My function call works great for any
parameter I pass, but I can only do 1 function call.
 
 
 

IRX0812E Exec variables were being accessed while the exec was executing

Post by Mark Yudki » Sat, 11 Mar 2006 19:34:18

Unfortunately, you didn't give us much to go on, as you elided the actual
meat. It looks like you have a bug in ABRXCOMM - that it isn't cleaning up
properly after the call, so that the second call fails as the first call
hasn't released everything.

 
 
 

IRX0812E Exec variables were being accessed while the exec was executing

Post by tim.nauman » Sun, 12 Mar 2006 04:59:55

Mark,
Sorry I omitted the meat of the program, but I initially was
looking for a starting point, even if that meant someone could clarify
what the message really meant. Let's be totally honest now. I mentioned
that I used the Xephon WAITREXX example as the basis of my program.
What I really mean is that I:
- Gutted it, reformatted, etc.
- The original WAITREXX consisted of the WAITREXX program that
ATTACHED a WAITTCB program to accomplish the STIMER
interval processing.
- I moved all my STIMER activity to the one program (ABRXCOMM) and
changed STIMER to STIMERM processing.
- Make us of a STIMER exit to post the completion.
- Expanded the options to be able to specify Bintvl, Dintvl, or Local
Time.

I thought the ATTACH method may have had something to do with the
problem so I created a 2 program scenario similiar to the original
WAITREXX, using a modified ABRXCOMM which I named ABRXWAIT. This
program then ATTACHed a ABRXWTCB for STIMER processing. Same results
after all the work. But this in itself could verify what you are saying
in that there is a bug in the ABRXCOMM program.

I guess what I am really looking for is an explanation of what is
going on. Following is the results I normally see with the problem I am
having:

Time = 13:00:57
..OK Interval <=== NOTE - This is
what I get back from the function call ===>
Time = 13:01:00
IRX0812E Exec variables were being accessed while the exec was
executing.
23 +++ Command = ABRXWAIT('B',3000)
IRX0040I Error running CIBWAIT, line 23: Incorrect call to routine
READY
END

To me I have been able to call the function and get information
returned. Most of the doc was straight forward in terms of storing some
value and it's length in the EVALBLOCK. I'm able to say the time which
means I am in REXX once again. Then I take off for the next function
call and the problem occurs.
- Can you expand on your "cleanup" reference in terms of REXX?
besides storing the return information?
- Is there something I need to do to some REXX control blocks on
return?
- Are you thinking mainly standard linkage problems between the
function and REXX?
- Is there some doc that would better explain the message and
possibly give me some indications what would cause this sort of
problem?

I appreciate your response. You don't know how much searcing I'v
done trying to get some sor tof answer!

Thanks,
Tim
 
 
 

IRX0812E Exec variables were being accessed while the exec was executing

Post by Mark Yudki » Mon, 13 Mar 2006 19:39:56

I do not know the Xephon samle you started with, so that isn't of any
assistance. The obvious source of reference is the z/OS - REXX documentation
that explains how to code REXX external functions, subroutines and function
packages.

I presume you're accessing your variables via IRXEXCOM. The documentation
explains that a REXX exec must be "enabled for variable access". My thinking
is that you have a problem here. It's also possible your problem is related
to calls to IRXINIT or IRXTERM. The absence of any details on your code's
actual REXX interaction makes it pure guesswork on my part.
 
 
 

IRX0812E Exec variables were being accessed while the exec was executing

Post by tim.nauman » Tue, 14 Mar 2006 02:43:53

Thanks for your time and suggestions. Based on your comments that
something wasn't getting set correctly on return, I started looking at
incoming registers and outgoing. Did you know what kind of problems you
can get into whe you do more than 1
L R13,4(R13) RETURN LINKAGE
when trying to return to an original program. That second one kind of
sets an incorrect environment. Sorry to bother but you suggestions did
really point me into some direction. Now that I see my errors and feel
better about processing external functions and think they are as fairly
simple as I thought.
Thanks again....
Tim
 
 
 

IRX0812E Exec variables were being accessed while the exec was executing

Post by Mark Yudki » Thu, 16 Mar 2006 15:42:17

I would assume that if you know your code to be in error, then speculating
on the possible consequences is probably pointless.

Anyway, glad to hear you found the cause.