If RECEIVE sees that the original PDSE was blksize 27920 and allocates the target that way, then the DSCB will have block size 27920 and SDB should not be invoked. SDB is not supposed to do anything umless the block size is zero in all of DCB, JFCB and DSCB. Either they're lying to you or IEBCOPY is doing OPENJ with "no merge" set. Have you tried escalating?
32720 is a good block size for load libraries. I doubt that it comes from SDB. Can you run some tests of your own? Allocate with BLKSIZE=27920. Open Close Examine -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Wendell Lovewell [[email protected]] Sent: Wednesday, March 3, 2021 10:18 AM To: [email protected] Subject: Re: TSO RECEIVE and System Determined Blksize - New RFE It's hard to tell exactly what's going on under the covers, but as best I've been able to deduce in this particular case is: 1) RECEIVE reads the INMR02 record, sees the original PDSE was blksize 27920 and allocates it that way, but does not open it. 2) SDB steps in, says "they really want 32720" and changes the (VTOC?) entry to that. (32720 seems like a really poor choice) 3) IEBCOPY is called, opens the 32720 file, starts reloading the file and notices that it should be 27920 (not sure how), issues IEB1139W, & RC4 4) RECEIVE sees IEBCOPY's RC4, says 'uh-oh' (technical term), ends with RC12 Why is it not a bug? That's a really good question Shmuel. Imo it is a bug. I've been going back and forth with IBM to correct it since December. I'm honestly not sure they ever really understood what was going on, even when the job was as simple as this: //TRANRECV JOB CLASS=A //EXP EXPORT SYMLIST=(*) //* // SET INFILE=&SYSUID..TESTLIB // SET XMIFILE=&SYSUID..TESTLIB.XMIT // SET OUTFILE=&SYSUID..TESTLIB.NEW //* //TRANSMIT EXEC PGM=IKJEFT01,DYNAMNBR=05 //SYSTSPRT DD SYSOUT=* //INFILE DD DISP=SHR,DSN=&INFILE //XMIFILE DD DSN=&XMIFILE,DISP=(NEW,PASS), // DCB=(DSORG=PS),LIKE=&INFILE //SYSTSIN DD *,SYMBOLS=(JCLONLY) TRANSMIT,SYS1.&SYSUID.,DDNAME(INFILE), + OUTDDNAME(XMIFILE) /* //* //RECEIVE EXEC PGM=IKJEFT01,DYNAMNBR=05 //MSGFILE DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //XMIT DD DISP=SHR,DSN=&XMIFILE //SYSTSIN DD *,SYMBOLS=(JCLONLY) RECEIVE INDDNAME(XMIT), DA('&OUTFILE') // Every week or two IBM support would give me some reason why it couldn't be done. Once it was "just turn off SDB for that job". Finally they said "It's not possible, open an RFE.". You can read the whole story here if you want: https://www.ibm.com/mysupport/s/case/5003p00002TsDUDAA3/iebcopy-msg-ieb1139w-incorrectly-generated-when-systemdeterminedblocksize-yes Or, just vote early, vote often here: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=148961 Thanks to those of you who have already voted. Paul, I believe it's a problem with RECEIVE because RECEIVE is pre-allocating the file. All it would need to do is open and close the file before calling IEBCOPY and SDB would stay out of it--SDB doesn't get involved if the program that allocates the file also opens it. But IEBCOPY could have also noted that the file was empty when it started and therefore known it was ok to change the DCB information & not RC=4. (If the file weren't empty, the IEB1139W message would be warranted.) Wendell ---------------------------------------------------------------------- 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
