Re: Performance comparison: Hiperbatch, BLSR, SMB?
Peter Apologies if this has already been answered, but the way for a job to opt out of using Hiperbatch is to ask your RACF Security Admin to update the DLF DATA segment for a particular dataset and remove that job or jobs (using a wildcard) from the list of jobs that are allowed to access the DLF object. I struggle to understand how BLSR can give better performance than HB if all other system resources are equal (same WLM Service Class, similar level of CPU contention). My understanding of BLSR is that it will buffer parts (in Control Intervals) of your VSAM cluster into memory. If you have all or most of the cluster allocated to a DLF data object, why would BLSR be faster ? You say that you don't have access to SMF data, but do you have access to RMF or Omegamon/Epilog to indicate what is causing performance degradation ? regards, Alex Alex Tough Systems Programmer Express Gifts -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
Alex Tough asked: If you have all or most of the cluster allocated to a DLF data object, why would BLSR be faster ? It might depend on what you mean by faster... Note that nowadays a DLF (or any) hiperspace would be backed by central but would still require a more distant data movement. And, in principle, VSAM LSR (whether via BLSR or not) ought to be in the job's own address space. So, in CPU terms I'd speculate that BLSR might cost less CPU. That probably wouldn't turn into elapsed time differences that were measurable - but it just MIGHT. Another thing to remember, though, is that Hiperbatch keeps the memory pro bono publico whereas BLSR doesn't. The affordability of Hiperbatch may be much greater for CONCURRENT jobs. In the same vein with multiple BLSR jobs each job would have to populate the buffer pool itself. So initially you might get a lot of misses. All a long-winded way of saying YMMV. :-) Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
Also, remember that for Hiperbatch only the Data component is kept in the DLF object. So you would still have to deal with I/Os to the index. You can provide enough buffers to keep the index set in storage but you don't get lookaside on the sequence set. With BLSR, you can avoid the seqence set I/Os too. So you have to see which is going to provide the greater benefit, eliminating all of the data I/Os with Hiperbatch, or eliminating more index I/Os (and hopefully some data I/Os) with BLSR. Which provides greater benefit is going to depend on the reference patterns of the jobs accessing the file (that's a fancy way of saying YMMV!). :-) Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/12/2007 07:44:59 AM: Alex Tough asked: If you have all or most of the cluster allocated to a DLF data object, why would BLSR be faster ? It might depend on what you mean by faster... Note that nowadays a DLF (or any) hiperspace would be backed by central but would still require a more distant data movement. And, in principle, VSAM LSR (whether via BLSR or not) ought to be in the job's own address space. So, in CPU terms I'd speculate that BLSR might cost less CPU. That probably wouldn't turn into elapsed time differences that were measurable - but it just MIGHT. Another thing to remember, though, is that Hiperbatch keeps the memory pro bono publico whereas BLSR doesn't. The affordability of Hiperbatch may be much greater for CONCURRENT jobs. In the same vein with multiple BLSR jobs each job would have to populate the buffer pool itself. So initially you might get a lot of misses. All a long-winded way of saying YMMV. :-) Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
-Original Message- From: Alex Tough [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 7:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Performance comparison: Hiperbatch, BLSR, SMB? Peter Apologies if this has already been answered, but the way for a job to opt out of using Hiperbatch is to ask your RACF Security Admin to update the DLF DATA segment for a particular dataset and remove that job or jobs (using a wildcard) from the list of jobs that are allowed to access the DLF object. I struggle to understand how BLSR can give better performance than HB if all other system resources are equal (same WLM Service Class, similar level of CPU contention). My understanding of BLSR is that it will buffer parts (in Control Intervals) of your VSAM cluster into memory. If you have all or most of the cluster allocated to a DLF data object, why would BLSR be faster ? You say that you don't have access to SMF data, but do you have access to RMF or Omegamon/Epilog to indicate what is causing performance degradation ? As to RMF access, I don't think so, but I've also not gone looking for it yet. Ditto for Omegamon/Epilog, but I can ask about it. I have officially asked the performance gurus here to look at these jobs and tell me what we can do to improve the performance. It's very hard for me to test different HB scenarios because HB is so strictly controlled by security methods and I have no authorization to use it. I do understand that BLSR may not help in this scenario, but having tested with SMB (without HB) and noted 50% savings in counted I/O's for that KSDS, I thought SMB would be a good thing to use. However, it apparently conflicted with HB and made the performance several times as bad as HB alone when we tried it out in the QA environment with HB active. Hence my research and questions here. Peter 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RES: Performance comparison: Hiperbatch, BLSR, SMB?
Peter, Try using COFDMON programs that can show you who is currently using hiperbatch at the moment. The source code is in SYS1.SAMPLIB and used to work pretty fine. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Engenharia de Software - Sistemas Operacionais Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 -Mensagem original- De: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Em nome de Farley, Peter x23353 Enviada em: segunda-feira, 12 de novembro de 2007 13:30 Para: IBM-MAIN@BAMA.UA.EDU Assunto: Re: Performance comparison: Hiperbatch, BLSR, SMB? -Original Message- From: Alex Tough [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 7:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Performance comparison: Hiperbatch, BLSR, SMB? Peter Apologies if this has already been answered, but the way for a job to opt out of using Hiperbatch is to ask your RACF Security Admin to update the DLF DATA segment for a particular dataset and remove that job or jobs (using a wildcard) from the list of jobs that are allowed to access the DLF object. I struggle to understand how BLSR can give better performance than HB if all other system resources are equal (same WLM Service Class, similar level of CPU contention). My understanding of BLSR is that it will buffer parts (in Control Intervals) of your VSAM cluster into memory. If you have all or most of the cluster allocated to a DLF data object, why would BLSR be faster ? You say that you don't have access to SMF data, but do you have access to RMF or Omegamon/Epilog to indicate what is causing performance degradation ? As to RMF access, I don't think so, but I've also not gone looking for it yet. Ditto for Omegamon/Epilog, but I can ask about it. I have officially asked the performance gurus here to look at these jobs and tell me what we can do to improve the performance. It's very hard for me to test different HB scenarios because HB is so strictly controlled by security methods and I have no authorization to use it. I do understand that BLSR may not help in this scenario, but having tested with SMB (without HB) and noted 50% savings in counted I/O's for that KSDS, I thought SMB would be a good thing to use. However, it apparently conflicted with HB and made the performance several times as bad as HB alone when we tried it out in the QA environment with HB active. Hence my research and questions here. Peter 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html HTMLfont face=Tahoma size=1HRAVISO LEGAL brEsta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. HTMLfont face=Tahoma size=1HRLEGAL ADVICE brThis message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu
Re: Performance comparison: Hiperbatch, BLSR, SMB?
-Original Message- From: ITURIEL DO NASCIMENTO NETO [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 1:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: RES: Performance comparison: Hiperbatch, BLSR, SMB? Peter, Try using COFDMON programs that can show you who is currently using hiperbatch at the moment. The source code is in SYS1.SAMPLIB and used to work pretty fine. That looks like a very interesting program. Unfortunately, it requires authorization and authority to run it. From the comments in the COFDMON main program: Restrictions: - COFDMON must reside in an APF-authorized library or in the LNKLST. - COFDMON must be linkedited with AC=1. - The following IKJTSOnn parms must be set: AUTHCMD NAMES(COFDMON) Not having access to an authorized library nor authority to change TKJTSOnn parms, I would not be able to run it anyway. Thank you for the pointer anyway, this is quite interesting code. Peter 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
On Mon, 12 Nov 2007 14:15:08 -0500, Farley, Peter x23353 wrote: -Original Message- From: ITURIEL DO NASCIMENTO NETO Try using COFDMON programs that can show you who is currently using hiperbatch at the moment. The source code is in SYS1.SAMPLIB and used to work pretty fine. That looks like a very interesting program. Unfortunately, it requires authorization and authority to run it. From the comments in the COFDMON main program: Restrictions: - COFDMON must reside in an APF-authorized library or in the LNKLST. - COFDMON must be linkedited with AC=1. - The following IKJTSOnn parms must be set: AUTHCMD NAMES(COFDMON) Not having access to an authorized library nor authority to change TKJTSOnn parms, I would not be able to run it anyway. Peter, You can run it, you just can't perform the linkedit yourself; find a friendly sysprog to do that for you and then you ought to be good to go. -- Tom Schmidt Madison, WI (What ever happened to Bala and Ziggy, anyway?) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Performance comparison: Hiperbatch, BLSR, SMB?
Hi all, We have a highly used randomly accessed read-only VSAM KSDS that is managed by Hiperbatch during the Production batch window. Unfortunately, some of the jobs that use it are still seeing unacceptably high I/O counts and long elapsed times. I have been asked to improve the performance of these jobs in my application area. I think I need to determine if Hiperbatch is still the best way for our programs to access this file, or whether BLSR or the newer SMB buffering will produce better results overall. Many tens, perhaps hundreds, of jobs probably access this file over the course of the batch window. My experience so far is that I can get proveably better performance than Production gets from an individual job by using BLSR or SMB in place of Hiperbatch, but I have no handle on how exchanging one central memory repository (Hiperbatch) for tens or hundreds of jobs buffering the file themselves will affect overall system performance and thus the performance of all the jobs that use the file. I also haven't got test access to Hiperbatch (yet), so it's kind of hard to run comparison tests myself at the moment. That may change, but it will take a while before I can think about having that access. Is there a way for an individual job to opt out of letting Hiperbatch manage a particular file? Without stopping other jobs from continuing to use it? Advice, pointers to redbooks or whitepapers, any help at all gratefully accepted. Peter P.S. -- I do NOT have access to SMF records, I do NOT have access to DCOLLECT, nor any other real performance measurement tools. I'm just the programmer trying to improve the job's performance based on what I see in the JESMSGLG and JESYSMSG outputs. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
Unfortuanately I haven't looked up this stuff in a long time, so I might be wrong. But IIRC, Hiperbatch is intended for sequential access and is counter-productive for random files. Since it uses a Most Recently Used algorithm (instead of LRU), the intent was to ensure that the most recent access to a record was the most eligible for getting discarded from memory (since this represented the last reader of the data). The whole point was to avoid having records discarded because of age just ahead of someone that was reading the file sequentially. Also, another point was that the I/O counts were unaffected since the application was unaware that it was using Hiperbatch, so that information is largely irrelevant. Anyway ... here's hoping my memory isn't completely gone Adam We have a highly used randomly accessed read-only VSAM KSDS that is managed by Hiperbatch during the Production batch window. Unfortunately, some of the jobs that use it are still seeing unacceptably high I/O counts and long elapsed times. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RES: Performance comparison: Hiperbatch, BLSR, SMB?
Hiperbatch works only with sequential data. If you use it random it will simply not work. SMB is a great tool and can be used for any kind of access, but you have to pay attention in the ACB of the program that opens the dataset. If ACB specifies RANDOM and SEQUENTIAL, (ACCESS MODE IS DYNAMIC in Cobol) you have to select the most appropriate in JCL, otherwise your job can suffer. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Engenharia de Software - Sistemas Operacionais Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 HTMLfont face=Tahoma size=1HRAVISO LEGAL brEsta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. HTMLfont face=Tahoma size=1HRLEGAL ADVICE brThis message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RES: Performance comparison: Hiperbatch, BLSR, SMB?
You can copy a VSAM file to populate the Hiperbatch hiperspace. And then read it from there - by multiple jobs using VSAM NSR. If the reference patterns of the key jobs are tight you may do better with BLSR to trigger VSAM LSR. If the file is large most of it might not fit in Hiperbatch. Ypu're right to question one big store vs lots of smaller ones. Maybe it's the big jobs that need their own big stores - by increasing the VSAM LSR buffer pool sizes on those jobs. (Often people tell me they've been aggressive with buffering and I subsequently discover by aggressive they mean 10MB. It was ridiculous 20 years ago. Guess what it is now.) :-) Really you need proper data analysis - at a number of levels - to figure out what's likely to work best. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
-Original Message- From: ITURIEL DO NASCIMENTO NETO [mailto:[EMAIL PROTECTED] Sent: Friday, November 09, 2007 2:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: RES: Performance comparison: Hiperbatch, BLSR, SMB? Hiperbatch works only with sequential data. If you use it random it will simply not work. I must differ with you. We use Hiperbatch all night long in many, many jobs that use the file randomly and simultaneously (and my SMF gurus have the data and reports to back that up). Also, here is a quote from the last published Hiperbatch manual: Hiperbatch can place data in a DLF object only when the job reads or writes the data set sequentially. Once data is in the DLF object, then jobs can read the data from the object both randomly and sequentially. URL for the Hiperbatch manual is here (watch the wrap): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA5J700/2.2.2?SH ELF=EZ2ZO10IDT=19990208095033#HDRRANDOM SMB is a great tool and can be used for any kind of access, but you have to pay attention in the ACB of the program that opens the dataset. If ACB specifies RANDOM and SEQUENTIAL, (ACCESS MODE IS DYNAMIC in Cobol) you have to select the most appropriate in JCL, otherwise your job can suffer. Agreed. BTDT, and when you select the right ACCBIAS it works very well. Peter 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
-Original Message- From: Gerhard Adam [mailto:[EMAIL PROTECTED] Sent: Friday, November 09, 2007 1:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Performance comparison: Hiperbatch, BLSR, SMB? Unfortuanately I haven't looked up this stuff in a long time, so I might be wrong. But IIRC, Hiperbatch is intended for sequential access and is counter-productive for random files. Since it uses a Most Recently Used algorithm (instead of LRU), the intent was to ensure that the most recent access to a record was the most eligible for getting discarded from memory (since this represented the last reader of the data). Well, I don't know about your memory, but the latest version does indeed support random access, AFTER the DLF has been loaded sequentially. Don't know what algorithm it uses, but my SMF gurus tell me they can prove it is being used, and in fact the batch jobs run longer if anything happens to Hiperbatch, so I think it's working. Our access is almost all random. The whole point was to avoid having records discarded because of age just ahead of someone that was reading the file sequentially. Also, another point was that the I/O counts were unaffected since the application was unaware that it was using Hiperbatch, so that information is largely irrelevant. I didn't know that, but it makes sense. Thanks. Anyway ... here's hoping my memory isn't completely gone Not completely. :) Peter 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
Remember there are two types of DLF objects (Hiperbatch Retain and non-Retain) Non-Retain is the one that gets deleted when the open count for the dataset is 0. This is the one that was intended for sequential use and you didn't need a DLR object as large as the dataset. Just one large enough that concurrent sequential readers would benefit. Reader 1 reads from disk and places copy in Hiperbatch, readers 2, 3, 4, etc. read the Hiperbatch copy. If the DLF object can hold 100 records than you just hope the other readers have all gotten to record 1 before the first one gets to record 101. Sort of a moving window. Retain is the one that stays there until you explicility delete it. This is good for both sequential and random, especially if it's large enough to fit the entire dataset. You load the whole thing into memory once and then everyone reads the Hiperbatch copy in memory. Just thought I'd pass on that distinction since it's important when talking about whether sequential or random can benefit. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] 1-240-715-4655, tie line 268-1499 DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/09/2007 04:07:56 PM: -Original Message- From: Gerhard Adam [mailto:[EMAIL PROTECTED] Sent: Friday, November 09, 2007 1:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Performance comparison: Hiperbatch, BLSR, SMB? Unfortuanately I haven't looked up this stuff in a long time, so I might be wrong. But IIRC, Hiperbatch is intended for sequential access and is counter-productive for random files. Since it uses a Most Recently Used algorithm (instead of LRU), the intent was to ensure that the most recent access to a record was the most eligible for getting discarded from memory (since this represented the last reader of the data). Well, I don't know about your memory, but the latest version does indeed support random access, AFTER the DLF has been loaded sequentially. Don't know what algorithm it uses, but my SMF gurus tell me they can prove it is being used, and in fact the batch jobs run longer if anything happens to Hiperbatch, so I think it's working. Our access is almost all random. The whole point was to avoid having records discarded because of age just ahead of someone that was reading the file sequentially. Also, another point was that the I/O counts were unaffected since the application was unaware that it was using Hiperbatch, so that information is largely irrelevant. I didn't know that, but it makes sense. Thanks. Anyway ... here's hoping my memory isn't completely gone Not completely. :) Peter 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
