Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
> You cited TWO sentences Yes, I cited two consecutive sentences, to provide context.. Why are you ignoring the sentence directly prior my response? > Can it be shorter and more ambigous? It's not ambiguous at all. Had it been a response to the first sentence then it would have directly followed the first sentence. > However YES, there are ZAPs to change it in original IBM code. Aren't there? You used a computer to send that, didn't you? See, I can write irrelevant questions too. I never suggested that there were no such zaps. > Regarding the second sentence - I used quotes. Why? What could it mean? The obvious meaning is that while they are technically legal the SMP documentation warns against them. > Maybe this: ZAP can be done without SMP/E, just load module > modification. Can't it be? Caution: I don't say it is good practise. > In that case such ZAP is somehow illegal from SMP/E point of view. > Isn't it? Not even close. > And last, but not least - I also wrote it is not supported by IBM. Maybe > it is not big issue, but ...isn't it true? Why do you want me to comment on statements that are not in dispute and that don't seem to require clarification? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 2:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 20:35, Seymour J Metz pisze: > Whoosh! What is in dispute is the ludicrous claim '"Illegal" from SMP/E point > of view'. Aps have *never* been Illegal from SMP/E point of view, or even > from the POV of the free SMP versions. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > R.S. [r.skoru...@bremultibank.com.pl] > Sent: Wednesday, January 20, 2021 1:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no > member list) > > W dniu 20.01.2021 o 18:43, Seymour J Metz pisze: >> Nonsense, there's nothing illegal about ++ ZAP. >> >> SMP does what you would expect, including warning you of conflicting service. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> R.S. [r.skoru...@bremultibank.com.pl] >> Sent: Wednesday, January 20, 2021 12:32 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no >> member list) >> >> W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: >>>> There are ZAPs to change it in original IBM code. >>>> "Illegal" from SMP/E point of view >>> No. >>> >> Yes. >> >> -- >> Radoslaw Skorupka >> Lodz, Poland > Nonsense, there are ZAPs to change it. > What is in dispute is written in the messages. You cited TWO sentences and commented it "No." Can it be shorter and more ambigous? However YES, there are ZAPs to change it in original IBM code. Aren't there? Regarding the second sentence - I used quotes. Why? What could it mean? Maybe this: ZAP can be done without SMP/E, just load module modification. Can't it be? Caution: I don't say it is good practise. In that case such ZAP is somehow illegal from SMP/E point of view. Isn't it? And last, but not least - I also wrote it is not supported by IBM. Maybe it is not big issue, but ...isn't it true? Oh, BTW, some answers: No, Yes, You're wrong, PKB, ABC, XYZ. Or maybe single letter ones? BTW2: I used SYSOUT(n) (n is some class) and it fills the expectations - almost all IEBCOPY output is redirected to JES2. Almost all, because some PDSes caused RC=4 and some messages were available on the screen. Unfortunately RC=4 from IEBCOPY caused XMIT to fail. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,http://secure-web.cisco.com/1nG_PE1
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
I believe that 3120 is one of the optimal block sizes for 80 byte records on 3330. At 3120 you get four blocks/track, at 3200 you get only three. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, January 20, 2021 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) On Wed, 20 Jan 2021 10:03:01 -0600, Wendell Lovewell wrote: > >Could you please elaborate on your comment "never solved issue like non-SDB >(system determined blocksize) in XMIT and RECEIVE command"? > Long ago there were discussions here of ISPF SUBMIT's failing because of inadequate (default?) SPACE for its workfiles. The same might apply to TRANSMIT. Likewise old utilities might have hardcoded BLKSIZE (3120? 6144?) suboptimal for recent DASD. But if such utilities were changed to BLKSIZE=0 the larger values supplied by SDB might cause downstream programs to fail. Formerly some utilities (Linkage Editor?) imposed a limit of 3120. I had some Rexx programs fail when EXECIO removed its internal BLKSIZE computation to let SDB operate. Rapidly fixed by APAR, but Support advised "Always code BLKSIZE." An ironic consequence of SDB. >I have been having an issue with TSO RECEIVE (and a program that also calls >IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and >displaying this message: > >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. > >and ending with a return code of 4. The dataset being RECEIVEd is actually >fine, as the LRECL is always less than 27920 (80 in this case). But RECEIVE >sees the RC=4 from IEBCOPY and ends with RC=12. > >IBM currently has case number TS004689510 open for this, but I assumed it was >a new issue although I only have SDB=Y on right now for testing. -- 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
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
W dniu 20.01.2021 o 20:35, Seymour J Metz pisze: Whoosh! What is in dispute is the ludicrous claim '"Illegal" from SMP/E point of view'. Aps have *never* been Illegal from SMP/E point of view, or even from the POV of the free SMP versions. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 18:43, Seymour J Metz pisze: Nonsense, there's nothing illegal about ++ ZAP. SMP does what you would expect, including warning you of conflicting service. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: There are ZAPs to change it in original IBM code. "Illegal" from SMP/E point of view No. Yes. -- Radoslaw Skorupka Lodz, Poland Nonsense, there are ZAPs to change it. What is in dispute is written in the messages. You cited TWO sentences and commented it "No." Can it be shorter and more ambigous? However YES, there are ZAPs to change it in original IBM code. Aren't there? Regarding the second sentence - I used quotes. Why? What could it mean? Maybe this: ZAP can be done without SMP/E, just load module modification. Can't it be? Caution: I don't say it is good practise. In that case such ZAP is somehow illegal from SMP/E point of view. Isn't it? And last, but not least - I also wrote it is not supported by IBM. Maybe it is not big issue, but ...isn't it true? Oh, BTW, some answers: No, Yes, You're wrong, PKB, ABC, XYZ. Or maybe single letter ones? BTW2: I used SYSOUT(n) (n is some class) and it fills the expectations - almost all IEBCOPY output is redirected to JES2. Almost all, because some PDSes caused RC=4 and some messages were available on the screen. Unfortunately RC=4 from IEBCOPY caused XMIT to fail. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / arc
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
Whoosh! What is in dispute is the ludicrous claim '"Illegal" from SMP/E point of view'. Aps have *never* been Illegal from SMP/E point of view, or even from the POV of the free SMP versions. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 18:43, Seymour J Metz pisze: > Nonsense, there's nothing illegal about ++ ZAP. > > SMP does what you would expect, including warning you of conflicting service. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > R.S. [r.skoru...@bremultibank.com.pl] > Sent: Wednesday, January 20, 2021 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no > member list) > > W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: >>> There are ZAPs to change it in original IBM code. >>> "Illegal" from SMP/E point of view >> No. >> > Yes. > > -- > Radoslaw Skorupka > Lodz, Poland Nonsense, there are ZAPs to change it. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,http://secure-web.cisco.com/1cyYZcNASiei6jtps-pasbxw-5aeT14hIeYUgHP5Ow1XUf5weuEdMgl1rKHLbIT_fNK558_ThMwlwdFL_MZ_cmeWuyCvOpQuARQ7dflNIrPxjL8rzaB3MC47-gDyPTxERJWIuCj3f9MtMnHtNvOTWl28K6S0OAHPH9YfzAZPZADkkSYyWWqldKX8L0_2PxusxGrV_cTNKe3j2CLe91UyztR6-Hbbm4aVF2JQ-sOpbxFp3ae1Y8VP6I7YQ7jRrPDIikc8eny7rbBz0i3o2oZ1cFPAXMYUWB_FMUcrk3Nt155gLY2eqcacwzFNgRCtbVugaWPkSIQ31NKtneDKN92ALEapsSzCuU6k-iZHKhsFkOnwE99jC3w760VPBZYobsuFSi3tmYYMmen7aFw5Cj1GLQk-OPLshv41AMiQfM6E_JNXv4oa-gG62HeI8U1WO1sHz/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na http://secure-web.cisco.com/1VoD2-5JoMYlyystLrJe2zfscxQAdOu3yTSgDxIwHhuZCCKsqK5ePDDk5ub-qmGdPhcqn5IDo6I7mMnW6Tyl-f3VsyIuctqc8IXNp1UBRp4_2p8xkkjshKEfkZP7yl0dm2CDtC9EsB3KOFGAJAUQglF2bA-VNfhk5Agx3LX43eoHm2kHNypP2g6UA4sVtt-o1QVJltV4P3nwxZFG12fXVpfZUCJ4UrJc3Im6b7EpR0EmNUlLbwnDHpGR85adxAPTN3Y74xqKYtzn5WPS9BvGjCVKv9e5jcI_T93t1x06hRp__-KQWUpfGUUxAs5MoO0tGNYCwiEEHjnKuhPnPIbFlJLnxNaNx2dgmA5ZF85IGsEbSsBkDo-i_hltQXoesjRFqMPknF0rDkcbN3oMbUbUBZ8h85OawgQH4wvusc05MmZT9m4y2t0V5XTpc0dX1Pfvx/http%3A%2F%2Fwww.mbank.pl%2Frodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,http://secure-web.cisco.com/1cyYZcNASiei6jtps-pasbxw-5aeT14hIeYUgHP5Ow1XUf5weuEdMgl1rKHLbIT_fNK558_ThMwlwdFL_MZ_cmeWuyCvOpQuARQ7dflNIrPxjL8rzaB3MC47-gDyPTxERJWIuCj3f9MtMnHtNvOTWl28K6S0OAHPH9YfzAZPZADkkSYyWWqldKX8L0_2PxusxGrV_cTNKe3j2CLe91UyztR6-Hbbm4aVF2JQ-sOpbxFp3ae1Y8VP6I7YQ7jRrPDIikc8eny7rbBz0i3o2oZ1cFPAXMYUWB_FMUcrk3Nt155gLY2eqcacwzFNgRCtbVugaWPkSIQ31NKtneDKN92ALEapsSzCuU6k-iZHKhsFkOnwE99jC3w760VPBZYobsuFSi3tmYYMmen7aFw5Cj1GLQk-OPLshv41AMiQfM6E_JNXv4oa-gG62HeI8U1WO1sHz/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-02
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
On Wed, 20 Jan 2021 13:13:44 -0500, David Spiegel wrote: >"... Formerly some utilities (Linkage Editor?) imposed a limit of 3120. ..." >Linkage Editor //SYSLIN had a Max BLKSIZE of 3200. > I stand corrected. Damn! So I was needlessly using 3120 all those years. It's mentioned (in an example) in: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bdta500/bdta50085.htm -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
Not sure what the argument is about here, whether you can zap a SMPE module, or whether you *should* zap a SMPE module. We used to have this usermod for Fault Analyzer before it was a dynamic exit ++USERMOD (MSYS013) . ++VER(Z038) FMID(HBB77A0) . ++ZAP (IEAVTABX) . NAME IEAVTABX VER , COUNT FIELD REP ,0001 SET COUNT FIELD VER 0004 4040,4040,4040,4040FIRST UNUSED ENTRY REP 0004 C9C4,C9E7,C4C3,C1D7SET TO IDIXDCAP _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Wednesday, January 20, 2021 1:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** W dniu 20.01.2021 o 18:43, Seymour J Metz pisze: > Nonsense, there's nothing illegal about ++ ZAP. > > SMP does what you would expect, including warning you of conflicting service. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > R.S. [r.skoru...@bremultibank.com.pl] > Sent: Wednesday, January 20, 2021 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no > member list) > > W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: >>> There are ZAPs to change it in original IBM code. >>> "Illegal" from SMP/E point of view >> No. >> > Yes. > > -- > Radoslaw Skorupka > Lodz, Poland Nonsense, there are ZAPs to change it. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or un
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
"... Formerly some utilities (Linkage Editor?) imposed a limit of 3120. ..." Linkage Editor //SYSLIN had a Max BLKSIZE of 3200. On 2021-01-20 11:25, Paul Gilmartin wrote: On Wed, 20 Jan 2021 10:03:01 -0600, Wendell Lovewell wrote: Could you please elaborate on your comment "never solved issue like non-SDB (system determined blocksize) in XMIT and RECEIVE command"? Long ago there were discussions here of ISPF SUBMIT's failing because of inadequate (default?) SPACE for its workfiles. The same might apply to TRANSMIT. Likewise old utilities might have hardcoded BLKSIZE (3120? 6144?) suboptimal for recent DASD. But if such utilities were changed to BLKSIZE=0 the larger values supplied by SDB might cause downstream programs to fail. Formerly some utilities (Linkage Editor?) imposed a limit of 3120. I had some Rexx programs fail when EXECIO removed its internal BLKSIZE computation to let SDB operate. Rapidly fixed by APAR, but Support advised "Always code BLKSIZE." An ironic consequence of SDB. I have been having an issue with TSO RECEIVE (and a program that also calls IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and displaying this message: 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. and ending with a return code of 4. The dataset being RECEIVEd is actually fine, as the LRECL is always less than 27920 (80 in this case). But RECEIVE sees the RC=4 from IEBCOPY and ends with RC=12. IBM currently has case number TS004689510 open for this, but I assumed it was a new issue although I only have SDB=Y on right now for testing. -- 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
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
W dniu 20.01.2021 o 18:43, Seymour J Metz pisze: Nonsense, there's nothing illegal about ++ ZAP. SMP does what you would expect, including warning you of conflicting service. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: There are ZAPs to change it in original IBM code. "Illegal" from SMP/E point of view No. Yes. -- Radoslaw Skorupka Lodz, Poland Nonsense, there are ZAPs to change it. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
Nonsense, there's nothing illegal about ++ ZAP. SMP does what you would expect, including warning you of conflicting service. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: >> There are ZAPs to change it in original IBM code. >> "Illegal" from SMP/E point of view > No. > Yes. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,http://secure-web.cisco.com/1FIZGVOi9h__eH3UGTf5enlGEp10eAz-FFgWUHncEAKJBFI41gLumuLiCSqqavdGZyzdKyDtP92Mp_w1u59Ir64R_FBR4IJXFxaZIA06oY_EzFjka5HNHS-RMDYeuwl-p8NW9-Ntr5Aw1xPfhpqa-JYYUe6an_YC7XBysN_ACBx4IlzzqV_cAYCYuWjrPE2U1h3ObwxTw2ZMxxBiKzl1B0U44StRUDieIit0pL7PlURE0aKEBH0t-2gyA1zVifqRO5vW6HhOBdfCVZR133j0owYsc56FDfNWTM8aelJoRBIhhcBTnhA0_bvqgeP35bhaBLBMsGofH2CHBY379gx3yTU-aPFEi90Y_ap7oOiZ4g0I2F1wrxSytAjIteDmwphJVe3WRazWKozuVA55Civd0Dg6P3TVCHBhv0hRvFTYXCw6cibA3VXqMY35XALVpOSt2/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na http://secure-web.cisco.com/1aC2kFERl2O0EzeSd41iOUQNpmgSzJpcnPiMu5K0zBjkZ4VkC8RAN0VtcBCOOj0nRWfHYW3NrmZWAlfOINf31WW4srQ9G8SOoobionPbafib2PffJJHVN1QDwd4DtmtfiNCoc6OPNwR4WyxP7y-x2kOsrGFUIjm_lfxoHAxtJMz17-UNaNZBbjGaf94P_xFw4oHrTxFMAOQkQZL4qor-MN4cYv942eBecyH1ZjYy-xlNEkCrSZtO--6gJqyEJm4wMoxXWiuMQF1FKRdK0EpycAb9OvwugylyAoJBim1xw3xCqFP8PzRxH7DcHoKSGAEKU7vkxSOLgyiUiW-fN-6Zaq-7R_Onqk3IJWle1LGe9tmfwwSCgXzXhu68A-RgUnGOIdbH9FCeTv4p91d5BR-gXu8Wp_8wsYKX8aDevKJak65tFDBWxsnq2q03DsxQdtnYV/http%3A%2F%2Fwww.mbank.pl%2Frodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,http://secure-web.cisco.com/1FIZGVOi9h__eH3UGTf5enlGEp10eAz-FFgWUHncEAKJBFI41gLumuLiCSqqavdGZyzdKyDtP92Mp_w1u59Ir64R_FBR4IJXFxaZIA06oY_EzFjka5HNHS-RMDYeuwl-p8NW9-Ntr5Aw1xPfhpqa-JYYUe6an_YC7XBysN_ACBx4IlzzqV_cAYCYuWjrPE2U1h3ObwxTw2ZMxxBiKzl1B0U44StRUDieIit0pL7PlURE0aKEBH0t-2gyA1zVifqRO5vW6HhOBdfCVZR133j0owYsc56FDfNWTM8aelJoRBIhhcBTnhA0_bvqgeP35bhaBLBMsGofH2CHBY379gx3yTU-aPFEi90Y_ap7oOiZ4g0I2F1wrxSytAjIteDmwphJVe3WRazWKozuVA55Civd0Dg6P3TVCHBhv0hRvFTYXCw6cibA3VXqMY35XALVpOSt2/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on http://secure-web.cisco.com/1aC2kFERl2O0EzeSd41iOUQNpmgSzJpcnPiMu5K0zBjkZ4VkC8RAN0VtcBCOOj0nRWfHYW3NrmZWAlfOINf31WW4srQ9G8SOoobionPbafib2PffJJHVN1QDwd4DtmtfiNCoc6OPNwR4WyxP7y-x2kOsrGFUIjm_lfxoHAxtJMz17-UNaNZBbjGaf94P_xFw4oHrTxFMAOQkQZL4qor-MN4cYv942eBecyH1ZjYy-xlNEkCrSZtO--6gJqyEJm4wMoxXWiuMQF1FKRdK0EpycAb9OvwugylyAoJBim1xw3xCqFP8PzRxH7DcHo
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
W dniu 20.01.2021 o 18:10, Seymour J Metz pisze: There are ZAPs to change it in original IBM code. "Illegal" from SMP/E point of view No. Yes. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
> There are ZAPs to change it in original IBM code. > "Illegal" from SMP/E point of view No. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, January 20, 2021 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list) W dniu 20.01.2021 o 17:03, Wendell Lovewell pisze: > Radoslaw, > > Could you please elaborate on your comment "never solved issue like non-SDB > (system determined blocksize) in XMIT and RECEIVE command"? > > I have been having an issue with TSO RECEIVE (and a program that also calls > IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and > displaying this message: > > 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. > > and ending with a return code of 4. The dataset being RECEIVEd is actually > fine, as the LRECL is always less than 27920 (80 in this case). But RECEIVE > sees the RC=4 from IEBCOPY and ends with RC=12. > > IBM currently has case number TS004689510 open for this, but I assumed it was > a new issue although I only have SDB=Y on right now for testing. > > Any thoughts? > > ~ Wendell Lovewell I mean the following: try the command XMIT NODE.USER DA(SOME.PDS) OUTDA(XMIT.FILE) and you will get XMIT.FILE as PS FB LRECL=80,BLKSIZE=3120 and that blocksize does not look good nowadays. We have SDB for decades, but not here. There are ZAPs to change it in original IBM code. "Illegal" from SMP/E point of view and no supported by IBM. Not to mention last "few years" we have 3390 geometry with very few exceptions. Nevermind, the only exception we can meet can be 3380. I would bet it is possible to use a little bigger blocksize for both of them if one wants to still support 47k trk. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,http://secure-web.cisco.com/1SR9lJdyiFBq22X-_yGSpj7_2T1N8Sbd5M7tZo3qBRJYE1CMwJyAJXgTze5EeMiWd3a1W25Z8SDirEEwaEvk5-MPv-LZFFCb4dqK9TieC2b50AZSulb80WiJJVy99AxANSyB2BxOiPA-00SaNAjEQuGoNDcqn9C43cWq3zabnmVmfRsfEN1AioF-M-C5ThEnic86okijsVviBrkeFgaLINVlbhsfwprBFiFFPc2n0L_aQmgeZ07tpeqy3WHr5Fwq--g-DMq_k-xFIQ5uaBaGZVkBPzmxINN_6igSlIlSG6bGDjmzu718LuH5Ke-UkpxH1M6hYiD9pCJiZx9quNYJijNOvYGrG7FsdXvILRXsJX-j4GGLLbZYvsj7l6W2syvqRMscJjy-1GU2f4TagHSFOMi8k_zKQgEERayLUXH4z5U56Tc31bOXfj32_b1Z8ocmq8_VEaUFrxXGtuJ767BlW0g/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na http://secure-web.cisco.com/1pyjzPYy_hEkfK21vdGo8mwIvn_SCYxtHwiqczfxqsxlTVquwZ-2zdHnApbyO6FlgoZnD20MwAtk-5xZy0N6rDPEVjlcAAZHBGua41gZU0jN-SAvzdFAt1IUK2KGMavIhsVd3uvvQ5_DFL-YPr-ip35XPIMP0T0DDkdYzrnp4S09Dd9l1cZjF9Mrhu2qx5D4nwg2k6MoOVzPw0kMAWKVhmg0mE6HtPJu3HlR6yA3vO5suL9FdFXoyBt4IrLmBkwd47vYhk0JWe-CLFmowU0KWx6UyS_doeC-ijo_JkM_irylRIH_jhD05FnW9Hm7Vg8Uc8zKXR58gUzc1Sw3nKzXvMwz9Qvf-CAqQqfxaTRNjnthEZ6ryRLtYdoO25qJiDK0QPLm1irl32_i9yNRT5TMV1WIAJ82bH6OR996MN8PgMllpIIM1xH-wyevVD8svMefWRsndC8dpxcmbKM9Y-wTyJw/http%3A%2F%2Fwww.mbank.pl%2Frodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised.
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
On Wed, 20 Jan 2021 10:03:01 -0600, Wendell Lovewell wrote: > >Could you please elaborate on your comment "never solved issue like non-SDB >(system determined blocksize) in XMIT and RECEIVE command"? > Long ago there were discussions here of ISPF SUBMIT's failing because of inadequate (default?) SPACE for its workfiles. The same might apply to TRANSMIT. Likewise old utilities might have hardcoded BLKSIZE (3120? 6144?) suboptimal for recent DASD. But if such utilities were changed to BLKSIZE=0 the larger values supplied by SDB might cause downstream programs to fail. Formerly some utilities (Linkage Editor?) imposed a limit of 3120. I had some Rexx programs fail when EXECIO removed its internal BLKSIZE computation to let SDB operate. Rapidly fixed by APAR, but Support advised "Always code BLKSIZE." An ironic consequence of SDB. >I have been having an issue with TSO RECEIVE (and a program that also calls >IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and >displaying this message: > >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. > >and ending with a return code of 4. The dataset being RECEIVEd is actually >fine, as the LRECL is always less than 27920 (80 in this case). But RECEIVE >sees the RC=4 from IEBCOPY and ends with RC=12. > >IBM currently has case number TS004689510 open for this, but I assumed it was >a new issue although I only have SDB=Y on right now for testing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
W dniu 20.01.2021 o 17:03, Wendell Lovewell pisze: Radoslaw, Could you please elaborate on your comment "never solved issue like non-SDB (system determined blocksize) in XMIT and RECEIVE command"? I have been having an issue with TSO RECEIVE (and a program that also calls IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and displaying this message: 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. and ending with a return code of 4. The dataset being RECEIVEd is actually fine, as the LRECL is always less than 27920 (80 in this case). But RECEIVE sees the RC=4 from IEBCOPY and ends with RC=12. IBM currently has case number TS004689510 open for this, but I assumed it was a new issue although I only have SDB=Y on right now for testing. Any thoughts? ~ Wendell Lovewell I mean the following: try the command XMIT NODE.USER DA(SOME.PDS) OUTDA(XMIT.FILE) and you will get XMIT.FILE as PS FB LRECL=80,BLKSIZE=3120 and that blocksize does not look good nowadays. We have SDB for decades, but not here. There are ZAPs to change it in original IBM code. "Illegal" from SMP/E point of view and no supported by IBM. Not to mention last "few years" we have 3390 geometry with very few exceptions. Nevermind, the only exception we can meet can be 3380. I would bet it is possible to use a little bigger blocksize for both of them if one wants to still support 47k trk. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)
Radoslaw, Could you please elaborate on your comment "never solved issue like non-SDB (system determined blocksize) in XMIT and RECEIVE command"? I have been having an issue with TSO RECEIVE (and a program that also calls IEBCOPY) when SDB is "Y". IEBCOPY is having some sort of problem and displaying this message: 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. and ending with a return code of 4. The dataset being RECEIVEd is actually fine, as the LRECL is always less than 27920 (80 in this case). But RECEIVE sees the RC=4 from IEBCOPY and ends with RC=12. IBM currently has case number TS004689510 open for this, but I assumed it was a new issue although I only have SDB=Y on right now for testing. Any thoughts? ~ Wendell Lovewell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
