Check tables not in RW mode

Ron Thomas

Check tables not in RW mode


Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

John Bucaria

Check tables not in RW mode
(in response to Ron Thomas)
Hi Ron,

This Db2 command should list all tables in read-only status:

-DISPLAY DB(*) SPACE(*) ADVISORY RESTRICT (RO)

Best,
John

From: Ron Thomas <[login to unmask email]>
Sent: Thursday, May 09, 2019 4:07 PM
To: [login to unmask email]
Subject: [DB2-L] - Check tables not in RW mode


Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----

Bharath Nunepalli

RE: Check tables not in RW mode
(in response to Ron Thomas)

I have coded a REXX routine that runs these commands every 15 mins, to find out the objects in restricted status in all operational databases
-DIS DATABASE(*dbname) SPACENAM(*) RESTRICT(REORP) LIMIT(*)
-DIS DATABASE(*dbname) SPACENAM(*) RESTRICT(RECP) LIMIT(*)
-DIS DATABASE(*dbname) SPACENAM(*) RESTRICT(RBDP) LIMIT(*)
-DIS DATABASE(*dbname) SPACENAM(*) RESTRICT(STOP) LIMIT(*)

 

Bharath Nunepalli,

Senior DB2 DBA.

Ron Thomas

RE: Check tables not in RW mode
(in response to Bharath Nunepalli)

Thanks a lot for the inputs .

Srinivas Adupa

Check tables not in RW mode
(in response to Ron Thomas)
Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be
shown to you. I suggest you to use LIMIT(*) also as the last parameter so
that Db2 will not limit the output to lesser objects while result is being
displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]> wrote:

>
> Hi all.
>
> we have 200 + tables in a schema , i would like to know whether there is
> any method to query to check the db2 system catalog and see what all tables
> are not in read write mode.
>
> Thanks
> Ron T
>
> -----End Original Message-----
>


--
*Thanks & Regards,*
*Srinivas Adupa*

Roy Boxwell

Check tables not in RW mode
(in response to Srinivas Adupa)
Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...

Or has this disappeared over the years and releases??



Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: <mailto:[login to unmask email]> [login to unmask email]
Web http://www.seg.de http://www.seg.de

https://www.seg.de/corporate/rechtliche-hinweise/datenschutz Link zur Datenschutzerklärung


Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich



From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode



Hey Ron,

-DIS DB(*) SP(*) RES



RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.



-DIS DB(*) SP(*) RES LIMIT(*)



Best regards,

Srini.



On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email] <mailto:[login to unmask email]> > wrote:


Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T



-----End Original Message-----






--

Thanks & Regards,

Srinivas Adupa



-----End Original Message-----

Attachments

  • smime.p7s (5.1k)

Raymond Bell

Check tables not in RW mode
(in response to Ron Thomas)
As the STATUS of an object is maintained in the Directory, and you can now query some (most? All?) of the Directory tables, might one of the cryptic columns in one of those tables indicate the state of an object?

Not looked, but it might be worth you digging around in that area if you’re after an SQL statement to do that, rather than the excellent DSN command options you’ve already been given. For some reason I thought you were after an SQL statement – probably because you used the word, ‘query’. :o)

Cheers,


Raymond

From: Ron Thomas [mailto:[login to unmask email]
Sent: 09 May 2019 21:07
To: [login to unmask email]
Subject: [DB2-L] - Check tables not in RW mode


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


Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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

Ruediger Kurtz

AW: Check tables not in RW mode
(in response to Raymond Bell)
Raymond,

I cannot find any hint in any of the directory table, there is, however, the STATUS-column in SYSTABLESPACE with at least a bit of information that might – or might not – be helpful.

<snip>

STATUS CHAR(1) NOT NULL
Availability status of the table space:

· A Available

· C Definition is incomplete because the table space does not use table-controlled partitioning and a partitioning index has not been created.

· P Table space is in a check pending status.

· S Table space is in a check pending status with the scope less than the entire table space.

· T Definition is incomplete because no table has been created.

</snip>

Best regards

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Freitag, 10. Mai 2019 09:46
An: '[login to unmask email]' <[login to unmask email]>
Betreff: [DB2-L] - RE: Check tables not in RW mode

As the STATUS of an object is maintained in the Directory, and you can now query some (most? All?) of the Directory tables, might one of the cryptic columns in one of those tables indicate the state of an object?

Not looked, but it might be worth you digging around in that area if you’re after an SQL statement to do that, rather than the excellent DSN command options you’ve already been given. For some reason I thought you were after an SQL statement – probably because you used the word, ‘query’. :o)

Cheers,


Raymond

From: Ron Thomas [mailto:[login to unmask email]
Sent: 09 May 2019 21:07
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Check tables not in RW mode


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

Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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
-----End Original Message-----

Philip Sevetson

Check tables not in RW mode
(in response to Roy Boxwell)
Roy,

How long you been doing DB2, there, neighbor? :-D

I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

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

Check tables not in RW mode
(in response to Ruediger Kurtz)
Yeah, I looked at STATUS but the only entry you’d get similar to a –DIS command is whether it’s check pending or not. I suspect one of the cryptic bits in SYSIBM.DBDR might have the answer but I’ve never been very good at reading BLOB columns. :o)

