1 IDUGDB2-L.ORG /home/listserv/home/db2-l May 2010, week 5
2 34 49_Re: Querying tables from different DB2 subsystems11_Dave Harvey17_db2dave@GMAIL.COM31_Sun, 30 May 2010 04:12:06 -0400379_UTF-8 Yes - the SP approach gives you everything but beware a few 'gotchas'.<br><br>When populating the CDB's (IPNAMES etc), remember to design it around your network colleagues VTAM/LUNAMES needs. Their repertoire of commands drives particular features and the CDB is fairly 'static' when matching DB2's LOCATIONs. DB2 usually plays second fiddle to network issues anyway. [...]49_7158109244290078.WA.db2davegmail.com@www.idug.org
37 46 38_Reorg with DISCARD - slow UNLOAD phase14_Michael Kaplan25_micaelkp@NETVISION.NET.IL31_Sun, 30 May 2010 06:44:23 -0400587_UTF-8 Hello,<br><br>We have experienced a slow UNLOAD phase of REORG SHRLEVEL REFERENCE with DISCARD.<br>Because SORTDATA NO was specified, UNLOAD algorithm choose one of 4 table indexes ( each one - UNCLUSTERED).<br>The index which was chosen is occasionally UNIQUE index ( I think it does not matter) and it caused massive<br>SYNC IO and that is the reason for UNLOAD to be slow.<br>There is another INDEX, also unclustered but fit much better for WHEN condition, but it was not chosen.<br>My questions :<br>1) Can we manage which index will be used to unload, if all indexes are [...]57_0929374471952001.WA.micaelkpnetvision.net.il@www.idug.org
84 179 41_SV: DB2 V8 z/OS Catalog & Directory Reorg13_Hanne Lyssand20_Hanne.Lyssand@VPS.NO31_Mon, 31 May 2010 22:10:49 +0200713_us-ascii I have done reorg reference on the catalog inflight serveral times, but we are a small shop. I look for a relative low use window. It's only the switch that can be a problem. Do you have high bind activity? And application do not usually update the catalog.<br><br>Best regards<br>Hanne<br><br>_____________________________________________________________________<br><br>* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *<br>* Your only source for independent, unbiased, and trusted DB2 information. *<br>** The most DB2 technical sessions of any conference<br>** Access IBM experts and developers<br>_____________________________________________________________________ [...]60_BC3112D53848914B97C86CFB032EBF330189BA9AA025@vsnts235.vps.no