View previous topic :: View next topic |
Author |
Message |
srimachan Beginner
Joined: 17 Dec 2002 Posts: 5 Topics: 2 Location: Concord, USA
|
Posted: Tue Dec 17, 2002 6:57 pm Post subject: Block size considerations. |
|
|
FD TEST-FILE
RECORDING MODE F
LABEL RECORDS ARE STANDARD
BLOCK CONTAINS 0 RECORDS
DATA RECORD IS TEST-REC.
I see that the BLOCK CONTAINS statement along with the RECORD CONTAINS statement is used to calculate the block size.
My understanding is that , based on this detail the data read is optimized.
Could someone add more info on the same.
Thanx in advance,
Srimachan. _________________ Keep Smiling |
|
Back to top |
|
|
nxn00 Beginner
Joined: 02 Dec 2002 Posts: 18 Topics: 0 Location: US
|
Posted: Tue Dec 17, 2002 7:39 pm Post subject: |
|
|
Hi, srimachan!
The system will calculate the optimal block size for you. You shouldn't try calculating it for yourself. Your JCL DD statement for that dataset should include in the DCB BLKSIZE=0. _________________ Natalie |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
|
Posted: Tue Dec 17, 2002 7:55 pm Post subject: |
|
|
Srimachan,
Block contains 0 records indicates to the system that information about blocksize should be taken either from JCL or Label. This is done to avoid recompilation of the pgm any time the data set blocksize is changed.
If you code BLKSIZE=0 and if you have SMS at your shop, then the system automatically calculates the optimal blocksize.
Hope this helps...
cheers
kolusu |
|
Back to top |
|
|
srimachan Beginner
Joined: 17 Dec 2002 Posts: 5 Topics: 2 Location: Concord, USA
|
Posted: Tue Dec 17, 2002 7:57 pm Post subject: |
|
|
Thank U all ..
Regards
Srimachan _________________ Keep Smiling |
|
Back to top |
|
|
CaptBill Beginner
Joined: 02 Dec 2002 Posts: 100 Topics: 2 Location: Pasadena, California, USA
|
Posted: Wed Dec 18, 2002 4:17 pm Post subject: |
|
|
One thing about BLOCK CONTAINS and RECORD CONTAINS clauses is that they are really not necessary. If you have them, the length of the RECORD CONTAINS must be the length of the calculated record length based on the PIC clauses in the record. If you are off, you get a compile error. If you change block size, you may get an error during execution, I'm not sure.
I generally do not code anything but BLOCK CONTAINS 0 RECORDS. |
|
Back to top |
|
|
RonB Beginner
Joined: 02 Dec 2002 Posts: 93 Topics: 0 Location: Orlando, FL
|
Posted: Wed Dec 18, 2002 4:44 pm Post subject: |
|
|
CaptBill
You say Quote: | One thing about BLOCK CONTAINS and RECORD CONTAINS clauses is that they are really not necessary | and while that may be true, according to the manual Quote: | If the records in the file are not blocked, the BLOCK CONTAINS clause can be omitted. When it is omitted, the compiler assumes that records are not blocked | ergo, if you leave off the BLOCK CONTAINS clause, the compiler will assume BLOCK CONTAINS 1 RECORD and will allocate buffers accordingly. For output files, that means that any BLKSIZE coded in the JCL will be ignored. For input files, it means that any BLKSIZE larger than the maximum LRECL ( +4 for Variable Length Files ) will result in an ABEND. Unless you INTEND to have unblocked files, ALWAYS code BLOCK CONTAINS 0 RECORDS.
Ron |
|
Back to top |
|
|
CaptBill Beginner
Joined: 02 Dec 2002 Posts: 100 Topics: 2 Location: Pasadena, California, USA
|
Posted: Wed Dec 18, 2002 5:08 pm Post subject: |
|
|
RonB
I guess you didn't see the last line of my original comment.
Quote: | I generally do not code anything but BLOCK CONTAINS 0 RECORDS. |
|
|
Back to top |
|
|
RonB Beginner
Joined: 02 Dec 2002 Posts: 93 Topics: 0 Location: Orlando, FL
|
Posted: Thu Dec 19, 2002 10:37 am Post subject: |
|
|
Yes, I DID see the last line of your original post. But the fact that you "GENERALLY" don't code anything other than BLOCK CONTAINS 0 RECORDS does not educate others in WHY they should NOT OMIT that statement unless they mean to accept the consequences - that is, the inability to process anything other than single record blocks.
My comment, though a response to your post, was not really for your benefit, but for those who may have easily misinterpreted your post.
Ron |
|
Back to top |
|
|
|
|