Hi! This is my first post in the forum. I am facing the problem while debugging in xpediter. When I run the batch it goes well but while I am trying to debug using xpediter it's abending with a SOC04.
On analysing found that a program with Amode 31 is called from Amode 24. During the return back it's adding 4 bytes to the returning address to come to "-----------X" rather than "-----------------Y" . This is where we are getting SOC04.
If I do not add 4 to R14 the return is successful.
Below is the calling pgm code:-
Code:
DIO0343A DC A(2) F
DIO0343B DC A(0) A
DIO0343C DC A(0) A
L R15,=V(xyz) L
BALR R14,R15 L
B EXEC3650 ----------------------------Y
L R1,DIO0343C -------------------------X
Called pgm xyz:-
Code:
MVC DIOPEOF,=F'4'
EXIT L R13,SAVEAREA+4
L R14,12(R13)
L R15,DIOPEOF
AR R14,R15
LM R15,R12,16(R13)
XR R15,R15
BR R14
I tried duing STATIC ON but it did not worked too. Any help will be appreciated.
Note:- The LOAD we are trying to debug is a comp load with aroung 200 lod linked to it.
As a control measure, try using the module you created for debug in the normal JCL. As in, build the module for Xpeditor, but point to that version in you NON Xpeditor run.
That will help rule out the possibility of a bad link.
If that gets the S0C4 again, you know where to start looking. If it doesn't, then try debugging using Xpeditor but with out recompiling/linking the program. You should get a message about "no source code" but it should still be able to run.
if THAT blows up, then you have a bad set of steplibs for your Xpeditor run.
Hi Ed,
We already tried what you suggested. The normal JCL is going fine but while expediting we are getting a SOC04.
The Steplib are correct too.
We are guessing something problem with the transfer from 31 bit mode to 24 bit mode which xped is not able to handle effeciently.
Your 2 cents on the same.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Please include all relevant information in your posts. If there is something you have already done and don't mention the results, people can waste their time doing the same thing for you.
What do you mean "it's adding 4 bytes" and "If I do not add 4"?
Please use the Code tags for anything which requires proportional spacing to make sense. Your assembler has appeared as a bunch of jumble. Is that how you wrote it? No? So why expect us to read it?
When you try something else, don't just say "it didn't work", but tell us the symptoms of it not working.
1) What do you mean "it's adding 4 bytes" and "If I do not add 4"?
Ans In the called pgm inst
AR R14,R15
R14 has the return address of the calling module.
R15 value is 4.
When this code runs thru Xped we are getting a SOC04 at BR R14.
I skipped the AR R14,R15 instruction in xped. Then my control was succcessfully transmitted to the calling pgm( though the label it's goes is not what we intend. It was just to cross check is our return address getting corrupted).
The code is a part of a leagcy product and I pasted the same.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If you look at your first post now, you'll see what I mean about the Code tags. If you want to see how it is done, click on the Quote button on your post. Then notice all the formatting buttons above the main input box, not the quick reply.
Code:
AR R14,R15
This, then, must be coming up with an invalid address. Have you checked what is actually in R15 at the time? I'm prepared to bet that it is more than "4". Then in R14?. Check the definition of DIOPEOF.
Since, you say, everything runs fine except with Xpeditor, I suggest you check the Xpeditor documentation for this 24/31 arrangement you have. Has anyone Xpedited this before? Maybe they discovered how?
R15 value shows 4.
Below is the definition of DIOPEOF:-
DIOPEOF DC A(0)
This is the first time we trying to set the XPED. We are not having any documentation related to 24/31 documentation.Trying to get the info from the internet but to no luck.
Why is the module 31?
As already informed the system is a legacy system. This is the way how it is defined from last many years.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
hg121 wrote:
R15 value shows 4.
Below is the definition of DIOPEOF:-
DIOPEOF DC A(0)
This is the first time we trying to set the XPED. We are not having any documentation related to 24/31 documentation.Trying to get the info from the internet but to no luck.
Why is the module 31?
As already informed the system is a legacy system. This is the way how it is defined from last many years.
S0C4 is a "protection exception". It prevents you from doing anything with storage that you do not have access to, have not established, directly or indirectly, yourself.
If you are getting a S0C4 on a Branch of any sort, then the address-to-be-branched-to is invalid, outside your allowed values, and certainly not four bytes away from where you think it is. When you remove the modification of R14, the S0C4 goes away, so you know that it is the modification of R14 causing the problem. I don't know how you can look at the actual values in the registers, rather than relying on XPED to show you.
When I was asking about why the module is 31, I wasn't expecting the answer that it is because it is old. What I'm trying to get at is, is there a reason it is 31, or can it be re-assembled/linked like the rest? If it was, I'd suspect it would work, but that is no good to you if it is relying on something which has to be "31".
Why it runs normally and fails in XPED you'll need to get it working in XPED to help discover.
I want to make sure you did something... you built the module for Xped. Then you took THAT load module and ran it using the normal batch JCL???
I don't mean the source code, I mean the actual, honest to god load module.
I doubt Xped is getting hung up on call trying to transfer from one level to another. Xped is watching the OTHER program run. Xped is not transferring anything on its own.
I'd be more suspect that one of the compile/link options you use to make information available for the Xped DDIO are changing how the load module works. That's why it's very important to isolate that load module and run it in the regular batch JCL.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Before the CALL/BALR, I imagine R1 is loaded with the address of DIO0343A and the Caller is addressing this as a 12-Byte parmlist off R1?
It's perfectly fine for AMODE 24 to call AMODE 31 but not vice-versa because then you'll raise a S0C4 as soon as you address R1, which will contain a 31-Bit address.
Have you pinpointed where in the Callee's logic-path R15 is being set to F'4'? R15 should contain F'0' to inform the Caller that all is well.
Otherwise, it should contain a non-F'0' value when things are not alright.
The addition of R15 to R14 is strange as R14 will contain the address of the Caller's NSI and must be left intact. Have you tried bypassing the addition?
There's something missing here, but I'm unsure what it is....
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Code:
DIO0343A DC A(2) F
DIO0343B DC A(0) A
DIO0343C DC A(0) A
L R15,=V(xyz) L
BALR R14,R15 L
B EXEC3650 ----------------------------Y
L R1,DIO0343C -------------------------X
Called pgm xyz:-
Code:
MVC DIOPEOF,=F'4'
EXIT L R13,SAVEAREA+4
L R14,12(R13)
L R15,DIOPEOF
AR R14,R15
LM R15,R12,16(R13)
XR R15,R15
BR R14
It is curious code. Presumably there are two exit-points from xyz? It is "reading" something, and when it gets to EOF, it adjusts the return-address to avoid the branch in the calling program which is do the processing of what has been read, for the other exit point.
It loads 14 out of the savearea, to be amended. It uses 15 to load the value of 4 from the a-con DIOPEOF. Adds 15 to 14. Then loads 15 through 12 from the savearea, zeros 15 with the XR and branches to the amended 14, hoping to hop over the branch in the calling program.
According to the snippet, the called program loads the address of the called program to 15 after the savearea has been stored.
Can you, when you at the BR R14 and see what the full value of R14 is? Can you find the other exit point and do the same? Are they four bytes apart?
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
I dont see any proof this MVC DIOPEOF,=F'4' instruction is expected.
Maybe somewhere is a branch to the EXIT label skipping that instruction.
Why else to use a label?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If I want to find out how long an instruction is, I can do that, easity. That is not what I was asking.
I'll type slowly to try to make it easier.
You are S0C4'ing on a "branch" instruction. The address for the branch is therefore "invalid".
When you ignore the "add 4" the program does not S0C4. There is another exit from the program which also does not S0C4.
You have three addresses for two different branch instructions. One of the addresses, the one which came from a 24-bit and was manipulated in a 31-bit, is invalid. The others which came from 24-bit but haven't had the add done, work.
Ergo, the AR is screwing it up. Why runs in batch, not under XPED? Well, blow me down, I wonder if the two things are using identical addresses? No?
So, now, did you actually answer my previous questions, or just question my ability to find out how long instructions are?
Seems you are well-versed in not being useful to those trying to help, and not well-versed in the application of logic?
In other words, when you're testing with Xpediter in batch mode -- you're not even executing YOUR program, you're executing Xpediter and one of the parameters in DD name XPIN is your program. You need to rethink how Xpediter does things and come up with a more realistic idea -- the only STEPLIB in the original JCL was the last one listed above; the rest were all inserted by Xpediter based upon parameter settings in Xpediter/TSO.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
My guess, Ed (back up to full speed for you), XPED is causing the program to run at a "higher" address, and the AR is having a "side-effect", like a "carry" for negative, generating an address which is a combination of the origrinal address plus a lot. Off it pops.
Seems to me a dumb way to code it, but it's "old" stuff. If the return address isn't amended (like at the other exit point from the program, and when the AR is stepped over) there isn't a problem. If the a-con isn't doing it, it is the AR.
I'd change things anyway so that the called module isn't messing with the control flow of the calling module anyway. Change the called module so it knows "end of file", not just that it happens to branch/not branch. That sort of thing you don't want to discover having spent a couple of hours looking at it.
Of course, assembling it at 24 would also "fix" it, I think, but TS hasn't bothered to indicate if that is possible or not, too busy teaching people how to su** eggs, when they are the one who has the problem :-)
Robert, I posted that question about Xped, not the TS, but thanks for the info.
Bill, also thanks for the info.
When we used Xped here at this site, for batch jobs, we ran the actual program, not this "XPTSO" program.
It looked more like the IBM debugger, with the test options added on top. Then the program would stop and wait to be attached to the debug session.
eg
Code:
//CEEOPTS DD *
TEST(,,,VTAM%WXXX:)
/*
Of course, we had to have special compiles that created the DDIO information, which also had to be added to the run time. A lot of times this same issue would come up because of a modified compile having different settings than the "regular" compile.
