Interesting. I'll look into SMP/E's processing to see if it can easily identify the ddname in the message. But in the mean time, here are some thoughts:
You say the same APPLY runs fine with no out of space errors when you run it from JCL. I suspect there are one or more data sets allocated by DD statements in your JCL, which z/OSMF or SMP/E are allocating differently. For example, does your JCL have DD statements for temporary data sets like SYSUT1 - 4 and SMPWRK1 - 6? And does your target zone contain DDDEF entries for those same ddnames? In the absence of a DD statement, SMP/E uses a DDDEF entry to allocate a data set. Therefore, that's the first area I would check, to make sure your DDDEF entries for these temporary data sets are defined with space equivalent to your DD statements. Based on the SMP/E messages, the out of space occurs after JCLIN processing, which leads me to believe the likely culprit is one or more of these work data sets, SYSUTx or SMPWRKx.
The other area to check are output data sets, like SMPRPT. Your JCL likely defines these data sets as SYSOUT, but z/OSMF allocates temporary data sets so it can capture and save the output. The Temporary Data Set Allocation Parameters on the Settings page allow you to specify volumes or SMS classes to allocate these temporary output data sets, so maybe some adjustment there will help.
Additionally, the GIM43201T message indicates that SMP/E itself was writing to a data set when the out of space was detected. This is important to note because that means it was not a utility program like IEBCOPY or IEWL for example that was writing, so the out of space is likely not a target or distlib data set.
Hopefully the problem is with one of the SMP/E work data sets (SYSUTx or SMPWRKx). Please post back if you are still stuck, or if you figure out the culprit.
------------------------------
Kurt Quackenbush
IBM, z/OS SMP/E and z/OSMF Software Management
kurtq@us.ibm.com------------------------------
Original Message:
Sent: Wed February 04, 2026 08:15 AM
From: Murat Bissembayev
Subject: Getting E37 when trying to APPLY maintenance via Software Update.
Thanks for checking, Kurt!
No there no pointers to specific dataset and this is why this thread was created. Below is what we see in SMPOUT.
GIM41802I JCLIN PROCESSING WAS SUCCESSFUL FOR SYSMOD LU17911.
GIM41802I JCLIN PROCESSING WAS SUCCESSFUL FOR SYSMOD LU18008.
GIM41802I JCLIN PROCESSING WAS SUCCESSFUL FOR SYSMOD LU18217.
GIM41802I JCLIN PROCESSING WAS SUCCESSFUL FOR SYSMOD LU18510.
GIM43201T ** PROGRAM GIMSMP FAILED WITH A SYSTEM ABEND CODE OF 0E37.
------------------------------
Murat Bissembayev
Original Message:
Sent: Tue February 03, 2026 03:41 PM
From: Kurt Quackenbush
Subject: Getting E37 when trying to APPLY maintenance via Software Update.
ABEND E37 is a data set out of space condition. Are there any other messages to indicate which data set ran out of space? What SMP/E messages precede GIM43201T?
------------------------------
Kurt Quackenbush
IBM, z/OS SMP/E and z/OSMF Software Management
kurtq@us.ibm.com
Original Message:
Sent: Tue February 03, 2026 03:26 PM
From: Murat Bissembayev
Subject: Getting E37 when trying to APPLY maintenance via Software Update.
Issue appears only if use z/OSMF Software Update, when run APPLY using jcl from TSO all works without errors. No changes to CSI were made between those two runs. The error doesn't point to any specific dataset. I was thinking that it should fail same way when run via jcl. Is there any settings in z/OSMF UI that control that? I saw 'Temporary Data Set Allocation Parameters' field but not sure if that right place
GIM43201T ** PROGRAM GIMSMP FAILED WITH A SYSTEM ABEND CODE OF 0E37.
Appreciate any help.
------------------------------
Cheers,
Murat
------------------------------