Re: Debugging Tips

[Roland Schiradin]

Hi Michael, in these days we should code RENT code only. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

Michael Knigge wrote:

Thank you all for your hints... When the bug is found I'll tell you...


If anybody is interested - it is solved!

The bug wasn't found by using IPCS, ABEND-AID, DumpMaster or whatever, 
just by using the all time favourite Debugger "Eyes'n'Brain" ;-)


My application is written in C with the exception of two modules which 
are written in assembler (for invoking LOCATE and OBTAIN). This has been 
my code (extract):


LOCATE   CSECT
LOCATE   AMODE ANY
LOCATE   RMODE ANY
 SAVE  (14,12)
 BALR  R3,0
 USING *,R3
 LRR9,R13
 LAR13,SAVEAREA
 STR13,8(R9)
 STR9,4(R13)
*
 L R4,0(R1)
 USING PARM,R4
*
 LOCATE PARM
 STR15,RC
*
 L R13,4(,R13)
 MVC   16(4,R13),RC
 LMR14,R12,12(R13)
 BRR14

SAVEAREA DS18F
RC   DSF


Where is the fault? Nowhere! It's all correct. But this is true only for 
non-threaded code. My application uses multiple threads and by using the 
above code all thready have been sharing the same SAVEAREA


I've written the ASM-modules LE/370 compliant now with dynamic saveareas 
and hey all works perfect...



Bye,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

The 'call stack' saying UNKNOWN called UNKNOWN called UNKNOWN called (you get 
the picture) basically means that *something* called a BPX service that is 
either in LPA or located somewhere in the OMVS address space.


H I'm playing a lot with this POSIX-Threads stuff...



How familiar are you with IPCS? Enough to get around and issue a few commands? 
Set a slip trap on the 0C1 *and* the 422 for your job name, include your job, 
omvs asid and all of OMVSs dataspaces.


Currently I have no access to IPCS (no permissions on current z/OS host) 
and I've never used it. But currently I'm planning/doing the migration 
to another z/OS host for our company and then I have IPCS access and I 
plan to play arounf with it




The last few days have been very hetic here and I've been not able to 
focus on this bug. So... I've started to implement a lot of trace stuff 
this weekend in the product and hope it will crash today ;-)



If it won't... welk, then I'll have to go on digging in the dump :-(


bye & thanks
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

find something that will trigger an early failure, run a GTF trace with IF
recording. I'd advise using SYSMDUMP rather than SYSUDUMP, so that you can
use IPCS. Of course, if you have SLIP take the dump then you'll have


Hmmm... Never did this before I'll have look this week.


something to browse with IPCS regardless.


  GPR C-F 000C 4298A448  


R13 looks like it might be legitimate. What are the stored R14-R12,
forward and back links? What format is it?


I'm familar with the SAVEAREa concepts and so on, but everytime I'm 
digging that deep in a dump I really need some time, concentration and 
*SILENCE* - this is not my daily job


And sadly currently here in my office I have  nothing of that. So I'll 
have to go back to this issue in a few days...


bye & thanks,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Barbara Nitz]

Michael,

I know I'm late on this :-)

>PSW 078D1400 8002
>GPR 0-3  4298A340 40894608 108602CA
>GPR 4-7 4298A3B0 40876C10 C086EA6C 0661F420
>GPR 8-B 40875200 4298A500  4086E872
>GPR C-F 000C 4298A448  

What instruction does R6 point to? 

The 'call stack' saying UNKNOWN called UNKNOWN called UNKNOWN called (you get 
the picture) basically means that *something* called a BPX service that is 
either in LPA or located somewhere in the OMVS address space.

How familiar are you with IPCS? Enough to get around and issue a few commands? 
Set a slip trap on the 0C1 *and* the 422 for your job name, include your job, 
omvs asid and all of OMVSs dataspaces.

Take that dump into IPCS, and do some incantations of the verbx ledata 
'tcb(your-tcb-address) asid(your-asid) ceedump'. (Sometimes it takes a while to 
get the LE exit to find the right tcb, I never understood why.) You should see 
something similar to the call trace you're used to from any old formatted dump. 
Find the point where either one of your programs/DLLs last had control or where 
you see a BPX module for the first time. That module should map to the name of 
a C call (somehow) that might make it easier for you to find the point control 
left your own code. Chnaces are that somethings wrong with the parms there.

