Db2 z/OS - DSNDB07 disk space issues

Peter Vanroose

Db2 z/OS - DSNDB07 disk space issues

Dear Db2 community,

On our test system, we're observing unreasonably many (and relatively large) datasets allocated for the two work database tablespaces, and we would like to clean up (& reclaim diskspace):
DSNCAT2.DSNDBD.DSNDB07.DSN4K00.I0001.A0*
and
DSNCAT2.DSNDBD.DSNDB07.DSN32K00.I0001.A0*

with A0* ranging up to A015 => 15 partitions of about 2 GB each.

I'd like to reduce that to a single partition (of maybe a smaller size).
Since REORG is not supported on DSNDB07, it'll be a -STOP DB plus VSAM manipulation, it seems.
This (old) IDUG thread: https://www.idug.org/p/fo/et/thread=19609 gives a partial answer to my question.

Has someone done this recently? Is it safe to do the following, or does someone have a better suggestion?

ALTER TABLESPACE DSNDB07.DSN4K00 PRIQTY 1000 SECQTY 0
-STOP DB(DSNDB07) SPNAM(DSN4K00)
=> IDCAMS DELETE DSNCAT2.DSNDBD.DSNDB07.DSN4K00.I0001.A002 (up to A015)
-START DB(DSNDB07) SPNAM(DSN4K00)

More specifically, my question is: will Db2 happily continue with just a single partition after that?
(It seems that SYSIBM.SYSTABLEPART only knows about a partition 0, so I don't see any "15 partitions" info in the catalog ...)

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Mahmood Wadee

RE: Db2 z/OS - DSNDB07 disk space issues
(in response to Peter Vanroose)

Hi , 

I did it a about a year ago .. these were the sequence of steps 

1)   do a display on the work DB to ensure no processes were using it
2)   Stop the tablespaces .. in my case it was DSN32K02 , DSN32K03 and DSN32K04.
3)   DROP these objects
4)   Recerate the VSAM clusters for them to ensure that only 1 part is allocated .
5)  Create the work file TS's in DB2

Peter Vanroose

RE: Db2 z/OS - DSNDB07 disk space issues
(in response to Mahmood Wadee)

Thanks for your response, Mahmood!

I'm only a little concerned about doing this with the "first" tablespace DSN32K00; as we have no DSN32K01 etc.
Not sure if Db2 has some "hard-coded" issues with physical changes to DSN32K00 (and DSN4K00).
The IBM manuals don't say anything in this respect, apart from "leave those datasets alone", which makes me a bit more careful...

In Reply to Mahmood Wadee:

I did it a about a year ago .. these were the sequence of steps 

1)   do a display on the work DB to ensure no processes were using it
2)   Stop the tablespaces .. in my case it was DSN32K02 , DSN32K03 and DSN32K04.
3)   DROP these objects
4)   Recerate the VSAM clusters for them to ensure that only 1 part is allocated .
5)  Create the work file TS's in DB2

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Isaac Yassin

Db2 z/OS - DSNDB07 disk space issues
(in response to Peter Vanroose)
Drop / Create for the TS works just fine. Never had a problem with that.
No need for VSAM manual allocation

*Isaac Yassin *
*dbX-Consulting Services*
*IBM Gold Consultant*
*IBM Champion for Analytics #ibmchampion*
IBM Certified Solution Expert
IBM Certified Database Administrator - DB2 for z/OS 9, 10, 11
IBM Certified System Administrator - DB2 10, 11 for z/OS
IBM Certified Database Administrator - DB2 LUW 10.1
IBM Certified Specialist - PureData System for Analytics v7.1
IDUG Israel RUG co-Chair


On Mon, Mar 26, 2018 at 2:51 PM, Peter Vanroose <[login to unmask email]>
wrote:

> Thanks for your response, Mahmood!
>
> I'm only a little concerned about doing this with the "first" tablespace
> DSN32K00; as we have no DSN32K01 etc.
> Not sure if Db2 has some "hard-coded" issues with physical changes to
> DSN32K00 (and DSN4K00).
> The IBM manuals don't say anything in this respect, apart from "leave
> those datasets alone", which makes me a bit more careful...
>
> In Reply to Mahmood Wadee:
>
> I did it a about a year ago .. these were the sequence of steps
>
> 1) do a display on the work DB to ensure no processes were using it
> 2) Stop the tablespaces .. in my case it was DSN32K02 , DSN32K03 and
> DSN32K04.
> 3) DROP these objects
> 4) Recerate the VSAM clusters for them to ensure that only 1 part is
> allocated .
> 5) Create the work file TS's in DB2
>
> -- Peter Vanroose
> *ABIS Training & Consulting,*
> * Leuven, Belgium.*
> http://www.abis.be/ http://www.abis.be/html/enDB2Calendar.html
>
> -----End Original Message-----
>

