I would describe changing the block size of an existing dataset to a hard wired value as "Broken As Designed (BAD)".
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Sylvester [peter.sylves...@gmail.com] Sent: Tuesday, March 2, 2021 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize - New RFE 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
