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. 

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?

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. 

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.

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?

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. 

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.

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.

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?

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. 

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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. 

Murat, z/OSMF only allocates sequential data sets to contain output, such as SMPOUT, SMPRPT, SYSPRINT, etc.  SMPWRK3 is not a sequential output data set, therefore, it is not allocated by z/OSMF.  SMPWRK3 is a partitioned data set used to contain module objects from PTFs or from assembled source.  When z/OSMF calls SMP/E the SMPWRK3 data set is allocated by SMP/E using a DDDEF entry in the target zone.  How does this DDDEF entry differ from the DD statement for SMPWRK3 in your JCL?  Compare them and update the DDDEF entry as necessary to match the DD statement.

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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. 

sorry for dummy questions. 

Initially i was thinking that z/OSMF use what is defined in CSI and seems that is correct. The issue appears in one environment and I need to check with person who owns that. 
Some time ago we saw similar issue in own environment, but that was fixed by manual update of DDDEF and later product shipped sample jcl as a hold data action that do updates in CSI including SMPWRK3. In our following test that all worked. 

So now we have one place where that issue pop-up again, the SMPWRK3 already was updated and that makes that issue odd. 

I will check on that and get back to you. 
Btw just curious if we can have zoom call to discuss this subject? 

Murat, z/OSMF only allocates sequential data sets to contain output, such as SMPOUT, SMPRPT, SYSPRINT, etc.  SMPWRK3 is not a sequential output data set, therefore, it is not allocated by z/OSMF.  SMPWRK3 is a partitioned data set used to contain module objects from PTFs or from assembled source.  When z/OSMF calls SMP/E the SMPWRK3 data set is allocated by SMP/E using a DDDEF entry in the target zone.  How does this DDDEF entry differ from the DD statement for SMPWRK3 in your JCL?  Compare them and update the DDDEF entry as necessary to match the DD statement.

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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. 

Hi Kurt,

       I'm the person having this problem. It's happened twice now - this year and last year when applying our annual maintenance drop on software. The temporary dataset having the issue is SMPWRK3. The z/OSMF attempt to apply fixes fails with the B37 error. What I have done to bypass the error is code a large space size in the DDDEF for SMPWRK3 in the target zone CSI then run some JCL (with no SMPWRK3 DD). Even after changing the DDDEF to have the increase in size I still get the z/OSMF apply failing with the same B37.

From my experience I think there are 2 problems using z/OSMF....   1. z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?   2. z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?

cheers

Roddy Manson

sorry for dummy questions. 

Initially i was thinking that z/OSMF use what is defined in CSI and seems that is correct. The issue appears in one environment and I need to check with person who owns that. 
Some time ago we saw similar issue in own environment, but that was fixed by manual update of DDDEF and later product shipped sample jcl as a hold data action that do updates in CSI including SMPWRK3. In our following test that all worked. 

So now we have one place where that issue pop-up again, the SMPWRK3 already was updated and that makes that issue odd. 

I will check on that and get back to you. 
Btw just curious if we can have zoom call to discuss this subject? 

Murat, z/OSMF only allocates sequential data sets to contain output, such as SMPOUT, SMPRPT, SYSPRINT, etc.  SMPWRK3 is not a sequential output data set, therefore, it is not allocated by z/OSMF.  SMPWRK3 is a partitioned data set used to contain module objects from PTFs or from assembled source.  When z/OSMF calls SMP/E the SMPWRK3 data set is allocated by SMP/E using a DDDEF entry in the target zone.  How does this DDDEF entry differ from the DD statement for SMPWRK3 in your JCL?  Compare them and update the DDDEF entry as necessary to match the DD statement.

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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. 

Roddy, regarding your questions:

Q:  z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?
A:  The issue here is not with z/OSMF but with SMP/E; SMP/E is not identifying the data set.  As I mentioned in an earlier response, I will investigate if SMP/E can be updated to identify the failing data set.

Q:  z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?
A:  z/OSMF does not allocate SMPWRK3.  SMP/E allocates SMPWRK3 using information from a DDDEF entry.  The original problem reported was an E37 ABEND, but now you're getting B37.  Is that correct or is that a typo?  I ask, because B37 means the data set was not allocated large enough, whereas E37 means there is not enough space on the volume.  So depending on which ABEND you are getting, can you adjust the SMPWRK3 DDDEF entry to either specify a larger primary and/or secondary allocation, or specify a different volume that has more available space?

If you're still stuck, please reach out to me via email so we can continue this in some more detail.

Hi Kurt,

       I'm the person having this problem. It's happened twice now - this year and last year when applying our annual maintenance drop on software. The temporary dataset having the issue is SMPWRK3. The z/OSMF attempt to apply fixes fails with the B37 error. What I have done to bypass the error is code a large space size in the DDDEF for SMPWRK3 in the target zone CSI then run some JCL (with no SMPWRK3 DD). Even after changing the DDDEF to have the increase in size I still get the z/OSMF apply failing with the same B37.

