Workfile sizing in Db2 on Z (Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)

Philip Sevetson

Workfile sizing in Db2 on Z (Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)
Can someone explain to me the justification for creating workfiles with nonzero secondary extents?

The workfile allocations at every site where I’ve ever worked have been zero. You either have enough space for a given large result set or you don’t, and leaving it as an “unallocated” quantity doesn’t seem to me to help.

If the space is unallocated, then the implication is that it might need to be used for something else. If it’s being used for something else (presumably another temporary file), your system’s capacity to handle large queries is curtailed and **you won’t know about it until a query, which used to work, fails for a refused request for more DASD in your workfile**.

If your argument is that you might need it for a surprise huge query, the question is, again, how does this help? You extend a lot, and maybe you have enough space and maybe you don’t… but after the extending, you now have the _new_ “We need this much space” value in your workfiles. Either you give back the secondaries as Gabriel has described (you do monitor your workfiles and regularly drop and recreate them, right? Anyone?), or you leave them out there and you should have been allocating all of this all along!!

What am I missing, here? What’s the benefit of sizing your workfiles as start-small-and-add, instead of start-with-as-much-space-as-you-are-allowed?

-phil sevetson


Philip Sevetson
Computer Systems Manager
City of New York / FISA-OPA
[login to unmask email]<mailto:[login to unmask email]>

From: Gabriel Pelly <[login to unmask email]>
Sent: Tuesday, June 9, 2020 6:06 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!


I started having this type of issue with DB2 V10, where the DB2 workfiles gobbled up all available workfile dasd space and did not release it. It was caused by a few transactions that could not be changed.

My bandaid, was to drop the excessively sized worfile(s) and re-create them. As they are workfiles, they can be dropped without fear of losing data- assuming they are not 'in use' at the time of drop.

I eventually wrote a REXX to perform the process in batch, run weekly. Let me know if you are interested in it.

BTW: At DB2 V10 (I dont believe it has changed), you should have some workfiles defined that have 0 secondary space, and some with secondary space for each of the 4K and 32K workfiles groups.

Cheers

Gabriel

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Philip Sevetson

Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)
(in response to Philip Sevetson)
Hah. One small but terribly significant change on reread.


Philip Sevetson
Computer Systems Manager
FISA-OPA
5 Manhattan West
New York, NY 10001
[login to unmask email]<mailto:[login to unmask email]>
917-991-7052 m
212-857-1659 f
[cid:[login to unmask email]

From: Sevetson, Phil <[login to unmask email]>
Sent: Wednesday, June 10, 2020 9:24 AM
To: [login to unmask email]
Subject: [DB2-L] - Workfile sizing in Db2 on Z (RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)

Can someone explain to me the justification for creating workfiles with nonzero secondary extents?

The workfile secondary allocations at every site where I’ve ever worked have been zero. You either have enough space for a given large result set or you don’t, and leaving it as an “unallocated” quantity doesn’t seem to me to help.

If the space is unallocated, then the implication is that it might need to be used for something else. If it’s being used for something else (presumably another temporary file), your system’s capacity to handle large queries is curtailed and **you won’t know about it until a query, which used to work, fails for a refused request for more DASD in your workfile**.

If your argument is that you might need it for a surprise huge query, the question is, again, how does this help? You extend a lot, and maybe you have enough space and maybe you don’t… but after the extending, you now have the _new_ “We need this much space” value in your workfiles. Either you give back the secondaries as Gabriel has described (you do monitor your workfiles and regularly drop and recreate them, right? Anyone?), or you leave them out there and you should have been allocating all of this all along!!

What am I missing, here? What’s the benefit of sizing your workfiles as start-small-and-add, instead of start-with-as-much-space-as-you-are-allowed?

-phil sevetson


Philip Sevetson
Computer Systems Manager
City of New York / FISA-OPA
[login to unmask email]<mailto:[login to unmask email]>

From: Gabriel Pelly <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Tuesday, June 9, 2020 6:06 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!


I started having this type of issue with DB2 V10, where the DB2 workfiles gobbled up all available workfile dasd space and did not release it. It was caused by a few transactions that could not be changed.

My bandaid, was to drop the excessively sized worfile(s) and re-create them. As they are workfiles, they can be dropped without fear of losing data- assuming they are not 'in use' at the time of drop.

I eventually wrote a REXX to perform the process in batch, run weekly. Let me know if you are interested in it.

BTW: At DB2 V10 (I dont believe it has changed), you should have some workfiles defined that have 0 secondary space, and some with secondary space for each of the 4K and 32K workfiles groups.

Cheers

Gabriel

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
Attachments

  • image001.png (3.3k)

Jim Tonchick

Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)
(in response to Philip Sevetson)
The practice of setting the work file secondary allocation to zero gies back decades.  A poorly code query could quickly monopolize all the temporary workspace and impact the production online workload.  
Preventing the work files from expanding, triggers a temporary "out of space" situation and the runaway query is killed with an error message.  The excess space consumed by the runaway query is released as its unit of work is rolled back.  This keeps any impact to the online workload to a minimum.  Eventually, the user who submitted the offending query would complain to a DBA giving the DBA the opportunity to educate the user on how to write a more efficient query.
Jim Tonchick
Senior Database Administrator, retired 