Peter Vanroose

Re: Db2 z/OS - DSNDB07 disk space issues
(in response to Isaac Yassin)

Thanks, Isaac.
I just "bit the bullet" and did the following, which seems to have worked (and indeed cleaned up lots of DASD):

-DIS   DB(DSNDB07) SP(*) LOCKS         => no-one active on temp db
-STOP  DB(DSNDB07) SP(DSN4K00)
DROP tablespace DSNDB07.DSN4K00
CREATE TABLESPACE DSN4K00 IN DSNDB07
  CLOSE NO USING STOGROUP SYSDEFLT PRIQTY 1000 SECQTY 0
-STA  DB(DSNDB07) SP(DSN4K00)

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Edited By:
Peter Vanroose[Organization Members] @ Mar 26, 2018 - 02:46 PM (Europe/Brussels)

James Campbell

Db2 z/OS - DSNDB07 disk space issues
(in response to Peter Vanroose)
Remember that if you have 15 datasets (still a single partition, though) it means that at some
time you really were using over 28 GiB of space. If you prevent the future size growing to
that then some queries will fail.

If you recreate the tablespaces with MAXPARTITIONS you can have Db2 allocated space
and limit the number of datasets.

I am not sure how deleteing datasets 2-15 would go. Db2 keeps the Hi-used page number in
the header. It might get upset if the dataset that has that page no longer exists. But, what's
the worst that can happen with DSNDB07?

James Campbell


On 26 Mar 2018 at 3:29, Peter Vanroose wrote:

