Here are our LE settings. It seems DYNDUMP is significant, you can specify this
as a runtime option https://www.ibm.com/docs/en/zos/2.4.0?topic=ulero-dyndump.
CEEDUMP(60,SYSOUT=*,FREE=END,
SPIN=UNALLOC)
DYNDUMP(*USERID.CEEDUMP,DYNAMIC,TDUMP)
ENVAR("TZ=GMT-8")
NATLANG(ENU)
TERMTHDACT(UADUMP,,)
Peter,
I strongly suspect this abend is due to a build issue. When Ibm_db is installed
using pip3 it is compiled from source as it’s a cross-platform library. As I
previously mentioned, there may be compatibility issues depending on how the
environment is setup. I urge you to reach out to the admins and ask them how
they built this package. I notice that you have opened an issue in Github and
that the Rocket devs are involved. Before we start diving into dumps can you
please confirm the environment is sound first.
https://www.ibm.com/docs/en/python-zos/3.9?topic=information-using-distutils-module
>> Note: There might be compatibility issues when mixing xlc and
xlclang for compiled code and thus only one should be used consistently for
building and linking modules.
> On 16 Jul 2023, at 9:18 am, David Crayford <dcrayf...@gmail.com> wrote:
>
> Are you sure you don’t have a dump? LE is usually configured with
> TERMTHDACT(UADUMP) which creates a transaction (SYSMDUMP). Look in the
> syslog. Set the following environment variable to enable dumps by default.
>
> export _CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) TERMTHDACT(UADUMP)
> ABTERMENC(ABEND)
>
> FYI, ibm_db is in beta status so I wouldn’t consider using it for real work.
> We had a look at this abend a few weeks ago but couldn’t re-create it. It
> only happens with Python3.9 which we don’t have installed. We suspected an
> ABI problem where the package was built using a different compiler to the
> Python VM. The IBM XL C compiler is not compatible with IBM Open XL C/C++.
>
>> On 16 Jul 2023, at 2:17 am, Farley, Peter
>> <0000031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
>> Jon Perryman
>> Sent: Saturday, July 15, 2023 11:28 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> 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:0000031df298a9da-dmarc-requ...@listserv.ua.edu> 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 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