-----Original Message-----
From: Sevetson, Phil <[login to unmask email]>
To: [login to unmask email] <[login to unmask email]>
Sent: Wed, Jun 10, 2020 08:24 AM
Subject: [DB2-L] - Workfile sizing in Db2 on Z (RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)


&lt;!-- #yiv3138997370 _filtered {} _filtered {} #yiv3138997370 #yiv3138997370 p.yiv3138997370MsoNormal, #yiv3138997370 li.yiv3138997370MsoNormal, #yiv3138997370 div.yiv3138997370MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman", serif;} #yiv3138997370 a:link, #yiv3138997370 span.yiv3138997370MsoHyperlink {color:blue;text-decoration:underline;} #yiv3138997370 a:visited, #yiv3138997370 span.yiv3138997370MsoHyperlinkFollowed {color:purple;text-decoration:underline;} #yiv3138997370 p {margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:"Times New Roman", serif;} #yiv3138997370 p.yiv3138997370msonormal0, #yiv3138997370 li.yiv3138997370msonormal0, #yiv3138997370 div.yiv3138997370msonormal0 {margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:"Times New Roman", serif;} #yiv3138997370 span.yiv3138997370EmailStyle19 {font-family:"Calibri", sans-serif;color:#1F497D;} #yiv3138997370 .yiv3138997370MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {} #yiv3138997370 div.yiv3138997370WordSection1 {} --&gt;
Can someone explain to me the justification for creating workfiles with nonzero secondary extents?

 

The workfile allocations at every site where I’ve ever worked have been zero.  You either have enough space for a given large result set or you don’t, and leaving it as an “unallocated” quantity doesn’t seem to me to help.

 

If the space is unallocated, then the implication is that it might need to be used for something else. If it’s being used for something else (presumably another temporary file), your system’s capacity to handle large queries is curtailed and **you won’t know about it until a query, which used to work, fails for a refused request for more DASD in your workfile**. 

 

If your argument is that you might need it for a surprise huge query, the question is, again, how does this help? You extend a lot, and maybe you have enough space and maybe you don’t… but after the extending, you now have the _new_ “We need this much space” value in your workfiles.  Either you give back the secondaries as Gabriel has described (you do monitor your workfiles and regularly drop and recreate them, right?  Anyone?), or you leave them out there and you should have been allocating all of this all along!!

 

What am I missing, here?  What’s the benefit of sizing your workfiles as start-small-and-add, instead of start-with-as-much-space-as-you-are-allowed?

 

-phil sevetson

 

 

Philip Sevetson

Computer Systems Manager

City of New York / FISA-OPA

[login to unmask email]

 

From: Gabriel Pelly <[login to unmask email]>
Sent: Tuesday, June 9, 2020 6:06 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!

 

I started having this type of issue with DB2 V10, where the DB2 workfiles gobbled up all available workfile dasd space and did not release it. It was caused by a few transactions that could not be changed.

My bandaid, was to drop the excessively sized worfile(s) and re-create them. As they are workfiles, they can be dropped without fear of losing data- assuming they are not 'in use' at the time of drop.

I eventually wrote a REXX to perform the process in batch, run weekly. Let me know if you are interested in it.

BTW: At DB2 V10 (I dont believe it has changed), you should have some workfiles defined that have 0 secondary space, and some with secondary space for each of the 4K and 32K workfiles groups.

Cheers

Gabriel

 
-----End Original Message-----**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription  

This email has been sent to: [login to unmask email]
Try BCV5, the BCV5 Masking Tool, & XDM a rapid Refresh/Clone/TDM Suite for Db2 z & distributed.
DBARS -Audit,record,& block Db2 accesses to sensitive data real-time, NO audit trace or log required
http://www.ESAIGroup.com/IDUG



Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2

Philip Sevetson

Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)
(in response to Jim Tonchick)
Jim,

Yeah, that works for me. I’m just puzzled over why some folks do it another way.

It seems to me that zero-secondary on workfiles is a clear best practice. However - obviously there’s another school of thought, and I’m hoping someone can explain it to me clearly enough to understand.

-phil


