The CPU-cost associated with STOPX37 shows up as INIT CPU-TIME, for each 
initialization/active-step allocation - with significant user/admin 
flexibility, of course at a cost of CPU-consumption.

Along similar cause/effect to some degree/level, SMS DATACLAS functionality 
(less flexible than STOPX37) using SPACE CONSTRAINT RELIEF (SCR) along with DVC 
(dynamic ADDVOL requests, if/where possible).

Scott Barry
SBBTech LLC


On Tue, 23 Jun 2026 21:58:17 -0500, Paul Feller <[email protected]> wrote:

>Joe, the data in the dataset is not affected.  The executing program does not 
>know that the X37 software stepped in to do the recovery process.  If I recall 
>correctly with both of the different X37 software I worked with over the years 
>there are rules you can setup to try to handle things.  
>
>Now these types of software do have limits.  As an example they can't help if 
>there is not any DASD space to extend a dataset or you have reached the limit 
>for how many volumes a dataset can extend across.
>
>
>Paul
>
>-----Original Message-----
>From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
>Joseph Reichman
>Sent: Tuesday, June 23, 2026 09:01 PM
>To: [email protected]
>Subject: Re: Automating fix for B37 from a recovery program
>
>So when get a x 37 type error what happens to the data that’s already written 
>to the file is it intact
>
>
>Can you close the dataset reallocate and continue
>
>Doesn’t sound like it but I guess I can ask
>
>
>
>
>Joe Reichman
>
>On Tue, Jun 23, 2026 at 9:57 PM Paul Feller < 
>[email protected]> wrote:
>
>> As Steve said that is what X37 type software does.  The X37 software 
>> steps in to determine if it should try to help recover from a X37 
>> error.  Now if that type of software is not in the cards, then maybe 
>> looking at how datasets are allocated might be a way to help reduce X37 
>> errors.
>>
>> If SMS is in the picture, you could look at some type of general rule 
>> around volume count.  The down side to that is it takes up room in the 
>> TIOT below the line.  If you open/allocate lots of datasets you might 
>> run out of room in the TIOT.  If you are pushing all TIOT stuff above 
>> the line then space may not be an issue.
>>
>> Keeping with SMS maybe look at dataset allocation stuff.  It comes 
>> down to the size of the primary and secondary allocation.  Maybe some 
>> datasets are better off with a large primary and small secondary.  
>> While other datasets might work better with a small primary and large 
>> secondary.
>>
>> As far as I know SMS changes really only come into play during dataset 
>> allocation.  Will not help with datasets already allocated.
>>
>> Paul
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List <[email protected]> On 
>> Behalf Of Steve Beaver
>> Sent: Tuesday, June 23, 2026 07:45 PM
>> To: [email protected]
>> Subject: Re: Automating fix for B37 from a recovery program
>>
>> What you’re describing and wanting to do is exactly how the product 
>> stop X
>> 37 works
>>
>>
>>
>> Sent from my iPhone
>>
>> No one said I could type with one thumb
>>
>> > On Jun 23, 2026, at 19:39, Joseph Reichman <
>> [email protected]> wrote:
>> >
>> > I was able to verify what Kurtz Q told me earlier that SDWAGR02 
>> > Points  to the dcb in a recovery program
>> >
>> > That being said is it possible I guess via SVC 99 to fix I.e 
>> > reallocate a dataset from a recovery program
>> >
>> > Thanks
>> > --------------------------------------------------------------------
>> > -- 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
>
>----------------------------------------------------------------------
>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

Reply via email to