Another command to try is the omvsdata process detail. Some of that information 
might be residual and cannot be believed (I've got the scars from that), but it 
could also provide a starting point to see where you were last.

All else failing, do a summary format on your failing asid and check your 
(saved) xmem state. Look for the linkage stack entries (if any). I would almost 
expect at least one entry for bpxsjss (or something) which is the calling stub 
for the actual space switching PC into OMVS. As registers always point to the 
primary address space (unless qualified by an AR<>0), your registers may point 
somewhere into OMVSs private. 

Hope that helps,
regards, Barbara
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/13/2008
   at 04:40 PM, Michael Knigge <[EMAIL PROTECTED]> said:

>The application sometimes crashes after a few minutes, sometimes after 
>some days with the S0C1. 

Did you look at the last branch address? If that doesn't work and you can
find something that will trigger an early failure, run a GTF trace with IF
recording. I'd advise using SYSMDUMP rather than SYSUDUMP, so that you can
use IPCS. Of course, if you have SLIP take the dump then you'll have
something to browse with IPCS regardless.

>   GPR C-F 000C 4298A448  

R13 looks like it might be legitimate. What are the stored R14-R12,
forward and back links? What format is it?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

Steve,


This particular kind of thing is sometimes seen where a program is
NON-LE compliant and gets called by LE compliant code. R12 is not what
LE want's it to be (and x'000c' is NOT what LE wants) and so it
augers in and makes a crater.


I also currently assume that I have to look in this direction. Everythig 
I use is my own code, written in C or ASM. The only exception (AFAIR) is 
the invokation of the CSI (Catalog Search Interface).



Ok I'll go ahead and x-check my code again and read the C-Manual 
(linking stuff)



Thank you all for your hints... When the bug is found I'll tell you...


Bye,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Knigge
Sent: Wednesday, August 13, 2008 9:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Debugging Tips


+CEE0374C CONDITION=CEE3201S TOKEN=00030C81 59C3C5C5   954
   WHILE RUNNING PROGRAM UNKNOWN
   AT THE TIME OF INTERRUPT
   PSW 078D1400 8002
   GPR 0-3  4298A340 40894608 108602CA
   GPR 4-7 4298A3B0 40876C10 C086EA6C 0661F420
   GPR 8-B 40875200 4298A500  4086E872
   GPR C-F 000C 4298A448  


ASSUMING that R13 is pointing to a savearea, and that the code had just
done a LM 14,12,12(13), this savearea (the current one) has been stepped
on, and you may have BR 14 to return. 

OK, assuming the reverse, that the current savearea is "valid" and you
haven't just unchained, You have an RC=0 with a return from an internal
subroutine that has gotten a corrupted address to return with in R14.

This particular kind of thing is sometimes seen where a program is
NON-LE compliant and gets called by LE compliant code. R12 is not what
LE want's it to be (and x'000c' is NOT what LE wants) and so it
augers in and makes a crater.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

Do you have a standard SYSUDUMP available, and are you on z/OS 1.8 or
above, and on a z9? If so, then find the RTM2WA area in the SYSUDUMP.
Now find the name BEA in the dump. That is the address of the last
successful BRANCH type instruction. It should point you to where you
came from. Find that in your source code and see what is missing.


Thanks!!!  Sounds "easy"... I'll check that tomorrow...


Bye,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

Being multi threaded, perhaps one or more of your modules is not really
re entrant /reusable but still bound as such. 


Well, they are... But I'm using some system stuff Catalog Search 
Interface for example, SVC99, and so on. I'll go ahead and read the 
manual if there is some kind of serializaion neccessary




LE has a number of debugging tools. I think you should find an exception
trace: one that only traces the last x number of events. 


I know very little about C, but you should be able to do a HANDLE
CONDITION and trap some diagnostic information.



Hmmm... I'll search in the LE Manuals for that... Never heared abou that



Thanks,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Michael Knigge]

David,

I have some kind of "limited skills", but I'm not *THAT* stupid ;)


I would start start by looking up the condition description in the 'LE Run-Time 
Messages' manual.  


I have some kind of "limited skills", but I'm not *THAT* stupid ;)  Of 
course I've looked up the condition description



Programmer Response:  Examine the contents of registers 14 and 15. If 
register 15 has a value of 0, then the cause was probably a routine 
didn't exist and a branch was made to location 0. This would indicate a link-
edit failure. Examine the contents of register 14 to determine the point 


Yes, and R15 **AND** R14 are ZERO So I came from address Zero... 
Voood ;-)



Bye,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Hal Merritt]

