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

DASD storage


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

Active User


Joined: 14 Jul 2005
Posts: 105

PostPosted: Fri May 28, 2010 12:57 am
Reply with quote

Dear Experts,
Recently I came across a job in production the job CPU and elapsed time makes me some doubtfull.
This job runs during batch update and I see the driver file it reads which is a falt file
of around 2,185 allocated megabytes with 55 alocated extents and jumbo dataclas as defined.This file basically gets created from other place.
The lrecl of this file is 900.

I see that the COU time for this job is around 1.6 whereas the elapsed time around 64 minutes which makes me to beleive that this
is probably more I/O bound job.This file is read first in the cobol program before further readin around 10 vsam file(there could be a possibility that these vsam file tuning could be done).

Our shop had strobe earlier but now they have take this off so I can not get any conclusion blind.

But as I mentioned about the driver flat file I see it has got following on jcl

DCB=BUFNO=2,I am just thinking on what basis we select the BUFNO should be of what value if we really want to get the work finished as quickly as possible.

This job is running in critical path so I am trying to find out any imporvemnt if can be done
to get its elapsed time reduced as of now job takes around 1 hour to complete.Please advise I know that this is very little information for this job for you but
still experienced eyes can catch something ...Please let me know if
I can provide some other details.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri May 28, 2010 1:14 am
Reply with quote

More buffers!
Back to top
View user's profile Send private message
raghavmcs

Active User


Joined: 14 Jul 2005
Posts: 105

PostPosted: Fri May 28, 2010 1:18 am
Reply with quote

Okay,additonally I see following stats from latest daily run

ROCSTEP RC EXCP CPU SRB CLOCK SERV PG PAGE
STN0020 00 1079K 1.83 .06 61.67 56434K 0 40985

Is there any advisible buffer size in thsi case...with the information I provided or might be I could give some more if you ask something which is avaliable..
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: Fri May 28, 2010 2:19 am
Reply with quote

My experience has been that sequential files benefit from having about 30 to 50 buffers allocated as long as memory is available. VSAM file buffering is more complicated as it depends upon whether the file is being accessed randomly or sequentially. However, the default 2 data and 1 index buffer for KSDS is usually provides much worse performance than can be achieved.
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Wed Jun 30, 2010 2:45 pm
Reply with quote

What is the BLKSIZE of the file? 1079k EXCPS might indicate a non-optimal BLKSIZE in which case reallocating with BLKSIZE=0 specified will sort it out via SDB.

Have a look at it through RMF or equivalent for further clues. May need increased REGION size, or could be that it's running on a constrained system.
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 CLIST - Virtual storage allocation error CLIST & REXX 5
No new posts CICS vs LE: STORAGE option CICS 0
No new posts Insufficient Storage ABENDS & Debugging 7
No new posts DASD - non SMS - volser change - VSAM... JCL & VSAM 2
No new posts Interviewers are surprised with my an... Mainframe Interview Questions 6
Search our Forums:

Back to Top