Re: RECFM=VBS,LRECL=32767?
In 3288864492454705.wa.paulgboulderaim@listserv.ua.edu, on 12/16/2014 at 01:18 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: Why is this considered an error? The buffer length had to fit in a signed[1] half word, and they didn't change that when the large block interface came along. In fact, 32761 is accepted; That I don't understand; I would have expected the cutoff to be 32760. On what rationale is this based? The dead hand of history. [1] Even had it been longer, the 16-bit data length in the count field would still have imposed[2] a 64Ki-1 restriction. [2] Yes, I know about track overflow, but there are issues. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
In 20141216105556.66da404ee6d280833b79b...@gmx.net, on 12/16/2014 at 10:55 AM, nitz-...@gmx.net nitz-...@gmx.net said: These two make up the 6 byte BDW+RDW is 8 bytes. without exceeding geometry. I've seen geometry used to refer to the number of tracks per cylinder, but never for the length field of the count. I guess it makes sense. But note that the length filed is 16 bits unsigned, so it's not the source oif the access method limit. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
In 002901d01953$e00d4390$a027cab0$@q.com, on 12/16/2014 at 09:15 AM, retired mainframer retired-mainfra...@q.com said: Isn't the RDW already included in the LRECL (VBA print files are 137 which leaves 133 for data which includes carriage control)? Isn't the BDW always excluded from the LRECL since only one is present in a block which may contain more than one record)? Aren't the RDW and BDW both 4 bytes each? Yes*3. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any such data set. The explanation I came up with when I tested boundary conditions (VBG) was that 32767 is the maximum allowed for fixed records. And that length was determined by DASD geometry (in the past). A variable length record always has a length field preceding the actual record data. And since this is blocked, you also need length for the block descriptor. These two make up the 6 byte that you cannot specify for lrecl without exceeding geometry. I haven't tested (or if I did, I forgot the results) if it makes a difference when you use RECFM=V(S). The layout is described somewhere in SC26-7410 Using data sets. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
W dniu 2014-12-16 o 08:18, Paul Gilmartin pisze: I get: 6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 STMT NO. MESSAGE 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any such data set. (I like to test boundary conditions.) I don't know what the rationale is (is any at all?), but I know the following: a) official documentations says you can specify 1 to 32760 for PS and 1 to 32761 for VSAM (ES, KS, RR) b) you can use PS RECFM=VBS,LRECL=32767, but you cannot specify the LRECL on DD. c) you can also use LRECL=X for PS V(B)S , but I have never seen it in use. X means LRECL32760. d) to allocate first new PS dataset with LRECL=32676 a trick is needed. Later you can use LIKE. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
On VSAM I suspect it's 32K-7 bytes. The 7 for a CIDF (for the CI) and a RDF (for the one record you could stuff into a 32K CI). Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@LISTSERV.UA.EDU Date: 16/12/2014 11:11 Subject:Re: RECFM=VBS,LRECL=32767? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU W dniu 2014-12-16 o 08:18, Paul Gilmartin pisze: I get: 6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 STMT NO. MESSAGE 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any such data set. (I like to test boundary conditions.) I don't know what the rationale is (is any at all?), but I know the following: a) official documentations says you can specify 1 to 32760 for PS and 1 to 32761 for VSAM (ES, KS, RR) b) you can use PS RECFM=VBS,LRECL=32767, but you cannot specify the LRECL on DD. c) you can also use LRECL=X for PS V(B)S , but I have never seen it in use. X means LRECL32760. d) to allocate first new PS dataset with LRECL=32676 a trick is needed. Later you can use LIKE. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
W dniu 2014-12-16 o 12:13, Martin Packer pisze: On VSAM I suspect it's 32K-7 bytes. The 7 for a CIDF (for the CI) and a RDF (for the one record you could stuff into a 32K CI). Please, note the VSAM can have SPANNED records, longer than 32k. The limit is CA size minus CIDFs and RDFs. So, I couldn't name it rationale or my English is poor. ;-) Regards -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
Paul Gilmartin wrote: I get: 6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 STMT NO. MESSAGE 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? I am still finding it 'Weird', but it is WAD and for backward compatibility or for possible max blocksize to be used. What dataset (VSAM, PS, PDS, OMVS, etc.) are you using? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any such data set. Ok. 32767 is x'7FFF'. I suspect it is something about record length and probably something about ability to store a record length in the first 4 bytes. Granted, for SMF, I cannot use 32767 in JCL, but had to use a lower number (32760 - x'7FF8'), but IFASMFDP will change it to 32767 anyways. It is one of the Big Blue mysteries... ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Tuesday, December 16, 2014 1:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RECFM=VBS,LRECL=32767? 6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any such data set. The explanation I came up with when I tested boundary conditions (VBG) was that 32767 is the maximum allowed for fixed records. And that length was determined by DASD geometry (in the past). A variable length record always has a length field preceding the actual record data. And since this is blocked, you also need length for the block descriptor. These two make up the 6 byte that you cannot specify for lrecl without exceeding geometry. I haven't tested (or if I did, I forgot the results) if it makes a difference when you use RECFM=V(S). The layout is described somewhere in SC26-7410 Using data sets. Isn't the RDW already included in the LRECL (VBA print files are 137 which leaves 133 for data which includes carriage control)? Isn't the BDW always excluded from the LRECL since only one is present in a block which may contain more than one record)? Aren't the RDW and BDW both 4 bytes each? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
W dniu 2014-12-16 o 18:15, retired mainframer pisze: [...] Isn't the RDW already included in the LRECL (VBA print files are 137 which leaves 133 for data which includes carriage control)? Isn't the BDW always excluded from the LRECL since only one is present in a block which may contain more than one record)? Aren't the RDW and BDW both 4 bytes each? BDW and RDW are always 4-bytes each. VBA contains additional character for carriage control LRECL is total length of the record: the content + RDW. Of course LRECL in JCL means maximum LRECL allowable for the records. Block contains BDW and some (at least 1) records. Each record consist of RDW and record content. The above is for RECFM=VB, not for VBS or VS, but if you replace record with segment it will be OK. ;-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
On Tue, 16 Dec 2014 09:15:21 -0800, retired mainframer wrote: 6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. Isn't the RDW already included in the LRECL (VBA print files are 137 which leaves 133 for data which includes carriage control)? Isn't the BDW always excluded from the LRECL since only one is present in a block which may contain more than one record)? Aren't the RDW and BDW both 4 bytes each? All as I understand it. And to muddle things further: user@HOST: rexx say d2x( BPXWDYN( 'alloc recfm(v,b,s) lrecl(32760) msg(2)' ) ) 0 user@HOST: rexx say d2x( BPXWDYN( 'alloc recfm(v,b,s) lrecl(32761) msg(2)' ) ) IKJ56231I UTILITY DATA SET NOT ALLOCATED, SYSTEM OR INSTALLATION ERROR+ IKJ56231I TEXT UNIT X'0042' CONTAINS INVALID PARAMETER 35C0042 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
Oh boy, did someone go off on a tangent. Let me throw in my $0.02 on this: #1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL= #2. From the MVS JCL Reference: the value of LRECL is either: 1 to 32,760 for non-VSAM data sets. Or 1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, data sets.) So specifying 32,767 exceeds the maximum allowed, just as the error message states. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Tuesday, December 16, 2014 12:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RECFM=VBS,LRECL=32767? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Tuesday, December 16, 2014 1:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RECFM=VBS,LRECL=32767? 6 //DD7 DD UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD Why is this considered an error? In fact, 32761 is accepted; 32762 causes the error. On what rationale is this based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any such data set. The explanation I came up with when I tested boundary conditions (VBG) was that 32767 is the maximum allowed for fixed records. And that length was determined by DASD geometry (in the past). A variable length record always has a length field preceding the actual record data. And since this is blocked, you also need length for the block descriptor. These two make up the 6 byte that you cannot specify for lrecl without exceeding geometry. I haven't tested (or if I did, I forgot the results) if it makes a difference when you use RECFM=V(S). The layout is described somewhere in SC26-7410 Using data sets. Isn't the RDW already included in the LRECL (VBA print files are 137 which leaves 133 for data which includes carriage control)? Isn't the BDW always excluded from the LRECL since only one is present in a block which may contain more than one record)? Aren't the RDW and BDW both 4 bytes each? -- 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: RECFM=VBS,LRECL=32767?
On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote: Oh boy, did someone go off on a tangent. Let me throw in my $0.02 on this: #1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL= #2. From the MVS JCL Reference: the value of LRECL is either: 1 to 32,760 for non-VSAM data sets. Or 1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, data sets.) So specifying 32,767 exceeds the maximum allowed, just as the error message states. My question is, why should there be a limit of 32761? I understand the signed halfword format imposes a limit of 32767. I see no reason for any smaller limit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] My question is, why should there be a limit of 32761? I understand the signed halfword format imposes a limit of 32767. I see no reason for any smaller limit. In a VSAM Control Interval (CI), the CIDF is 4 bytes (think BDW) but the RDF is three bytes (think RDW). So, with VSAM you get an extra byte of space. :-) -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
Laxman John T. Abell President International Software Products Tel: 800-295-7608 Ext: 224 International: 1-416-593-5578 Ext: 224 Fax: 800-295-7609 International: 1-416-593-5579 E-mail: john.ab...@intnlsoftwareproducts.com Web: www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 16, 2014 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RECFM=VBS,LRECL=32767? On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote: Oh boy, did someone go off on a tangent. Let me throw in my $0.02 on this: #1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL= #2. From the MVS JCL Reference: the value of LRECL is either: 1 to 32,760 for non-VSAM data sets. Or 1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, data sets.) So specifying 32,767 exceeds the maximum allowed, just as the error message states. My question is, why should there be a limit of 32761? I understand the signed halfword format imposes a limit of 32767. I see no reason for any smaller limit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
On Tue, Dec 16, 2014 at 12:25 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote: Oh boy, did someone go off on a tangent. Let me throw in my $0.02 on this: #1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL= #2. From the MVS JCL Reference: the value of LRECL is either: 1 to 32,760 for non-VSAM data sets. Or 1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, data sets.) So specifying 32,767 exceeds the maximum allowed, just as the error message states. My question is, why should there be a limit of 32761? I understand the signed halfword format imposes a limit of 32767. I see no reason for any smaller limit. -- gil I _think_ that I figured out where the 32760 came from. 32760 == 0x7FF8. It is the largest multiple of 8 which can be kept in a signed half-word. OS/360 used signed half-words to avoid sign extension when using the LH instruction. The original CCW had a two byte size field, so that's likely where the half-word in all the I/O control blocks came from. And we need a multiple of 8 because that's the granularity of the GETMAIN / FREEMAIN allocation. To go to 32767 would really be to require 32768 (due to 8 byte granularity), which is 0x8000. OOPS, there's the nasty sign extension on the LH instruction. And, in OS/360 days, who's going to write that large a block anyway? The only possibility would be on a tape because disk drives in that era didn't have tracks that big. And, in any case, who back then had that much core memory for such a big physical block? We are constrained today by staying backwards compatible. Even today, if I read it correctly, the Large Block Interface for physical records 32760 bytes is _only_ for tape. And, in any case, everybody should just convert to DB2 and not even worry about it. Right? -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
At 12:25 -0600 on 12/16/2014, Paul Gilmartin wrote about Re: RECFM=VBS,LRECL=32767?: x-charset UTF-8On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote: Oh boy, did someone go off on a tangent. Let me throw in my $0.02 on this: #1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL= #2. From the MVS JCL Reference: the value of LRECL is either: 1 to 32,760 for non-VSAM data sets. Or 1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, data sets.) So specifying 32,767 exceeds the maximum allowed, just as the error message states. My question is, why should there be a limit of 32761? I understand the signed halfword format imposes a limit of 32767. I see no reason for any smaller The limit should be 32763. That allows a 32767 byte VB (or VBS) block. With a VB, there is room in a block for the 4 byte BDW and a 5-32763 byte V record (4 byte RDW plus 1-32759 of data). Why the 32760 LRECL Limit I do not know since that wastes 3 bytes in a VB single record record block. limit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN /x-charset -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
On Tue, 16 Dec 2014 16:19:20 -0500, Robert A. Rosenberg wrote: The limit should be 32763. That allows a 32767 byte VB (or VBS) block. With a VB, there is room in a block for the 4 byte BDW and a 5-32763 byte V record (4 byte RDW plus 1-32759 of data). Why the 32760 LRECL Limit I do not know since that wastes 3 bytes in a VB single record record block. The limit should be 32767. Let me explain for the numerically challenged: Suppose I have RECFM=VBS,BLKSIZE=10929,LRECL=32767. I can write 3 blocks, each consisting of: o A BDW (4 bytes) o A SDW (4 bytes) o 10921 bytes of data (total 10929 bytes). The first SDW should indicate that it's an initial segment; the second that it's an interior segment, the last a final segment. The total data are 10921 * 3; 32763 bytes. But LRECL always counts a 4-byte RDW, for a total of 32767. (If the RDW is not to be counted, add another block with 4 bytes of data (a 12-byte block) .) It was explained to me here that page alignment considerations impel buffers a multiple of 4KiB, and that there are a few bytes of overhead, and doubleword alignment considerations impel 32760. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=32767?
On Tue, Dec 16, 2014 at 1:11 PM, John McKown john.archie.mck...@gmail.com wrote: I _think_ that I figured out where the 32760 came from. 32760 == 0x7FF8. It is the largest multiple of 8 which can be kept in a signed half-word. OS/360 used signed half-words to avoid sign extension when using the LH instruction. The original CCW had a two byte size field, so that's likely where the half-word in all the I/O control blocks came from. And we need a multiple of 8 because that's the granularity of the GETMAIN / FREEMAIN allocation. To go to 32767 would really be to require 32768 (due to 8 byte granularity), which is 0x8000. OOPS, there's the nasty sign extension on the LH instruction. And, in OS/360 days, who's going to write that large a block anyway? The only possibility would be on a tape because disk drives in that era didn't have tracks that big. And, in any case, who back then had that much core memory for such a big physical block? We are constrained today by staying backwards compatible. Even today, if I read it correctly, the Large Block Interface for physical records 32760 bytes is _only_ for tape. And, in any case, everybody should just convert to DB2 and not even worry about it. Right? -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. Maranatha! John McKown You could write a block longer than a track using track overflow. What didn't fit on the first track was continued onto the second track or subsequent tracks. Dropped on devices with track sizes over 32K. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
