Re: Large block interface for VB
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, IOS logic, channel programs, etc. One of reliefs done in the past are 3390B - alias devices, then HyperPAV, MIDAW, zHPF. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 10.03.2021 o 09:31, Colin Paice pisze: 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 happens in the storage controller and onto the disk. On Tue, 9 Mar 2021 at 21:45, Radoslaw Skorupka wrote: 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 utility or user program, with at most changes to SMS profile? Yes, you have to define it in SC. And use extended format. What's the maximum performance boost? "Linear" can't mean "infinite". Limited by channel, main storage, controller cache ... bandwidth. (Model-dependent, of course.) It depends. I remember loong discussion (read: quarrel) with my co-worker. It was 20+ years ago and it was about sense of striping on RAMAC RVA. He was right. ;-) Striping gave some performance gain. I can't remember exact values, but adding further stripes didn't help. One may say for real (old gone) 3390 volumes the performance gain was rather obvious, but bunch of volumes emulated on same hardware - controller, disk RAID group - it should be no difference whether you use one or several emulated volumes. However it is UNTRUE. Tested many times on various disk system models. And sometime you can deep dive in disk system details and create storage group consisting of volumes from different RAID groups, possibly server by different controllers (electronics). Modern arrays have quite reasonable features to support it. And2: even volumes defined on exactly same physical resources perform better when striping is in effect. This would appear to be a solution for the OP. Of course, unless he's already experiencing it, perhaps unbeknownst. Good to consider. However striping is the best for (long) sequential read or write operations. Last, but not least: it is easy to test. BTW: Striping and multi-volume and extents is quite interesting issue for quiz. ;-) Things changed with the z/OS releases and the rules are different for ef-PS and VSAM. When I teach it on VSAM course, people usually forget about VSAM and discuss about PS. -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- 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: Large block interface for VB
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 happens in the storage controller and onto the disk. On Tue, 9 Mar 2021 at 21:45, Radoslaw Skorupka wrote: > 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 utility or user program, with at > > most changes to SMS profile? > Yes, you have to define it in SC. And use extended format. > > > What's the maximum performance boost? "Linear" can't mean > > "infinite". Limited by channel, main storage, controller cache ... > > bandwidth. (Model-dependent, of course.) > > It depends. I remember loong discussion (read: quarrel) with my > co-worker. It was 20+ years ago and it was about sense of striping on > RAMAC RVA. He was right. ;-) Striping gave some performance gain. I > can't remember exact values, but adding further stripes didn't help. > One may say for real (old gone) 3390 volumes the performance gain was > rather obvious, but bunch of volumes emulated on same hardware - > controller, disk RAID group - it should be no difference whether you use > one or several emulated volumes. However it is UNTRUE. Tested many times > on various disk system models. And sometime you can deep dive in disk > system details and create storage group consisting of volumes from > different RAID groups, possibly server by different controllers > (electronics). Modern arrays have quite reasonable features to support it. > And2: even volumes defined on exactly same physical resources perform > better when striping is in effect. > > > > This would appear to be a solution for the OP. Of course, unless > > he's already experiencing it, perhaps unbeknownst. > > Good to consider. However striping is the best for (long) sequential > read or write operations. > Last, but not least: it is easy to test. > > > BTW: Striping and multi-volume and extents is quite interesting issue > for quiz. ;-) > Things changed with the z/OS releases and the rules are different for > ef-PS and VSAM. > When I teach it on VSAM course, people usually forget about VSAM and > discuss about PS. > > -- > Radoslaw Skorupka > (looking for new job) > Lodz, Poland > > -- > 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: Large block interface for VB
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 utility or user program, with at most changes to SMS profile? Yes, you have to define it in SC. And use extended format. What's the maximum performance boost? "Linear" can't mean "infinite". Limited by channel, main storage, controller cache ... bandwidth. (Model-dependent, of course.) It depends. I remember loong discussion (read: quarrel) with my co-worker. It was 20+ years ago and it was about sense of striping on RAMAC RVA. He was right. ;-) Striping gave some performance gain. I can't remember exact values, but adding further stripes didn't help. One may say for real (old gone) 3390 volumes the performance gain was rather obvious, but bunch of volumes emulated on same hardware - controller, disk RAID group - it should be no difference whether you use one or several emulated volumes. However it is UNTRUE. Tested many times on various disk system models. And sometime you can deep dive in disk system details and create storage group consisting of volumes from different RAID groups, possibly server by different controllers (electronics). Modern arrays have quite reasonable features to support it. And2: even volumes defined on exactly same physical resources perform better when striping is in effect. This would appear to be a solution for the OP. Of course, unless he's already experiencing it, perhaps unbeknownst. Good to consider. However striping is the best for (long) sequential read or write operations. Last, but not least: it is easy to test. BTW: Striping and multi-volume and extents is quite interesting issue for quiz. ;-) Things changed with the z/OS releases and the rules are different for ef-PS and VSAM. When I teach it on VSAM course, people usually forget about VSAM and discuss about PS. -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 SMS profile? What's the maximum performance boost? "Linear" can't mean "infinite". Limited by channel, main storage, controller cache ... bandwidth. (Model-dependent, of course.) This would appear to be a solution for the OP. Of course, unless he's already experiencing it, perhaps unbeknownst. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 (which are read in parallel) using a storage class with a non-zero sustained data rate attribute. Choosing the value of the sustained data rate is a little clumsy but, in brief, 8 gives two stripes and 12 gives 3 stripes for 3390 device geometry. Last time I looked, the throughput scaled roughly linearly with the number of stripes. I stand corrected vis-à-vis my pessimism: 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? Striped PS datasets (extended format PS) are managed by IEBGENER, ICEGENER or IDCAMS as regular (non-striped) datasets. I mean user perspective. -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 UNIT=SYSALLDA,SPACE=(TRK,0),RECFM=... //DD PATH=... And it works! Go figger. Some utilities make needless validity checks, then neglect to check all catenands. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
BSAM and QSAM with extended format require a level of DFSMSdfp that supports it. EXCP with extended format requires application code to deal with it. The same applies to EAV. Even when striping is handled by the director, you would need the appropriate CCWs to request it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu] Sent: Monday, March 8, 2021 1:47 PM 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" level?) so one would expect that QSAM wouldn't even know it was happening. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
I have been working with EF data sets as they can be encrypted. My understanding is that the interface for EXCP for EF data sets is not published. Lennie Dymoke-Bradshaw ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List 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" level?) so one would expect that QSAM wouldn't even know it was happening. More sophisticated utilities like SORT may be aware of striping, but such utilities are expected to DTRT as well because they are far more aware of system-level efficiencies. ISTR that IBM and Syncsort in the days of real CKD devices regularly one-upped each other by patenting more and more sophisticated and efficient CCW sequences. I never did 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 interface for VB EXTERNAL EMAIL 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 with a non-zero sustained data rate attribute. Choosing the >value of the sustained data rate is a little clumsy but, in brief, 8 gives two >stripes and 12 gives 3 stripes for 3390 device geometry. > >Last time I looked, the throughput scaled roughly linearly with the number of >stripes. > I stand corrected vis-à-vis my pessimism: 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? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: 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 happening. More sophisticated utilities like SORT may be aware of striping, but such utilities are expected to DTRT as well because they are far more aware of system-level efficiencies. ISTR that IBM and Syncsort in the days of real CKD devices regularly one-upped each other by patenting more and more sophisticated and efficient CCW sequences. I never did 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 interface for VB EXTERNAL EMAIL 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 with a non-zero sustained data rate attribute. Choosing the >value of the sustained data rate is a little clumsy but, in brief, 8 gives two >stripes and 12 gives 3 stripes for 3390 device geometry. > >Last time I looked, the throughput scaled roughly linearly with the number of >stripes. > I stand corrected vis-à-vis my pessimism: 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? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 supported and I assume that IEBGENER uses one of those rather than EXCP. Bets are off if you want to use EXCP as the format isn't the same as a traditional sequential data set. I'm trying to remember how long striped data sets have been around- it's been a good few years. I've just remembered that extended format also allows hardware compression using zEDC cards so a compressed extended format sequential data set would also be worth considering if the hardware's there. Regards, Nigel Morton -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 with a non-zero sustained data rate attribute. Choosing the >value of the sustained data rate is a little clumsy but, in brief, 8 gives two >stripes and 12 gives 3 stripes for 3390 device geometry. > >Last time I looked, the throughput scaled roughly linearly with the number of >stripes. > I stand corrected vis-à-vis my pessimism: 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? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 value of the sustained data rate is a little clumsy but, in brief, 8 gives two stripes and 12 gives 3 stripes for 3390 device geometry. Last time I looked, the throughput scaled roughly linearly with the number of stripes. Regards, Nigel Morton -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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, however I >haven't found any. >And I think it is not only my observation. > I thought PDSE supports long aliases but not long primary member names. And I thought long names exist to support C++ with its quasi-Hungarian notation for function names. It's not linear. Increasing BLKSIZE by a factor of ten will not yield a tenfold performance improvement. And increasing BUFNO by a factor of ten will not yield a tenfold performance improvement. Don't know about striped RAID. I suspect there's no software support for the desirable parallel I/O. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 at a time. QSAM could run that fast and did chaining of channel programs to minimize I/O & CPU required. In that case BSAM wasn't any faster and without careful coding could easily be slower or have errors like losing blocks or order of blocks. Today, I suspect that the CKD disk is virtual and simulated on multiple(?) fixed block disks so perhaps it might be possible to transfer data faster. This still in my estimation likely to make QSAM a better choice than BSAM and not any slower. Remember that QSAM can assume you will continue reading sequentially (and read ahead) while BSAM may think it's likely but not sure until you issue the next READs. > In other words you don’t think bufno / ncp > And overlapped I/O will produce anything significant I'd think that QSAM is already doing that if you specify a high enough BUFNO in any of DCB, JCL DD card DCB subparm, or dynamic allocation key DALBUFNO. And if performance was important, I'd make measurements of what was happening on a fine grain basis (time I/O? and CPU) and compare with the hardware specifications. And then if they didn't match try to figure out why... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 whenever possible. However this is different story. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 07.03.2021 o 21:37, Joseph Reichman pisze: 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 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 endusers should usually avoid using specific, rare (and bizarre) techniques. Usually simple is better. Usually my problem was solved several times. YMMV. As usual. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 07.03.2021 o 16:56, Joseph Reichman pisze: 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 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 read/check. manual DF/DSS Advanced services under the DEVTYPE macro will has a table of largest blocksize per decice type 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, however I haven't found any. And I think it is not only my observation. From the other hand large blocks on tape are widely used and supported by existing system tools. Last, but not least: author of the thread wants better performance. I would not expect significant performance improvement by changing BLKSIZE =half track to whole track. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 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 endusers should usually avoid using specific, rare (and bizarre) > techniques. Usually simple is better. Usually my problem was solved several > times. YMMV. As usual. > > -- > Radoslaw Skorupka > (looking for new job) > Lodz, Poland > > > > W dniu 07.03.2021 o 16:56, Joseph Reichman pisze: >> 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 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 read/check. manual DF/DSS Advanced services under the DEVTYPE macro will has a table of largest blocksize per decice type >>> 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, however I >>> haven't found any. >>> And I think it is not only my observation. >>> >>> From the other hand large blocks on tape are widely used and supported by >>> existing system tools. >>> >>> Last, but not least: author of the thread wants better performance. I would >>> not expect significant performance improvement by changing BLKSIZE =half >>> track to whole track. >>> >>> > > -- > 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: Large block interface for VB
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 endusers should usually avoid using specific, rare (and bizarre) techniques. Usually simple is better. Usually my problem was solved several times. YMMV. As usual. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 07.03.2021 o 16:56, Joseph Reichman pisze: 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 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 read/check. manual DF/DSS Advanced services under the DEVTYPE macro will has a table of largest blocksize per decice type 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, however I haven't found any. And I think it is not only my observation. From the other hand large blocks on tape are widely used and supported by existing system tools. Last, but not least: author of the thread wants better performance. I would not expect significant performance improvement by changing BLKSIZE =half track to whole track. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 less >> I/o should speed things up no ? >> > If you have a large enough number of buffers, the difference should be > negligible. For QSAM I hope they would be above the line taking > advantage of the 31 bit address space. HavingBSA oddball data sets which > require special handling and maybe even EXCP will probably cost more > time than you save. Playing with BUFNO and NCP are a better > expenditure of time and effort. > > Clark Morris >> 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 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 read/check. manual DF/DSS Advanced services under the DEVTYPE macro will has a table of largest blocksize per decice type >>> >>> 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, however I >>> haven't found any. >>> And I think it is not only my observation. >>> >>> From the other hand large blocks on tape are widely used and supported by >>> existing system tools. >>> >>> Last, but not least: author of the thread wants better performance. I would >>> not expect significant performance improvement by changing BLKSIZE =half >>> track to whole track. >>> >>> -- >>> Radoslaw Skorupka >>> (looking for new job) >>> Lodz, Poland >>> >>> -- >>> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
[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 negligible. For QSAM I hope they would be above the line taking advantage of the 31 bit address space. Having oddball data sets which require special handling and maybe even EXCP will probably cost more time than you save. Playing with BUFNO and NCP are a better expenditure of time and effort. Clark Morris > >> 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 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 >>> read/check. manual DF/DSS Advanced services under the DEVTYPE macro will >>> has a table of largest blocksize per decice type >> >> 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, however I >> haven't found any. >> And I think it is not only my observation. >> >> From the other hand large blocks on tape are widely used and supported by >> existing system tools. >> >> Last, but not least: author of the thread wants better performance. I would >> not expect significant performance improvement by changing BLKSIZE =half >> track to whole track. >> >> -- >> Radoslaw Skorupka >> (looking for new job) >> Lodz, Poland >> >> -- >> 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: Large block interface for VB
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 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 read/check. >> manual DF/DSS Advanced services under the DEVTYPE macro will has a table of >> largest blocksize per decice type > > 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, however I > haven't found any. > And I think it is not only my observation. > > From the other hand large blocks on tape are widely used and supported by > existing system tools. > > Last, but not least: author of the thread wants better performance. I would > not expect significant performance improvement by changing BLKSIZE =half > track to whole track. > > -- > Radoslaw Skorupka > (looking for new job) > Lodz, Poland > > -- > 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: Large block interface for VB
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 no larger than what written. this is for BSAM read/check. manual DF/DSS Advanced services under the DEVTYPE macro will has a table of largest blocksize per decice type 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, however I haven't found any. And I think it is not only my observation. From the other hand large blocks on tape are widely used and supported by existing system tools. Last, but not least: author of the thread wants better performance. I would not expect significant performance improvement by changing BLKSIZE =half track to whole track. -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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. Existing datasets will read one block per > i/o and will be no larger than what written. this is for BSAM read/check. > manual DF/DSS Advanced services under the DEVTYPE macro will has a table of > largest blocksize per decice type > > Laddie Hanus > > -- > 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: Large block interface for VB
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 read/check. manual DF/DSS Advanced services under the DEVTYPE macro will has a table of largest blocksize per decice type Laddie Hanus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 1/3 Track? As a guess, try RECFM=FB,LRECL=16385,BLKSIZE=0. In one astonishing extreme case, SDB is 1/7 track. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
My recommendation was specifically for z/OS; I don't know how z/VSE handles multiple READs, and I would expect most CMS I/O to be native CMS, BFS or SFS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: 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, 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. > (Decades old experience:) Of course, if the programmer is coding for overlapped I/O, the access method may be unable to detect EOF before the program has issued several more READs. MVS BSAM somehow handles this correctly: READs beyond EOF just don't happen. CMS/XA OS emulation was terrible. READs were synchronous: control did not return to the caller until channel/device end and DECB was posted. Additional READs intended to be asynchronous read garbage data or got I/O errors. I used the same code on both OSes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
> In theory, using EXCP, you could read using CCWs with data chaining > that would read multiple blocks in one I/O operation and concatenate them > into one data area. Only if you used Read Multiple CKD; given that SAM-E is bundled into z/OS, I'm not convinced that you'd get a noticeable performance boost. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Walt Farrell [walt.farr...@gmail.com] Sent: Tuesday, March 2, 2021 12:30 PM To: IBM-MAIN@LISTSERV.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 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 ( >Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me >that it was still processing blksize of 32,000 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. If you're reading a block, it is as long as it is, and no longer. In theory, using EXCP, you could read using CCWs with data chaining that would read multiple blocks in one I/O operation and concatenate them into one data area. But that would be complex, and (I think) unlikely to get significantly better performance than simply increasing the number of channel programs that QSAM uses. -- Walt -- 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: Large block interface for VB
> Where's QPAM that we've needed forever? In TSS/360. I guess that it's too recent to copy. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: 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 >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 reblocks to accommodate the values in the DCB or JCL. I find that admirable behavior and felt, far earlier than OMVS, that it be supported for all filesystems. But QSAM largely spares the programmer the chore of dealing with blocks. Where's QPAM that we've needed forever? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 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 >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 reblocks to accommodate the values in the DCB or JCL. I find that admirable behavior and felt, far earlier than OMVS, that it be supported for all filesystems. But QSAM largely spares the programmer the chore of dealing with blocks. Where's QPAM that we've needed forever? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 ( >Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me >that it was still processing blksize of 32,000 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. If you're reading a block, it is as long as it is, and no longer. In theory, using EXCP, you could read using CCWs with data chaining that would read multiple blocks in one I/O operation and concatenate them into one data area. But that would be complex, and (I think) unlikely to get significantly better performance than simply increasing the number of channel programs that QSAM uses. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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. > (Decades old experience:) Of course, if the programmer is coding for overlapped I/O, the access method may be unable to detect EOF before the program has issued several more READs. MVS BSAM somehow handles this correctly: READs beyond EOF just don't happen. CMS/XA OS emulation was terrible. READs were synchronous: control did not return to the caller until channel/device end and DECB was posted. Additional READs intended to be asynchronous read garbage data or got I/O errors. I used the same code on both OSes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
That’s the way I’m doing it Thanks > On Mar 2, 2021, at 11:36 AM, 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. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > 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 of the number of reads you do till you > do a check > > >> On Mar 1, 2021, at 7:34 PM, Joseph Reichman wrote: >> >> Thanks I’ll look Into it >> >>>> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 >>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> Joseph, >>> >>> Apologies, I mis-remembered what SMB can do. SMB is available only for >>> VSAM files, not for concatenated QSAM files. BLSR is one of two options >>> for many-buffered QSAM input. >>> >>> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max >>> of 99 for each one) that may or may not help with I/.O performance. I have >>> run some work with NCP=99,BUFNO=99 with some helpful effects, though not >>> dramatic. >>> >>> To really take advantage of NCP/BUFNO you probably would need to code to >>> juggle "NCP" different READ's at a time using BSAM and your own de-blocking >>> subroutine. Lots of bookkeeping to keep track of them all and only CHECK >>> in the correct 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-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) is coded with >>> he BLSR parameters and nothing else, that DD then points (via a BLSR >>> parameter) to a second DD where you put your large concatenation. >>> >>> SMB is applied directly to your primary DD name, specify the SMB parameters >>> on only the first of the concatenated DD's. >>> >>> Peter >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On Behalf Of >>> Joseph Reichman >>> Sent: Monday, March 1, 2021 1:36 PM >>> 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 x23353 >>>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >>>> >>>> Joseph, >>>> >>>> I believe that LBI is only for tape inputs and outputs. You can speed up >>>> your processing easier by using either the older BLSR buffering subsystem >>>> or better the newer SMB buffering system. See the JCL reference manual >>>> for SMB parameters. >>>> >>>> Allocate as much REGION as your installation will allow (some >>>> installations limit the maximum any job without special authorization may >>>> use, even sometimes production jobs). >>>> >>>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size >>>> you can allocate. >>>> >>>> I have seen substantial decreases in run time using these techniques with >>>> very large sequential files. >>>> >>>> I would also recommend using at least software compression or better >>>> hardware compression (if your CPU has it) for your large sequential files. >>>> The CPU time used for compression and d
Re: Large block interface for VB
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. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 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 of the number of reads you do till you do a check > On Mar 1, 2021, at 7:34 PM, Joseph Reichman wrote: > > Thanks I’ll look Into it > >> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 >> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >> >> Joseph, >> >> Apologies, I mis-remembered what SMB can do. SMB is available only for VSAM >> files, not for concatenated QSAM files. BLSR is one of two options for >> many-buffered QSAM input. >> >> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of >> 99 for each one) that may or may not help with I/.O performance. I have run >> some work with NCP=99,BUFNO=99 with some helpful effects, though not >> dramatic. >> >> To really take advantage of NCP/BUFNO you probably would need to code to >> juggle "NCP" different READ's at a time using BSAM and your own de-blocking >> subroutine. Lots of bookkeeping to keep track of them all and only CHECK in >> the correct 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-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) is coded with >> he BLSR parameters and nothing else, that DD then points (via a BLSR >> parameter) to a second DD where you put your large concatenation. >> >> SMB is applied directly to your primary DD name, specify the SMB parameters >> on only the first of the concatenated DD's. >> >> Peter >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Joseph Reichman >> Sent: Monday, March 1, 2021 1:36 PM >> 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 x23353 >>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> Joseph, >>> >>> I believe that LBI is only for tape inputs and outputs. You can speed up >>> your processing easier by using either the older BLSR buffering subsystem >>> or better the newer SMB buffering system. See the JCL reference manual for >>> SMB parameters. >>> >>> Allocate as much REGION as your installation will allow (some installations >>> limit the maximum any job without special authorization may use, even >>> sometimes production jobs). >>> >>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size >>> you can allocate. >>> >>> I have seen substantial decreases in run time using these techniques with >>> very large sequential files. >>> >>> I would also recommend using at least software compression or better >>> hardware compression (if your CPU has it) for your large sequential files. >>> The CPU time used for compression and decompression will sometimes be >>> offset by decreases in elapsed time due to reduced 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 for VB >>> >>> Wh
Re: Large block interface for VB
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 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 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 and maybe more. Why is it so unpopular? Because usually we use shorter LRECLs. To be honest I found it accidentally when preparing excercises for VSAM course. Default CISZ on 3390 is 18432 and physical block is also 18432, and it is the most effective usage of track (least space unassigned to any CI). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 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 and maybe more. > >Why is it so unpopular? >Because usually we use shorter LRECLs. > >To be honest I found it accidentally when preparing excercises for VSAM >course. Default CISZ on 3390 is 18432 and physical block is also 18432, >and it is the most effective usage of track (least space unassigned to >any CI). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 and maybe more. Why is it so unpopular? Because usually we use shorter LRECLs. To be honest I found it accidentally when preparing excercises for VSAM course. Default CISZ on 3390 is 18432 and physical block is also 18432, and it is the most effective usage of track (least space unassigned to any CI). -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 02.03.2021 o 14:24, David Spiegel pisze: 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 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 blocks and it was used by ADRDSSU (read HSM backups). AFAIK LBI was proviced with OS/390 V2R10, long time after MAGSTAR family GA. 2. Blocksize on DASD *does affect performance*, but it is not so strong as with tapes. More: on tape there is no big reason not to use large blocks, but on DASD the blocksize is strictly related to track size. For 3390 blocksize of, let's imagine 160kB has no sense, because block has to fit in track. And even 32760 is not very reasonable (assuming same consecutive blocks), because waste of space. Yes, it would be nice to have blocksize limit at 56664B, but there is no such option (we talk about z/OS, not z/VSE). Optimal blocksize is SDB, which is usually close to half of the track (sometimes third...). 3. However "big enough" blocksize is good enough! In other words you will not observe big performance difference between BLKSIZE=32000 and BLKSIZE=8000. On DASD, of course. 4. So, in this case, hypothetical LBI=track would not provide important relief. That could mean maybe there are other ways to skin a cat. I don't know the application, but some ideas to consider: - use VSAM, SMB, BLSR, etc. - use index if applicable - use LDS and DIV - use DB2 table My €0,02 -- 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: Large block interface for VB
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 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 blocks and it was used by ADRDSSU (read HSM backups). AFAIK LBI was proviced with OS/390 V2R10, long time after MAGSTAR family GA. 2. Blocksize on DASD *does affect performance*, but it is not so strong as with tapes. More: on tape there is no big reason not to use large blocks, but on DASD the blocksize is strictly related to track size. For 3390 blocksize of, let's imagine 160kB has no sense, because block has to fit in track. And even 32760 is not very reasonable (assuming same consecutive blocks), because waste of space. Yes, it would be nice to have blocksize limit at 56664B, but there is no such option (we talk about z/OS, not z/VSE). Optimal blocksize is SDB, which is usually close to half of the track (sometimes third...). 3. However "big enough" blocksize is good enough! In other words you will not observe big performance difference between BLKSIZE=32000 and BLKSIZE=8000. On DASD, of course. 4. So, in this case, hypothetical LBI=track would not provide important relief. That could mean maybe there are other ways to skin a cat. I don't know the application, but some ideas to consider: - use VSAM, SMB, BLSR, etc. - use index if applicable - use LDS and DIV - use DB2 table My €0,02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 separate DECB for each read I'd create the > DECB's after open based on the NCP value. And then the "availablity" > of a not in use DECB would control the number of outstanding READs. > > I strongly suspect that a good BSAM implementation isn't going to be > faster than QSAM. QSAM can queue reads for more than one block. > > See the DCB keyword BUFNO (and JCL DD DCB subparm BUFNO). > > PS: I'd suggest using GET Locate mode (MACRF=GL) > > -- > 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: Large block interface for VB
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 blocks and it was used by ADRDSSU (read HSM backups). AFAIK LBI was proviced with OS/390 V2R10, long time after MAGSTAR family GA. 2. Blocksize on DASD *does affect performance*, but it is not so strong as with tapes. More: on tape there is no big reason not to use large blocks, but on DASD the blocksize is strictly related to track size. For 3390 blocksize of, let's imagine 160kB has no sense, because block has to fit in track. And even 32760 is not very reasonable (assuming same consecutive blocks), because waste of space. Yes, it would be nice to have blocksize limit at 56664B, but there is no such option (we talk about z/OS, not z/VSE). Optimal blocksize is SDB, which is usually close to half of the track (sometimes third...). 3. However "big enough" blocksize is good enough! In other words you will not observe big performance difference between BLKSIZE=32000 and BLKSIZE=8000. On DASD, of course. 4. So, in this case, hypothetical LBI=track would not provide important relief. That could mean maybe there are other ways to skin a cat. I don't know the application, but some ideas to consider: - use VSAM, SMB, BLSR, etc. - use index if applicable - use LDS and DIV - use DB2 table My €0,02 -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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" of a not in use DECB would control the number of outstanding READs. I strongly suspect that a good BSAM implementation isn't going to be faster than QSAM. QSAM can queue reads for more than one block. See the DCB keyword BUFNO (and JCL DD DCB subparm BUFNO). PS: I'd suggest using GET Locate mode (MACRF=GL) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
Described in detail in the DFSMS Using Datasets manual, see https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/uoiowb.htm Includes sample code On Tue, Mar 2, 2021 at 1:38 PM Joseph Reichman wrote: > 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 Reichman > wrote: > > > > Thanks I’ll look Into it > > > >> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 < > 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> Joseph, > >> > >> Apologies, I mis-remembered what SMB can do. SMB is available only for > VSAM files, not for concatenated QSAM files. BLSR is one of two options > for many-buffered QSAM input. > >> > >> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn > (max of 99 for each one) that may or may not help with I/.O performance. I > have run some work with NCP=99,BUFNO=99 with some helpful effects, though > not dramatic. > >> > >> To really take advantage of NCP/BUFNO you probably would need to code > to juggle "NCP" different READ's at a time using BSAM and your own > de-blocking subroutine. Lots of bookkeeping to keep track of them all and > only CHECK in the correct 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-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) is coded > with he BLSR parameters and nothing else, that DD then points (via a BLSR > parameter) to a second DD where you put your large concatenation. > >> > >> SMB is applied directly to your primary DD name, specify the SMB > parameters on only the first of the concatenated DD's. > >> > >> Peter > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > >> Sent: Monday, March 1, 2021 1:36 PM > >> 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 x23353 < > 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > >>> > >>> Joseph, > >>> > >>> I believe that LBI is only for tape inputs and outputs. You can speed > up your processing easier by using either the older BLSR buffering > subsystem or better the newer SMB buffering system. See the JCL reference > manual for SMB parameters. > >>> > >>> Allocate as much REGION as your installation will allow (some > installations limit the maximum any job without special authorization may > use, even sometimes production jobs). > >>> > >>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION > size you can allocate. > >>> > >>> I have seen substantial decreases in run time using these techniques > with very large sequential files. > >>> > >>> I would also recommend using at least software compression or better > hardware compression (if your CPU has it) for your large sequential files. > The CPU time used for compression and decompression will sometimes be > offset by decreases in elapsed time due to reduced 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 for VB > >>> > >>> Who uses tape > >>> > >>> I went to bsam trying to speed up my application wonder if going to > >>> bsam > >&g
Re: Large block interface for VB
As far as I can remember (it's been a *long* time since I did this kind of programming), you should not (perhaps cannot?) exceed the NCP number of READ's at the same time using the same DCB. Your code would need to use the NCP value from the opened DCB to control how many READ's you may issue before you need a CHECK. IIRC there is a default NCP value - perhaps 5? -- that also needs to be considered if no override is present in the JCL or the DCB. As I said, it's been a long time since I went that deep, so please RTFM for yourself. Peter -Original Message- From: IBM 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 Reichman wrote: > > Thanks I’ll look Into it > >> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 >> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >> >> Joseph, >> >> Apologies, I mis-remembered what SMB can do. SMB is available only for VSAM >> files, not for concatenated QSAM files. BLSR is one of two options for >> many-buffered QSAM input. >> >> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of >> 99 for each one) that may or may not help with I/.O performance. I have run >> some work with NCP=99,BUFNO=99 with some helpful effects, though not >> dramatic. >> >> To really take advantage of NCP/BUFNO you probably would need to code to >> juggle "NCP" different READ's at a time using BSAM and your own de-blocking >> subroutine. Lots of bookkeeping to keep track of them all and only CHECK in >> the correct 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-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) is coded with >> he BLSR parameters and nothing else, that DD then points (via a BLSR >> parameter) to a second DD where you put your large concatenation. >> >> SMB is applied directly to your primary DD name, specify the SMB parameters >> on only the first of the concatenated DD's. >> >> Peter >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >> Sent: Monday, March 1, 2021 1:36 PM >> 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 x23353 >>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> Joseph, >>> >>> I believe that LBI is only for tape inputs and outputs. You can speed up >>> your processing easier by using either the older BLSR buffering subsystem >>> or better the newer SMB buffering system. See the JCL reference manual for >>> SMB parameters. >>> >>> Allocate as much REGION as your installation will allow (some installations >>> limit the maximum any job without special authorization may use, even >>> sometimes production jobs). >>> >>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size >>> you can allocate. >>> >>> I have seen substantial decreases in run time using these techniques with >>> very large sequential files. >>> >>> I would also recommend using at least software compression or better >>> hardware compression (if your CPU has it) for your large sequential files. >>> The CPU time used for compression and decompression will sometimes be >>> offset by decreases in elapsed time due to reduced I/O burdens for the >>> compressed data, especially if you have hardware compression available. >>> >>> HTH >>> >>> Peter >>> >>> -Original Message- >>> From: IBM Mainframe Di
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 Reichman wrote: > > Thanks I’ll look Into it > >> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 >> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >> >> Joseph, >> >> Apologies, I mis-remembered what SMB can do. SMB is available only for VSAM >> files, not for concatenated QSAM files. BLSR is one of two options for >> many-buffered QSAM input. >> >> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of >> 99 for each one) that may or may not help with I/.O performance. I have run >> some work with NCP=99,BUFNO=99 with some helpful effects, though not >> dramatic. >> >> To really take advantage of NCP/BUFNO you probably would need to code to >> juggle "NCP" different READ's at a time using BSAM and your own de-blocking >> subroutine. Lots of bookkeeping to keep track of them all and only CHECK in >> the correct 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-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) is coded with >> he BLSR parameters and nothing else, that DD then points (via a BLSR >> parameter) to a second DD where you put your large concatenation. >> >> SMB is applied directly to your primary DD name, specify the SMB parameters >> on only the first of the concatenated DD's. >> >> Peter >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Joseph Reichman >> Sent: Monday, March 1, 2021 1:36 PM >> 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 x23353 >>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> Joseph, >>> >>> I believe that LBI is only for tape inputs and outputs. You can speed up >>> your processing easier by using either the older BLSR buffering subsystem >>> or better the newer SMB buffering system. See the JCL reference manual for >>> SMB parameters. >>> >>> Allocate as much REGION as your installation will allow (some installations >>> limit the maximum any job without special authorization may use, even >>> sometimes production jobs). >>> >>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size >>> you can allocate. >>> >>> I have seen substantial decreases in run time using these techniques with >>> very large sequential files. >>> >>> I would also recommend using at least software compression or better >>> hardware compression (if your CPU has it) for your large sequential files. >>> The CPU time used for compression and decompression will sometimes be >>> offset by decreases in elapsed time due to reduced 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 for VB >>> >>> 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: >>>>>> >>>>>> It di
Re: Large block interface for VB
Thanks I’ll look Into it > On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 > <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > Joseph, > > Apologies, I mis-remembered what SMB can do. SMB is available only for VSAM > files, not for concatenated QSAM files. BLSR is one of two options for > many-buffered QSAM input. > > The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of > 99 for each one) that may or may not help with I/.O performance. I have run > some work with NCP=99,BUFNO=99 with some helpful effects, though not dramatic. > > To really take advantage of NCP/BUFNO you probably would need to code to > juggle "NCP" different READ's at a time using BSAM and your own de-blocking > subroutine. Lots of bookkeeping to keep track of them all and only CHECK in > the correct 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-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) is coded with he > BLSR parameters and nothing else, that DD then points (via a BLSR parameter) > to a second DD where you put your large concatenation. > > SMB is applied directly to your primary DD name, specify the SMB parameters > on only the first of the concatenated DD's. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Monday, March 1, 2021 1:36 PM > 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 x23353 >> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: >> >> Joseph, >> >> I believe that LBI is only for tape inputs and outputs. You can speed up >> your processing easier by using either the older BLSR buffering subsystem or >> better the newer SMB buffering system. See the JCL reference manual for SMB >> parameters. >> >> Allocate as much REGION as your installation will allow (some installations >> limit the maximum any job without special authorization may use, even >> sometimes production jobs). >> >> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size >> you can allocate. >> >> I have seen substantial decreases in run time using these techniques with >> very large sequential files. >> >> I would also recommend using at least software compression or better >> hardware compression (if your CPU has it) for your large sequential files. >> The CPU time used for compression and decompression will sometimes be offset >> by decreases in elapsed time due to reduced 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 for VB >> >> 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: >>>>> >>>>> 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, 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 32
Re: Large block interface for VB
Joseph, Apologies, I mis-remembered what SMB can do. SMB is available only for VSAM files, not for concatenated QSAM files. BLSR is one of two options for many-buffered QSAM input. The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of 99 for each one) that may or may not help with I/.O performance. I have run some work with NCP=99,BUFNO=99 with some helpful effects, though not dramatic. To really take advantage of NCP/BUFNO you probably would need to code to juggle "NCP" different READ's at a time using BSAM and your own de-blocking subroutine. Lots of bookkeeping to keep track of them all and only CHECK in the correct 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-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) is coded with he BLSR parameters and nothing else, that DD then points (via a BLSR parameter) to a second DD where you put your large concatenation. SMB is applied directly to your primary DD name, specify the SMB parameters on only the first of the concatenated DD's. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Monday, March 1, 2021 1:36 PM 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 x23353 > <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > Joseph, > > I believe that LBI is only for tape inputs and outputs. You can speed up > your processing easier by using either the older BLSR buffering subsystem or > better the newer SMB buffering system. See the JCL reference manual for SMB > parameters. > > Allocate as much REGION as your installation will allow (some installations > limit the maximum any job without special authorization may use, even > sometimes production jobs). > > Use BLSR or SMB to allocate as many buffers as will fit in the REGION size > you can allocate. > > I have seen substantial decreases in run time using these techniques with > very large sequential files. > > I would also recommend using at least software compression or better hardware > compression (if your CPU has it) for your large sequential files. The CPU > time used for compression and decompression will sometimes be offset by > decreases in elapsed time due to reduced 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 for VB > > 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: >>> >>> 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, 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 device type? >>>> >>>>> After the first read using bsam read macro I looked at the first 4 >>>>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 >>>>> which seemed to me that it was still processing blksize of 32,000 >> >> -- gil >> -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged a
Re: Large block interface for VB
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) is coded with he BLSR parameters and nothing else, that DD then points (via a BLSR parameter) to a second DD where you put your large concatenation. SMB is applied directly to your primary DD name, specify the SMB parameters on only the first of the concatenated DD's. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Monday, March 1, 2021 1:36 PM 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 x23353 > <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > Joseph, > > I believe that LBI is only for tape inputs and outputs. You can speed up > your processing easier by using either the older BLSR buffering subsystem or > better the newer SMB buffering system. See the JCL reference manual for SMB > parameters. > > Allocate as much REGION as your installation will allow (some installations > limit the maximum any job without special authorization may use, even > sometimes production jobs). > > Use BLSR or SMB to allocate as many buffers as will fit in the REGION size > you can allocate. > > I have seen substantial decreases in run time using these techniques with > very large sequential files. > > I would also recommend using at least software compression or better hardware > compression (if your CPU has it) for your large sequential files. The CPU > time used for compression and decompression will sometimes be offset by > decreases in elapsed time due to reduced 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 for VB > > 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: >>> >>> 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, 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 device type? >>>> >>>>> After the first read using bsam read macro I looked at the first 4 >>>>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 >>>>> which seemed to me that it was still processing blksize of 32,000 >> >> -- gil >> -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 x23353 > <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > Joseph, > > I believe that LBI is only for tape inputs and outputs. You can speed up > your processing easier by using either the older BLSR buffering subsystem or > better the newer SMB buffering system. See the JCL reference manual for SMB > parameters. > > Allocate as much REGION as your installation will allow (some installations > limit the maximum any job without special authorization may use, even > sometimes production jobs). > > Use BLSR or SMB to allocate as many buffers as will fit in the REGION size > you can allocate. > > I have seen substantial decreases in run time using these techniques with > very large sequential files. > > I would also recommend using at least software compression or better hardware > compression (if your CPU has it) for your large sequential files. The CPU > time used for compression and decompression will sometimes be offset by > decreases in elapsed time due to reduced 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 for VB > > EXTERNAL EMAIL > > 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: >>> >>> 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, 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 device type? >>>> >>>>> After the first read using bsam read macro I looked at the first 4 >>>>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 >>>>> which seemed to me that it was still processing blksize of 32,000 >> >> -- gil >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > > -- > 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: Large block interface for VB
Joseph, I believe that LBI is only for tape inputs and outputs. You can speed up your processing easier by using either the older BLSR buffering subsystem or better the newer SMB buffering system. See the JCL reference manual for SMB parameters. Allocate as much REGION as your installation will allow (some installations limit the maximum any job without special authorization may use, even sometimes production jobs). Use BLSR or SMB to allocate as many buffers as will fit in the REGION size you can allocate. I have seen substantial decreases in run time using these techniques with very large sequential files. I would also recommend using at least software compression or better hardware compression (if your CPU has it) for your large sequential files. The CPU time used for compression and decompression will sometimes be offset by decreases in elapsed time due to reduced 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 for VB EXTERNAL EMAIL 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: > >> 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, 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 device type? >>> >>>> After the first read using bsam read macro I looked at the first 4 >>>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 >>>> which seemed to me that it was still processing blksize of 32,000 > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 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, 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 device type? > After the first read using bsam read macro I looked at the first 4 bytes > ( Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed > to me that it was still processing blksize of 32,000 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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: > >> 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, 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 device type? >>> After the first read using bsam read macro I looked at the first 4 bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me that it was still processing blksize of 32,000 > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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, 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 device type? >> >>> After the first read using bsam read macro I looked at the first 4 bytes ( >>> Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to >>> me that it was still processing blksize of 32,000 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large block interface for VB
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 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 device type? > >> After the first read using bsam read macro I looked at the first 4 bytes ( >> Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to >> me that it was still processing blksize of 32,000 > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 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 things up by >specifying a blksize of 32 in the DCBE > What device type? >After the first read using bsam read macro I looked at the first 4 bytes ( >Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me >that it was still processing blksize of 32,000 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Large block interface for VB
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 ( Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me that it was still processing blksize of 32,000 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