Cheers,


Raymond

From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: 10 May 2019 13:20
To: '[login to unmask email]'
Subject: [DB2-L] - AW: Check tables not in RW mode


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

Raymond,

I cannot find any hint in any of the directory table, there is, however, the STATUS-column in SYSTABLESPACE with at least a bit of information that might – or might not – be helpful.

<snip>

STATUS CHAR(1) NOT NULL
Availability status of the table space:

• A Available

• C Definition is incomplete because the table space does not use table-controlled partitioning and a partitioning index has not been created.

• P Table space is in a check pending status.

• S Table space is in a check pending status with the scope less than the entire table space.

• T Definition is incomplete because no table has been created.

</snip>

Best regards

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:

09561 96-44148

Telefax:

09561 96-44104

E-Mail:

[login to unmask email]

Internet:

www.huk.de

________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Freitag, 10. Mai 2019 09:46
An: '[login to unmask email]' <[login to unmask email]>
Betreff: [DB2-L] - RE: Check tables not in RW mode

As the STATUS of an object is maintained in the Directory, and you can now query some (most? All?) of the Directory tables, might one of the cryptic columns in one of those tables indicate the state of an object?

Not looked, but it might be worth you digging around in that area if you’re after an SQL statement to do that, rather than the excellent DSN command options you’ve already been given. For some reason I thought you were after an SQL statement – probably because you used the word, ‘query’. :o)

Cheers,


Raymond

From: Ron Thomas [mailto:[login to unmask email]
Sent: 09 May 2019 21:07
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Check tables not in RW mode


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

Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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
-----End Original Message-----

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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

Chad Walmer

Check tables not in RW mode
(in response to Raymond Bell)
I don’t think that information is present in the catalog or directory. It’s stored in the Database Exception Status Table (DBET) which is a memory object rather than a physical table. In data-sharing environments, it’s stored in the Shared Communications Area (SCA) in the coupling facility as well as each member’s local memory. It’s rebuilt from the log and the last checkpoint when DB2 is started (or pulled from the SCA if data-sharing.)

Chad Walmer

From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 8:36 AM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Yeah, I looked at STATUS but the only entry you’d get similar to a –DIS command is whether it’s check pending or not. I suspect one of the cryptic bits in SYSIBM.DBDR might have the answer but I’ve never been very good at reading BLOB columns. :o)

Cheers,


Raymond

From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: 10 May 2019 13:20
To: '[login to unmask email]'
Subject: [DB2-L] - AW: Check tables not in RW mode


*********************************************
" 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"
*********************************************
Raymond,

I cannot find any hint in any of the directory table, there is, however, the STATUS-column in SYSTABLESPACE with at least a bit of information that might – or might not – be helpful.

<snip>

STATUS CHAR(1) NOT NULL
Availability status of the table space:

• A Available

• C Definition is incomplete because the table space does not use table-controlled partitioning and a partitioning index has not been created.

• P Table space is in a check pending status.

• S Table space is in a check pending status with the scope less than the entire table space.

• T Definition is incomplete because no table has been created.

</snip>

Best regards

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:

09561 96-44148

Telefax:

09561 96-44104

E-Mail:

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

Internet:

www.huk.de http://www.huk.de

________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Freitag, 10. Mai 2019 09:46
An: '[login to unmask email]' <[login to unmask email]<mailto:[login to unmask email]>>
Betreff: [DB2-L] - RE: Check tables not in RW mode

As the STATUS of an object is maintained in the Directory, and you can now query some (most? All?) of the Directory tables, might one of the cryptic columns in one of those tables indicate the state of an object?

Not looked, but it might be worth you digging around in that area if you’re after an SQL statement to do that, rather than the excellent DSN command options you’ve already been given. For some reason I thought you were after an SQL statement – probably because you used the word, ‘query’. :o)

Cheers,


Raymond

From: Ron Thomas [mailto:[login to unmask email]
Sent: 09 May 2019 21:07
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Check tables not in RW mode


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

Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=smd--_RmWE-u8andCu6vauO5hYA2EPHeGnaus3lhiPo&s=57Sbq08VuzGVgWX-vzgviwgJm5W7SOZVGITutQJRh7Y&e=
-----End Original Message-----

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=smd--_RmWE-u8andCu6vauO5hYA2EPHeGnaus3lhiPo&s=57Sbq08VuzGVgWX-vzgviwgJm5W7SOZVGITutQJRh7Y&e=
-----End Original Message-----

Paul Ogborne

Check tables not in RW mode
(in response to Philip Sevetson)
Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul

> On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]> wrote:
>
> Roy,
>
> How long you been doing DB2, there, neighbor? :-D
>
> I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.
>
> Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?
>
> -phil
>
> From: Boxwell, Roy [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 2:04 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
> Or has this disappeared over the years and releases??
>
> Roy Boxwell
>
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
>
> Heinrichstrasse 83-85
> 40239 Duesseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email: [login to unmask email] <mailto:[login to unmask email]>
> Web http://www.seg.de http://www.seg.de
> Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
>
> From: Srinivas Adupa [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 7:04 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Hey Ron,
> -DIS DB(*) SP(*) RES
>
> RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.
>
> -DIS DB(*) SP(*) RES LIMIT(*)
>
> Best regards,
> Srini.
>
> On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email] <mailto:[login to unmask email]>> wrote:
>
> Hi all.
>
> we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
>
> Thanks
> Ron T
>
>
> -----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 https://www.idug.org/p/fo/st/?post=189068&anc=p189068#p189068 View mailing list online https://www.idug.org/p/fo/si/?topic=19 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://www.idug.org/p/us/to
>
> This email has been sent to: [login to unmask email] <mailto:[login to unmask email]>
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> http://www.ESAIGroup.com/idug 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 http://www.idug.org/p/cm/ld/fid=2

Raymond Bell

Check tables not in RW mode
(in response to Paul Ogborne)
Paul,

Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?

Fortunately I don’t have to worry about QMF these days. ;o)

