Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Long running job.....

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IMS DB/DC
View previous topic :: :: View next topic  
Author Message
vaibhavjadhav

New User


Joined: 27 Jul 2007
Posts: 33
Location: mumbai

PostPosted: Thu Nov 07, 2013 12:31 am    Post subject: Long running job.....
Reply with quote

Hi,

In my system there is one job which does read, insert, delete and replace function on the IMS databases, there are kind of 5 databases which are used in this job. A month ago one of the database was migrated to DB2 and the job started taking long running time. I just want to know what would be the reasons behind this and how and where to check the possibilities for this issue.

Your suggestion/guidance would be much appreciated.

Note: Prior to DB2 migration, job used to take 1 hour and now it takes almost 3 to 4 hours.

Thanks
Vaibhav
Back to top
View user's profile Send private message

Gary McDowell

Active User


Joined: 15 Oct 2012
Posts: 139
Location: USA

PostPosted: Thu Nov 07, 2013 1:22 am    Post subject:
Reply with quote

Does your shop have any systems tools, like Freeze Frame?
Back to top
View user's profile Send private message
vaibhavjadhav

New User


Joined: 27 Jul 2007
Posts: 33
Location: mumbai

PostPosted: Thu Nov 07, 2013 1:43 am    Post subject:
Reply with quote

No... sorry i dont have any kind of these tools
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Nov 07, 2013 1:45 am    Post subject:
Reply with quote

Hello,

If your IMS system was reasonably well implemented, it is no surprise that the db2 replacement takes longer (and uses more resources).

This should have been observed when doing full-volume testing and dealt with before being moved into Production.

What specific performance analysis has been done to determine if everything in the run is bad or if there isw a smaller number of problem areas?
Back to top
View user's profile Send private message
vaibhavjadhav

New User


Joined: 27 Jul 2007
Posts: 33
Location: mumbai

PostPosted: Thu Nov 07, 2013 1:56 am    Post subject:
Reply with quote

Thanks for your reply dick scherrer....

Actually i belong to application support area and the migration was done by development team so i am not very sure about the performance analysis but now as a part of service improvement i am analyzing why does this job takes long time to run....hence i just wanna know what would be the possible reasons for this so that i can begin with my analysis in the correct direction.
Hope i am much clear in case if i am not do let me know so that i will try to provide more information.

Thanks
Vaibhav
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Nov 07, 2013 2:03 am    Post subject:
Reply with quote

Hello,

Look at the definition of the tables (and index entries) for the tables used in the poor performing processes. Review the SQL code and run EXPLAINs to see what SQL needs to do to service these quesirs.

It is most unfortunate that this is not being done in a test environment. . .

I believe you have been clear enough for generally purposes, but in order to actually diagnose/tune, you will need to deal with much lower level specifics. There is probably not a "quick fix" as i suspect there are several things that will need help.
Back to top
View user's profile Send private message
Gary Jacek

New User


Joined: 17 Dec 2007
Posts: 44
Location: Victoria, BC, Canada

PostPosted: Thu Nov 07, 2013 4:13 am    Post subject:
Reply with quote

Hi Vaibhav

Have you checked to see if you have Omegamon for IMS, Omegamon for DB2, Mainview/IMS, Mainview/DB2 products which might be usedful to find out why the job runs so long now?

One step to take, is to run RUNSTATs against the new DB2 tables and then rebind the packages/plans that use these tables. The most efficient access path may have changed when full-size production data was loaded.

When you say "moved to DB2", you don't by any chance mean that the data moved to DB2 on a non-zOS platform, and your zOS DB2 is being used to obtain/update the data remotely. This would REALLY slow it down.

You may get more suggestions by posting this in the DB2 forum, but make sure you mention this is DB2 on zOS/MVS so you get answers that pertain to this platform.

Gary
Back to top
View user's profile Send private message
vaibhavjadhav

New User


Joined: 27 Jul 2007
Posts: 33
Location: mumbai

PostPosted: Thu Nov 07, 2013 11:42 pm    Post subject:
Reply with quote

Thanks everyone for your replies, I will try to check the above mentioned points and will get back to you guys in case i still have any concern.
Thanks again... icon_smile.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IMS DB/DC All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. How to move a long alphanumeric data ... lind sh COBOL Programming 8 Mon Dec 05, 2016 7:51 pm
No new posts Problem in Running Query via JCL vickey_dw DB2 3 Tue Oct 18, 2016 11:11 pm
No new posts Syntax for running batch history repo... polymathtarun CA Products 1 Tue Jun 21, 2016 1:51 pm
No new posts DFSORT split long VB lines efficiently BridgetBrackenbury DFSORT/ICETOOL 2 Fri Feb 12, 2016 5:10 am
No new posts Jobs from iseries not running in sequ... lyd All Other Mainframe Topics 4 Mon Jan 18, 2016 1:17 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us