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
<[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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
