Re: Transactional VSAM (DFSMStvs) question - performance
We had a couple of shared packs. I even had datasets in the linklist on both the PROD and TEST Lpars. I only updated them on the PROD Lpar, and then did a LLA refresh on the test lpar. Whenever I rebuilt the test lpar, I just went with 3.4 and catalogued the PDSs I needed in the Test Lpars catalogues. Like I said, I never had a problem, but I realize it is risky. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: McKown, John [EMAIL PROTECTED] One of my configurations was a two monoplexes with an iron curtain between them. When the others realized that I meant absolutely NO sharing of ANYTHING, they were aghast as the thought. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- 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: Transactional VSAM (DFSMStvs) question - performance
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld Sent: Friday, November 30, 2007 12:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Transactional VSAM (DFSMStvs) question - performance You are probably right - having a sysplex is a better way to go, but running two Lpars on the same box with most of the dasd offline to the opposite lpar is a pretty safe way to go, if done right. At PH Mining, we ran that way for years, and never had a problem. Granted, the TEST Lpar was mostly a sysprog lpar, but it was used occasionally for testing by the programmers. We often had to back up their files from the PROD Lpar and restore them to the TEST lpar so they could have valid test data. As long as you don't share VSAM or database data, you are ok. You have to only update PDS files on one lpar if you share them. Eric Bielefeld One of my configurations was a two monoplexes with an iron curtain between them. When the others realized that I meant absolutely NO sharing of ANYTHING, they were aghast as the thought. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Transactional VSAM (DFSMStvs) question - performance
John, AFAIK TVS is a paid feature. May be you should look at SMSVSAM, that is free and has funcionality you're looking for, with great performance. 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 McKown, John Enviada em: sexta-feira, 30 de novembro de 2007 15:40 Para: IBM-MAIN@BAMA.UA.EDU Assunto: Re: Transactional VSAM (DFSMStvs) question - performance -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Friday, November 30, 2007 11:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Transactional VSAM (DFSMStvs) question - performance John, Do you have a coupling facility? (My understanding was that you don't.) If you do not have a coupling facility you will not be able to use DFSMStvs (Transactional VSAM) since it requires RLS, which requires a CF for at least 2 structures. I expect that you knew that but this stuff is archived. Thanks. You are right in that I don't have a CF. TVS is one of my arguments for a CF. We are splitting our single z/OS into two images (prod vs. non-prod). I am really pushing Parallel Sysplex to the max. But a CFL engine on our z9BC supposedly costs US $201,000! OUCH. So I need as much plus as possible to sell this to management. Which is difficult since I don't even want to split the z/OS image. I lost that battle. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Transactional VSAM (DFSMStvs) question - performance
On Fri, 30 Nov 2007 09:28:08 -0600, McKown, John wrote: Does anybody have any statistics about how much impact (slowing down of the batch program) using Transaction VSAM for accessing VSAM data in batch would have compared to accessing the same data without it. Any comparisons with SYSB from HW? John, Do you have a coupling facility? (My understanding was that you don't.) If you do not have a coupling facility you will not be able to use DFSMStvs (Transactional VSAM) since it requires RLS, which requires a CF for at least 2 structures. I expect that you knew that but this stuff is archived. We have found (just this month) that the elapsed time for the batch job is sometimes unchanged and other times it actually ran faster with DFSMStvs. The CPU time is much more difficult to measure, since SYSB's CPU time is spread across a lot of components. From the measurements that we have, we believe it to be approximately equal (hard to guess what the VTAM CICS dispatcher overhead for the SYSB stuff actually was). The clear advantage of DFSMStvs is that it does not burden the CICS QR TCB with the batch job's VSAM file processing while still maintaining data buffer coherency and integrity. It does what it says it does without hurting transaction throughput. -- Tom Schmidt -- 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: Transactional VSAM (DFSMStvs) question - performance
But a CFL engine on our z9BC supposedly costs US $201,000! OUCH. Yes! OUCH! The first quote I saw was $125,000. And, I've heard they are down around USD90,000. Can you verify with IBM? Negotiate a discount? - Too busy driving to stop for gas! -- 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: Transactional VSAM (DFSMStvs) question - performance
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Friday, November 30, 2007 11:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Transactional VSAM (DFSMStvs) question - performance John, Do you have a coupling facility? (My understanding was that you don't.) If you do not have a coupling facility you will not be able to use DFSMStvs (Transactional VSAM) since it requires RLS, which requires a CF for at least 2 structures. I expect that you knew that but this stuff is archived. Thanks. You are right in that I don't have a CF. TVS is one of my arguments for a CF. We are splitting our single z/OS into two images (prod vs. non-prod). I am really pushing Parallel Sysplex to the max. But a CFL engine on our z9BC supposedly costs US $201,000! OUCH. So I need as much plus as possible to sell this to management. Which is difficult since I don't even want to split the z/OS image. I lost that battle. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Transactional VSAM (DFSMStvs) question - performance
You are probably right - having a sysplex is a better way to go, but running two Lpars on the same box with most of the dasd offline to the opposite lpar is a pretty safe way to go, if done right. At PH Mining, we ran that way for years, and never had a problem. Granted, the TEST Lpar was mostly a sysprog lpar, but it was used occasionally for testing by the programmers. We often had to back up their files from the PROD Lpar and restore them to the TEST lpar so they could have valid test data. As long as you don't share VSAM or database data, you are ok. You have to only update PDS files on one lpar if you share them. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: McKown, John [EMAIL PROTECTED] Thanks. You are right in that I don't have a CF. TVS is one of my arguments for a CF. We are splitting our single z/OS into two images (prod vs. non-prod). I am really pushing Parallel Sysplex to the max. But a CFL engine on our z9BC supposedly costs US $201,000! OUCH. So I need as much plus as possible to sell this to management. Which is difficult since I don't even want to split the z/OS image. I lost that battle. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- 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
Transactional VSAM (DFSMStvs) question - performance
Does anybody have any statistics about how much impact (slowing down of the batch program) using Transaction VSAM for accessing VSAM data in batch would have compared to accessing the same data without it. Any comparisons with SYSB from HW? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