From my experience I think there are 2 problems using z/OSMF....   1. z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?   2. z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?

cheers

Roddy Manson

sorry for dummy questions. 

Initially i was thinking that z/OSMF use what is defined in CSI and seems that is correct. The issue appears in one environment and I need to check with person who owns that. 
Some time ago we saw similar issue in own environment, but that was fixed by manual update of DDDEF and later product shipped sample jcl as a hold data action that do updates in CSI including SMPWRK3. In our following test that all worked. 

So now we have one place where that issue pop-up again, the SMPWRK3 already was updated and that makes that issue odd. 

I will check on that and get back to you. 
Btw just curious if we can have zoom call to discuss this subject? 

Murat, z/OSMF only allocates sequential data sets to contain output, such as SMPOUT, SMPRPT, SYSPRINT, etc.  SMPWRK3 is not a sequential output data set, therefore, it is not allocated by z/OSMF.  SMPWRK3 is a partitioned data set used to contain module objects from PTFs or from assembled source.  When z/OSMF calls SMP/E the SMPWRK3 data set is allocated by SMP/E using a DDDEF entry in the target zone.  How does this DDDEF entry differ from the DD statement for SMPWRK3 in your JCL?  Compare them and update the DDDEF entry as necessary to match the DD statement.

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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. 

Hi Kurt,

   sorry for the late reply. Following on in the questions:

    1. Did you get any where with the problem where using z/OSMF we dont get the failing datasets identified?

  2. Looking back the error message was a B37. I'm still unconvinced that this problem goes away if I just allocated a larger dataset in the DDDEF for it in SMP/e - my experience is that if I do this and then go back to z/OSMF it still fails. I say this as we got this problem last year when I then increased the DDDEF but had to run JCL to get it working and then this year the same issue occurred needing the same solution.

cheers

Roddy

Roddy, regarding your questions:

Q:  z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?
A:  The issue here is not with z/OSMF but with SMP/E; SMP/E is not identifying the data set.  As I mentioned in an earlier response, I will investigate if SMP/E can be updated to identify the failing data set.

Q:  z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?
A:  z/OSMF does not allocate SMPWRK3.  SMP/E allocates SMPWRK3 using information from a DDDEF entry.  The original problem reported was an E37 ABEND, but now you're getting B37.  Is that correct or is that a typo?  I ask, because B37 means the data set was not allocated large enough, whereas E37 means there is not enough space on the volume.  So depending on which ABEND you are getting, can you adjust the SMPWRK3 DDDEF entry to either specify a larger primary and/or secondary allocation, or specify a different volume that has more available space?

If you're still stuck, please reach out to me via email so we can continue this in some more detail.

Hi Kurt,

       I'm the person having this problem. It's happened twice now - this year and last year when applying our annual maintenance drop on software. The temporary dataset having the issue is SMPWRK3. The z/OSMF attempt to apply fixes fails with the B37 error. What I have done to bypass the error is code a large space size in the DDDEF for SMPWRK3 in the target zone CSI then run some JCL (with no SMPWRK3 DD). Even after changing the DDDEF to have the increase in size I still get the z/OSMF apply failing with the same B37.

From my experience I think there are 2 problems using z/OSMF....   1. z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?   2. z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?

cheers

Roddy Manson

sorry for dummy questions. 

Initially i was thinking that z/OSMF use what is defined in CSI and seems that is correct. The issue appears in one environment and I need to check with person who owns that. 
Some time ago we saw similar issue in own environment, but that was fixed by manual update of DDDEF and later product shipped sample jcl as a hold data action that do updates in CSI including SMPWRK3. In our following test that all worked. 

So now we have one place where that issue pop-up again, the SMPWRK3 already was updated and that makes that issue odd. 

I will check on that and get back to you. 
Btw just curious if we can have zoom call to discuss this subject? 

Murat, z/OSMF only allocates sequential data sets to contain output, such as SMPOUT, SMPRPT, SYSPRINT, etc.  SMPWRK3 is not a sequential output data set, therefore, it is not allocated by z/OSMF.  SMPWRK3 is a partitioned data set used to contain module objects from PTFs or from assembled source.  When z/OSMF calls SMP/E the SMPWRK3 data set is allocated by SMP/E using a DDDEF entry in the target zone.  How does this DDDEF entry differ from the DD statement for SMPWRK3 in your JCL?  Compare them and update the DDDEF entry as necessary to match the DD statement.

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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. 

Q:  Did you get any where with the problem where using z/OSMF we dont get the failing datasets identified?
A:  Yes, I see where in SMP/E I'll have to make some changes to capture the ddname of the out-of-space data set.  Be that as it may, I won't have a fix done very soon, so I'd like to help you make progress and identify your current out-of-space data set.

