Hi
A little example from few days ago. Files are 30 years old.
A pds with blksize 6160 that already had members (longer than a block)
1st try:
RECEIVE INDATASET(whatever) OUTDATASET(pds(member)) -> oops really, not possible to allocate
a member. resulting in an abend?
2nd try:
ALLOC FI(MEMBER) da(pds(member))
RECEIVE INDATASET(whatever) OUTFILE(MEMBER)
alles klar auf der Andrea Doria, blocksize got changed to 3120 ;-) IO error when opening with
isredit the old members.
Un petit coup avec IEBGENER to change the blocksize, members are back.
I hadn't touch a "modern" augmented mvs clone in 25 years, so maybe these were
my faults.
All this seems perfectly reasonable, " 'works as designed' since it is 'coded as
designed' " :-)
Best
Peter Sylvester
On 02/03/2021 18:34, Paul Gilmartin wrote:
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
