with the 4.4.5 bugfix, using code based on sample split code, batch size of 500 was selected.
subsequent parsing of the split file revealed 1000 records.
Looking back on the documentation, it should be emphasized:
The batch size is the number of blocks, not the number of records.
My desire was RECFM_VB output to match the input (thus the use of bdw_iter), but I was thinking of batches in records, not blocks. Examining the hex data to answer your question reveals 2 records per BDW
My only recommendation at this point would be for all test data to include multiple RDW per BDW since that is real...make sure all test cases still function under those conditions, which I expect they will.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That indicates a unit testing error.
Here's data used to test a VB file with a BDW and RDW. This is the kind of file that would require a RECFM=VB and would use the
bdw_iter()function.For the iterator to be behaving badly, this file must be improper test data.
A hex dump of the first few bytes of the offending file might provide some insight as to what's wrong with this test case.
Last edit: Steven F. Lott 2015-03-01
Nope, it is a user confusion error.
Looking back on the documentation, it should be emphasized:
The batch size is the number of blocks, not the number of records.
My desire was RECFM_VB output to match the input (thus the use of bdw_iter), but I was thinking of batches in records, not blocks. Examining the hex data to answer your question reveals 2 records per BDW
My only recommendation at this point would be for all test data to include multiple RDW per BDW since that is real...make sure all test cases still function under those conditions, which I expect they will.
Test case revised to show multiple records per block.