Q:  Looking back the error message was a B37.  I'm still unconvinced that this problem goes away if I just allocated a larger dataset in the DDDEF for it in SMP/e.
A:  No, sorry, the very first message in this thread indicated E37, which means not enough space on the volume.

GIM43201T ** PROGRAM GIMSMP FAILED WITH A SYSTEM ABEND CODE OF 0E37.

Sorry I haven't been very convincing so far.  Having said that, trust me when I say, if the failing data set is OTHER THAN an output data set like SMPOUT, SMPRPT, SYSPRINT, etc, then the data set is allocated by SMP/E using the DDDEF entry in the target zone, not by z/OSMF.  Therefore, updating the DDDEF entry can fix the out-of-space error.  However, if the failing data set is SMPRPT or similar, then the data set is allocated by z/OSMF using information you provide for temporary data sets on the Software Update Settings page.

If you'd like my assistance in debugging this further I would like to see the job output for when you run the APPLY using JCL and you do NOT get an out of space error.  You can send that output to me directly:  kurtq@us.ibm.com.  If you choose not to pursue this further, that's OK too.

Hi Kurt,

   sorry for the late reply. Following on in the questions:

    1. Did you get any where with the problem where using z/OSMF we dont get the failing datasets identified?

  2. Looking back the error message was a B37. I'm still unconvinced that this problem goes away if I just allocated a larger dataset in the DDDEF for it in SMP/e - my experience is that if I do this and then go back to z/OSMF it still fails. I say this as we got this problem last year when I then increased the DDDEF but had to run JCL to get it working and then this year the same issue occurred needing the same solution.

cheers

Roddy

Roddy, regarding your questions:

Q:  z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?
A:  The issue here is not with z/OSMF but with SMP/E; SMP/E is not identifying the data set.  As I mentioned in an earlier response, I will investigate if SMP/E can be updated to identify the failing data set.

Q:  z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?
A:  z/OSMF does not allocate SMPWRK3.  SMP/E allocates SMPWRK3 using information from a DDDEF entry.  The original problem reported was an E37 ABEND, but now you're getting B37.  Is that correct or is that a typo?  I ask, because B37 means the data set was not allocated large enough, whereas E37 means there is not enough space on the volume.  So depending on which ABEND you are getting, can you adjust the SMPWRK3 DDDEF entry to either specify a larger primary and/or secondary allocation, or specify a different volume that has more available space?

If you're still stuck, please reach out to me via email so we can continue this in some more detail.

Hi Kurt,

       I'm the person having this problem. It's happened twice now - this year and last year when applying our annual maintenance drop on software. The temporary dataset having the issue is SMPWRK3. The z/OSMF attempt to apply fixes fails with the B37 error. What I have done to bypass the error is code a large space size in the DDDEF for SMPWRK3 in the target zone CSI then run some JCL (with no SMPWRK3 DD). Even after changing the DDDEF to have the increase in size I still get the z/OSMF apply failing with the same B37.

From my experience I think there are 2 problems using z/OSMF....   1. z/OSMF output does not identify the failing B37 dataset. Why is this? Can it be sorted?   2. z/OSMF appears to be using its own definitions for SMPWRK3 as it fails even after the increase in size to DDDEF SMPWRK3 in the target zone. Any ideas why that is?

cheers

Roddy Manson

sorry for dummy questions. 

Initially i was thinking that z/OSMF use what is defined in CSI and seems that is correct. The issue appears in one environment and I need to check with person who owns that. 
Some time ago we saw similar issue in own environment, but that was fixed by manual update of DDDEF and later product shipped sample jcl as a hold data action that do updates in CSI including SMPWRK3. In our following test that all worked. 

So now we have one place where that issue pop-up again, the SMPWRK3 already was updated and that makes that issue odd. 

I will check on that and get back to you. 
Btw just curious if we can have zoom call to discuss this subject? 

Murat, z/OSMF only allocates sequential data sets to contain output, such as SMPOUT, SMPRPT, SYSPRINT, etc.  SMPWRK3 is not a sequential output data set, therefore, it is not allocated by z/OSMF.  SMPWRK3 is a partitioned data set used to contain module objects from PTFs or from assembled source.  When z/OSMF calls SMP/E the SMPWRK3 data set is allocated by SMP/E using a DDDEF entry in the target zone.  How does this DDDEF entry differ from the DD statement for SMPWRK3 in your JCL?  Compare them and update the DDDEF entry as necessary to match the DD statement.

Hi Kurt, 

we suspect that dddef that cause the issue is SMPWRK3. So seems that z/OSMF has own temp files and we would like to know if there a way to manage those(z/OSMF one) via z/OSMF UI. 

Thanks,
Murat. 

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.

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.

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?

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.