Yes, you are right.
However I observed benefits on DASD array connected using 8 channels
FICON Express16S+ with utilization below 10%.
BTW: it was all flash array with big cache.
However you mentioned important thing, which I didn't mention - whole
process "from memory to disk". I mean MVS,
One of the benefits of striping is that you can do I/O in parallel, for
example have 4 concurrent I/Os, so you reduce the "connect time" for
transmission of data.
Once the data gets to the end of the cable into the Storage Controller, it
tends to be caught in cache, and should not matter what
W dniu 09.03.2021 o 18:21, Paul Gilmartin pisze:
On Tue, 9 Mar 2021 12:42:34 +0100, Radoslaw Skorupka wrote:
Striped PS datasets (extended format PS) are managed by IEBGENER,
ICEGENER or IDCAMS as regular (non-striped) datasets. I mean user
perspective.
In other words, transparent to the
On Tue, 9 Mar 2021 12:42:34 +0100, Radoslaw Skorupka wrote:
>
>Striped PS datasets (extended format PS) are managed by IEBGENER,
>ICEGENER or IDCAMS as regular (non-striped) datasets. I mean user
>perspective.
>
In other words, transparent to the utility or user program, with at
most changes to
W dniu 08.03.2021 o 18:42, Paul Gilmartin pisze:
On Mon, 8 Mar 2021 11:15:56 -0600, Nigel Morton wrote:
Have you considered using extended format sequential striped data sets?
Define using a data class with DSNTYPE set to require or request extended
format; control the number of stripes
On Mon, 8 Mar 2021 18:47:30 +, Farley, Peter x23353 wrote:
>Why wouldn't they be totally compatible? ...
>
This sort of thing depends on the utility. For example,
AMATERSE PARM=UNPACK refuses to deal with //SYSUT1 DD PATH=...
But I can fool it with:
//SYSUT1 DD
: Re: Large block interface for VB
Why wouldn't they be totally compatible? I would think that striping occurs at
a much lower level than QSAM (probably EXCP or lower? maybe "Media Manager"
level?) so one would expect that QSAM wouldn't even know it was
On Behalf Of
Farley, Peter x23353
Sent: 08 March 2021 18:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
Why wouldn't they be totally compatible? I would think that striping occurs at
a much lower level than QSAM (probably EXCP or lower? maybe "Media Manager"
d know who won that particular game, or if it even matters in the
final analysis now that real CKD are gone.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Monday, March 8, 2021 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block
On Sun, 7 Mar 2021 15:42:33 -0600, Paul Gilmartin wrote:
>>...
>>Don't know about striped RAID. I suspect there's no software support
>>for the desirable parallel I/O.
>Are such data sets compatible with Classic utilities such as IEBGENER
> or Assembler programs using QSAM?
QSAM or BSAM are
On Mon, 8 Mar 2021 11:15:56 -0600, Nigel Morton wrote:
>Have you considered using extended format sequential striped data sets?
>
>Define using a data class with DSNTYPE set to require or request extended
>format; control the number of stripes (which are read in parallel) using a
>storage class
Have you considered using extended format sequential striped data sets?
Define using a data class with DSNTYPE set to require or request extended
format; control the number of stripes (which are read in parallel) using a
storage class with a non-zero sustained data rate attribute. Choosing the
On Sun, 7 Mar 2021 16:39:54 +0100, Radoslaw Skorupka wrote:
>
>The problem is I have never seen LBI block on DASD.
>Can I allocate such dataset using ISPF 3.2 or JCL DD ?
>Can I copy existing LBI dataset using IEBGENER or IDCAMS?
>
>It's more or less like long member names in PDSE. They exist,
On Sun, Mar 07, 2021 at 01:13:26PM -0500, Joseph Reichman wrote:
> That’s what I’m trying I.E overlapped i/o
>
> BSAM
In the old days with real "count key data" (CKD) disks the fastest you
could read a disk depended on the disk rotational speed and it was only
possible to run one read per disk
No. I think there is no significant performance difference between
half-track and full-track blocksize and there is significant difference
in support of nonstandard blocksize.
I just wanted to advice, nothing more.
For tapes (especially physical ones) I would suggest the largest
blocksize
In other words you don’t think bufno / ncp
And overlapped I/O will produce anything significant
> On Mar 7, 2021, at 2:14 PM, Radoslaw Skorupka wrote:
>
> Joseph,
>
> There is some nuance missing. I wrote about *significant* difference.
> Actually I should say the difference is
Joseph,
There is some nuance missing. I wrote about *significant* difference.
Actually I should say the difference is negligible.
I really don't know your application, however I guess such blocksize
change will not help you. I have suggested some other techniques to
consider instead.
IMHO
That’s what I’m trying I.E overlapped i/o
BSAM
> On Mar 7, 2021, at 12:40 PM, Clark Morris wrote:
>
> [Default] On 7 Mar 2021 07:57:02 -0800, in bit.listserv.ibm-main
> reichman...@gmail.com (Joseph Reichman) wrote:
>
>> If you read a larger number of bytes into core let’s say above the bar
[Default] On 7 Mar 2021 07:57:02 -0800, in bit.listserv.ibm-main
reichman...@gmail.com (Joseph Reichman) wrote:
>If you read a larger number of bytes into core lets say above the bar less
>I/o should speed things up no ?
>
If you have a large enough number of buffers, the difference should be
If you read a larger number of bytes into core let’s say above the bar less I/o
should speed things up no ?
> On Mar 7, 2021, at 10:40 AM, Radoslaw Skorupka wrote:
>
> W dniu 06.03.2021 o 16:50, Laddie Hanus pisze:
>> LBI is available on DASD the largest block that will fit on 1 track, on
W dniu 06.03.2021 o 16:50, Laddie Hanus pisze:
LBI is available on DASD the largest block that will fit on 1 track, on the
3390 thats about 56K. Logical record (LRECL) is still limited to 32760, This is
for new datasets being written. Existing datasets will read one block per i/o
and will be
Going to and see if I can allocate this
> On Mar 6, 2021, at 10:50 AM, Laddie Hanus wrote:
>
> LBI is available on DASD the largest block that will fit on 1 track, on the
> 3390 thats about 56K. Logical record (LRECL) is still limited to 32760, This
> is for new datasets being written.
LBI is available on DASD the largest block that will fit on 1 track, on the
3390 thats about 56K. Logical record (LRECL) is still limited to 32760, This is
for new datasets being written. Existing datasets will read one block per i/o
and will be no larger than what written. this is for BSAM
Hi Paul,
I tried this using z/OS 2.4 ISPF OPT32 and got BLKSIZE=16385.
Regards,
David
On 2021-03-02 09:01, Paul Gilmartin wrote:
On Tue, 2 Mar 2021 08:24:09 -0500, David Spiegel wrote:
Hi Radek,
You said: "... which is usually close to half of the track (sometimes
third...) ..."
When is SDB
-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, March 2, 2021 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
On Tue, 2 Mar 2021 16:35:46 +, Seymour J Metz wrote:
>For best performance,
RV.UA.EDU
Subject: Re: Large block interface for VB
On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman
wrote:
>I have 100 files concatenated that are normally processed by qsam with a lrecl
>31996 and blksize 32000
>
>Since processing takes a long time I was looking to speed thin
tin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, March 2, 2021 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
On Tue, 2 Mar 2021 11:30:09 -0600, Walt Farrell wrote:
>
>I'm surprised no one has mentioned it, but for input files, the blocksize is
&g
On Tue, 2 Mar 2021 11:30:09 -0600, Walt Farrell wrote:
>
>I'm surprised no one has mentioned it, but for input files, the blocksize is
>determined by the application that wrote the file. The application that is
>reading has no control over it. ...
>
Except for zFS, for which the access method
On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman
wrote:
>I have 100 files concatenated that are normally processed by qsam with a lrecl
>31996 and blksize 32000
>
>Since processing takes a long time I was looking to speed things up by
>specifying a blksize of 32 in the DCBE
>
>After
On Tue, 2 Mar 2021 16:35:46 +, Seymour J Metz wrote:
>For best performance, NCP should match the number of DECBs you allocate and
>you should do a READ on each of them. If real storage is an issue, reduce that
>number appropriately. When you hit EOF (EODAD is entered), stop issuing READ.
>
[reichman...@gmail.com]
> Sent: Monday, March 1, 2021 9:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
>
> For NCP do you have to have a counter of the number of reads you do till you
> do a check
>
>
>> On Mar 1, 2021, at 7:34 PM,
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Joseph Reichman [reichman...@gmail.com]
Sent: Monday, March 1, 2021 9:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
For NCP do you have to have a counter
Yes, of course!
9 will be blocked to 3x3.
However for VSAM it is possible to get 9 blk/trk, as well as 4, 12, 10,
8...
Of course it is not the same as SDB for PS file.
--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland
W dniu 02.03.2021 o 15:33, Paul Gilmartin pisze:
On Tue, 2 Mar
On Tue, 2 Mar 2021 15:25:33 +0100, Radoslaw Skorupka wrote:
>try any RECFM=FB and LRECL between 13349 and 18118
>
>Generally it may be 1/3 or other 1/n where n is odd (uneven).
>
It must be either prime or 1.
Has anyone an example for 1/11?
(Always assuming Blocked.)
>As currently unemployed I
try any RECFM=FB and LRECL between 13349 and 18118
Generally it may be 1/3 or other 1/n where n is odd (uneven).
As currently unemployed I have no z/OS at hand (OK, I have one due to
someone's kindness), when you play with large enough LRECLs you will get
SDB at 3 blk/trk, 5 blk/trk, 7 blk/trk
On Tue, 2 Mar 2021 08:24:09 -0500, David Spiegel wrote:
>Hi Radek,
>You said: "... which is usually close to half of the track (sometimes
>third...) ..."
>When is SDB 1/3 Track?
>
As a guess, try RECFM=FB,LRECL=16385,BLKSIZE=0.
In one astonishing extreme case, SDB is 1/7 track.
-- gil
Hi Radek,
You said: "... which is usually close to half of the track (sometimes
third...) ..."
When is SDB 1/3 Track?
Thanks and regards,
David
On 2021-03-02 07:25, Radoslaw Skorupka wrote:
General comment about LBI, large blocks and performance:
1. Blocksize for tapes, especially for real
Thanks I look at the IHADCB DSECT comments
> On Mar 2, 2021, at 2:18 AM, Michael Stein wrote:
>
> On Mon, Mar 01, 2021 at 09:37:57PM -0500, Joseph Reichman wrote:
>> For NCP do you have to have a counter of the number of reads you do
>> till you do a check
>
> Yes, but since you need a
General comment about LBI, large blocks and performance:
1. Blocksize for tapes, especially for real tapes is very important for
performance. LBI is something to legalize previously used large blocks -
I mean blocks larger than officially supported 32760. Even 3490E tapes
supported larger
On Mon, Mar 01, 2021 at 09:37:57PM -0500, Joseph Reichman wrote:
> For NCP do you have to have a counter of the number of reads you do
> till you do a check
Yes, but since you need a separate DECB for each read I'd create the
DECB's after open based on the NCP value. And then the "availablity"
m. Solvable, but thorny.
> >>
> >> Peter
> >>
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List On
> Behalf Of Farley, Peter x23353
> >> Sent: Monday, March 1, 2021 1:43 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
&g
Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Monday, March 1, 2021 9:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
For NCP do you have to have a counter of the number of reads you do till you do
a check
> On Mar 1, 2021, at 7:34 PM, Joseph Reich
de is also a
>> thorny problem. Solvable, but thorny.
>>
>> Peter
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of
>> Farley, Peter x23353
>> Sent: Monday, March 1, 2021 1:43 PM
>> To: IBM-MAIN@LISTSERV.
orrect order. Robust recovery from I/O errors in such code is also a
> thorny problem. Solvable, but thorny.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Farley, Peter x23353
> Sent: Monday, March 1, 2021 1:43 PM
> To: IBM
y, March 1, 2021 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
EXTERNAL EMAIL
You assume correctly, it does. In my experience both BLSR and SMB will handle
concatenations of any size without any issue.
When using BLSR your primary DD (the one your program reads
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB
Thank you I’m doing searches for files so I have over 100 concatenated files
does the access matters I mean I assume QSAM reads a block under the covers
> On Mar 1, 2021, at 1:26 PM, Farley, Peter x23
Discussion List On Behalf Of
> Joseph Reichman
> Sent: Monday, March 1, 2021 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
>
> EXTERNAL EMAIL
>
> Who uses tape
>
> I went to bsam trying to speed up my application wonder if go
I/O burdens for the compressed data, especially if
you have hardware compression available.
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Monday, March 1, 2021 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface
On Mon, 1 Mar 2021 13:13:50 -0500, Joseph Reichman wrote:
>Who uses tape
>
Programmers who want large blocks?
>I went to bsam trying to speed up my application wonder if going to bsam
>
>Does anything positive for me
>
>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin wrote:
>>
>> On Mon, 1
Who uses tape
I went to bsam trying to speed up my application wonder if going to bsam
Does anything positive for me
> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>
>>
On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>It disk then documentation says the system only supports tape at this time is
>That true ?
>
Have you any reason to doubt it?
I suspect it's a hardware limitation.
>> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
>>
>> On Mon,
It disk then documentation says the system only supports tape at this time is
That true ?
> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
>
>> I have 100 files concatenated
On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
>I have 100 files concatenated that are normally processed by qsam with a lrecl
>31996 and blksize 32000
>
>Since processing takes a long time I was looking to speed things up by
>specifying a blksize of 32 in the DCBE
>
What
I have 100 files concatenated that are normally processed by qsam with a lrecl
31996 and blksize 32000
Since processing takes a long time I was looking to speed things up by
specifying a blksize of 32 in the DCBE
After the first read using bsam read macro I looked at the first 4 bytes (
54 matches
Mail list logo