Cheers,


Raymond

From: Paul Ogborne [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode


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

Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul


On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Roy,

How long you been doing DB2, there, neighbor? :-D

I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.
we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
Thanks
Ron T

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


-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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

Paul Ogborne

Check tables not in RW mode
(in response to Raymond Bell)
Raymond,

I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.

As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
(If you can pass that on in a Canadian accent then he’ll understand!).

P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)

Regards,
Paul


> On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]> wrote:
>
> Paul,
>
> Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?
>
> Fortunately I don’t have to worry about QMF these days. ;o)
>
> Cheers,
>
>
> Raymond
>
> From: Paul Ogborne [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: 10 May 2019 13:51
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
>
> *********************************************
> " 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"
> *********************************************
>
>
> Raymond,
>
> Yes I did although some time ago.
> If memory serves, I ended up REPAIRing the DBD to shrink it down again.
> For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.
>
> Regards,
> Paul
>
>
> On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email] <mailto:[login to unmask email]>> wrote:
>
> Roy,
>
> How long you been doing DB2, there, neighbor? :-D
>
> I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.
>
> Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?
>
> -phil
>
> From: Boxwell, Roy [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 2:04 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
> Or has this disappeared over the years and releases??
>
> Roy Boxwell
>
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
>
> Heinrichstrasse 83-85
> 40239 Duesseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email: [login to unmask email] <mailto:[login to unmask email]>
> Web http://www.seg.de http://www.seg.de
> Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
>
> From: Srinivas Adupa [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 7:04 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Hey Ron,
> -DIS DB(*) SP(*) RES
>
> RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.
>
> -DIS DB(*) SP(*) RES LIMIT(*)
>
> Best regards,
> Srini.
>
> On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email] <mailto:[login to unmask email]>> wrote:
>
> Hi all.
> we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
> Thanks
> Ron T
>
> -----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-----
> -----End Original Message-----
> The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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
> Site Links: View post online https://www.idug.org/p/fo/st/?post=189071&anc=p189071#p189071 View mailing list online https://www.idug.org/p/fo/si/?topic=19 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://www.idug.org/p/us/to
>
> This email has been sent to: [login to unmask email] <mailto:[login to unmask email]>
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> http://www.ESAIGroup.com/idug 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 http://www.idug.org/p/cm/ld/fid=2

Philip Sevetson

Check tables not in RW mode
(in response to Paul Ogborne)
Paul O.,

I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?

-phil (sevetson)

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:17 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode

Raymond,

I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.

As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
(If you can pass that on in a Canadian accent then he’ll understand!).

P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)

Regards,
Paul



On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul,

Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?

Fortunately I don’t have to worry about QMF these days. ;o)

Cheers,


Raymond

From: Paul Ogborne [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode


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


Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul



On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Roy,

How long you been doing DB2, there, neighbor? :-D

I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.
we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
Thanks
Ron T

-----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-----
-----End Original Message-----
________________________________
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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
________________________________
-----End Original Message-----


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

Check tables not in RW mode
(in response to Chad Walmer)
Ah, Chad, you’re probably right – and that rings a vague bell. So yes, looks like it’s a –DIS command or… nothing. :o)

Cheers,


Raymond

From: Chad A. Walmer [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode


*********************************************
" 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 don’t think that information is present in the catalog or directory. It’s stored in the Database Exception Status Table (DBET) which is a memory object rather than a physical table. In data-sharing environments, it’s stored in the Shared Communications Area (SCA) in the coupling facility as well as each member’s local memory. It’s rebuilt from the log and the last checkpoint when DB2 is started (or pulled from the SCA if data-sharing.)

Chad Walmer

From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 8:36 AM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Yeah, I looked at STATUS but the only entry you’d get similar to a –DIS command is whether it’s check pending or not. I suspect one of the cryptic bits in SYSIBM.DBDR might have the answer but I’ve never been very good at reading BLOB columns. :o)

Cheers,


Raymond

From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: 10 May 2019 13:20
To: '[login to unmask email]'
Subject: [DB2-L] - AW: Check tables not in RW mode


*********************************************
" 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"
*********************************************
Raymond,

I cannot find any hint in any of the directory table, there is, however, the STATUS-column in SYSTABLESPACE with at least a bit of information that might – or might not – be helpful.

<snip>

STATUS CHAR(1) NOT NULL
Availability status of the table space:

• A Available

• C Definition is incomplete because the table space does not use table-controlled partitioning and a partitioning index has not been created.

