Re: Hiperbatch revisited
Thanks for that Martin, makes interesting reading. I believe that IBM carried out some kind of investigation here at Express Gifts about 1992, but I don't have any documentation from that time. I was recently asked to investigate dataset contention on a VSAM KSDS approx. 2.6GB. PAV was first put forward, but couldn't be justified since we only see intermittent IOSQ. We couldn't have easily implemented HB with our 9672 with 2GB of central storage, but our zSeries comes with 8GB. Even after accounting for 1GB HSA and approx. 2GB used by MQ, we still have enough free to load most of our cluster into storage, at least overnight. I will try to convince our Ops Analysts to remove BLSR, at least temporarily. Do you know if HBAID is still available ? I have already downloaded Parallel Sysplex Batch Performance, will have another read. 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: Hiperbatch revisited
Alex Tough asked Do you know if HBAID is still available ? Somehow I strongly doubt it. It's been 20 years. Maybe some IBMer still has it squirreled away. As my good friend Ted Blank once told me it started out as a SAS prototype and most of the effort was in replacing it by a series of sort steps. (HBAID has NO external dependencies, other than Sort.) Ted is very experienced at SAS so I guess he wrote the SAS prototype. 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: Hiperbatch revisited
Prompted by all this talk of Hiperbatch I took a trip back down memory lane and blogged about it... http://www.ibm.com/developerworks/blogs/page/MartinPacker?entry=memories_of_hiperbatch It's more reminiscence than anything solid. But you might enjoy it, particularly if you enjoyed it the first time around. :-) 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
Hiperbatch revisited
Having some fun this week with Hiperbatch. I want to run one of our largest VSAM clusters as a retained DLF object in RACF during batch run. Asked Ops to run EXPORT, IMPORT to load into memory and everything looked fine, so went to bed. Next morning, it turns out that the object has been purged after being updated by job using BLSR. Today I have proven to myself with a very simple Cobol programme that subsequent use of BLSR will purge a retained object, but I can't see from the MVS Hiperbatch Guide that this is working as expected : Retained DLF objects continue to exist after the last user closes the data set and must be deleted in one of the following ways: * When the data set is recreated. * When the data set is deleted or renamed. * When the data set is updated by an access method (such as BSAM) that does not support Hiperbatch. * When the object is explicitly deleted The data set hasn't been recreated, deleted, renamed or explicitly deleted (I've tested that), so that just leaves being updated by an unsupported access method. Using BLSR with VSAM, the access method is still VSAM, certainly that's what I see in relevant SMF type 64 records. Granted that it may well not be a good idea to access same cluster using both BLSR and Hiperbatch and we can easily change our JCL. Anybody seen this behaviour or have any thoughts ? many thanks, 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
RES: Hiperbatch revisited
Long time since last time i've used Hiperbatch (and problably i'm missing something), but i'll try to list some other issues with Hiperbatch : a) CI size must be multiple of 4096 b) Does not work with shroptions 3 or 4 (VSAM) c) Only QSAM (No Sort, IEBGENER) and VSAM sequential reading d) Dataset can not be opened as I/O (otherwise will be removed from storage) e) If you want to use it with SORT, you can code EXIT15 and EXIT35 using QSAM It used to work pretty fine (i believe it still does) but you have to follow the rules... 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 Alex Tough Enviada em: sexta-feira, 9 de novembro de 2007 16:00 Para: IBM-MAIN@BAMA.UA.EDU Assunto: Hiperbatch revisited Having some fun this week with Hiperbatch. I want to run one of our largest VSAM clusters as a retained DLF object in RACF during batch run. Asked Ops to run EXPORT, IMPORT to load into memory and everything looked fine, so went to bed. Next morning, it turns out that the object has been purged after being updated by job using BLSR. Today I have proven to myself with a very simple Cobol programme that subsequent use of BLSR will purge a retained object, but I can't see from the MVS Hiperbatch Guide that this is working as expected : Retained DLF objects continue to exist after the last user closes the data set and must be deleted in one of the following ways: * When the data set is recreated. * When the data set is deleted or renamed. * When the data set is updated by an access method (such as BSAM) that does not support Hiperbatch. * When the object is explicitly deleted The data set hasn't been recreated, deleted, renamed or explicitly deleted (I've tested that), so that just leaves being updated by an unsupported access method. Using BLSR with VSAM, the access method is still VSAM, certainly that's what I see in relevant SMF type 64 records. Granted that it may well not be a good idea to access same cluster using both BLSR and Hiperbatch and we can easily change our JCL. Anybody seen this behaviour or have any thoughts ? many thanks, 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 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: Hiperbatch revisited
I'm sure I can page this stuff back in if I have to. :-) But for now suffice it to say that BLSR postdates Hiperbatch and the latter didn't unfortunately gain enough speed to get airborne i.e. have a subsequent release (maybe even of the docs). :-( It's certainly true that LSR access causes the effect you mention. And BLSR is just a delivery mechanism for LSR. And for the purposes of this conversation I'd say VSAM LSR is sufficiently different from VSAM NSR for this to be no real surprise. Granted the data underneath is the same - else you wouldn't have gotten into this situation - but the buffering algorithm is totally different. Not defending this, just shedding some perspective on it. And I know there are other people on IBM-MAIN who have their own experiences of Hiperbatch from the Development perspective. (Personally I consider Hiperbatch a fore-runner in a way to BatchPipes/MVS and I KNOW there's an ex-Pipes developer hanging out here BTW Pipes is still alive and well and worth considering for Sequential data.) As Hiperbatch - given the IBM-MAIN traffic on it today - seems to be a topical (ahem) topic :-) I may just have to find something Hiperbatch-related to blog on. :-) 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: RES: Hiperbatch revisited
Another restriction - which might be the most severe of all: Hiperbatch is not supported for Extended Format Sequential or VSAM. Think Striped, Compressed, 4GB. 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
