BLKSIZE=0 requests "System-Determined Block size". It is indeed the best option. Presumably the "system" has all the relevant facts and knowledge at its disposal. Which is likely at least as much as you know.
However, BLKSIZE is one of the many things carried over from medieval times where the amount of core used, how long your reads stayed connected to a channel, how efficiently DASD at $1000/mb was used, and various other no-longer-relevant considerations factored into that specification. sas On Mon, May 6, 2019 at 2:08 PM Paul Gilmartin < [email protected]> wrote: > On Mon, 6 May 2019 16:44:47 +0000, Seymour J Metz wrote: > > >Not that I know of, other then the SMF records for the input and output. > >________________________________________ > >From: Paul Gilmartin > >Sent: Friday, May 3, 2019 1:42 PM > > > >When IEBCOPY reblocks a module, does it leave any audit trail? That > >might be of interest in case of the OP's problem. > > > Amidst the nattering about 32760 vs. half-track vs. 4KiB vs. ... > I suggested coding BLKSIZE=0. That received neither support nor > opposition. So, I wonder: > > Does coding BLKSIZE=0 ever lead to complete failure of a utility or > product? > I encountered one many years ago. It was promptly fixed by APAR. > > Does BLKSIZE=0 ever lead to suboptimum performance? > > There might be trivial exceptions for unlabelled tapes with DISP=MOD > or for IEBGENER where SYSUT1 is already adversely blocked. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