• P Table space is in a check pending status.

• S Table space is in a check pending status with the scope less than the entire table space.

• T Definition is incomplete because no table has been created.

</snip>

Best regards

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:

09561 96-44148

Telefax:

09561 96-44104

E-Mail:

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

Internet:

www.huk.de http://www.huk.de

________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Freitag, 10. Mai 2019 09:46
An: '[login to unmask email]' <[login to unmask email]<mailto:[login to unmask email]>>
Betreff: [DB2-L] - RE: Check tables not in RW mode

As the STATUS of an object is maintained in the Directory, and you can now query some (most? All?) of the Directory tables, might one of the cryptic columns in one of those tables indicate the state of an object?

Not looked, but it might be worth you digging around in that area if you’re after an SQL statement to do that, rather than the excellent DSN command options you’ve already been given. For some reason I thought you were after an SQL statement – probably because you used the word, ‘query’. :o)

Cheers,


Raymond

From: Ron Thomas [mailto:[login to unmask email]
Sent: 09 May 2019 21:07
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Check tables not in RW mode


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

Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=smd--_RmWE-u8andCu6vauO5hYA2EPHeGnaus3lhiPo&s=57Sbq08VuzGVgWX-vzgviwgJm5W7SOZVGITutQJRh7Y&e=
-----End Original Message-----

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=smd--_RmWE-u8andCu6vauO5hYA2EPHeGnaus3lhiPo&s=57Sbq08VuzGVgWX-vzgviwgJm5W7SOZVGITutQJRh7Y&e=
-----End Original Message-----

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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

Raymond Bell

Check tables not in RW mode
(in response to Philip Sevetson)
There is a gentleman with that surname at a site Mr. Ogborne and myself are familiar with, so is indeed from north of your border. And mine at the moment.

I think Paul, despite his protestations, has indeed been having a few ‘meals in a glass’ this afternoon. I’m still not sure why Paul’s going on about repairs and DBDs; I think he’s getting his Rays/Roys/Phils/Petes confused.

Good times ahead methinks, Paul. Good luck with the forms. :o)

Cheers,


Raymond

From: Sevetson, Phil [mailto:[login to unmask email]
Sent: 10 May 2019 14:25
To: '[login to unmask email]'
Subject: [DB2-L] - RE: Check tables not in RW mode

Paul O.,

I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?

-phil (sevetson)

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:17 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode

Raymond,

I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.

As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
(If you can pass that on in a Canadian accent then he’ll understand!).

P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)

Regards,
Paul


On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul,

Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?

Fortunately I don’t have to worry about QMF these days. ;o)

Cheers,


Raymond

From: Paul Ogborne [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode


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

Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul


On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Roy,

How long you been doing DB2, there, neighbor? :-D

I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.
we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
Thanks
Ron T

-----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-----
-----End Original Message-----
-----End Original Message-----
-----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 83026. 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

Paul Ogborne

Check tables not in RW mode
(in response to Philip Sevetson)
Hi Phil,

I assumed that Raymond had misspelt and I was actually referring to a Mr ’Sivertsen’ and not your good self.

Best regards,
Paul

> On 10 May 2019, at 14:25, Sevetson, Phil <[login to unmask email]> wrote:
>
> Paul O.,
>
> I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?
>
> -phil (sevetson)
>
> From: Paul Ogborne [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 9:17 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Raymond,
>
> I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
> It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.
>
> As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
> (If you can pass that on in a Canadian accent then he’ll understand!).
>
> P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)
>
> Regards,
> Paul
>
>
>
> On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email] <mailto:[login to unmask email]>> wrote:
>
> Paul,
>
> Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?
>
> Fortunately I don’t have to worry about QMF these days. ;o)
>
> Cheers,
>
>
> Raymond
>
> From: Paul Ogborne [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: 10 May 2019 13:51
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
>
> *********************************************
> " 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"
> *********************************************
>
>
>
> Raymond,
>
> Yes I did although some time ago.
> If memory serves, I ended up REPAIRing the DBD to shrink it down again.
> For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.
>
> Regards,
> Paul
>
>
>
> On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email] <mailto:[login to unmask email]>> wrote:
>
> Roy,
>
> How long you been doing DB2, there, neighbor? :-D
>
> I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.
>
> Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?
>
> -phil
>
> From: Boxwell, Roy [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 2:04 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
> Or has this disappeared over the years and releases??
>
> Roy Boxwell
>
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
>
> Heinrichstrasse 83-85
> 40239 Duesseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email: [login to unmask email] <mailto:[login to unmask email]>
> Web http://www.seg.de http://www.seg.de
> Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
>
> From: Srinivas Adupa [mailto:[login to unmask email] <mailto:[login to unmask email]>]
> Sent: Friday, May 10, 2019 7:04 AM
> To: [login to unmask email] <mailto:[login to unmask email]>
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Hey Ron,
> -DIS DB(*) SP(*) RES
>
> RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.
>
> -DIS DB(*) SP(*) RES LIMIT(*)
>
> Best regards,
> Srini.
>
> On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email] <mailto:[login to unmask email]>> wrote:
>
> Hi all.
> we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
> Thanks
> Ron T
>
> -----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-----
> -----End Original Message-----
> -----End Original Message-----
> -----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 https://www.idug.org/p/fo/st/?post=189074&anc=p189074#p189074 View mailing list online https://www.idug.org/p/fo/si/?topic=19 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://www.idug.org/p/us/to
>
> This email has been sent to: [login to unmask email] <mailto:[login to unmask email]>
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> http://www.ESAIGroup.com/idug 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 http://www.idug.org/p/cm/ld/fid=2

