I believe that the DCB information specified by the program should take 
precedent. However, I also believe that a utility should not override the block 
size of an existing dataset. When dataset has an existing blocksize and the DD 
or DYNALLOC has a different blocksize, then I believe that OPEN should provide 
a warning message unless the no-reverse-merge bit is set.

In particular, RECEIVE should use the existing nonzero target block size, 
otherwise use the block size from the source, and XMIT to a dataset should use 
the existing nonzero block size of the target if the is one.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [[email protected]] on behalf of 
Paul Gilmartin [[email protected]]
Sent: Tuesday, March 2, 2021 12:34 PM
To: [email protected]
Subject: Re: TSO RECEIVE and System Determined Blksize - New RFE

On Tue, 2 Mar 2021 16:02:35 +0000, Seymour J Metz  wrote:

>Why is that an enhancement rather than a bug fix? Isn't SDB supposed to be 
>active only if BLKSIZE=0? Are you sure that RECEIVE allocated the target with 
>a nonzero block size?
>
To what extent do programmers approve the OS's overriding
programmer-specified parameters with values that utilities
deem optimal?

For example, when IBM changed the default(!) BUFNO from
2 to 5, the OS correspondingly began adjusting REGION
upward.  (How could it know how much?)

What's proper?
o Quietly override?
o Override with message as below?
o Accept programmer's value, but issue warning?
o Quietly accept programmer's values?

This may be more complicated if RECEIVE calls a utility and
supplies an option for how that utility may adjust BLKSIZE.

At the advent of SDB, IEBGENER first switched to honoring
SDB, then by APAR reverted to the classical behavior of
replicating the SYSUT1 BLKSIZE with PARM to use SDB,
then a PARM value to convert LBI for a DASD  SYSUT2 ...

The BLKSIZEs below are multiples of 80.  Perhaps a
programmer had allocated DSORG=PO,RECFM=FB,BLKSIZE=32720
but IEBCOPY had a better idea.

That's an IEB message, not IKJ.

>________________________________________
>From: Wendell Lovewell
>Sent: Tuesday, March 2, 2021 10:35 AM
>
>If anyone has had a problem trying to use System Determined Blocksize with TSO 
>RECEIVE and getting a message IEB1139W like:
>
>IEB1139W THE OUTPUT DATA SET BLOCK SIZE IS BEING REDUCED FROM 32720 TO 27920 
>BYTES.  ANY EXISTING PHYSICAL RECORDS LONGER THAN 27920 BYTES ARE FAT BLOCKS 
>AND MAY CAUSE I/O ERRORS.
>
>...because SDB was changing the blksize between the time RECEIVE allocated the 
>file according to the DCB information in the INMR02 record in the XMIT file 
>and the time IEBCOPY tries to open it, I've opened an RFE in the hopes that 
>IBM will correct the problem.
>
>Please consider watching and/or voting for RFE # 148961: TSO RECEIVE should 
>correctly handle System Defined Blocksize = YES
>at
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=148961
>
>Thanks for your support.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to