This smells a bit like a wild branch. The '0Cx' family of exceptions
typically center around addressing issues. Perhaps a vector/pointer
address has been overlain, there was an undetected/ignored failure in a
getmain, open, or service call that left the regs unpredictable, etc.

Being multi threaded, perhaps one or more of your modules is not really
re entrant /reusable but still bound as such. 

LE has a number of debugging tools. I think you should find an exception
trace: one that only traces the last x number of events. 

I know very little about C, but you should be able to do a HANDLE
CONDITION and trap some diagnostic information.

HTH and good luck. 

   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Knigge
Sent: Wednesday, August 13, 2008 9:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Debugging Tips

All,

sind a few days now I try to track down a S0C1 in one of my 
applications. The application is a multi-threaded application (TCP/IP 
Server) written in C using a bunch of self-written DLL's.

The application sometimes crashes after a few minutes, sometimes after 
some days with the S0C1. DumpMaster tells me that the ABEND occurs in 
program BPXINLPA, and the PSW is 078D1400 8002.

But no call stack (well, it tells me "UNKNOWN called UNKNOWN called 
UNKNOWN) and that the failing instruction at  is at offset 
 in program PSA


The job itself ends with a S422. Some information from the Log:

+CEE0374C CONDITION=CEE3201S TOKEN=00030C81 59C3C5C5   954
   WHILE RUNNING PROGRAM UNKNOWN
   AT THE TIME OF INTERRUPT
   PSW 078D1400 8002
   GPR 0-3  4298A340 40894608 108602CA
   GPR 4-7 4298A3B0 40876C10 C086EA6C 0661F420
   GPR 8-B 40875200 4298A500  4086E872
   GPR C-F 000C 4298A448  
   FLT 0-2 4848A181A1EE3A55  
   FLT 4-6   
BPXP011I THREAD 40F74C000422, IN PROCESS 211, WAS  955
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
BPXP011I THREAD 40FA00E002AF, IN PROCESS 211, WAS  956
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
BPXP011I THREAD 40F9E2C1, IN PROCESS 211, WAS  957
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
BPXP011I THREAD 40F9F1D2, IN PROCESS 211, WAS  958
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
SYSTEM COMPLETION CODE=0C1  REASON CODE=0001
  TIME=14.27.13  SEQ=44974  CPU=  ASID=00C7
  PSW AT TIME OF ERROR  078D1400   8002  ILC 2  INTC 01
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW   - 000A  000130E1  
GR 0:    1: 4298A340
   2: 40894608   3: 108602CA
   4: 4298A3B0   5: 40876C10
   6: C086EA6C   7: 0661F420
   8: 40875200   9: 4298A500
   A:    B: 4086E872
   C: 000C   D: 4298A448
   E:    F: 
  END OF SYMPTOM DUMP
BPXP018I THREAD 40F897600424, IN PROCESS 211, ENDED  321
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 940C1000, AND REASON CODE
0001.
SYSTEM COMPLETION CODE=422  REASON CODE=01A0
  TIME=14.29.16  SEQ=45446  CPU=  ASID=00C7
  PSW AT TIME OF ERROR  070C4400   C08642BE  ILC 2  INTC 78
NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
NAME=UNKNOWN
BPXP023I THREAD 40F9B590, IN PROCESS 211, WAS  342
TERMINATED BY SIGNAL SIGCNCL, SENT FROM THREAD
40F897600424, IN PROCESS 211, UID 50049, IN JOB E1407900.