Philip Sevetson

Check tables not in RW mode
(in response to Paul Ogborne)
☺ Got it. Thanks. Signing off before the mods club me into submission…

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:31 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode

Hi Phil,

I assumed that Raymond had misspelt and I was actually referring to a Mr ’Sivertsen’ and not your good self.

Best regards,
Paul


On 10 May 2019, at 14:25, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul O.,

I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?

-phil (sevetson)

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:17 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Raymond,

I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.

As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
(If you can pass that on in a Canadian accent then he’ll understand!).

P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)

Regards,
Paul




On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul,

Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?

Fortunately I don’t have to worry about QMF these days. ;o)

Cheers,


Raymond

From: Paul Ogborne [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode


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



Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul




On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Roy,

How long you been doing DB2, there, neighbor? :-D

I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.
we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
Thanks
Ron T

-----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-----
-----End Original Message-----
-----End Original Message-----
-----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-----


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

Roy Boxwell

Check tables not in RW mode
(in response to Philip Sevetson)
Well, I use SSAR (soon not any more!) to cross memory access the DBET from an APF authorized load module. Dump the contents down to a little COBOL program that decodes it all and Bibs your uncle!
No need for complex REXX or pesky DISPLAY commands...

Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Heinrichstrasse 83-85
40239 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de
Link zur Datenschutzerklärung

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

> On 10 May 2019, at 15:37, Sevetson, Phil <[login to unmask email]> wrote:
>
> J Got it. Thanks. Signing off before the mods club me into submission…
>
> From: Paul Ogborne [mailto:[login to unmask email]
> Sent: Friday, May 10, 2019 9:31 AM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Hi Phil,
>
> I assumed that Raymond had misspelt and I was actually referring to a Mr ’Sivertsen’ and not your good self.
>
> Best regards,
> Paul
>
>
> On 10 May 2019, at 14:25, Sevetson, Phil <[login to unmask email]> wrote:
>
> Paul O.,
>
> I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?
>
> -phil (sevetson)
>
> From: Paul Ogborne [mailto:[login to unmask email]
> Sent: Friday, May 10, 2019 9:17 AM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Raymond,
>
> I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
> It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.
>
> As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
> (If you can pass that on in a Canadian accent then he’ll understand!).
>
> P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)
>
> Regards,
> Paul
>
>
>
>
> On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]> wrote:
>
> Paul,
>
> Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?
>
> Fortunately I don’t have to worry about QMF these days. ;o)
>
> Cheers,
>
>
> Raymond
>
> From: Paul Ogborne [mailto:[login to unmask email]
> Sent: 10 May 2019 13:51
> To: [login to unmask email]
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
>
> *********************************************
> " 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"
> *********************************************
>
>
>
>
> Raymond,
>
> Yes I did although some time ago.
> If memory serves, I ended up REPAIRing the DBD to shrink it down again.
> For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.
>
> Regards,
> Paul
>
>
>
>
> On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]> wrote:
>
> Roy,
>
> How long you been doing DB2, there, neighbor? :-D
>
> I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.
>
> Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?
>
> -phil
>
> From: Boxwell, Roy [mailto:[login to unmask email]
> Sent: Friday, May 10, 2019 2:04 AM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
> Or has this disappeared over the years and releases??
>
> Roy Boxwell
>
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
>
> Heinrichstrasse 83-85
> 40239 Duesseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email: [login to unmask email]
> Web http://www.seg.de
> Link zur Datenschutzerklärung
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
>
> From: Srinivas Adupa [mailto:[login to unmask email]
> Sent: Friday, May 10, 2019 7:04 AM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: Check tables not in RW mode
>
> Hey Ron,
> -DIS DB(*) SP(*) RES
>
> RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.
>
> -DIS DB(*) SP(*) RES LIMIT(*)
>
> Best regards,
> Srini.
>
> On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]> wrote:
>
> Hi all.
> we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
> Thanks
> Ron T
>
> -----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-----
> -----End Original Message-----
> -----End Original Message-----
> -----End Original Message-----
> -----End Original Message-----
> -----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]
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> 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
>
Attachments

  • smime.p7s (3.9k)

Roy Boxwell

Check tables not in RW mode
(in response to Roy Boxwell)
Who is Bib??? Naturally Bob is the general purpose fathers brother here... I swear I haven't had any beer yet either...

Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Heinrichstrasse 83-85
40239 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de
Link zur Datenschutzerklärung

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

