|
Converting merchandise sales data for 1 year for a $400 million company . . . runs about 4 or 5 days . . . <ChadB@xxxxxxxxxxxxxxxxxxxx> wrote in message news:mailman.255.1169759711.2713.midrange-l@xxxxxxxxxxxxxxx Must be some pretty hefty data conversion! I'm not skilled enough on the database side to help you with specifics, but i'm sure some others here are. Alternatively, i'd call IBM support and get the DB2 people on the line to describe what you're seeing. A basic thing you could try to see if it makes a difference is to use the CHGRCYAP command to scale your target recovery time back (increased target recovery time) to a point that seems to impact your conversion processes at an acceptable level. It does seem to make sense that if the files being protected are constantly in flux while being 'converted', the access paths being protected by SMAPP are probably continually being processed for SMAPP coverage. I've never seen SMAPP have any real detrimental impact, but i've never had a box that was purely converting files for very long, either! ChadB@wheeling-ni sshin.com Sent by: To midrange-l-bounce Midrange Systems Technical s@xxxxxxxxxxxx Discussion <midrange-l@xxxxxxxxxxxx> cc 01/25/2007 02:54 PM Subject Re: SMAPP is killing our 520 Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> What is your SMAPP target recovery time set to? You can see this with the DSPRCYAP command... "Steve McKay" <steve.mckay@hibb ett.com> To Sent by: midrange-l@xxxxxxxxxxxx midrange-l-bounce cc s@xxxxxxxxxxxx Subject SMAPP is killing our 520 01/25/2007 02:51 PM Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> Installed brand-spanking new 520 running V5R4 and current PTFs to use for a data conversion process. Data conversion is the only thing running on the system so it gets 70-80% of CPU. Suddenly the data conversion job drops to 20-30% of CPU but nothing is evident on WRKACTJOB to account for the change. We start iNav system monitor and see JO-EVALUATE-TSK1 and JO-EVALUATE-TSK2, each taking between 40 & 50 % of CPU. These jobs don't just run for a minute or two and go away, they run for quite a while, and are (the best I can tell) related to determining something or other related to SMAPP (System Managed Access Path Protection). My question: What can be done so that the conversion process (which already takes several days) doesn't turn into something that takes several weeks and the JO... jobs don't suck all of the life out of this new system? The system is new out of the box and has had no special modifications such as additional ASPs or user ASPs, etc. It is currently using 48% of 6 TB DASD and 16 GB memory. TIA, Steve -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _____________________________________________________________________________ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com _____________________________________________________________________________ ForwardSourceID:NT000610A6 _____________________________________________________________________________ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com _____________________________________________________________________________-- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. ForwardSourceID:NT000610B6
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.