AW: Re: No BDW for RECFM=V was Re: 32767?
> The z/OS 2.2 manual has the same diagram, but KC search didn't find it. The diagram is a bit confusing because where it shows the unblocked records, Record B is not shown with the BDW, but Record A and Record C are. This is an erroneous remake of the diagram as it existed in old manuals, e.g. DFSMS V1.3 (i.e. pre-OS/390 & z/OS era). I just had a look at the diagram there and it shows the BDW also for record b. It is drawn using "-", "+", and "|" to draw boxes. The docwriter who draw the new diagram obviously misinterpreted the old one ( I think it is clear). -- ßph -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: No BDW for RECFM=V was Re: 32767?
On Fri, 16 Dec 2016 13:03:04 -0600, Tom Marchant wrote: >On Fri, 16 Dec 2016 10:16:12 -0400, Clark Morris wrote: > >>For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just >>checked Knowledge center. > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_1.13.0/com.ibm.zos.r13.idad400/d4356.htm > >The z/OS 2.2 manual has the same diagram, but KC search didn't >find it. The diagram is a bit confusing ... > Did you submit an RCF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: No BDW for RECFM=V was Re: 32767?
On Fri, 16 Dec 2016 10:16:12 -0400, Clark Morris wrote: >For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just >checked Knowledge center. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_1.13.0/com.ibm.zos.r13.idad400/d4356.htm The z/OS 2.2 manual has the same diagram, but KC search didn't find it. The diagram is a bit confusing because where it shows the unblocked records, Record B is not shown with the BDW, but Record A and Record C are. Figure 44 shows blocked and unblocked variable-length (format-V) records without spanning. A block in a data set containing unblocked records is in the same format as a block in a data set containing blocked records. The only difference is that with blocked records each block can contain multiple records. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: No BDW for RECFM=V was Re: 32767?
>For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just checked Knowledge center. I might missread your statement, but if you meant to say that a block in a RECFM=V data set does *not have a BDW, only the record has its RDW, then this is *not* true. Every RECFM=V block starts with a BDW decribing the length of that block. Inside the block, there are one or more records, each starting with a RDW, describing the length of that record (and some flags for the spanned format RECFM=V...S). - Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: 32767?
>It is NOT true that RECFM=V on z/OS has ONLY an RDW. I did not claim that. (Did you want to reply to a different post than mine?) >RECFM=V on z/OS has BOTH the BDW and the RDW. Just what I said, and the BDW is 4 bytes. -- Peter Hunkeler -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Friday, December 16, 2016 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: 32767? >The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a RECFM=VB dataset. When it comes to BLKSIZE versus LRECL, there is *no* difference between RECFM=V and RECFM=VB. And even the print control character variants with the additional A or M in th RECFM do not make it any different. A block is a block and a such it has a 4 byte BDW (for RECFM=V only, of course). To "B" or not only tells the reader or writer code whether exactly one or possibly multiple logical records are in the block. It doesn't change the format of the block. -- Peter Hunkeler -- 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
Re: 32767?
On Fri, 16 Dec 2016 07:34:46 -0600, Tom Marchant wrote: > >The maximum BLKSIZE for DASD is 32760. > In fact: z/OS 2.2.0 z/OS DFSMS z/OS DFSMS Using Data Sets Non-VSAM Access to Data Sets and UNIX Files Specifying and Initializing Data Control Blocks Selecting Data Set Options Block Size (BLKSIZE) If you do not use the large block interface (LBI), the maximum block size is 32␠760 except ... My motivation: I have an EXEC that extracts all the spool files for a job, passing DDNAMES generated by the SDSF Rexx API as SYSUT1 to IEBGENER. When I test on an edge condition, I get S013-68. Support was unable to reproduce the failure using EXECIO in place of my IEBGENER. (They recently tried IEBGENER and reproduced it; they've sent me a fixtest, not yet tried.) But I'm experimenting and trying to imagine why EXECIO accepts files that IEBGENER rejects. I suppose it's possible that EXECIO uses LBI and IEBGENER does not. The examples in the Manual generally use EXECIO, not IEBGENER. http://trevorjim.com/postels-law-is-not-for-you/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
On Fri, 16 Dec 2016 06:01:56 -0600, Bill Woodger wrote: > >The RC for the message goes up steps of four, and is already busted. Other RC >values have multiple items. Some are not even inclusive, and probably can't be. > >I think it is unrealistic to expect a separate RC for each possible >combination of something which is invalid. > Not for "each possible combination" but it should specifically identify one particular violation. The the programmer can repair that; re-test and iteratively fix the remaining up to seven problems. "busted" I've had some facilities give me a 32-bit RC. Surely that's enough. Whereby hangs a sad tale. Rexx takes that 32-bit RC and displays it in decimal. It used to truncate to 8 digits; now it extends to 9 or 10 if needed. (My APAR; thanks). But still decimal whereas the diagnostic manuals are mostly hex. Maybe time for an RFE. Except the more useful behavior would be incompatible. "steps of 4"? Why? Who depends on that nowadays? On Fri, 16 Dec 2016 07:41:59 -0500, Tony Thigpen wrote: > >Does anybody know (historically) why z/OS does not support a true 32K >block? z/VSE has supported it since "way back" in the DOS days. > I've asked this question here, repeatedly. The mostly satisfactory answer was that buffers should page-aligned for performance, and a few bytes of overhead are required. And when the rule was made no DASD supported records so large, and no one could affort the core storage for such buffers anyway. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
It is NOT true that RECFM=V on z/OS has ONLY an RDW. RECFM=V on z/OS has BOTH the BDW and the RDW. RECFM=V on DOS has only a 4-byte RDW. NOTE: THE INFILE VFILE IS is RECFM=V,LRECL=32756,BLKSIZE=32760 When read with RECFM=U you can see both the BDW and the RDW. RULE: +1+2+3+4+5+6+7+- ---8+9+0 1 CHAR THIS IS THE TEST STRING IN RECFM V 42 ZONE 02000200ECCE4CE4ECC4ECEE4EEDCDC4CD4DCCCD4E NUMR 0A0006003892092038503523023995709509536405 Barry Merrill Merrilly yours, Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive technical questions: supp...@mxg.com Dallas, TX 75229 http://www.mxg.comadmin questions: ad...@mxg.com tel: 214 351 1966 fax: 214 350 3694 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Friday, December 16, 2016 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: 32767? >The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a RECFM=VB dataset. When it comes to BLKSIZE versus LRECL, there is *no* difference between RECFM=V and RECFM=VB. And even the print control character variants with the additional A or M in th RECFM do not make it any different. A block is a block and a such it has a 4 byte BDW (for RECFM=V only, of course). To "B" or not only tells the reader or writer code whether exactly one or possibly multiple logical records are in the block. It doesn't change the format of the block. -- Peter Hunkeler -- 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: No BDW for RECFM=V was Re: 32767?
On Fri, 16 Dec 2016 10:16:12 -0400, Clark Morris wrote: > >For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just >checked Knowledge center. > Cite, please (more precisely than "KC"). I find: z/OS 2.2.0 z/OS DFSMS z/OS DFSMS Using Data Sets Non-VSAM Access to Data Sets and UNIX Files Specifying and Initializing Data Control Blocks Selecting Data Set Options Block Size (BLKSIZE) If format-V records are unblocked, the block size must be 4 bytes greater than the record length (LRECL). If you find a contradictory topic, one of us should submit an RCF. It doesn't say: o Whether the 4 required additional bytes are used for a BDW or simply unused. o Whether BLKSIZE must be exactly or at least 4 bytes greater tnan LRECL. In my experience, BSAM uses the BDW to set the count in the CCW, so I'd not be surprised if it used the same code for unblocked records and required a BDW. But: Selecting Record Formats for Non-VSAM Data Sets Variable-Length Record Formats Format-V Records Figure 1 shows blocked and unblocked variable-length (format-V) records without spanning. A block in a data set containing unblocked records is in the same format as a block in a data set containing blocked records. The only difference is that with blocked records each block can contain multiple records. If you find a contradictory topic, one of us should submit an RCF. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: 32767?
>The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a >RECFM=VB dataset. When it comes to BLKSIZE versus LRECL, there is *no* difference between RECFM=V and RECFM=VB. And even the print control character variants with the additional A or M in th RECFM do not make it any different. A block is a block and a such it has a 4 byte BDW (for RECFM=V only, of course). To "B" or not only tells the reader or writer code whether exactly one or possibly multiple logical records are in the block. It doesn't change the format of the block. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
No BDW for RECFM=V was Re: 32767?
[Default] On 16 Dec 2016 05:34:12 -0800, in bit.listserv.ibm-main 000a2a8c2020-dmarc-requ...@listserv.ua.edu (Tom Marchant) wrote: >On Fri, 16 Dec 2016 07:22:59 +, Vernooij, Kees wrote: > >>The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a >>RECFM=VB dataset. For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just checked Knowledge center. Clark Morris > >For a RECFM=V data set, BLKSIZE must indeed be 4 greater than LRECL. >That is to allow room for the Block Data Word. The Record Data Word is >included in LRECL. For a RECFM-VB data set, the BLKSIZE must be at >least 4 bytes greater than LRECL. > >For RECFM=VS or VBS, the BLKSIZE can be smaller than these limits. > >The maximum BLKSIZE for DASD is 32760. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
On Fri, 16 Dec 2016 07:22:59 +, Vernooij, Kees wrote: >The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a >RECFM=VB dataset. For a RECFM=V data set, BLKSIZE must indeed be 4 greater than LRECL. That is to allow room for the Block Data Word. The Record Data Word is included in LRECL. For a RECFM-VB data set, the BLKSIZE must be at least 4 bytes greater than LRECL. For RECFM=VS or VBS, the BLKSIZE can be smaller than these limits. The maximum BLKSIZE for DASD is 32760. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
32760 is the maximum blocksize. You have an LRECL of 32760, which is not at least four bytes less than the maximum blocksize. The RC for the message goes up steps of four, and is already busted. Other RC values have multiple items. Some are not even inclusive, and probably can't be. I think it is unrealistic to expect a separate RC for each possible combination of something which is invalid. You didn't get a 20, so something was more twisted than would be normal for this type of error. 34 looks like a catch-all "you've done something 'illogical', you'd best fix it". You could experiment and perhaps find other illogical things which cause a 34. The message-text could perhaps have a main part which is more explicit, and the individual items listed as a "possible explanations" without the implication that all possible causes are covered. It is like trying to document the exact results of "undefined behaviour", and keeping it up-to-date with each change to the software. Now, what happens if you change your LRECL to 32752 at most? Does it "work" (keeping your 32767 for BLKSIZE) and does it give you 32760 for the actual BLKSIZE, or does it fail, and how? With a V rather than VB, you can get to LRECL 32756. So, you've broken three limits (BLKSIZE, LRECL for V, LRECL for VB), and you want a specific RC and message for that, plus, implicitly, additional RCs and specific messages for assorted combinations? I don't think anyone would find that worth the effort, or possible for all "illogical combinations of parameters" possible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
I'm still before first coffee, but I would rephrase it:
The BLKSIZE must be 4 more than *usable record length* for a RECFM=V
dataset and 8 for a RECFM=VB dataset.
LRECL is (max) record lentgh *including* RDW, not just user data.
Picture:
RDW-user_data...
BWD-RDW-user_data
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2016-12-16 o 08:22, Vernooij, Kees (ITOPT1) - KLM pisze:
Sorry, I mixed up some things (before the first coffee).
Rewrite:
The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a
RECFM=VB dataset.
You are right that, although bullet 5 is applicable, it is incorrect or at
least incomplete. You must be able to SR this.
Thanks,
Kees.
-Original Message-
From: Vernooij, Kees (ITOPT1) - KLM
Sent: 16 December, 2016 8:20
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: 32767?
The reason is (you know, I suppose) that blksize must be 8 (4 for the RDW +4
for the BDW) less than lrecl for a VB dataset.
Reading the possible errors, you could see that bullet 5 is applicable to you,
although it says '4' i.s.o. '8'. 4 is for RECFM=V, 8 for RECFM=FB.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: 16 December, 2016 1:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 32767?
9 *-* say BPXWDYN( 'alloc dd(SYSUT1) path(''/etc/services'')
filedata(TEXT)' ,
'recfm(V,B) LRECL(32760) blksize(32767) reuse msg(WTP)' )
>>>"0"
0
11*-* address 'MVS' 'EXECIO * DISKR SYSUT1 (finis stem JUNK.'
>>>"EXECIO* DISKR SYSUT1 (finis stem JUNK."
12*-* say JUNK.0
>>>"203"
203
???
IEBGENER fails (as it should) with the same SYSUT1:
IEC141I 013-34,IGG0199G,user,$STCTSO1,SYSUT1
IRX0250E System abend code 013, reason code 0052.
... And here I'm dissatisfied. M gives eight possible explanations for
RC=34.
That's bad. Each reason should have a distinct reason code rather than
requiring
the programmer to investigate each of the eight.
And here, none of the eight seems to apply. If someone can't supply what I fail
to understand, I may go to SR.
And damn Rexx for showing RC in decimal when all the reference material show
hex!
Postel's law was a bad idea.
-- gil
---
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.2016 r. kapitał zakładowy mBanku S.A. (w całości
wpłacony) wynosi 168.955.696 złotych.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
Sorry, I mixed up some things (before the first coffee).
Rewrite:
The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a
RECFM=VB dataset.
You are right that, although bullet 5 is applicable, it is incorrect or at
least incomplete. You must be able to SR this.
Thanks,
Kees.
-Original Message-
From: Vernooij, Kees (ITOPT1) - KLM
Sent: 16 December, 2016 8:20
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: 32767?
The reason is (you know, I suppose) that blksize must be 8 (4 for the RDW +4
for the BDW) less than lrecl for a VB dataset.
Reading the possible errors, you could see that bullet 5 is applicable to you,
although it says '4' i.s.o. '8'. 4 is for RECFM=V, 8 for RECFM=FB.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: 16 December, 2016 1:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 32767?
9 *-* say BPXWDYN( 'alloc dd(SYSUT1) path(''/etc/services'')
filedata(TEXT)' ,
'recfm(V,B) LRECL(32760) blksize(32767) reuse msg(WTP)' )
>>> "0"
0
11 *-* address 'MVS' 'EXECIO * DISKR SYSUT1 (finis stem JUNK.'
>>> "EXECIO * DISKR SYSUT1 (finis stem JUNK."
12 *-* say JUNK.0
>>> "203"
203
???
IEBGENER fails (as it should) with the same SYSUT1:
IEC141I 013-34,IGG0199G,user,$STCTSO1,SYSUT1
IRX0250E System abend code 013, reason code 0052.
... And here I'm dissatisfied. M gives eight possible explanations for
RC=34.
That's bad. Each reason should have a distinct reason code rather than
requiring
the programmer to investigate each of the eight.
And here, none of the eight seems to apply. If someone can't supply what I fail
to understand, I may go to SR.
And damn Rexx for showing RC in decimal when all the reference material show
hex!
Postel's law was a bad idea.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 32767?
The reason is (you know, I suppose) that blksize must be 8 (4 for the RDW +4
for the BDW) less than lrecl for a VB dataset.
Reading the possible errors, you could see that bullet 5 is applicable to you,
although it says '4' i.s.o. '8'. 4 is for RECFM=V, 8 for RECFM=FB.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: 16 December, 2016 1:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 32767?
9 *-* say BPXWDYN( 'alloc dd(SYSUT1) path(''/etc/services'')
filedata(TEXT)' ,
'recfm(V,B) LRECL(32760) blksize(32767) reuse msg(WTP)' )
>>> "0"
0
11 *-* address 'MVS' 'EXECIO * DISKR SYSUT1 (finis stem JUNK.'
>>> "EXECIO * DISKR SYSUT1 (finis stem JUNK."
12 *-* say JUNK.0
>>> "203"
203
???
IEBGENER fails (as it should) with the same SYSUT1:
IEC141I 013-34,IGG0199G,user,$STCTSO1,SYSUT1
IRX0250E System abend code 013, reason code 0052.
... And here I'm dissatisfied. M gives eight possible explanations for
RC=34.
That's bad. Each reason should have a distinct reason code rather than
requiring
the programmer to investigate each of the eight.
And here, none of the eight seems to apply. If someone can't supply what I fail
to understand, I may go to SR.
And damn Rexx for showing RC in decimal when all the reference material show
hex!
Postel's law was a bad idea.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
32767?
9 *-* say BPXWDYN( 'alloc dd(SYSUT1) path(''/etc/services'')
filedata(TEXT)' ,
'recfm(V,B) LRECL(32760) blksize(32767) reuse msg(WTP)' )
>>> "0"
0
11 *-* address 'MVS' 'EXECIO * DISKR SYSUT1 (finis stem JUNK.'
>>> "EXECIO * DISKR SYSUT1 (finis stem JUNK."
12 *-* say JUNK.0
>>> "203"
203
???
IEBGENER fails (as it should) with the same SYSUT1:
IEC141I 013-34,IGG0199G,user,$STCTSO1,SYSUT1
IRX0250E System abend code 013, reason code 0052.
... And here I'm dissatisfied. M gives eight possible explanations for
RC=34.
That's bad. Each reason should have a distinct reason code rather than
requiring
the programmer to investigate each of the eight.
And here, none of the eight seems to apply. If someone can't supply what I fail
to understand, I may go to SR.
And damn Rexx for showing RC in decimal when all the reference material show
hex!
Postel's law was a bad idea.
-- 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?
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
RECFM=VBS,LRECL=32767?
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.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