> On 10 May 2019, at 18:08, Boxwell, Roy <[login to unmask email]> wrote:
>
> Well, I use SSAR (soon not any more!) to cross memory access the DBET from an APF authorized load module. Dump the contents down to a little COBOL program that decodes it all and Bibs your uncle!
> No need for complex REXX or pesky DISPLAY commands...
>
> Roy Boxwell
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
> Heinrichstrasse 83-85
> 40239 Düsseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email: [login to unmask email]
> http://www.seg.de
> Link zur Datenschutzerklärung
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>
>> On 10 May 2019, at 15:37, Sevetson, Phil <[login to unmask email]> wrote:
>>
>> J Got it. Thanks. Signing off before the mods club me into submission…
>>
>> From: Paul Ogborne [mailto:[login to unmask email]
>> Sent: Friday, May 10, 2019 9:31 AM
>> To: [login to unmask email]
>> Subject: [DB2-L] - RE: Check tables not in RW mode
>>
>> Hi Phil,
>>
>> I assumed that Raymond had misspelt and I was actually referring to a Mr ’Sivertsen’ and not your good self.
>>
>> Best regards,
>> Paul
>>
>>
>> On 10 May 2019, at 14:25, Sevetson, Phil <[login to unmask email]> wrote:
>>
>> Paul O.,
>>
>> I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?
>>
>> -phil (sevetson)
>>
>> From: Paul Ogborne [mailto:[login to unmask email]
>> Sent: Friday, May 10, 2019 9:17 AM
>> To: [login to unmask email]
>> Subject: [DB2-L] - RE: Check tables not in RW mode
>>
>> Raymond,
>>
>> I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
>> It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.
>>
>> As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
>> (If you can pass that on in a Canadian accent then he’ll understand!).
>>
>> P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)
>>
>> Regards,
>> Paul
>>
>>
>>
>>
>> On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]> wrote:
>>
>> Paul,
>>
>> Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?
>>
>> Fortunately I don’t have to worry about QMF these days. ;o)
>>
>> Cheers,
>>
>>
>> Raymond
>>
>> From: Paul Ogborne [mailto:[login to unmask email]
>> Sent: 10 May 2019 13:51
>> To: [login to unmask email]
>> Subject: [DB2-L] - RE: Check tables not in RW mode
>>
>>
>> *********************************************
>> " 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"
>> *********************************************
>>
>>
>>
>>
>> Raymond,
>>
>> Yes I did although some time ago.
>> If memory serves, I ended up REPAIRing the DBD to shrink it down again.
>> For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.
>>
>> Regards,
>> Paul
>>
>>
>>
>>
>> On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]> wrote:
>>
>> Roy,
>>
>> How long you been doing DB2, there, neighbor? :-D
>>
>> I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.
>>
>> Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?
>>
>> -phil
>>
>> From: Boxwell, Roy [mailto:[login to unmask email]
>> Sent: Friday, May 10, 2019 2:04 AM
>> To: [login to unmask email]
>> Subject: [DB2-L] - RE: Check tables not in RW mode
>>
>> Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
>> Or has this disappeared over the years and releases??
>>
>> Roy Boxwell
>>
>> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
>> -Product Development-
>>
>> Heinrichstrasse 83-85
>> 40239 Duesseldorf/Germany
>> Tel. +49 (0)211 96149-675
>> Fax +49 (0)211 96149-32
>> Email: [login to unmask email]
>> Web http://www.seg.de
>> Link zur Datenschutzerklärung
>>
>> Software Engineering GmbH
>> Amtsgericht Düsseldorf, HRB 37894
>> Geschäftsführung: Gerhard Schubert, Ulf Heinrich
>>
>>
>> From: Srinivas Adupa [mailto:[login to unmask email]
>> Sent: Friday, May 10, 2019 7:04 AM
>> To: [login to unmask email]
>> Subject: [DB2-L] - RE: Check tables not in RW mode
>>
>> Hey Ron,
>> -DIS DB(*) SP(*) RES
>>
>> RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.
>>
>> -DIS DB(*) SP(*) RES LIMIT(*)
>>
>> Best regards,
>> Srini.
>>
>> On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]> wrote:
>>
>> Hi all.
>> we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
>> Thanks
>> Ron T
>>
>> -----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-----
>> -----End Original Message-----
>> -----End Original Message-----
>> -----End Original Message-----
>> -----End Original Message-----
>> -----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]
>> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
>> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
>> 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
>>
Attachments

  • smime.p7s (3.9k)

Larry Jardine

Check tables not in RW mode
(in response to Roy Boxwell)
Another option is to issue the command via the SYSPROC.ADMIN_COMMAND_DB2 stored procedure.

Larry Jardine
Database Advisor
[1_Heart_Aetna_logo_reg_rgb_vio]



Proprietary
From: Boxwell, Roy <[login to unmask email]>
Sent: Friday, May 10, 2019 12:09 PM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: Check tables not in RW mode

**** External Email - Use Caution ****
Well, I use SSAR (soon not any more!) to cross memory access the DBET from an APF authorized load module. Dump the contents down to a little COBOL program that decodes it all and Bibs your uncle!
No need for complex REXX or pesky DISPLAY commands...
Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Heinrichstrasse 83-85
40239 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
http://www.seg.de https://urldefense.proofpoint.com/v2/url?u=http-3A__www.seg.de&d=DwMGaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=hUauOtEzc_FEgC2h2TrQ8zCb6W4EpeOsWq90IXvBHMM&s=2jQtJFiONCmFRu_kr6JDzMB8GjHTRYDjW1tPSV85FlE&e=
Link zur Datenschutzerklärung https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seg.de_corporate_rechtliche-2Dhinweise_datenschutz_&d=DwMGaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=hUauOtEzc_FEgC2h2TrQ8zCb6W4EpeOsWq90IXvBHMM&s=iHw85kNRzlzQavJXa5CBFqZoXb1s4G-RMRh4BqZpd_M&e=

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

