A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage

Roy Boxwell

A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage
Hi all!



You have probably all heard that RFEs are being deprecated and we now have the brand new “analytics ideas” ( http://ibm.biz/IBMAnalyticsIdeasPortal http://ibm.biz/analyticsideas ) way of requesting stuff.

To “test the water” I have opened a couple of ideas , one of which is:



Idea DB24ZOS-I-894 created



Please go and review and vote if you like it! We can then see if it all hangs together as it should...



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: Boxwell, Roy [mailto:[login to unmask email]
Sent: Thursday, January 24, 2019 3:23 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS COPY YES indexes - who does it and why?



They annoy me a bit due to the MODIFY RECOVERY problem of NPI indexes... You must be *really* careful if doing MODIFY and having NPI with COPY YES. Currently MODIFY does not porcess NPIs as you would think meaning you must look for an d clean up the datasets! I have an RFE for this by the way...

Headline: MODIFY RECOVERY Utility enhancement

ID: 113062

Description: MODIFY RECOVERY works great for deleting entries in SYSCOPY/SYSLGRNGX/DBD etc. but it has a major failing. If the DB.TS is partitioned and there is an NPI then the NPI copies are never deleted when issuing a MODIFY RECOVERY TABLESPACE db.ts DSNUM 1 even if there are complete TP level image copies. It would be excellent if the MODIFY RECOVERY would get a new keyword INCLUDE_NPI which would tell the system to validate that all parts were ok and, if so, then do all the MODIFY work for any and all NPIs as well.

Use case: Today the DBA must manually validate that TP level copies exist before doing a DSNUM ALL modify because if one TP copy is not there then the entire space goes COPY pending which is not nice! If the DBA does not do this work and they work with DSNUM nnnn style then the copies of the NPIs stay forever filling up SYSCOPY, Disks, DBDs, SYSLGRNX entries etc.





Feel free to vote for it!







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: Kai Stroh [mailto:[login to unmask email]
Sent: Thursday, January 24, 2019 2:39 PM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: DB2 z/OS COPY YES indexes - who does it and why?



In Reply to David Simpson:

It generates extra log records that are not necessary if you are not doing index recovery.



Db2 does not generate extra log records for COPY YES indexes.

Well, I guess it is possible that there is the occasional log record that gets written when the index goes into informational copy pending, or some other status information. But my point is, COPY YES or COPY NO makes no difference when you look at the data change records for that index, and those probably account for 99.9% of the index log records. In other words, even for COPY NO indexes, Db2 will log every change to every page in the index, whether it's a key insertion, deletion, RID update, page split, and so on.

The reason for this is that Db2 needs those log records if you decide to rollback a transaction. If Db2 didn't have any log records for the index, it would have to put it in rebuild pending whenever you do a rollback (assuming the transaction affected the index in any way). This is similar to a tablespace with NOT LOGGED, which will go into recover pending upon rollback.

It's also the reason why we can use index log records in order to bring a dirty VSAM copy of an index into a consistent state. We do this in our BCV5 product to allow people to make consistent copies from running production objects, and we have seen that it does not matter if the index is COPY YES or COPY NO.

As far as I can tell, the only real difference is in a RECOVER scenario where you can avoid the index rebuild if you have an image copy. As for Db2 forcing you to choose between COPY YES and COPY NO, it does not make a lot of sense to me and you might as well use COPY YES for all indexes, and then make a separate decision for which indexes you actually want to create image copies. Just keep in mind that index image copies cannot be incremental because indexes lack space map pages with usage maps, so every copy is going to be a full copy.



Cheers

Kai





--

Kai Stroh

UBS Hainer

Fast, efficient Db2 z/OS data migrations and renewals. That’s BCV5 https://www.ubs-hainer.com/solutions/bcv5 .

Learn how the Test Data Management Field Guide http://tdm.ubs-hainer.com can help you to improve your own process.



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

Attachments

  • smime.p7s (5.1k)

Phil Grainger

A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage
(in response to Roy Boxwell)
I did vote for a couple, so it does seem to “hang together”

Seems you don’t even have to prove you have Db2 to be able to vote either
________________________________





[BMC Exchange 2019 - Global Event Series - REGISTER] https://www.bmc.com/ami

Phil Grainger
Principal Enablement Manager

Direct

+44 1189 218 000

Mobile

+44 7808 643 479

Email

[login to unmask email]

E2, Eskdale Road
Winnersh
Berkshire
United Kingdom
RG41 5TS
[image001 (002)][https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png][https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]










































From: Boxwell, Roy [mailto:[login to unmask email]
Sent: 25 January 2019 09:06
To: [login to unmask email]
Subject: [DB2-L] - A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage

Hi all!

You have probably all heard that RFEs are being deprecated and we now have the brand new “analytics ideas” ( http://ibm.biz/IBMAnalyticsIdeasPortal https://urldefense.proofpoint.com/v2/url?u=http-3A__ibm.biz_analyticsideas&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=RLB3dYNovyi_9AdzFxsb0RR9TCOv7z57VwFjV-7Q7w0&e= ) way of requesting stuff.
To “test the water” I have opened a couple of ideas , one of which is:

Idea DB24ZOS-I-894 created

Please go and review and vote if you like it! We can then see if it all hangs together as it should...

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=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=OrqIvM0GfW-k901V9WC8SGmv2Cp_IWHM3ZVJjL7ZB-g&e=
Link zur Datenschutzerklärung https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seg.de_corporate_rechtliche-2Dhinweise_datenschutz_&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=6Z3ut08DfdmwU62PCqu2q6YfSD-ag0iDDrDl0B7sjpE&e=

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

From: Boxwell, Roy [mailto:[login to unmask email]
Sent: Thursday, January 24, 2019 3:23 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: DB2 z/OS COPY YES indexes - who does it and why?

They annoy me a bit due to the MODIFY RECOVERY problem of NPI indexes... You must be *really* careful if doing MODIFY and having NPI with COPY YES. Currently MODIFY does not porcess NPIs as you would think meaning you must look for an d clean up the datasets! I have an RFE for this by the way...
Headline: MODIFY RECOVERY Utility enhancement
ID: 113062
Description: MODIFY RECOVERY works great for deleting entries in SYSCOPY/SYSLGRNGX/DBD etc. but it has a major failing. If the DB.TS is partitioned and there is an NPI then the NPI copies are never deleted when issuing a MODIFY RECOVERY TABLESPACE db.ts DSNUM 1 even if there are complete TP level image copies. It would be excellent if the MODIFY RECOVERY would get a new keyword INCLUDE_NPI which would tell the system to validate that all parts were ok and, if so, then do all the MODIFY work for any and all NPIs as well.
Use case: Today the DBA must manually validate that TP level copies exist before doing a DSNUM ALL modify because if one TP copy is not there then the entire space goes COPY pending which is not nice! If the DBA does not do this work and they work with DSNUM nnnn style then the copies of the NPIs stay forever filling up SYSCOPY, Disks, DBDs, SYSLGRNX entries etc.


Feel free to vote for it!



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=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=OrqIvM0GfW-k901V9WC8SGmv2Cp_IWHM3ZVJjL7ZB-g&e=
Link zur Datenschutzerklärung https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seg.de_corporate_rechtliche-2Dhinweise_datenschutz_&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=6Z3ut08DfdmwU62PCqu2q6YfSD-ag0iDDrDl0B7sjpE&e=

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

From: Kai Stroh [mailto:[login to unmask email]
Sent: Thursday, January 24, 2019 2:39 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: DB2 z/OS COPY YES indexes - who does it and why?


In Reply to David Simpson:
It generates extra log records that are not necessary if you are not doing index recovery.



Db2 does not generate extra log records for COPY YES indexes.

Well, I guess it is possible that there is the occasional log record that gets written when the index goes into informational copy pending, or some other status information. But my point is, COPY YES or COPY NO makes no difference when you look at the data change records for that index, and those probably account for 99.9% of the index log records. In other words, even for COPY NO indexes, Db2 will log every change to every page in the index, whether it's a key insertion, deletion, RID update, page split, and so on.

The reason for this is that Db2 needs those log records if you decide to rollback a transaction. If Db2 didn't have any log records for the index, it would have to put it in rebuild pending whenever you do a rollback (assuming the transaction affected the index in any way). This is similar to a tablespace with NOT LOGGED, which will go into recover pending upon rollback.

It's also the reason why we can use index log records in order to bring a dirty VSAM copy of an index into a consistent state. We do this in our BCV5 product to allow people to make consistent copies from running production objects, and we have seen that it does not matter if the index is COPY YES or COPY NO.

As far as I can tell, the only real difference is in a RECOVER scenario where you can avoid the index rebuild if you have an image copy. As for Db2 forcing you to choose between COPY YES and COPY NO, it does not make a lot of sense to me and you might as well use COPY YES for all indexes, and then make a separate decision for which indexes you actually want to create image copies. Just keep in mind that index image copies cannot be incremental because indexes lack space map pages with usage maps, so every copy is going to be a full copy.



Cheers

Kai




--
Kai Stroh
UBS Hainer
Fast, efficient Db2 z/OS data migrations and renewals. That’s BCV5 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ubs-2Dhainer.com_solutions_bcv5&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=5BvRWqN2PVoY5qyKGIOHzjMtNJf1hNivc-T_KdDpj4s&e= .
Learn how the Test Data Management Field Guide https://urldefense.proofpoint.com/v2/url?u=http-3A__tdm.ubs-2Dhainer.com_&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=EAGrd_qzLADPfI8dgytr8sbCG7_U9QfXwQMLgK1Zo30&m=m2LETxIvGyt0fUk-z-q_46oybnCVZaJ9RHDtAUpW9vM&s=k7vS3afB43VScNGxYcxiTfioQCGqM0aiARPABle2KRM&e= can help you to improve your own process.

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

  • image001.jpg (49.7k)
  • image002.png (6.7k)
  • image003.png (3.7k)
  • image004.png (<1k)

Roy Boxwell

A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage
(in response to Phil Grainger)
When I go there it seems to “forget” that I have created a couple of ideas... My name is there but it is never listed...



It looks like *anyone* from *anywhere* can vote... I will get daughters to vote fro my stuff tonight!



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: Grainger, Phil [mailto:[login to unmask email]
Sent: Friday, January 25, 2019 11:35 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage



I did vote for a couple, so it does seem to “hang together”



Seems you don’t even have to prove you have Db2 to be able to vote either




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

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

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



Attachments

  • smime.p7s (5.1k)

Kenny Fogarty

[OT] A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage
(in response to Roy Boxwell)
"Analytics ideas"? It's like English for Aliens.....(oblique reference
to a sketch from a 1990's comedy show).

Cheers,

Kenny

On Fri, 25 Jan 2019 at 09:06, Boxwell, Roy <[login to unmask email]> wrote:
>
> Hi all!
>
>
>
> You have probably all heard that RFEs are being deprecated and we now have the brand new “analytics ideas” ( http://ibm.biz/IBMAnalyticsIdeasPortal ) way of requesting stuff.
>
> To “test the water” I have opened a couple of ideas , one of which is:
>
>
>
> Idea DB24ZOS-I-894 created
>
>
>
> Please go and review and vote if you like it! We can then see if it all hangs together as it should...
>
>
>
> 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: Boxwell, Roy [mailto:[login to unmask email]
> Sent: Thursday, January 24, 2019 3:23 PM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: DB2 z/OS COPY YES indexes - who does it and why?
>
>
>
> They annoy me a bit due to the MODIFY RECOVERY problem of NPI indexes... You must be *really* careful if doing MODIFY and having NPI with COPY YES. Currently MODIFY does not porcess NPIs as you would think meaning you must look for an d clean up the datasets! I have an RFE for this by the way...
>
> Headline: MODIFY RECOVERY Utility enhancement
>
> ID: 113062
>
> Description: MODIFY RECOVERY works great for deleting entries in SYSCOPY/SYSLGRNGX/DBD etc. but it has a major failing. If the DB.TS is partitioned and there is an NPI then the NPI copies are never deleted when issuing a MODIFY RECOVERY TABLESPACE db.ts DSNUM 1 even if there are complete TP level image copies. It would be excellent if the MODIFY RECOVERY would get a new keyword INCLUDE_NPI which would tell the system to validate that all parts were ok and, if so, then do all the MODIFY work for any and all NPIs as well.
>
> Use case: Today the DBA must manually validate that TP level copies exist before doing a DSNUM ALL modify because if one TP copy is not there then the entire space goes COPY pending which is not nice! If the DBA does not do this work and they work with DSNUM nnnn style then the copies of the NPIs stay forever filling up SYSCOPY, Disks, DBDs, SYSLGRNX entries etc.
>
>
>
>
>
> Feel free to vote for it!
>
>
>
>
>
>
>
> 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: Kai Stroh [mailto:[login to unmask email]
> Sent: Thursday, January 24, 2019 2:39 PM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: DB2 z/OS COPY YES indexes - who does it and why?
>
>
>
> In Reply to David Simpson:
>
> It generates extra log records that are not necessary if you are not doing index recovery.
>
>
>
> Db2 does not generate extra log records for COPY YES indexes.
>
> Well, I guess it is possible that there is the occasional log record that gets written when the index goes into informational copy pending, or some other status information. But my point is, COPY YES or COPY NO makes no difference when you look at the data change records for that index, and those probably account for 99.9% of the index log records. In other words, even for COPY NO indexes, Db2 will log every change to every page in the index, whether it's a key insertion, deletion, RID update, page split, and so on.
>
> The reason for this is that Db2 needs those log records if you decide to rollback a transaction. If Db2 didn't have any log records for the index, it would have to put it in rebuild pending whenever you do a rollback (assuming the transaction affected the index in any way). This is similar to a tablespace with NOT LOGGED, which will go into recover pending upon rollback.
>
> It's also the reason why we can use index log records in order to bring a dirty VSAM copy of an index into a consistent state. We do this in our BCV5 product to allow people to make consistent copies from running production objects, and we have seen that it does not matter if the index is COPY YES or COPY NO.
>
> As far as I can tell, the only real difference is in a RECOVER scenario where you can avoid the index rebuild if you have an image copy. As for Db2 forcing you to choose between COPY YES and COPY NO, it does not make a lot of sense to me and you might as well use COPY YES for all indexes, and then make a separate decision for which indexes you actually want to create image copies. Just keep in mind that index image copies cannot be incremental because indexes lack space map pages with usage maps, so every copy is going to be a full copy.
>
>
>
> Cheers
>
> Kai
>
>
>
>
>
> --
>
> Kai Stroh
>
> UBS Hainer
>
> Fast, efficient Db2 z/OS data migrations and renewals. That’s BCV5.
>
> Learn how the Test Data Management Field Guide can help you to improve your own process.
>
>
>
> -----End Original Message-----

Mohammad Khan

A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage
(in response to Roy Boxwell)
You are a little late to the party with your voting idea. They have been doing this here in Chicago for ages :)
Sorry … Friday etc. and it's really cold.
Khalid

From: Boxwell, Roy <[login to unmask email]>
Sent: Friday, January 25, 2019 5:27 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage

When I go there it seems to “forget” that I have created a couple of ideas... My name is there but it is never listed...

It looks like *anyone* from *anywhere* can vote... I will get daughters to vote fro my stuff tonight!

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
HCSC Company Disclaimer

The information contained in this communication is confidential, private,
proprietary, or otherwise privileged and is intended only for the use of
the addressee. Unauthorized use, disclosure, distribution or copying is
strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately at
(312) 653-6000 in Illinois; (800) 447-7828 in Montana;
(800) 835-8699 in New Mexico; (918) 560-3500 in Oklahoma;
or (972) 766-6900 in Texas.

Javier Estrada Benavides

RE: A new Idea created - z/OS EXPLAIN CURRENT SCHEMA usage
(in response to Mohammad Khan)

Hey

   Thanks for sharing the link. I didn't know about that either.

I saw another one that I really liked, the ability to list enclaves and point them to their thread token. That could also be very helpful.

 

Regards,

Javier Estrada Benavides, Czech Republic / Mexico

IBM Champion for Analytics

IBM Certified System Administrator - Db2 12 for z/OS

IBM Db2 12 DBA for z/OS - 2018 (the ugly brown badge from IBM Open Badge Program)

IBM Certified System Administrator - DB2 11 for z/OS

IBM Certified Database Administrator - DB2 11 DBA for z/OS