I wouldn't call myself a SLIP expert, but I do a lot of SLIPs during software development.
Consider something like the private module parm of SLIP. You would use something like P=TOROLABA. Do you get registers when you get the S0C4? If you do, find the one that contains the base address and use that in a range parm. That might help narrow down the SLIP and not have to watch the whole address space. Chuck On Sat, Jul 15, 2023 at 2:59 PM Jon Perryman <[email protected]> wrote: > The SLIP I recommended was to capture the system trace which will not > solve your problem but would give you information about setting a slip to > capture the you need. S0C4 SVCDUMP is notoriously difficult to capture. > Since the error message contains the abend address, you don't need to use > the system trace table to get that address. > > If I understand the CEE3204S error message correctly, it tells you the > abending address which can be used in the SLIP. It's great that this > address is consistent. Note that setting SLIP can sometimes change the > abending address so a broader address range is advisable. I'm guessing that > we should see any other S0C4 within 1M of that address. Here's the slip I > would have asked customers to try: > > SLIP SET,ID=PYDB,COMP=0C4,ADDRESS=(1C300000,1C50000),ACTION=SVCD,END > > A 2M range is extreme but with limited access to setting slips, this will > be more likely to include the address. You could make it closer 1C3A79B4 > which would reduce the risk of capturing a false S0C4. > > On Saturday, July 15, 2023 at 11:50:20 AM PDT, Farley, Peter < > [email protected]> wrote: > > Follow-up: The python code that abends is already using try/except around > the calls to the fetch_both() function, and the “except” phrase is never > executed (I already have message outputs there, though not to > /dev/console), so there is no chance to output anything after the abend > happens. > > So what I think we need is something that will generate a dump after the > S0C4 in an OMVSEX AS forked from the bash login AS. > > In case it helps, the exact error message printed by the abend are as > follows: > > CEE3204S The system detected a protection exception (System Completion > Code=0C4). > From compile unit TOROLABA:./Objects/object.c at entry point > PyObject_Hash at statement 769 at compile unit offset +000000001C3A79B4 at > entry offset > +0000000000000074 at address 000000001C3A79B4. > Segmentation fault > > This is a consistently generated abend, at the same offset every time > (though the actual address changes). > > Peter > > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Farley, Peter > Sent: Saturday, July 15, 2023 2:18 PM > To: [email protected] > Subject: Re: How to set a SLIP to catch S0C4 in OMVS separate AS > > > > Thanks for trying to help Jon, but “IBM” hasn’t *officially* looked at > anything. The python ibmdb team is an open source collective (perhaps > including some IBM employees, but I do not know that for sure) and is not > “official” IBM support at all. One of the ibmdb team has asked for an > SVCDUMP as they may have seen this error previously but could not follow up > on it at that time. > > > > I do not have access to set the SLIP to catch this abend, I have to rely > on the admins at the Zxplore system to do that, and they are not experts > either. Zxplore is a “student learning” system that IBM runs in the cloud > but solving a problem with the python ibmdb code is not very high on their > list of priorities, though they have been trying to help here. I am not > dealing with an experienced z/OS sysprog on Zxplore for this task, just a > system “administrator” who has considerable authority on the system. > > > > The python program stops altogether after the abend even with a try/except > (at least I think it does – I will double check that) so there is no chance > to output anything after the abend. If it turns out that a try/except > works I will try getting an output to /dev/console after the abend and see > if that can help generate a dump. I am not sure that an SVCDUMP after the > python program terminates would be at all helpful, but I am not an expert > in that area either. > > > > Again, thanks for trying to help. > > > > Peter > > > > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Jon Perryman > > Sent: Saturday, July 15, 2023 11:28 AM > > To: [email protected] > > Subject: Re: How to set a SLIP to catch S0C4 in OMVS separate AS > > > > As you discovered, S0C4 SLIPs are at the best of times a pain in the a$$. > S0C4 is difficult because it has a real use which is to determine if a page > has been created (not just allocated). It requires multiple SLIP IGNORE > which can be obtained from IBM. Since you are working with IBM support, I > assume they gave you these SLIP IGNORE to be defined the SLIP SVCDUMP. It > would be helpful to see the SLIPs provided by IBM. > > I assume IBM looked at the CEEDUMP but it did not contain anything that > would be useful for setting a SLIP. This leaves you with some trial and > error. Without anything to go on, here's what I would look consider. > > 1. If you repeat the abend, does it occur at the same address? If so, > ADDRESS=,COND=0C4 may be your easiest option.2. If you can get quiet time > on a system, you can get quiet time on the system, this would be your > second choice.3. I assume you are somewhat comfortable with IPCS. If so, > capture an informational dump and create a SLIP using the information you > find as follows:3A. Generate a WTO as soon as possible after the abend. > Since you have Python source, code a TRY/EXCEPT which writes a message to > the console (If I remember correctly, its /dev/console). Alternatively, you > can write a small HLASM program that issues a WTO that is called from > except. Another alternative would be to write a script to run the python > program and issue the console message (/dev/console) after the python > program terminates. 3B. Write a SLIP WTO SVCDUMP for the console message > and capture the dump.3C. Using IPCS, Find the S0C4 abend in the trace > table. Since you think its occurring in another address space, don't > restrict it to the selected address space. Find the not all processors > message then search backwards for '*' until you find the correct S0C4. This > can be tedious on a very active system. 3D. The trace entry will have the > failing address space and address. Hopefully the abend address is in common > or the python program and abend occur in the same address space otherwise > you will need a method to capture the failing address space. Using the > WHERE command, specify ASID and ADDRESS to find out which module caused the > S0C4.3E. Create a slip using the module name. > > > > On Friday, July 14, 2023 at 05:17:06 PM PDT, Farley, Peter <mailto: > [email protected]> wrote: > > > > Hi All, > > > > I am trying to help the python ibmdb team help me solve an S0C4 abend > issue with (we think maybe) their code on the IBM Zxplore LPAR by > generating an SVCDUMP that the ibmdb team could analyze. The admins at > Zxplore have tried a couple of times to set a SLIP to catch the S0C4 abend > that I am getting when using one of the ibmdb functions, but it keeps > missing catching the abend. > > > > Here is the "usual" setup to duplicate the abend: > > > > 1. USS logon from ssh on a Windows box at my home into the Zxplore > system. Zxplore runs the bash shell as your default shell. > > 2. Execute "python3 db_fetch_both_err-2.py" > > 3. This reliably generates a S0C4 abend deep inside the python > runtime code in something named TOROLABA the first time the python script > tries to use the ibmdb function "fetch_both(...)". > > > > I can supply both a copy of the python script and the exact text of the > abend messages if it helps you to help me, but the real question we have is > how should a SLIP trap be set up to catch a S0C4 abend in a forked USS > address space? The only dump that seems to be generated is a CEEDUMP in my > $HOME directory on Zxplore. > > > > I have also tried a JCL executing BPXBATCH to run the exact same python > script, and that also does not trigger the SLIP they recently set to match > the JOB name of that JCL. SHAREAS=MUST does not work with the bash shell, > so the python process is (I believe) being forked to a new AS by BPXBATCH. > > > > Any and all assistance to help us catch this abend and generate the > SVCDUMP that the ibmdb team have requested to help solve the root cause > would be much appreciated. > > > > Peter > > -- > > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