On 10 May 2019, at 15:37, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:
:) Got it. Thanks. Signing off before the mods club me into submission...

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:31 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hi Phil,

I assumed that Raymond had misspelt and I was actually referring to a Mr 'Sivertsen' and not your good self.

Best regards,
Paul


On 10 May 2019, at 14:25, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul O.,

I can't tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don't recall discussing ACBLIBs outside of my team, so it's even more puzzling... Is there a quick and easy explanation somewhere?

-phil (sevetson)

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:17 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Raymond,

I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.

As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
(If you can pass that on in a Canadian accent then he'll understand!).

P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)

Regards,
Paul




On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul,

Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?

Fortunately I don't have to worry about QMF these days. ;o)

Cheers,


Raymond

From: Paul Ogborne [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode


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



Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it's better to update users' profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul




On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Roy,

How long you been doing DB2, there, neighbor? :-D

I've been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn't that have the "problem" of destroying the EDMPOOL by loading *all* DBD's into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de https://urldefense.proofpoint.com/v2/url?u=http-3A__www.seg.de_&d=DwMGaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=hUauOtEzc_FEgC2h2TrQ8zCb6W4EpeOsWq90IXvBHMM&s=MVHntsC4YbTWzSNPsjI6bm8avtJj1merxR74Z5dMc8U&e=
Link zur Datenschutzerklärung https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seg.de_corporate_rechtliche-2Dhinweise_datenschutz_&d=DwMGaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=hUauOtEzc_FEgC2h2TrQ8zCb6W4EpeOsWq90IXvBHMM&s=iHw85kNRzlzQavJXa5CBFqZoXb1s4G-RMRh4BqZpd_M&e=

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.
we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
Thanks
Ron T

-----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-----
-----End Original Message-----
-----End Original Message-----
-----End Original Message-----
-----End Original Message-----
-----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 may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna
Attachments

  • image001.jpg (2.3k)

John Bucaria

Check tables not in RW mode
(in response to Paul Ogborne)
You mean “misspelled” ��

From: Paul Ogborne <[login to unmask email]>
Sent: Friday, May 10, 2019 9:31 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode

Hi Phil,

I assumed that Raymond had misspelt and I was actually referring to a Mr ’Sivertsen’ and not your good self.

Best regards,
Paul


On 10 May 2019, at 14:25, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul O.,

I can’t tell whether that was to me, with my name misspelled (Sivertsen being phonetically similar to Sevetson), or to someone else. I also don’t recall discussing ACBLIBs outside of my team, so it’s even more puzzling… Is there a quick and easy explanation somewhere?

-phil (sevetson)

From: Paul Ogborne [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 9:17 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Raymond,

I used the REPAIR utility to sort the DBD out. There are more options these days, but it still works I believe.
It has probably become less popular though as the DBD no longer needs to be stored contiguously in the EDM Pool as it once did.

As for Mr Sivertsen, lest he has forgotten, please remind him that ACBLIB is optional for batch jobs.
(If you can pass that on in a Canadian accent then he’ll understand!).

P.S. I tend to avoid liquid lunches these days, as at my age, the snoring tends to distract people in the afternoon ;)

Regards,
Paul




On 10 May 2019, at 13:56, Bell, Raymond (Hosting Services, Technology) <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Paul,

Liquid lunch still on-going? Yes, you did what? Or were you talking to young Mr. Sevetson?

Fortunately I don’t have to worry about QMF these days. ;o)

Cheers,


Raymond

