Re: ISPF 3.2 (allocate) does not honor SDB
On Tue, 8 Sep 2015 10:29:49 -0300, Clark Morris wrote: >On 7 Sep 2015 22:31:05 -0700, in bit.listserv.ibm-main you wrote: > >What is the track utilization for a PDSE blocksize of 32760? What is >the physical blocksize (CISIZE)? > I believe PDSEs are described in terms not of "blocks", but of "pages", each being 4KiB. What overhead per page there might be, or how the pages are organized in tracks is an OCO matter. One might experiment with various BLKSIZES, perhaps 80, 6160, 20480, and 32720 (32760 is invalid for FB 80); write a few thousand records alike to each, and use DSLIST to measure tracks used. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: AW: Re: ISPF 3.2 (allocate) does not honor SDB
On 7 Sep 2015 22:31:05 -0700, in bit.listserv.ibm-main you wrote:
>>No.
>>Check the archives ("Default System BLKSIZE for PDSE" in Oct 2006)
>>"Partitioned Data Set Extended Usage Guide" (
>>http://www.redbooks.ibm.com/abstracts/sg246106.html?Open ) Figure 10-32 shows
>>a PDSE created 2004-11-04 with SMS.IND=R (SDB) and block size 32720.
>
>
>How embarrassing. I understand I'm at an age where one starts to forget.
>However, I don't understand I just never recognized this behaviour. Anyway,
>thanks for the pointer to that thread. Interesting reading.
What is the track utilization for a PDSE blocksize of 32760? What is
the physical blocksize (CISIZE)?
Clark Morris
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: ISPF 3.2 (allocate) does not honor SDB
>No.
>Check the archives ("Default System BLKSIZE for PDSE" in Oct 2006)
>"Partitioned Data Set Extended Usage Guide" (
>http://www.redbooks.ibm.com/abstracts/sg246106.html?Open ) Figure 10-32 shows
>a PDSE created 2004-11-04 with SMS.IND=R (SDB) and block size 32720.
How embarrassing. I understand I'm at an age where one starts to forget.
However, I don't understand I just never recognized this behaviour. Anyway,
thanks for the pointer to that thread. Interesting reading.
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: ISPF 3.2 (allocate) does not honor SDB
On Mon, 7 Sep 2015 17:59:22 +0200, Peter Hunkeler wrote: >>What type of dataset? PS, PO, PDSE, ...? The optimal block size for PDSE >>(FB-80, DSNTYPE=LIBRARY) is 32720. > >Yes, its about PDSEs. Kind a makes sense, sure. However I have been using >PDSEs for a long time and don't seem to remeber to have seen this. Must have >been blind (meaning I didn't care to look to carefully), obviously. > And the BLKSIZE is largely fictitious: You can OPEN with any BLKSIZE that's a multiple of 80 and process members without error. I suspect it's saved only to appease legacy programs that require that it be supplied in the label. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF 3.2 (allocate) does not honor SDB
On 9/7/2015 5:15 AM, Peter Hunkeler wrote: It seems I'm having a senior moment. For years, I used to allocate data sets in ISPF 3.2, leaving the block size field empty. The system then calculated the block size based on RECFM anf LRECL. The result was half track blocking. At my new employer, I get the block size set to maximum (for RECFM & LRECL), so FB-80 leads to 32720. This is z/OS V2.1. This is only via ISPF 3.2; in batch, I still get half track blocking. What am I missing? FWIW, I get blocksize 32720 on my z/OS V1R4 system. Yes, I have V1R4 running on my trusty old P390. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: ISPF 3.2 (allocate) does not honor SDB
On Mon, 7 Sep 2015 17:59:22 +0200, Peter Hunkeler wrote:
>>What type of dataset? PS, PO, PDSE, ...? The optimal block size for PDSE
>>(FB-80, DSNTYPE=LIBRARY) is 32720.
>
>Yes, its about PDSEs. Kind a makes sense, sure. However I have been using
>PDSEs for a long time and don't seem to remeber to have seen this. Must have
>been blind (meaning I didn't care to look to carefully), obviously.
>
>
>Did this change with z/OS V2.1?
>
No.
Check the archives ("Default System BLKSIZE for PDSE" in Oct 2006)
"Partitioned Data Set Extended Usage Guide" (
http://www.redbooks.ibm.com/abstracts/sg246106.html?Open ) Figure 10-32 shows a
PDSE created 2004-11-04 with SMS.IND=R (SDB) and block size 32720.
Norbert Friemel
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF 3.2 (allocate) does not honor SDB
I had not noticed this behavior for PDSEs. Tried allocating FB-80 PDSE with no blocksize specified. Got 32720 under both R13 and 2.1. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Monday, September 07, 2015 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: ISPF 3.2 (allocate) does not honor SDB >What type of dataset? PS, PO, PDSE, ...? The optimal block size for PDSE >(FB-80, DSNTYPE=LIBRARY) is 32720. Yes, its about PDSEs. Kind a makes sense, sure. However I have been using PDSEs for a long time and don't seem to remeber to have seen this. Must have been blind (meaning I didn't care to look to carefully), obviously. Did this change with z/OS V2.1? -- 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: ISPF 3.2 (allocate) does not honor SDB
>What type of dataset? PS, PO, PDSE, ...? The optimal block size for PDSE >(FB-80, DSNTYPE=LIBRARY) is 32720. Yes, its about PDSEs. Kind a makes sense, sure. However I have been using PDSEs for a long time and don't seem to remeber to have seen this. Must have been blind (meaning I didn't care to look to carefully), obviously. Did this change with z/OS V2.1? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF 3.2 (allocate) does not honor SDB
On Mon, 7 Sep 2015 11:15:01 +0200, Peter Hunkeler wrote: >It seems I'm having a senior moment. > > >For years, I used to allocate data sets in ISPF 3.2, leaving the block size >field empty. The system then calculated the block size based on RECFM anf >LRECL. The result was half track blocking. > > >At my new employer, I get the block size set to maximum (for RECFM & LRECL), >so FB-80 leads to 32720. This is z/OS V2.1. This is only via ISPF 3.2; in >batch, I still get half track blocking. > > >What am I missing? > What type of dataset? PS, PO, PDSE, ...? The optimal block size for PDSE (FB-80, DSNTYPE=LIBRARY) is 32720. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF 3.2 (allocate) does not honor SDB
Here, under V2.1 FB 80 with empty blocksize still gives 27920. It must be something in ACS routines or SDB settings(?). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 07 September, 2015 11:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF 3.2 (allocate) does not honor SDB It seems I'm having a senior moment. For years, I used to allocate data sets in ISPF 3.2, leaving the block size field empty. The system then calculated the block size based on RECFM anf LRECL. The result was half track blocking. At my new employer, I get the block size set to maximum (for RECFM & LRECL), so FB-80 leads to 32720. This is z/OS V2.1. This is only via ISPF 3.2; in batch, I still get half track blocking. What am I missing? -- Peter Hunkeler -- 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
ISPF 3.2 (allocate) does not honor SDB
It seems I'm having a senior moment. For years, I used to allocate data sets in ISPF 3.2, leaving the block size field empty. The system then calculated the block size based on RECFM anf LRECL. The result was half track blocking. At my new employer, I get the block size set to maximum (for RECFM & LRECL), so FB-80 leads to 32720. This is z/OS V2.1. This is only via ISPF 3.2; in batch, I still get half track blocking. What am I missing? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
