OCCURS vs Block Size

[sparrow]

I am currently discuusing a technical issue with some consultants that are supposed to be helping us an I was wondering if anybody out there could help.<br>
<br>
On an interface working file we have an OCCURS 24 hold price information. This occurs needs to be increased to 100.<br>
The consultants say that as this will make the record bigger than 1 block it would be more efficient to put the extra occurs in a seperate file.<br>
<br>
Any comments

 

[GeorgiK]

Hi sparrow,<br>
<br>
The question is not very clear to me. Please describe<br>
better the record, e.g.:<br>
... 03 PRICE1 OCCURS 24.<br>
05 PRICE PIC 9(7)V99. (you enter the real stuff)<br>
Tell me also what are the usual values in the price -<br>
from ... to ...<br>
Also, for me it is not problem to convert a file to<br>
another with a bigger block size.<br>
<br>
GeorgiK

 

[sparrow]

Hi GeorgiK, thanks for the reply<br>
<br>
The Current record definition is<br>
01 REC.<br>
03 KEY PIC X(39).<br>
03 DATA1 PIC X(141).<br>
03 SHAPE-GROUP.<br>
05 SHAPES OCCURS 24.<br>
07 QUANTITY PIC 9(9).<br>
07 PRICE PIC 9(7).<br>
03 DATA2 PIC X(4).<br>
<br>
My suggestion is<br>
01 REC.<br>
03 KEY PIC X(39).<br>
03 DATA1 PIC X(141).<br>
03 DATA2 PIC X(4).<br>
03 SHAPE-GROUP.<br>
05 SHAPES OCCURS 100.<br>
07 QUANTITY PIC 9(9).<br>
07 PRICE PIC 9(7).<br>
<br>
The consultant says this is inefficient as it will cause cobol to do a double i/o to get the whole record into the program. I have never heard of a probelm with record size making cobol do multiple i/o's just to read a single record.<br>
<br>
Is above soultion is being adopted, and is currently under system test. But I am very interested to know what the consultants are talking about asI can find no reference to this problem anywhere.<br>
<br>
In anticipation<br>
<br>
Sparrow

 

[GeorgiK]

Hi sparrow,<br>
<br>
Sorry for my late reply. I took my holiday in August<br>
(and also was lazy to check tek-tips).<br>
Your consultant is 'old fashioned' programmer, but<br>
also he is mixing i/o rules of VMS. The default<br>
block i/o is 5 blocks ( 5*512=2560bytes), so there<br>
is no problem in extra i/o! Of course the bigger<br>
the record the more buffer size of program and probably<br>
more page faults are involved.<br>
In either case you don't use optimaly the number of<br>
blocks in a bucket. Supose you have 1 record in a bucket<br>
you use:<br>
case 1:<br>
39+141+16*24+4+7(for index)+15(for bucket)=580 bytes<br>
the old record used more than 512bytes, so the retrieving<br>
of one record needed reading of two blocks.<br>
case 2:<br>
39+141+16*100+4+7(for index)+15(for bucket)=1806 bytes<br>
the 'new' record use more than 1536bytes(3*512), so the retrieving of one record needed reading of four <br>
blocks.<br>
In both cases you don't use optimaly the buffers, but<br>
of course you want to extend the quantity/price portion<br>
of the record to 100 (occurs 100).<br>
My sugestion:<br>
You change the PIC in the shape like this:<br>
...<br>
05 SHAPE OCCURS 100.<br>
07 QUANTITY PIC 9(9) COMP.<br>
07 PRICE PIC 9(7) COMP.<br>
...<br>
now you have:<br>
39+141+4+100*8+7+15=1006<br>
BENEFITS:<br>
1.YOU OPTIMALY USE BUFFERS 1006 IS JUST A LITTLE<br>
BIT LESS THAN 1024(2*512)<br>
2.YOU SAVE SPACE ON YOUR HARD DISK BY 80% FOR THAT<br>
FILE!<br>
3.YOU HAVE SLIGTHLY BETTER SPEED OF YOUR APPLICATION<br>
AND LESS MEMORY AND PAGE FAULT OVERHEAD OF YOUR<br>
SYSTEM<br>
<br>
Good luck!<br>
Georgi<br>
<br>
p.s.<br>
Of course you have to use proper ACCEPT and DISPLAY<br>
verbs in your program (e.g. accept quantity(index)<br>
with CONVERSION - Cobol does automaticaly convert<br>
keyboard data to COMP numeric item)<br>
<br>
<br>

 

[sparrow]

Georgi<br>
<br>
Thanks for the response. That has given me something to think about.<br>
<br>
<br>
Sparrow