Philip Sevetson
Computer Systems Manager
FISA-OPA
5 Manhattan West
New York, NY 10001
[login to unmask email]<mailto:[login to unmask email]>
917-991-7052 m
212-857-1659 f
[cid:[login to unmask email]

From: Jim Tonchick <[login to unmask email]>
Sent: Wednesday, June 10, 2020 9:36 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)

The practice of setting the work file secondary allocation to zero gies back decades. A poorly code query could quickly monopolize all the temporary workspace and impact the production online workload.

Preventing the work files from expanding, triggers a temporary "out of space" situation and the runaway query is killed with an error message. The excess space consumed by the runaway query is released as its unit of work is rolled back. This keeps any impact to the online workload to a minimum. Eventually, the user who submitted the offending query would complain to a DBA giving the DBA the opportunity to educate the user on how to write a more efficient query.

Jim Tonchick
Senior Database Administrator, retired


-----Original Message-----
From: Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>>
To: [login to unmask email]<mailto:[login to unmask email]> <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Wed, Jun 10, 2020 08:24 AM
Subject: [DB2-L] - Workfile sizing in Db2 on Z (RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)


Can someone explain to me the justification for creating workfiles with nonzero secondary extents?



The workfile allocations at every site where I’ve ever worked have been zero. You either have enough space for a given large result set or you don’t, and leaving it as an “unallocated” quantity doesn’t seem to me to help.



If the space is unallocated, then the implication is that it might need to be used for something else. If it’s being used for something else (presumably another temporary file), your system’s capacity to handle large queries is curtailed and **you won’t know about it until a query, which used to work, fails for a refused request for more DASD in your workfile**.



If your argument is that you might need it for a surprise huge query, the question is, again, how does this help? You extend a lot, and maybe you have enough space and maybe you don’t… but after the extending, you now have the _new_ “We need this much space” value in your workfiles. Either you give back the secondaries as Gabriel has described (you do monitor your workfiles and regularly drop and recreate them, right? Anyone?), or you leave them out there and you should have been allocating all of this all along!!



What am I missing, here? What’s the benefit of sizing your workfiles as start-small-and-add, instead of start-with-as-much-space-as-you-are-allowed?



-phil sevetson





Philip Sevetson

Computer Systems Manager

City of New York / FISA-OPA

[login to unmask email]<mailto:[login to unmask email]>



From: Gabriel Pelly <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Tuesday, June 9, 2020 6:06 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!



I started having this type of issue with DB2 V10, where the DB2 workfiles gobbled up all available workfile dasd space and did not release it. It was caused by a few transactions that could not be changed.

My bandaid, was to drop the excessively sized worfile(s) and re-create them. As they are workfiles, they can be dropped without fear of losing data- assuming they are not 'in use' at the time of drop.

I eventually wrote a REXX to perform the process in batch, run weekly. Let me know if you are interested in it.

BTW: At DB2 V10 (I dont believe it has changed), you should have some workfiles defined that have 0 secondary space, and some with secondary space for each of the 4K and 32K workfiles groups.

Cheers

Gabriel


-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
Attachments

  • image001.png (3.3k)

Chad Walmer

Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)
(in response to Philip Sevetson)
Where is the “like” button for this post? :-) I agree with Phil and I believe this has been discussed before in the past with what I thought was the same conclusion (but apparently not as it’s still being discussed.) Seems like a no brainer to just allocate to the amount of storage you want dedicated to sorting (scrollable cursors, DGTTs, etc) and leave it at that. No extra work dropping and consolidating work files and since you presumably already have the disk space earmarked for this purpose why not just allocate it? And if you happen to have it mixed in with other storage, are you OK with what probably is a rogue query that should not have run anyway causing problems to the applications that use that shared storage?

Chad Walmer

From: Sevetson, Phil [mailto:[login to unmask email]
Sent: Wednesday, June 10, 2020 9:25 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)

Hah. One small but terribly significant change on reread.