>
> Dear Db2 community,
> On our test system, we're observing unreasonably many (and relatively large) datasets allocated
> for the two work database tablespaces, and we would like to clean up (& reclaim diskspace):
> DSNCAT2.DSNDBD.DSNDB07.DSN4K00.I0001.A0*
> and
> DSNCAT2.DSNDBD.DSNDB07.DSN32K00.I0001.A0*
> with A0* ranging up to A015 => 15 partitions of about 2 GB each.
> I'd like to reduce that to a single partition (of maybe a smaller size).
> Since REORG is not supported on DSNDB07, it'll be a -STOP DB plus VSAM manipulation, it
> seems.
> This (old) IDUG thread: https://www.idug.org/p/fo/et/thread=19609 gives a partial answer to my
> question.
> Has someone done this recently? Is it safe to do the following, or does someone have a better
> suggestion?
> ALTER TABLESPACE DSNDB07.DSN4K00 PRIQTY 1000 SECQTY 0
> -STOP DB(DSNDB07) SPNAM(DSN4K00)
> => IDCAMS DELETE DSNCAT2.DSNDBD.DSNDB07.DSN4K00.I0001.A002 (up to A015)
> -START DB(DSNDB07) SPNAM(DSN4K00)
> More specifically, my question is: will Db2 happily continue with just a single partition after that?
> (It seems that SYSIBM.SYSTABLEPART only knows about a partition 0, so I don't see any "15
> partitions" info in the catalog ...)
> --      Peter Vanroose
>         ABIS Training &Consulting,
>         Leuven, Belgium.
>         http://www.abis.be/
>


---
This email has been checked for viruses by AVG.
http://www.avg.com

Peter Vanroose

RE: Db2 z/OS - DSNDB07 disk space issues
(in response to James Campbell)

Since this is a test system, I do indeed want to limit the size of DSNDB07.
And you are right: this 28 GiB was not "normal usage" so a thread trying to use that much work space should be blocked much sooner.
Didn't know DSN4K00 could be UTS PBG; I'll try that. Thanks for the suggestion!

In Reply to James Campbell:

Remember that if you have 15 datasets (still a single partition, though) it means that at some
time you really were using over 28 GiB of space. If you prevent the future size growing to
that then some queries will fail.

If you recreate the tablespaces with MAXPARTITIONS you can have Db2 allocated space
and limit the number of datasets.

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Russell Peters

RE: Db2 z/OS - DSNDB07 disk space issues
(in response to Peter Vanroose)

I've had to do this a few times. I just stop the tablespace (one at a time) then use a batch job to delete/redefine the vsam dataset, then start the tablespace. It only takes a few seconds. But I would advise you to create more 32k sort tablespaces. I have 19 (32k) and 15 (4k) sort tablespaces in prod. We had an issue in test a while back where one of the developers ran an adhoc query with an order by that used up all the sort tablespaces after putting them all in several extents and ran the storage group out of space. I just used the process above to delete/redefine the vsam datasets.

Graham Clarke

RE: Db2 z/OS - DSNDB07 disk space issues
(in response to Russell Peters)

Don't forget that you can limit individual 'rogue' transactions by setting the MAXTEMPS zparm to an appropriate size.

 

Graham

Kirk Hampton

Db2 z/OS - DSNDB07 disk space issues
(in response to Graham Clarke)
I second this, and highly recommend it as a way to limit the growth of your
DSNDB07 tablespaces. At a client installation where I previously worked,
the occasional rogue ad-hoc query would use up all the available DSNDB07
space, and was able to cause most, if not all of the other concurrent
threads that were accessing DSNDB07 to all fail with -904 at the same
time. Once they implemented the MAXTEMPS in ZPARMs, only the one rouge
thread would receive a -904 when it exceeded the MAXTEMPS value.

Thanks,

Kirk Hampton
817-228-6083

On Wed, Mar 28, 2018 at 4:09 AM, Graham Clarke <[login to unmask email]> wrote:

> Don't forget that you can limit individual 'rogue' transactions by setting
> the MAXTEMPS zparm to an appropriate size.
>
>
>
> Graham
>
> -----End Original Message-----
>

Philip Sevetson

Db2 z/OS - DSNDB07 disk space issues
(in response to Kirk Hampton)
< pedant > “Rogue” < / pedant >

From: Kirk Hampton [mailto:[login to unmask email]
Sent: Wednesday, March 28, 2018 10:39 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues

I second this, and highly recommend it as a way to limit the growth of your DSNDB07 tablespaces. At a client installation where I previously worked, the occasional rogue ad-hoc query would use up all the available DSNDB07 space, and was able to cause most, if not all of the other concurrent threads that were accessing DSNDB07 to all fail with -904 at the same time. Once they implemented the MAXTEMPS in ZPARMs, only the one rouge thread would receive a -904 when it exceeded the MAXTEMPS value.

Thanks,

Kirk Hampton
817-228-6083

On Wed, Mar 28, 2018 at 4:09 AM, Graham Clarke <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Don't forget that you can limit individual 'rogue' transactions by setting the MAXTEMPS zparm to an appropriate size.



Graham

-----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.**

Raymond Bell

Db2 z/OS - DSNDB07 disk space issues
(in response to Philip Sevetson)
Not necessarily. Maybe it was red. Orange at the very least.

Virtual Friday anyone?


Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

From: Sevetson, Phil [mailto:[login to unmask email]
Sent: 28 March 2018 17:23
To: '[login to unmask email]'
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues


*********************************************
" This message originates from outside our organisation. Consider carefully whether you should click on any links, open any attachments or reply. If in doubt, forward to ~ Phishing"
*********************************************

< pedant > “Rogue” < / pedant >

From: Kirk Hampton [mailto:[login to unmask email]
Sent: Wednesday, March 28, 2018 10:39 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues

I second this, and highly recommend it as a way to limit the growth of your DSNDB07 tablespaces. At a client installation where I previously worked, the occasional rogue ad-hoc query would use up all the available DSNDB07 space, and was able to cause most, if not all of the other concurrent threads that were accessing DSNDB07 to all fail with -904 at the same time. Once they implemented the MAXTEMPS in ZPARMs, only the one rouge thread would receive a -904 when it exceeded the MAXTEMPS value.

Thanks,

Kirk Hampton
817-228-6083

On Wed, Mar 28, 2018 at 4:09 AM, Graham Clarke <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Don't forget that you can limit individual 'rogue' transactions by setting the MAXTEMPS zparm to an appropriate size.



Graham

-----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-----
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 135 Bishopsgate, London EC2M 3UR. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (“RBS” or “us”) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com http://www.rbs.com
Attachments

  • image001.png (6.7k)

Phil Grainger

Db2 z/OS - DSNDB07 disk space issues
(in response to Raymond Bell)
I still remember IDUG in Denver a few years back when Nissan launched the ROGUE in the US (known as the Qashqai most other places)

There was an advertisement painted on the side of an office block (about 10 stories tall) announcing, in MASSIVE letters, “the New Nissan Rouge”
________________________________

Phil Grainger

Enablement Manager

[login to unmask email]

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[cid:[login to unmask email]






From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: 29 March 2018 09:19
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues

Not necessarily. Maybe it was red. Orange at the very least.

Virtual Friday anyone?


Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

From: Sevetson, Phil [mailto:[login to unmask email]
Sent: 28 March 2018 17:23
To: '[login to unmask email]'
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues


*********************************************
" This message originates from outside our organisation. Consider carefully whether you should click on any links, open any attachments or reply. If in doubt, forward to ~ Phishing"
*********************************************
< pedant > “Rogue” < / pedant >

From: Kirk Hampton [mailto:[login to unmask email]
Sent: Wednesday, March 28, 2018 10:39 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues

I second this, and highly recommend it as a way to limit the growth of your DSNDB07 tablespaces. At a client installation where I previously worked, the occasional rogue ad-hoc query would use up all the available DSNDB07 space, and was able to cause most, if not all of the other concurrent threads that were accessing DSNDB07 to all fail with -904 at the same time. Once they implemented the MAXTEMPS in ZPARMs, only the one rouge thread would receive a -904 when it exceeded the MAXTEMPS value.

Thanks,

Kirk Hampton
817-228-6083

On Wed, Mar 28, 2018 at 4:09 AM, Graham Clarke <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Don't forget that you can limit individual 'rogue' transactions by setting the MAXTEMPS zparm to an appropriate size.



Graham

-----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-----
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 135 Bishopsgate, London EC2M 3UR. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (“RBS” or “us”) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.


Visit our website at www.rbs.com https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rbs.com_&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=lGIoqC8iqqK0h-7OuOJhWDVi2evZq_8uFo9gV0PqJJY&e=
________________________________
Attachment Links: image001.png (7 k) https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_do_-3Fdownload-3D1-26fid-3D9181&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=dT_FNiGcvKjlEhuFhj56ssQf7vgZnUCHJ4W4xWeLoEA&e=
Site Links: View post online https://urldefense.proofpoint.com/v2/url?u=https-3A__www.idug.org_p_fo_st_-3Fpost-3D185399-26anc-3Dp185399-23p185399&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=aCQoE5Knje-XAj7gUSzxqYapZuP5Jg3AHMts3bwbdAI&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=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=CsYWKpyKp6G5arT5bDaCEK7jsH1DILAsyA5TxTdiwhY&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=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=WzuCT7XAfwzyO53ZyH3RTzD_RZ93TtM6mA_Em-K_HgY&e=

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

** ** ** IDUG DB2 Data and Analytics Technical Summit in Bengaluru, India 2018 ** ** **
---> Bengaluru, India, March 27, 2018 <---
http://ibm.biz/IDUGBengaluru2018 https://urldefense.proofpoint.com/v2/url?u=http-3A__ibm.biz_IDUGBengaluru2018&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=f-k4xc-h_hIa59GkT2ZzyNX32Xsp08uzn3tKBGLlKgs&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=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=6JLDXKPPCC4nanE-1k2PouMZsR-6a4XqId0NopmwRTc&s=hjGMptkL9DYHhuIvtsvwrz0o7x4_mC8Gj6ZB0SmOOMk&e=

________________________________
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image001.jpg (8k)
  • image002.png (5.9k)

Raymond Bell

Db2 z/OS - DSNDB07 disk space issues
(in response to Phil Grainger)
…made in Baton Red, no doubt…

Raymond Bell
Db2
Hosting Services, Technology
Royal Bank of Scotland Group
3rd Floor Regents House
40-42 Islington High Street
London N1 8XL
Mob: +44 (0) 7894 608214
Email: [login to unmask email]<mailto:[login to unmask email]>

The content of this email is confidential unless stated otherwise.
[cid:[login to unmask email]

From: Grainger, Phil [mailto:[login to unmask email]
Sent: 29 March 2018 10:35
To: [login to unmask email]
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues


*********************************************
" This message originates from outside our organisation. Consider carefully whether you should click on any links, open any attachments or reply. If in doubt, forward to ~ Phishing"
*********************************************

I still remember IDUG in Denver a few years back when Nissan launched the ROGUE in the US (known as the Qashqai most other places)

There was an advertisement painted on the side of an office block (about 10 stories tall) announcing, in MASSIVE letters, “the New Nissan Rouge”
-----End Original Message-----
-----End Original Message-----
________________________________
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
-----End Original Message-----


The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank of Scotland is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions.

National Westminster Bank Plc. Registered in England No. 929027. Registered Office: 135 Bishopsgate, London EC2M 3UR. National Westminster Bank Plc is authorised by the Prudential Regulation Authority, and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The Royal Bank of Scotland plc and National Westminster Bank Plc are authorised to act as agent for each other.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National Westminster Bank Plc or any affiliated entity (“RBS” or “us”) does not accept responsibility for changes made to this message after it was sent. RBS may monitor e-mails for business and operational purposes. By replying to this message you understand that the content of your message may be monitored.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by RBS in this regard and the recipient should carry out such virus and other checks as it considers appropriate.

Visit our website at www.rbs.com http://www.rbs.com
Attachments

  • image001.png (6.7k)

Kirk Hampton

Db2 z/OS - DSNDB07 disk space issues
(in response to Raymond Bell)
Oh dear, guess it's time to chunk that grade-school spelling bee trophy in
the garbage. In my defense, I got it right one out of two times.

Thanks,

Kirk Hampton
817-228-6083

On Thu, Mar 29, 2018 at 4:38 AM, Bell, Raymond (Hosting Services,
Technology) <[login to unmask email]> wrote:

> …made in Baton Red, no doubt…
>
>
>
> Raymond Bell
>
> Db2
>
> Hosting Services, Technology
>
> Royal Bank of Scotland Group
>
> 3rd Floor Regents House
>
> 40-42 Islington High Street
> https://maps.google.com/?q=40-42+Islington+High+Street+%0D%0A+London+N1&entry=gmail&source=g
>
> London N1
> https://maps.google.com/?q=40-42+Islington+High+Street+%0D%0A+London+N1&entry=gmail&source=g
> 8XL
>
> Mob: +44 (0) 7894 608214 <+44%207894%20608214>
>
> Email: [login to unmask email]
>
>
>
> The content of this email is confidential unless stated otherwise.
>
> [image: cid:[login to unmask email]
>
>
>
> *From:* Grainger, Phil [mailto:[login to unmask email]
> *Sent:* 29 March 2018 10:35
> *To:* [login to unmask email]
> *Subject:* [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues
>
>
>
>
> *********************************************
> " This message originates from outside our organisation. Consider
> carefully whether you should click on any links, open any attachments or
> reply. If in doubt, forward to ~ Phishing"
> *********************************************
>
> I still remember IDUG in Denver a few years back when Nissan launched the
> ROGUE in the US (known as the Qashqai most other places)
>
>
>
> There was an advertisement painted on the side of an office block (about
> 10 stories tall) announcing, in MASSIVE letters, “the New Nissan Rouge”
>
> -----End Original Message-----
>
> -----End Original Message-----
> -----End Original Message-----
>
>
>
> The Royal Bank of Scotland plc. Registered in Scotland No 90312.
> Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. The Royal Bank
> of Scotland is authorised by the Prudential Regulation Authority, and
> regulated by the Financial Conduct Authority and Prudential Regulation
> Authority. The Royal Bank of Scotland N.V. is authorised and regulated by
> the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands,
> and is registered in the Commercial Register under number 33002587.
> Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The
> Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are
> authorised to act as agent for each other in certain jurisdictions.
>
>
>
> National Westminster Bank Plc. Registered in England No. 929027.
> Registered Office: 135 Bishopsgate, London EC2M 3UR. National Westminster
> Bank Plc is authorised by the Prudential Regulation Authority, and
> regulated by the Financial Conduct Authority and the Prudential Regulation
> Authority.
>
>
>
> The Royal Bank of Scotland plc and National Westminster Bank Plc are
> authorised to act as agent for each other.
>
>
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return
> the message to the sender by replying to it and then delete the message
> from your computer. Internet e-mails are not necessarily secure. The
> Royal Bank of Scotland plc, The Royal Bank of Scotland N.V., National
> Westminster Bank Plc or any affiliated entity (“RBS” or “us”) does not
> accept responsibility for changes made to this message after it was sent.
> RBS may monitor e-mails for business and operational purposes. By replying
> to this message you understand that the content of your message may be
> monitored.
>
>
>
> Whilst all reasonable care has been taken to avoid the transmission of
> viruses, it is the responsibility of the recipient to ensure that the
> onward transmission, opening or use of this message and any attachments
> will not adversely affect its systems or data. No responsibility is
> accepted by RBS in this regard and the recipient should carry out such
> virus and other checks as it considers appropriate.
>
>
> Visit our website at www.rbs.com
> -----End Original Message-----
>

Ram Ramaiyan

RE: Db2 z/OS - DSNDB07 disk space issues
(in response to James Campbell)

Thanks James. We have similar issues in our shop and suggestion on converting workfile ts to PBG is something we would like to give a try at this moment. Could you please suggest how can we track the users of workfile dbs. There were days where we added few TS which were consumed within short span of time.

 

Thanks.

Ram R.

Dave Nance

Db2 z/OS - DSNDB07 disk space issues
(in response to Ram Ramaiyan)
I would be careful with that. Everywhere I have been we have allowed for a set size on DB07. Most times the SQL can be reworked so that it does not consume it all.
David Nance


On Tuesday, July 10, 2018, 3:17:34 PM CDT, Ram Ramaiyan <[login to unmask email]> wrote:


Thanks James. We have similar issues in our shop and suggestion on converting workfile ts to PBG is something we would like to give a try at this moment. Could you please suggest how can we track the users of workfile dbs. There were days where we added few TS which were consumed within short span of time.

 

Thanks.

Ram R.

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]
Faster data refresh is here! The long waits and babysitting of unload/load jobs is over. Contact
ESAi to learn about BCV5 & XDM. Be a hero to users with fast on-demand test/QA data provisioning.See
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

Db2 z/OS - DSNDB07 disk space issues
(in response to Dave Nance)
What Dave said.

Briefly: expect any storage which you specify, to be used at some point. Therefore, allocate for as much storage as you feel you can afford, put it all in pre-allocated tablespaces with SECQTY 0, and leave it alone.

You gain little or nothing by having secondary extents available.

Here are your cases if you specify a nonzero secondary:

1) You have already purchased DASD which is in a temp-only pool. Problem: you’re not saving any money or time by leaving the pool partly un-allocated. You’ve paid for the DASD already, all you’re doing is adding extents and allocation time to the cost. If you allocate it all, you are using what you have paid for and minimizing overhead.

2) The DASD which your secondaries will live on is part of a shared pool. If this is so, then you have to actively manage the secondaries – every time they are allocated to handle volume, you have to wait and, very soon thereafter, drop/create the temporary tablespace again in order to give back the shared space. (You may be up to this. If so, you’re in the 1%, neighbor, and you don’t have enough work.)

3) You don’t have any extra space in your pool. THEN DEFINITELY DON’T SPECIFY SECONDARIES. WHERE ARE THEY GOING TO LIVE??? MESSAGE=00D70014 or 00D70025.

None of these are a notably strong case for secondary extents. If you have dedicated space, allocate it _all_ to primary extents. If you don’t have dedicated space, you’ll have to constantly be pruning back the secondaries.

Okay, rant over. Toodles, all.

--Phil


From: Dave Nance [mailto:[login to unmask email]
Sent: Tuesday, July 10, 2018 4:33 PM
To: Ram Ramaiyan
Subject: [DB2-L] - RE: Db2 z/OS - DSNDB07 disk space issues

I would be careful with that. Everywhere I have been we have allowed for a set size on DB07. Most times the SQL can be reworked so that it does not consume it all.

David Nance



On Tuesday, July 10, 2018, 3:17:34 PM CDT, Ram Ramaiyan <[login to unmask email]> wrote:



Thanks James. We have similar issues in our shop and suggestion on converting workfile ts to PBG is something we would like to give a try at this moment. Could you please suggest how can we track the users of workfile dbs. There were days where we added few TS which were consumed within short span of time.



Thanks.

Ram R.

-----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.**