Shmuel, I believe that's the way it works for existing files that have been
opened and closed, whether SDB=Y or N. SDB comes into play when a file is
allocated but not written to by the allocating program. This is from the ISMF
help for the SDB setting:
Use the FORCE SYSTEM DETERMINED BLOCKSIZE (SDB) field to specify that
the system ignore a user-specified block size if no program opens the
new data set for writing while it still is allocated. This prevents
the user from overriding a system-determined block size.
Possible values:
Y If no program opens the data set for writing while the new data
set still is allocated, then the system will discard a BLKSIZE
value coded by the user. The system will attempt to calculate an
optimal block size. If a program opens the data set for output
while it still is allocated, then the user-specified BLKSIZE
will take effect and override a system-determined block size.
N If the user specifies a BLKSIZE value, it will take effect and
override a system-determined block size. This is the normal way
for the system to run.
Since IEBCOPY is adjusting the blksize, it must be that RECEIVE did the
allocation first and deallocated the empty file. Then SDB says "I can do
better" & changed the blksize. Then when IEBCOPY is called it says "that's not
right, I'll fix it". Makes me wonder if anyone uses SDB. Plus, how is 32720
an "optimal" block size? Optimal for disk sales? :)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