All I tried so far to track this one down failed. I'm at the end of my 
skills :-(



Could anyone please give me some advise how to find this bug? Any good 
manual to read?



Thank you very much,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[David Waldman]

>
>Could anyone please give me some advise how to find this bug? Any good
>manual to read?
>
>
>
>Thank you very much,
>Michael
>

I would start start by looking up the condition description in the 'LE Run-Time 
Messages' manual.  

CEE3201S The system detected an operation exception (System Completion
   Code=0C1).
 
Explanation:  The program attempted to execute an instruction with an invalid 
operation code. The operation code may be unassigned or the 
instruction with that operation code cannot be installed on this platform. See 
a Principles of Operation manual for a full list of operation exceptions.
 
Programmer Response:  Examine the contents of registers 14 and 15. If 
register 15 has a value of 0, then the cause was probably a routine 
didn't exist and a branch was made to location 0. This would indicate a link-
edit failure. Examine the contents of register 14 to determine the point 
at which the branch was made. Also examine the linkage editor map for any 
unresolved references reported by the linkage editor.
 
Another possible cause is a routine branched to some unintended location, 
such as a conflict in addressing mode between the calling and the 
called routine, or any other program error that branched to the wrong location.


hth,
Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael Knigge
> Sent: Wednesday, August 13, 2008 9:41 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Debugging Tips
> 
> All,
> 
> sind a few days now I try to track down a S0C1 in one of my 
> applications. The application is a multi-threaded application (TCP/IP 
> Server) written in C using a bunch of self-written DLL's.
> 
> The application sometimes crashes after a few minutes, 
> sometimes after 
> some days with the S0C1. DumpMaster tells me that the ABEND occurs in 
> program BPXINLPA, and the PSW is 078D1400 8002.
> 

Do you have a standard SYSUDUMP available, and are you on z/OS 1.8 or
above, and on a z9? If so, then find the RTM2WA area in the SYSUDUMP.
Now find the name BEA in the dump. That is the address of the last
successful BRANCH type instruction. It should point you to where you
came from. Find that in your source code and see what is missing.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging Tips

[Pedro Vera]

>> written in C using a bunch of self-written DLL's.

When I have an application with multiple programs, I add a trace 
capability.  Perhaps it is as easy as saving the current program name in a 
buffer.  Or even issuing WTO's. 

Pedro Vera

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Debugging Tips

[Michael Knigge]

All,

sind a few days now I try to track down a S0C1 in one of my 
applications. The application is a multi-threaded application (TCP/IP 
Server) written in C using a bunch of self-written DLL's.


The application sometimes crashes after a few minutes, sometimes after 
some days with the S0C1. DumpMaster tells me that the ABEND occurs in 
program BPXINLPA, and the PSW is 078D1400 8002.


But no call stack (well, it tells me "UNKNOWN called UNKNOWN called 
UNKNOWN) and that the failing instruction at  is at offset 
 in program PSA



The job itself ends with a S422. Some information from the Log:

+CEE0374C CONDITION=CEE3201S TOKEN=00030C81 59C3C5C5   954
  WHILE RUNNING PROGRAM UNKNOWN
  AT THE TIME OF INTERRUPT
  PSW 078D1400 8002
  GPR 0-3  4298A340 40894608 108602CA
  GPR 4-7 4298A3B0 40876C10 C086EA6C 0661F420
  GPR 8-B 40875200 4298A500  4086E872
  GPR C-F 000C 4298A448  
  FLT 0-2 4848A181A1EE3A55  
  FLT 4-6   
BPXP011I THREAD 40F74C000422, IN PROCESS 211, WAS  955
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
BPXP011I THREAD 40FA00E002AF, IN PROCESS 211, WAS  956
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
BPXP011I THREAD 40F9E2C1, IN PROCESS 211, WAS  957
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
BPXP011I THREAD 40F9F1D2, IN PROCESS 211, WAS  958
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
SYSTEM COMPLETION CODE=0C1  REASON CODE=0001
 TIME=14.27.13  SEQ=44974  CPU=  ASID=00C7
 PSW AT TIME OF ERROR  078D1400   8002  ILC 2  INTC 01
   NO ACTIVE MODULE FOUND
   NAME=UNKNOWN
   DATA AT PSW   - 000A  000130E1  
   GR 0:    1: 4298A340
  2: 40894608   3: 108602CA
  4: 4298A3B0   5: 40876C10
  6: C086EA6C   7: 0661F420
  8: 40875200   9: 4298A500
  A:    B: 4086E872
  C: 000C   D: 4298A448
  E:    F: 
 END OF SYMPTOM DUMP
BPXP018I THREAD 40F897600424, IN PROCESS 211, ENDED  321
WITHOUT BEING UNDUBBED WITH COMPLETION CODE 940C1000, AND REASON CODE
0001.
SYSTEM COMPLETION CODE=422  REASON CODE=01A0
 TIME=14.29.16  SEQ=45446  CPU=  ASID=00C7
 PSW AT TIME OF ERROR  070C4400   C08642BE  ILC 2  INTC 78
   NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
   NAME=UNKNOWN
BPXP023I THREAD 40F9B590, IN PROCESS 211, WAS  342
TERMINATED BY SIGNAL SIGCNCL, SENT FROM THREAD
40F897600424, IN PROCESS 211, UID 50049, IN JOB E1407900.



All I tried so far to track this one down failed. I'm at the end of my 
skills :-(




Could anyone please give me some advise how to find this bug? Any good 
manual to read?




Thank you very much,
Michael

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html