|
View previous topic :: View next topic
|
| Author |
Message |
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
I have a program that is executing a READQ TS that is behaving very strangely. It is coded as follows:
| Code: |
MOVE +70 TO WS-LENGTH.
MOVE +1 TO WK-ITEM.
EXEC CICS READQ TS
QUEUE ('TEMPQ001')
SET ('TEMP-PTR)
LENGTH (WS-LENGTH)
ITEM (WK-ITEM)
RESP (WS-RESP)
RESP2 (WS-RESP2)
END-EXEC.
IF WS-RESP NOT GOOD .... DO SOMETHING
SET ADDRESS OF WK-STATUS-AREA TO TEMP-PTR. |
My program was dying downstream because it had bad data in the WK-STATUS-AREA. However, when I'd step through the program (this logic) with expediter, everything worked fine. I finally found that, when I would do the following:
1. put expediter breaks immediately before the READQ command and then immediately after,
2. then use the expediter PF9 key to step through one line of code at a time (going from the exec to the IF statement)
3. kick off the remaining transaction with a PF12
Everything would work. However, if I would use expediter this way:
1. put expediter breaks immediately before the READQ command and then immediately after,
2. then use the expediter PF12 key to step through one line of code at a time (going from the exec to the IF statement)
3. kick off the remaining transaction with a PF12
Then my transaction would die (as it would when I processed the whole transaction normally).
What I found was that the TEMP-PTR is coming back with a different address when I step through (PF9) the code than when it executes in different ways. I determined this with an experiment - I stacked two identical READQ EXECs back to back in the program and used PF9 on one and PF12 on the other.
I hope I made sense here. The problem has me completely baffled. I've experimented with different compiler options (above the line, below, etcl) and I always get the same result - the logic only works when I step through one line at a time with expediter....
If anyone has any thoughts or insight, I would appreciate hearing from you.
Thanks! |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
What did the Xpediter vendor say when you raised the issue? If you haven't, then why not?
How is TEMP-PTR defined? |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3077
Location: NYC,USA
|
|
|
|
| Code: |
SET(ptr-ref) Specifies the pointer reference that is set to the address of the retrieved data. The pointer reference, unless changed by other commands or statements, is valid until the next READQ TS command or the end of task.
If the application program is defined with DATALOCATION(ANY), the address of the data can be above or below the 16 MB line. If the application program is defined with DATALOCATION(BELOW), the address of the data is below the 16 MB line.
If TASKDATAKEY(USER) is specified for the running task, and storage protection is active, the data that is returned is in a user-key. If TASKDATAKEY(CICS) is specified and storage protection is active, the data that is returned is in a CICS-key. |
|
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Is this TSQ shared by other programs or tasks? If so, then you'll need ENQ/DEQ API's to serialize access.
HTH.... |
|
| Back to top |
|
|
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
| Thank you, Rohit. I had already looked that up. Unfortunately, it does not explain why the pointer address that is coming back from the READQ TS execution is invalid (unless I missed something). I did, however, attempt the various compile options that were noted in the text that you offered, but I got the same results. |
|
| Back to top |
|
|
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
| Thank you, Bill. I will look into that. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| I'm not sure why you thought changing compile options would make any difference. What is the difference between using PF9 and PF12 in Xpediter? |
|
| Back to top |
|
|
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
Robert.... I was grasping at straws. When I read the part of the manual that Rohit listed above, it mentioned something about DATALOCATION. I started tweaking that option as well as AMODE, etc. Needless to say, they didn't work....
PF9 in xpediter executes one line of code. PF12 will execute until the next breakpoint. In my case, they should have essentially been the same thing. I put breakpoints on two consecutive lines (one for the EXEC statement and one on the line immediately after it). However, the results of the temp-ptr field were different based on using the PF9(correct pointer) versus the PF12(incorrect pointer). |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
One obvious difference is that Xpediter has to insert code to break for each line of code with F9 and doesn't have to do that for F12. I think your best bet is to contact the vendor for assistance -- they most likely have seen the problem before and know just how to resolve it.
I've seen a similar problem in the past -- a program wouldn't work until it was Xpedited at which time the code worked fine. IIFC (and it's been more than 20 years so that recall may not be correct), the issue was a storage overlay involving a map in CICS; since the Xpediter screen was injected in the middle it prevented the problem for showing up. |
|
| Back to top |
|
|
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
That's probably a wise course of action. My thinking was that this is not a "problem" with xpediter. It was only a tool to try to determine the root of the problem. It could have just as easily been a display.
It was just interesting and baffling to me that xpediter would allow the program to work in some way.
However, you have a good point. They likely have seen something like this before and may have an idea about how to correct it. I'll follow up with them.
Thanks for your input |
|
| Back to top |
|
|
RahulG31
Active User
Joined: 20 Dec 2014
Posts: 446
Location: USA
|
|
|
|
What are the RESP and RESP2 values, if I may ask?
. |
|
| Back to top |
|
|
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
| The Resp values both came back with 0's. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3077
Location: NYC,USA
|
|
|
|
| Code: |
Use the INTO or SET option to state whether the record is to be read into an area of main storage provided by your application program (READ INTO), or into an area of main storage CICS SET storage acquired by file control (READ SET). If the latter, the address of the data in the CICS SET storage is returned to your program. CICS SET storage normally remains valid until the next syncpoint, or the end of the task, or until next READ against the same file, whichever comes first.
If you have used the SET option, you do not have to specify the LENGTH option. However, you may specify it if you want to check whether the record length agrees with that originally defined to VSAM. The data area specified is set to the actual record length after the record has been retrieved. |
Would you also try with INTO or has to be done by SET? |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1317
Location: Vilnius, Lithuania
|
|
|
|
If you're running a program with a debugger, or compiler options that are different from those used on production compiles, you're running a different program!
Period. End of story. |
|
| Back to top |
|
|
moezbud
New User
Joined: 03 May 2016
Posts: 12
Location: usa
|
|
|
|
Rohit, yes I went the route you noted above late yesterday (using INTO). We got it working that way. I'll just chalk the SET problem up to one of the mysteries of the universe.... My problem was just getting stuck on something that "should" work and playing with it too long after I determined that it didn't.
Thanks to all for your input. |
|
| Back to top |
|
|
|
|
