Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Problem in debugging in Xpeditor

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CA Products
View previous topic :: :: View next topic  
Author Message
hg121

New User


Joined: 22 Sep 2011
Posts: 5
Location: India

PostPosted: Wed May 02, 2012 4:06 pm    Post subject: Problem in debugging in Xpeditor
Reply with quote

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.
Back to top
View user's profile Send private message

Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed May 02, 2012 10:40 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
hg121

New User


Joined: 22 Sep 2011
Posts: 5
Location: India

PostPosted: Thu May 03, 2012 10:02 am    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Thu May 03, 2012 12:03 pm    Post subject: Re: Problem in debugging in Xpeditor
Reply with quote

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.
Back to top
View user's profile Send private message
hg121

New User


Joined: 22 Sep 2011
Posts: 5
Location: India

PostPosted: Thu May 03, 2012 12:39 pm    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

Bill,
Below are the answers

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. icon_cry.gif
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Thu May 03, 2012 1:03 pm    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

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?

Why is the module 31?
Back to top
View user's profile Send private message
hg121

New User


Joined: 22 Sep 2011
Posts: 5
Location: India

PostPosted: Thu May 03, 2012 1:13 pm    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Thu May 03, 2012 1:43 pm    Post subject: Re: Reply to: Problem in debugging in Xpeditor
Reply with quote

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.


Assembler is not my forté, but given you have 31 addressing and don't know what is going on, I'd be inclined to define that as a fullword, not an a-con.

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.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Thu May 03, 2012 11:11 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu May 03, 2012 11:35 pm    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

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....
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Fri May 04, 2012 12:25 am    Post subject: Re: Problem in debugging in Xpeditor
Reply with quote

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?
Back to top
View user's profile Send private message
hg121

New User


Joined: 22 Sep 2011
Posts: 5
Location: India

PostPosted: Fri May 04, 2012 10:12 am    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

Bill O'Boyle
r15 is correctly handled. Looks you kissed the last part of called pgm XYZ.

Bill,
Yes..from the pgm XYZ there are 2 exit points
----------------X and ---------------------Y( see in the posted code 1).

The normal batch is going fine. The instructions are 4 bytes apart.

Still I am not able to figure out why the normal batch is going fine but bombs with SOC04 when I try to xped it. icon_cry.gif
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Fri May 04, 2012 12:24 pm    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Fri May 04, 2012 12:26 pm    Post subject: Re: Reply to: Problem in debugging in Xpeditor
Reply with quote

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?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri May 04, 2012 1:21 pm    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

Quote:
r15 is correctly handled. Looks you kissed the last part of called pgm XYZ.

I haven't "kissed" anything. It's your code.... icon_rolleyes.gif
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri May 04, 2012 7:25 pm    Post subject:
Reply with quote

Bill, this one is perplexing me quite a bit.

I am mainly stumped because I don't think Xped creates the run environment, or effects the running program in any way. I think it just allows access.

Is that true? Does Xped just kind of watch from the sidelines, or does it actually execute instructions?

Either way, are you trying to tell TS that he is executing a different logic path between their two experiments?

p.s. "I'll type slowly to try to make it easier." <-- LOL!
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7905
Location: Bellevue, IA

PostPosted: Fri May 04, 2012 7:44 pm    Post subject:
Reply with quote

Quote:
I am mainly stumped because I don't think Xped creates the run environment, or effects the running program in any way. I think it just allows access.

Is that true? Does Xped just kind of watch from the sidelines, or does it actually execute instructions?
If you ever execute Xpediter in batch mode, and look at the generated JCL, you'll see that Xpediter does a LOT of changing. For example:
Code:
 ==MSG> *** THE FOLLOWING STEP IS MODIFIED TO DEBUG WITH XPEDITER ***
 000020 //STEP1    EXEC  PGM=XPTSO,REGION=0M,PARM='CURRENCY'
 000021 //SYSPRINT DD   SYSOUT=*
 000022 //XDYNAMIC DD  DISP=(NEW,DELETE),
 000023 //             DSNTYPE=PDS,
 000024 //             UNIT=SYSDA,
 000025 //             DCB=(RECFM=U,DSORG=PO,BLKSIZE=32760),
 000026 //             SPACE=(CYL,(5,0,10))
 000027 //STEPLIB  DD  DSN=*.XDYNAMIC,VOL=REF=*.XDYNAMIC,DISP=(SHR,PASS)
 000028 //         DD  DISP=SHR,DSN=TESTING.TESTLIB
 000029 //         DD  DISP=SHR,DSN=COMPWARE.MLXT760.SLXTLOAD
 000030 //         DD  DISP=SHR,DSN=CEE.SCEERUN
 000031 //         DD  DISP=SHR,DSN=CEE.SCEERUN2
 000032 //         DD  DISP=SHR,DSN=COMPWARE.MLCX850.SLCXLOAD
 000033 //         DD  DISP=SHR,DSN=COMPWARE.MLXT760.SLXTLOAD
 000034 //         DD  DISP=SHR,DSN=COMPWARE.MLXT760.SLXTLOAD
 000035 //         DD  DISP=SHR,DSN=COMPWARE.MLCX850.SLCXLOAD
 000036 //         DD   DISP=SHR,DSN=TTSSRS0.COMPILES.LOADLIB
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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Fri May 04, 2012 7:45 pm    Post subject: Reply to: Problem in debugging in Xpeditor
Reply with quote

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 :-)

Without more information, that's my best :-)
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri May 04, 2012 8:12 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CA Products All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Problem in writing Output file vickey_dw COBOL Programming 5 Mon Nov 14, 2016 11:14 pm
No new posts Problem in Running Query via JCL vickey_dw DB2 3 Tue Oct 18, 2016 11:11 pm
No new posts DB2 Streaming Batch Processing Problem Manshadi DB2 4 Sat Sep 24, 2016 12:14 pm
No new posts Problem with GETMAIN command amitc23 CICS 6 Thu Sep 01, 2016 1:01 pm
No new posts TXT2PDF problem - printing @ in PDF vipul65 All Other Mainframe Topics 9 Thu Aug 25, 2016 12:48 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us