As long as the current product works, we will continue to use it both for CMS applications and VSE data access. If an upgrade to VSE breaks the current support, then we may be interested in purchasing something that works.
Peter -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tony Thigpen Sent: May 21, 2009 10:13 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.4 VSAM question Alan, Interesting thought, intercepting the VSAM calls and redirecting to VSE. That, of course, assumes that the customers are concerned with using CMS/VSAM to access VSE held files. So, the question is: Are people using CMS/VSAM for CMS only applications, OR, are they using it to share data with VSE? Before I, or any other vendor, would develop a new product, we would need to see a market. So, anybody who thinks they would be willing to shell out money for a new, fully supported, vendor product that lets you read VSE/VSAM files from VM, with no changes to existing programs using CMS/VSAM, send me an email off-list. Just to make it interesting, think $10k-$15k a copy. Due to other projects, figure 18 months until availability. Tony Thigpen -----Original Message ----- From: Alan Altmark Sent: 05/20/2009 11:29 PM > On Wednesday, 05/20/2009 at 10:01 EDT, David Boyes <dbo...@sinenomine.net> > wrote: >> On 5/20/09 4:29 AM, "jose raul baron" <jba...@calculo-sa.es> wrote: >> >>> - Does VSAM still exist in z/VM 5.4 ? >>> - Is it perhaps included in the z/VM 5.4 code (e.g. as TCPIP) ? >> No, it's under the same terms (and prices) as of old. > > - The CMS VSAM feature of VSE/VSAM is no longer available. If you don't > have it, you can't get it. > - Someone who already has it cannot give it to you. > - If you already have it, you can keep using it as long as you keep paying > the monthly license charge. > - It isn't licensed for use on IFLs. > - If it has become incompatible with current z/VSE VSAM support, all you > will receive from us are notes of sympathy and regret. > - OTOH, we haven't consciously done anything to break it. If *z/VM* > changes something that breaks *it*, we would likely undo whatever broke it > if that doesn't in turn break something else. (i.e. the reason for the > change in the first place.) > > I can't believe that no one remembers the SPE from around 1985 called the > "Alternate VSAM Emulator" that enables a program to intercept the VSAM > open/close/tclose calls. That means the program provides the addresses of > the read & write entry points as well since the program fills in the ACB. > See > http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.i bm.zvm.v53.dmsa5/hcsd2b00628.htm. > > It was originally exploited by DB2 (SQL/DS) on VM, allowing it to emulate > VSAM. > > I can envision that the VSAM calls and data could be exported via a > custom-built "connector" to z/VSE or z/OS. Or Linux. There are those who > might be willing to pay someone to provide a solution that would leave > their programs intact but sever the connection to CMS/VSAM. I wonder: > Perhaps the emulator could simply use the BPX1xxxx POSIX routines to mount > remote NFS server and read/write data that way. > > Alan Altmark > z/VM Development > IBM Endicott > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
