× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.