Philip Sevetson
Computer Systems Manager
FISA-OPA
5 Manhattan West
New York, NY 10001
[login to unmask email]<mailto:[login to unmask email]>
917-991-7052 m
212-857-1659 f
[cid:[login to unmask email]

From: Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Wednesday, June 10, 2020 9:24 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Workfile sizing in Db2 on Z (RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)

Can someone explain to me the justification for creating workfiles with nonzero secondary extents?

The workfile secondary allocations at every site where I’ve ever worked have been zero. You either have enough space for a given large result set or you don’t, and leaving it as an “unallocated” quantity doesn’t seem to me to help.

If the space is unallocated, then the implication is that it might need to be used for something else. If it’s being used for something else (presumably another temporary file), your system’s capacity to handle large queries is curtailed and **you won’t know about it until a query, which used to work, fails for a refused request for more DASD in your workfile**.

If your argument is that you might need it for a surprise huge query, the question is, again, how does this help? You extend a lot, and maybe you have enough space and maybe you don’t… but after the extending, you now have the _new_ “We need this much space” value in your workfiles. Either you give back the secondaries as Gabriel has described (you do monitor your workfiles and regularly drop and recreate them, right? Anyone?), or you leave them out there and you should have been allocating all of this all along!!

What am I missing, here? What’s the benefit of sizing your workfiles as start-small-and-add, instead of start-with-as-much-space-as-you-are-allowed?

-phil sevetson


Philip Sevetson
Computer Systems Manager
City of New York / FISA-OPA
[login to unmask email]<mailto:[login to unmask email]>

From: Gabriel Pelly <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Tuesday, June 9, 2020 6:06 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!


I started having this type of issue with DB2 V10, where the DB2 workfiles gobbled up all available workfile dasd space and did not release it. It was caused by a few transactions that could not be changed.

My bandaid, was to drop the excessively sized worfile(s) and re-create them. As they are workfiles, they can be dropped without fear of losing data- assuming they are not 'in use' at the time of drop.

I eventually wrote a REXX to perform the process in batch, run weekly. Let me know if you are interested in it.

BTW: At DB2 V10 (I dont believe it has changed), you should have some workfiles defined that have 0 secondary space, and some with secondary space for each of the 4K and 32K workfiles groups.

Cheers

Gabriel

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
________________________________
Attachment Links: image001.png (3 k) https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_do_-3Fdownload-3D1-26fid-3D12257&d=DwMFaQ&c=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=lEUOjyd5OPGBRcjR7SuW57L1NWayGGfS86Yu1eBkHg8&s=lAzVKjy2qxRrFWdK-NsEdhq4V_P1wic0JOFKn3IsbKQ&e=
Site Links: View post online https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_st_-3Fpost-3D192625-26anc-3Dp192625-23p192625&d=DwMFaQ&c=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=lEUOjyd5OPGBRcjR7SuW57L1NWayGGfS86Yu1eBkHg8&s=IznhwCQL2pdZp4YZBMQfQnkOsOhpKykN4leYAkUS18c&e= View mailing list online https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_si_-3Ftopic-3D19&d=DwMFaQ&c=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=lEUOjyd5OPGBRcjR7SuW57L1NWayGGfS86Yu1eBkHg8&s=wKzMIk9JBQs832Gx-w_773WeeuvN-a-pQhiY2efrP8s&e= Start new thread via email<mailto:[login to unmask email]> Unsubscribe from this mailing list<mailto:[login to unmask email]?Subject=Unsubscribe> Manage your subscription https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_us_to_&d=DwMFaQ&c=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=lEUOjyd5OPGBRcjR7SuW57L1NWayGGfS86Yu1eBkHg8&s=yoL3bkh5rXM5MoX-fHkDR8qQIl2B0xtgXSYtGAsDq7s&e=

This email has been sent to: [login to unmask email]<mailto:[login to unmask email]>

Try BCV5, the BCV5 Masking Tool, & XDM a rapid Refresh/Clone/TDM Suite for Db2 z & distributed.
DBARS -Audit,record,& block Db2 accesses to sensitive data real-time, NO audit trace or log required
http://www.ESAIGroup.com/IDUG https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ESAIGroup.com_IDUG&d=DwMFaQ&c=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=lEUOjyd5OPGBRcjR7SuW57L1NWayGGfS86Yu1eBkHg8&s=u77ylVk2sGPtP7CjLFbH5H6XgkJ2b_1ct8WqC7rIDmc&e=

Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.idug.org_p_cm_ld_fid-3D2&d=DwMFaQ&c=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=lEUOjyd5OPGBRcjR7SuW57L1NWayGGfS86Yu1eBkHg8&s=Ib3F4IhOs3CqiG6gc2E5fo34Hqz7dCPsfoAtR7R8-_k&e=

________________________________

Aurora Emanuela Dellanno

RE: Workfile sizing in Db2 on Z ( Db2 12 z/OS 2.4 - all my volumes are being ET UP by 32k workfiles!)
(in response to Philip Sevetson)

well keep your hair on everybody, I AM going to do it like this, it's what I've been saying all along :'D

 

and yes Chad, I am sure it's been discussed, but unfortuntely due to search parameters I was unable to find anything relevant - then of course today looking for something else I did find this https://www.idug.org/p/fo/et/thread=47655 - and now I'll dig into ZPARM WFDBSEP, so that we can MAYBE have one tablespace with SECQTY nonzero.

 

Thanks y'all, have a good weekend.

 

Aurora

 

PS stay safe and healthy

NB black lives matter