RE: Taking more time

Thanks Vern and Jeff, I found PPMAIN is running slow
since its doing lot of global processing at same
time(CPU & DISK), and also saw Journalling as one of
the reasons.
Thanks for your help
best wishes,
Murali.
--- Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
> Murali
> 
> DSPOBJD or DSPFD will give you the ASP.
> 
> As the other post said, check CPU time vs. elapsed
> time - if CPU times are 
> the same, then something else is taking cycles at
> the time of one of the 
> programs.
> 
> How much difference in time, how many records, etc.?
> Is there a condition 
> that adds more processing in one run and not the
> other? Maybe some writes 
> in the earlier one?
> 
> Try running DSPFD on both files, with its various
> options. Then do an 
> item-by-item comparison.
> 
> Then run DSPDBR against each one, to see what
> logical files exist against 
> each one.
> 
> HTH
> Vern
> 
> At 06:18 AM 5/4/2004, you wrote:
> >They run in different times in the night,PPMAIN
> runs
> >just before FMAIN(Final run).
> >This is consistently happening everyday.
> >"Are the i/o files in the same ASP when the two
> jobs
> >run?" I think it is Yes.How do I check this?
> >
> >
> >
> >
> >--- Jeff Bull <Jeff.Bull@xxxxxxxxxxxxxxx> wrote:
> > > Are the i/o files in the same ASP when the two
> jobs
> > > run?
> > > Are the jobs being run at a different time of
> > > day/night?
> > > Have you checked the jobs CPU times (the
> millisecond
> > > value in DSPJOB, run
> > > attributes) - are these similar.
> > > On the bottom line, you need to capture
> performance
> > > data while the jobs are
> > > running, then analyse that.
> > > If, as you say, the i/o files are comparable in
> > > size, the program processing
> > > them identical then it's ...
> > >    a) environmental - as you suggested, perhaps
> > > journalling or commitment
> > > control
> > >    b) data contention - perhaps the data is
> shared
> > > in one job (locks) and
> > > exclusive in the other
> > >    c) hardware contention - other apps are
> hogging
> > > memory, flooding disk
> > > with i/o's
> > >    d) data content - while the i/o files sizes
> may
> > > be comparable,
> > > conditional processing is a possibility
> > >    e) ... I dare say a brain-storming session
> could
> > > come up with a dozen
> > > more, but this may stimulate a few more lines of
> > > investigation.
> > >
> > > Good luck
> > >
> > > Kind regards,
> > >
> > > Jeffrey E. Bull
> > > OS400 Software Support Consultant
> > >
> > > IBM Certified Systems Expert, iSeries Technical
> > > Solutions
> > > IBM Certified Systems Specialist, AS/400 System
> > > Administration
> > >
> > > *      +44 [0] 149 454 9533               swb.  
> +44
> > > [0] 149 454 9400
> > > mbl.     +44 [0] 786 750 4961               fax.
> > > +44 [0] 149 454 9454
> > > web.     http://www.itm-group.co.uk
> > >
> > > ITM Group Ltd, Latimer Square, White Lion Road,
> > > Amersham, Buckinghamshire,
> > > HP7 9JQ, United Kingdom
> > >
> > >
> > > -----Original Message-----
> > > From: murali dhar [mailto:hydchap1@xxxxxxxxx]
> > > Sent: 04 May 2004 10:51
> > > To: Midrange Systems Technical Discussion
> > > Subject: Taking more time
> > >
> > >
> > > Hai!!!
> > > I have a CL program (YQRR10C) with almost
> identical
> > > size of the input files and output files while
> > > running
> > > in one library YQS36PP(PPMAIN) takes longer time
> > > than
> > > while running in another library QS36F
> (FMAIN-Final
> > > Batch Run).
> > >
> > > The only thing I can think of is we might stop
> > > Journaling/DataMirror during FMAIN but not
> PPMAIN.
> > > But YQS36PP library does not do any of them.
> > >
> > > Any ideas why is it so?
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Win a $20,000 Career Makeover at Yahoo! HotJobs
> > >
> http://hotjobs.sweepstakes.yahoo.com/careermakeover
> > > _______________________________________________
> > > 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.
> > >
> > >
> > >
>
>________________________________________________________________________
> > > This e-mail has been scanned for all viruses by
> ITM.
> > > The
> > > service is powered by MessageLabs. For more
> > > information on a proactive
> > > anti-virus service working around the clock,
> around
> > > the globe,
> > > email marketing@xxxxxxxxxxxxxxx
> > > ITM - Managing Communication and Information
> through
> > > technology
> > > Company registration number - 3783433
> > >
>
>________________________________________________________________________
> > >
> > >
> > > DISCLAIMER
> > >
> > > Any opinions expressed in this email are those
> of
> > > the
> > > individual and not necessarily the Company. This
> > > email
> > > and any files transmitted with it, including
> replies
> > > and
> > > forwarded copies (which may contain alterations)
> > > subsequently transmitted from the Company, are
> > > confidential and solely for the use of the
> intended
> > > recipient. If you are not the intended recipient
> or
> > > the
> > > person responsible for delivering to the
> intended
> > > recipient,
> > > be advised that you have received this email in
> > > error and
> > >  that any use is strictly prohibited.
> > >
> > > If you have received this email in error please
> > > notify the IT
> > > manager by telephone on +44 (0)870 871 2233 or
> via
> > > email to Administrator@xxxxxxxxxxxxxxx,
> including a
> > > copy
> 
=== message truncated ===



        
                
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover