EC6 ABEND with X'00FFCE54' in R15
I'm running a small program that uses BPX pthreads along with CEEPIPI. The program is a Systems/C program that uses BPX pthreads to start up a HEAVY thread that then creates a CEEPIPI environment, calls a simple IBM C (LE) function and returns, then destroys the CEEPIPI environment and then the pthread ends with a pthread_exit(). Under BATCH, the program runs just fine. But - under TSO the program runs to completion and then gets an ABEND and the message: IEA848I NO DUMP WAS PRODUCED FOR THIS ABEND, DUE TO SYSTEM OR INSTALLATION REQUEST Catching the ABEND with an ESPIE, I find that it is an SEC6 ABEND, with R15 containing X'00FFCE54'. Unfortunately the CE54 reason-code doesn't seem to be documented for the EC6 ABEND. And the EC6 documentation says R15 may, or may-not contain a reason-code... so - can't really tell. And, since the dump is suppresed... I get no info, and since the program runs fine under batch, I can't get a dump there. I would hazard a guess that something is amis with some callable service somewhere... possibly BPX exit(), but I'm hoping someone might have run into that CE54 reason-code before? I didn't find any PTFs that mention it. This is z/OS 2.4. - Thanks - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
You might want to run GTF trace to see all the Unix reason codes being produced. I haven't checked if the following works on 2.4 but this doesn't tend to change in decades ;) SLIP SET,IF,A=TRACE,RANGE=(10?+8C?+F0?+1f4?),TRDATA=(13R??+1B0,+B3),END On Sat, Aug 8, 2020 at 12:42 PM Thomas David Rivers wrote: > I'm running a small program that uses BPX pthreads > along with CEEPIPI. > > The program is a Systems/C program that uses BPX pthreads > to start up a HEAVY thread that then creates a CEEPIPI environment, > calls a simple IBM C (LE) function and returns, then destroys > the CEEPIPI environment and then the pthread ends with a pthread_exit(). > > Under BATCH, the program runs just fine. > > But - under TSO the program runs to completion and > then gets an ABEND and the message: > > > IEA848I NO DUMP WAS PRODUCED FOR THIS ABEND, DUE TO SYSTEM OR > INSTALLATION REQUEST > > Catching the ABEND with an ESPIE, I find that it is an > SEC6 ABEND, with R15 containing X'00FFCE54'. > > Unfortunately the CE54 reason-code doesn't seem to be > documented for the EC6 ABEND. And the EC6 documentation > says R15 may, or may-not contain a reason-code... so - can't > really tell. And, since the dump is suppresed... I get no info, > and since the program runs fine under batch, I can't get a dump > there. > > I would hazard a guess that something is amis with some callable > service somewhere... possibly BPX exit(), but I'm hoping someone > might have run into that CE54 reason-code before? I didn't find > any PTFs that mention it. > > This is z/OS 2.4. > >- Thanks - > - Dave Rivers - > > > > > > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
I have no idea about the problem (not seeing any obvious reason codes defined that look like that, with or without the 00FF) but: Catching the ABEND with an ESPIE, I find that it is an SEC6 ABEND, with R15 containing X'00FFCE54'. Did you really mean ESPIE? An ESPIE routine will not get control for an abend. If an ESPIE routine did get control, you are looking at the registers at the time of some program check, not at the time of an abend. The IEA848I message indicates that SLIP suppressed that dump. The SLIP traps for EC6 that are shipped with z/OS would not suppress for R15 = x'00FFCE54' (whether it's a reason code or not) SLIP SET,C=EC6,RE=FFXX,ID=XEC6,A=NODUMP,END SLIP SET,C=EC6,RE=FDXX,ID=XXC6,A=NOSVCD,END (the latter wouldn't apply because yours is not an SVC Dump) So maybe it wasn't 00FFCE54 but something else? or maybe your site has set a SLIP trap that suppresses additional EC6 cases that they could relax for you? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
Thanks all! Turns out I was confused by the EC6 doc; thinking the reason-code should be in R15. But - it's not - it's clearly where it needs to be... I'm getting an EC6 ABEND with a REASON code of which means that the BPX _exit() was invoked with subtasks (in this case, pthread subtasks.) Although - I _thought_ all the pthreads had been either joined or detached. I didn't think a pthread TASK would "stay around" (these are all HEAVY-weighted pthreads.) Is there some call that says "hey - end all the extent tasks waiting on pthreads". (I don't have a pthread_t thread-id because they have all "gone away" so I can't pthread_join the thread or anything...) Or - do we just "live with" this EC6 ABEND in this case? - Dave Rivers - p.s To Peter - yeah - I should have said ESTAE... sorry for the inaccuracy. -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
Umm... dont you maintain a table of your pthreads? Like storing off their ids somewhere? If not maybe you should? Then you can have a routine in your exit that kills off the pthreads from the table using their id before you exit... Joe On Sun, Aug 9, 2020 at 6:14 AM Thomas David Rivers wrote: > Thanks all! Turns out I was confused by the EC6 doc; > thinking the reason-code should be in R15. > > But - it's not - it's clearly where it needs to be... I'm > getting an EC6 ABEND with a REASON code of > which means that the BPX _exit() was invoked with > subtasks (in this case, pthread subtasks.) > > Although - I _thought_ all the pthreads had been either > joined or detached. I didn't think a pthread TASK would > "stay around" (these are all HEAVY-weighted pthreads.) > > Is there some call that says "hey - end all the extent tasks > waiting on pthreads". (I don't have a pthread_t thread-id > because they have all "gone away" so I can't pthread_join > the thread or anything...) > > Or - do we just "live with" this EC6 ABEND in this case? > >- Dave Rivers - > > p.s To Peter - yeah - I should have said ESTAE... sorry for the inaccuracy. > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
Joe Monk wrote: Umm... dont you maintain a table of your pthreads? Like storing off their ids somewhere? If not maybe you should? Then you can have a routine in your exit that kills off the pthreads from the table using their id before you exit... Joe O Yeah - but how do you kill a pthread? You can send it a signal or a cancel, but if it's not in a "good place" it won't act on those... and you have no way of knowing if it's dead-or-alive. And - there is another chicken-and-egg problem - what if one of the pthreads is the one invoking BPX _exit()? What kills the other pthreads? This 'feels like' it's better handled as an OS function... not an application one. And, I think, in any environment except TSO it is done that way, I wonder what's so special about TSO? - Dave -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
"I wonder what's so special about TSO?" TSO in batch or TSO Interactive? But either way, doesnt TSO normally spin off subtasks with an ATTACH/ATTACHX? Joe On Sun, Aug 9, 2020 at 11:01 AM Thomas David Rivers wrote: > Joe Monk wrote: > > >Umm... dont you maintain a table of your pthreads? Like storing off their > >ids somewhere? > > > >If not maybe you should? Then you can have a routine in your exit that > >kills off the pthreads from the table using their id > >before you exit... > > > >Joe > > > >O > > > Yeah - but how do you kill a pthread? You can send it a signal > or a cancel, but if it's not in a "good place" it won't act on those... > and you have no way of knowing if it's dead-or-alive. > > And - there is another chicken-and-egg problem - what if one of > the pthreads is the one invoking BPX _exit()? What kills the > other pthreads? > > This 'feels like' it's better handled as an OS function... not an > application one. > And, I think, in any environment except TSO it is done that way, I wonder > what's so special about TSO? > > >- Dave > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EC6 ABEND with X'00FFCE54' in R15
Yes. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Sunday, August 9, 2020 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EC6 ABEND with X'00FFCE54' in R15 "I wonder what's so special about TSO?" TSO in batch or TSO Interactive? But either way, doesnt TSO normally spin off subtasks with an ATTACH/ATTACHX? Joe On Sun, Aug 9, 2020 at 11:01 AM Thomas David Rivers wrote: > Joe Monk wrote: > > >Umm... dont you maintain a table of your pthreads? Like storing off their > >ids somewhere? > > > >If not maybe you should? Then you can have a routine in your exit that > >kills off the pthreads from the table using their id > >before you exit... > > > >Joe > > > >O > > > Yeah - but how do you kill a pthread? You can send it a signal > or a cancel, but if it's not in a "good place" it won't act on those... > and you have no way of knowing if it's dead-or-alive. > > And - there is another chicken-and-egg problem - what if one of > the pthreads is the one invoking BPX _exit()? What kills the > other pthreads? > > This 'feels like' it's better handled as an OS function... not an > application one. > And, I think, in any environment except TSO it is done that way, I wonder > what's so special about TSO? > > >- Dave > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at > http://secure-web.cisco.com/1hYKBJSOVMPQGt4IhJZFf3IT_kINaH5nxUsHWX4TALT51ALZTzZIEkhcPKSZhgeZ7-yh0KRwkvcywuEheaP3uK5g7I-2lSo-Hp3UeITdUP716TxrwMGGXtzHtjN4mHQJfqTVOXaeVxk9MPFpBnxlQM2lH-dR1TnL8Qh2k_cjIcg-IGH-TaDWjQi57BXTZqnBWF01M1osKTyAhmYkTAhH353nS7i40h41izxjGeDTtGyc56PXvLg9lcg2dcxMsGrg1CrRMI5keNYenwwIM0mEaJwhClm9JREPHUYZ4A6DzTEF8GsEyhmNqjAJ2c9E_uFKPZpJn6WE41WxNQ-Kb5jVaWaoLA_kw0CorHFdPXxZe7M2IEHjFkKH0AKKUXul1Kb_qJKyxmk08QYKC943YbXqjcA4JNCF-Hp3odNm0xkycBID1cExKpV5Aubxag_N8nU0S/http%3A%2F%2Fwww.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
