BLKSIZE is ZERO in JCL

Guru Bob · New User Joined: 31 Jan 2008 Posts: 21 Location: Malaysia

Terry

I have been playing with BUFNO and being a fan of 1/2 track blocking and knowing the benefit I was playing with BUFNO to see if it does or does not improve throughput. Previuosly I thought also that BUFNO had no effect but I am finally proven wrong.

Setting BUFNO to 5, 30 and 15 showed remarkedly different results in the ELAPSED time with 1 minute 35 secs and then 28 seconds and then 44 seconds for BUFNO=15 respectively. There is no difference in the number of EXCPS which is exactly what I expect. BUFNO 30 show me the best decrease in execution time being some 30% of the BUFNO=5 settings and BUFNO=15 was only 40% reduction in BUFNO execution times. I ran this 5+ times to prove thhe results.

I used IDCAMS 2 SEQUENTIAL FILES of 600+ cylinders) for my testing and will today use a COBOL program and a EASYTRIEVE Program also just to confirm.

Using 27997 for the BLKSIaze is frought with danger as pointed out. WHy not use the BLK3390 command instead? I also assume that that site does not use SMS else you would not even have to specify BLKSIZE parameter in the JCL. COding the BLKSIZE makes it difficult to change to a new device later or even CART usage.

Terry Heinze · Posted: Tue Jul 29, 2008 9:31 am

Although you ran 5+ tests, the job mix was most likely different in each case. Improved elapsed time is tough to measure because of job mix. I'd like to see what EXCP results you get with varying block sizes. I'd test it myself if I had access to a mainframe. I'm not surprised that you found no difference in EXCPs with varying BUFNO parameters. That was my experience also.

Guru Bob · New User Joined: 31 Jan 2008 Posts: 21 Location: Malaysia

Terry

I know from previous tests that we run during training classes smaller blksizes (and production fixes) dramatically increase the EXCP count. I only recommend 1/2 track blocking or for large LRECL 1/3 track blocking.

Basically any BLKSIZE between 19K-25K on a 3390 is a waste of DASD.

Guru Bob · New User Joined: 31 Jan 2008 Posts: 21 Location: Malaysia

To go back to the original post and the requirement.

Thre is n=more to tuning than just changing the BLKSIZE parameter - IMS DB/DC tuning if you run it?

VSAM tuning if you run it?
DB2 tuning if you run it?

More benfit can be achieved by tuning VSAM than BLKSIZE usually unless the BLKSIZE is really bad.

COBOL ensure that BLOCK CONTAINS 0 RECORDS is coded

BACKUPS and RESTORES using SORT or ADRDSSU or IDCAMS all parmaterised correctly (including BUFND,BUFNI,BUFNO etc were permitteed) will assist greatly. SOunds like a small patch to a big problem.

Have you confirmed with your SYSPROG/DASD administrarot if SMS is running for all QSAM files or only some. Do you still code VOL=???? or omit this parameter?

gcicchet · Posted: Tue Jul 29, 2008 4:54 pm

Hi Guru Bob,

Suresh Shankarakrishnan · New User Joined: 11 Jul 2008 Posts: 42 Location: USA

I believe for datasets with a smaller lrecl ( for example even as high as 4000 ) using 27997 or 27998 does not matter. Having said that, I honestly do not know why we use 27997 and not 27998. Will have to ask a systems person at my site.