IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Job performance


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
kranti

New User


Joined: 10 Oct 2005
Posts: 27

PostPosted: Thu Oct 22, 2009 12:41 pm
Reply with quote

Hi,

We have in our application something like Backup and reload of Vsam files.

Backup process reads all VSAM files and writes into two flat files, both the files are almost being written with the same data. As the files are needed to hold large data, these were defined with compression option.

During reload process, the records in flat files would be written back to Vsam files.

Observation we made that the backup process runs for 2 hours where as reload completes in 15 minutes.

Is it because the flat files are defined with compression option?

we also noticed that the cobol program for backup was compiled with TEST SYM option which made load to be big.
Is this the culprit for running backup for longer time?

Please advice.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Thu Oct 22, 2009 12:57 pm
Reply with quote

Have you tried using IDCAMS, either REPRO/REPRO or EXPORT/IMPORT to do this task.

Also if your site has FAVER installed, use this, as it is an excellent VSAM backup/restore product.
Back to top
View user's profile Send private message
kranti

New User


Joined: 10 Oct 2005
Posts: 27

PostPosted: Thu Oct 22, 2009 1:08 pm
Reply with quote

Hi Expat,

Unfortunately we can not use the IDCAMS or any utility for backup/reload as it should be program driven.

Duing the backup/reload proces we drop older data and write back remaining into the vsam files.

Coming to my question, would any of the reasons mentioned in my last tag causing the job to run for longer time?

Thanks.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Oct 22, 2009 4:38 pm
Reply with quote

The job could run longer due to program logic, conflicts with other jobs running at the same time that are done by the time the reload starts, or even other reasons.

Since you are testing data in each record, it is pretty much a given that the unload (back up) time will be longer than the reload time where you are not doing anything but putting records into the file.

Your best bet would be to contact your site support group and have them help you analyze the reason(s) for the time difference.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Oct 22, 2009 6:38 pm
Reply with quote

using idcams parameters properly, there is a good chance that you can do away with the cobol program if you are only making a date check.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Oct 22, 2009 9:19 pm
Reply with quote

Hello,

You might also look into using your sort product - it will probably run faster than idcams and most likely faster than the cobol code. . .
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts exploiting Z16 performance PL/I & Assembler 2
No new posts JOIN STATEMENT PERFORMANCE. DFSORT/ICETOOL 12
No new posts Which SORT utility can improve the Pe... DFSORT/ICETOOL 16
No new posts COBOL Performance Tuning COBOL Programming 6
No new posts CICS Performance statistics CICS 3
Search our Forums:

Back to Top