I don't think TOROLABA is a module name. Complete guess on my part but Peter
is using zXplore which makes me think this is something to do with labs as in
TORO LAB A. Does python on z compile an actual executable or is it more akin to
a bytecode generator? The message implies something like object.c has been
created and probably will be compiled. It's not clear what TOROLABA becomes but
if it's not a module, then Peter will need to wait for another attempt. If he
had console access, I would definitely say give it a try.
On Saturday, July 15, 2023 at 01:48:16 PM PDT, Charles Hardee
<[email protected]> wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
