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
