I don’t think your problem is CICS buffering. To preserve data integrity CICS writes records out to the ESDS and does not return control to the program until it knows the results. Instead I think your problem has to do with VSAM catalogs.
VSAM keeps extent information (e.g., space extents and record counts) in the catalog in which the dataset is defined. By design, VSAM does not update the extent information until the dataset closes. So, if a file is used all day, the catalog extent data becomes more and more inaccurate as the day wears on.
In your case, when the morning job runs, VSAM reads the extent information from the catalog as of the last close. If your application resets the dataset every night the catalog information given to the batch job will show a small dataset with very few records. Furthermore, your batch job will never read beyond the end of the dataset as noted by the catalog. The afternoon job probably reads more data because the first job closed the file when it finished processing.
You can confirm this behavior by putting an IDCAMS LISTCAT command at the beginning of each job. Chances are the morning LISTCAT will show the extent information from the previous night’s batch processing.
There are a couple of ways around this. One is to close the file to CICS before you run each job. When the cluster closes, VSAM will update the catalog with the latest and greatest extent data. If you can’t afford to close the file to online users, another technique involves creating a file owning region (FOR). The FOR should be set up so it has the file definition but no application transactions. With this set up you can safely open and close the dataset without impacting any online transactions.