From: Paul Ogborne [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode


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



Raymond,

Yes I did although some time ago.
If memory serves, I ended up REPAIRing the DBD to shrink it down again.
For QMF it’s better to update users’ profiles so that they use their own table space for QMF objects; otherwise this problem tends to reoccur.

Regards,
Paul




On 10 May 2019, at 13:27, Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Roy,

How long you been doing DB2, there, neighbor? :-D

I’ve been doing -DIS DB(*) SP(*) RES LIMIT(*) since 1992, V2.2 for MVS/XA. Never had a problem with it. Worked on a couple of fairly small-memory systems.

Has anyone run into this? Is it potentially a problem when a DBD is large (say, for an unmaintained DSQDBDEF.DSQTSDEF)?

-phil

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 2:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Doesn’t that have the “problem” of destroying the EDMPOOL by loading *all* DBD’s into memory? I vaguely remember that a -DIS DB(*) SP(*) was *not* recommended...
Or has this disappeared over the years and releases??

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Web http://www.seg.de http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Ulf Heinrich

From: Srinivas Adupa [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 7:04 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Hey Ron,
-DIS DB(*) SP(*) RES

RES here means REStrict. All the objects that are NOT in RW status will be shown to you. I suggest you to use LIMIT(*) also as the last parameter so that Db2 will not limit the output to lesser objects while result is being displayed.

-DIS DB(*) SP(*) RES LIMIT(*)

Best regards,
Srini.

On Fri, May 10, 2019 at 1:37 AM Ron Thomas <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Hi all.
we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.
Thanks
Ron T

-----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-----
-----End Original Message-----
-----End Original Message-----
-----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-----


-----End Original Message-----

Colin Raybould

RE: Check tables not in RW mode
(in response to Raymond Bell)

Hi Raymond,
and anyone else still wanting a usable SQL query for this question.

Try SYSPROC.DSNACCOX with QueryType ‘RESTRICT’ and Criteria ‘OBJECTSTATUS like ‘’%RO%’’’

DataStudio Example:

Call SYSPROC.DSNACCOX(
     'RESTRICT', NULL, NULL, NULL, NULL,
    NULL, 'OBJECTSTATUS like ''%RO%''', NULL, NULL, NULL,
    NULL, NULL, NULL, NULL, NULL,
    NULL, NULL, NULL, NULL, NULL,
    NULL, NULL, NULL, NULL, NULL,
    NULL, NULL, NULL, NULL, NULL,
    NULL, NULL, NULL, NULL, NULL,
    NULL, NULL, NULL, NULL, NULL,
    NULL, ?, ?, ?, ?, ?, ?
  );

 

Regards,

Colin Raybould.


In Reply to Raymond Bell:

Ah, Chad, you’re probably right – and that rings a vague bell. So yes, looks like it’s a –DIS command or… nothing. :o)

Cheers,


Raymond

From: Chad A. Walmer [mailto:[login to unmask email]
Sent: 10 May 2019 13:51
To: [login to unmask email]
Subject: [DB2-L] - RE: Check tables not in RW mode


*********************************************
" 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 don’t think that information is present in the catalog or directory. It’s stored in the Database Exception Status Table (DBET) which is a memory object rather than a physical table. In data-sharing environments, it’s stored in the Shared Communications Area (SCA) in the coupling facility as well as each member’s local memory. It’s rebuilt from the log and the last checkpoint when DB2 is started (or pulled from the SCA if data-sharing.)

Chad Walmer

From: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Sent: Friday, May 10, 2019 8:36 AM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: Check tables not in RW mode

Yeah, I looked at STATUS but the only entry you’d get similar to a –DIS command is whether it’s check pending or not. I suspect one of the cryptic bits in SYSIBM.DBDR might have the answer but I’ve never been very good at reading BLOB columns. :o)

Cheers,


Raymond

From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: 10 May 2019 13:20
To: '[login to unmask email]'
Subject: [DB2-L] - AW: Check tables not in RW mode


*********************************************
" 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"
*********************************************
Raymond,

I cannot find any hint in any of the directory table, there is, however, the STATUS-column in SYSTABLESPACE with at least a bit of information that might – or might not – be helpful.



STATUS CHAR(1) NOT NULL
Availability status of the table space:

• A Available

• C Definition is incomplete because the table space does not use table-controlled partitioning and a partitioning index has not been created.

• P Table space is in a check pending status.

• S Table space is in a check pending status with the scope less than the entire table space.

• T Definition is incomplete because no table has been created.



Best regards

Rüdiger


Rüdiger Kurtz
Abteilung Informatik - Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:

09561 96-44148

Telefax:

09561 96-44104

E-Mail:

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

Internet:

www.huk.de http://www.huk.de

________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Bell, Raymond (Hosting Services, Technology) [mailto:[login to unmask email]
Gesendet: Freitag, 10. Mai 2019 09:46
An: '[login to unmask email]' <[login to unmask email]<mailto:[login to unmask email]>>
Betreff: [DB2-L] - RE: Check tables not in RW mode

As the STATUS of an object is maintained in the Directory, and you can now query some (most? All?) of the Directory tables, might one of the cryptic columns in one of those tables indicate the state of an object?

Not looked, but it might be worth you digging around in that area if you’re after an SQL statement to do that, rather than the excellent DSN command options you’ve already been given. For some reason I thought you were after an SQL statement – probably because you used the word, ‘query’. :o)

Cheers,


Raymond

From: Ron Thomas [mailto:[login to unmask email]
Sent: 09 May 2019 21:07
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - Check tables not in RW mode


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

Hi all.

we have 200 + tables in a schema , i would like to know whether there is any method to query to check the db2 system catalog and see what all tables are not in read write mode.

Thanks
Ron T

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=smd--_RmWE-u8andCu6vauO5hYA2EPHeGnaus3lhiPo&s=57Sbq08VuzGVgWX-vzgviwgJm5W7SOZVGITutQJRh7Y&e=
-----End Original Message-----

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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: 250 Bishopsgate, London EC2M 4AA. 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=dXExZTjGJCKlGVuOpvLOSA&r=rjAbDHfQX9PPHUggzwPYc9fgjQITYeiAp7KPknlMlyw&m=smd--_RmWE-u8andCu6vauO5hYA2EPHeGnaus3lhiPo&s=57Sbq08VuzGVgWX-vzgviwgJm5W7SOZVGITutQJRh7Y&e=
-----End Original Message-----

-----End Original Message-----
The Royal Bank of Scotland plc. Registered in Scotland No 83026. 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