Is there a reason that zOS NFS won't work? Then you'd have direct access to the file, without copying via FTP or to z/VM, via a documented, supported and auditable interface to zOS that is also documented and supported by zLinux in the standard distribution. No odd files to build. No security or audit holes to document. The glossy sheet is at http://www-03.ibm.com/systems/z/os/zos/nfs/index.html
This is an interface that I'd easily be able to "sell" at my site. The pieces are already all in place, as they're part of the standard operating systems. There's network time involved, but there would be with any of the solutions. There's no additional disk space involved as there would be with an FTP store and forward type solution. I think NFS would be a much cleaner solution to your problem than mvsdasd. And, it has the advantage of being understandable by the person(s) who come along after you who might have to support it or make changes to it. -- Robert P. Nix Mayo Foundation .~. RO-OC-1-18 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 11/9/11 8:59 AM, "Agblad Tore" <[email protected]> wrote: > Ok, since I think I was the one starting this I think a clarification about > the reason is in place :) > The 'problem': We need to read huge amount of data using a program on zLinux, > but it needs access to the files. > We could use ftp, but due to the > huge amount of data, most of the costsaving is eaten up by ftp-cpucycles in > z/OS :( > And it takes time. > > If we could access the actual disks or files directly from zLinux it would > really cut the cost here. > > In that case it is some dedicated volumes, scheduled and documented z/OS jobs. > > And about the mvsdasd program, it works like this: > At the outpointed dasd volume it search for a file with a specified name, it > must be there and it is a z/OS std seq file. > It is created in z/OS and protected by RACF/ACF2. > That file should contain names of files on that volume that mvsdasd is allowed > to read. > > I think this makes it secure and auditable enough. > > But I haven't had the spare time to have this one working yet. > For the moment we test to copy files from z/OS to z/VM CMS-files (tracable and > auditable) and then read it from zLinux. > > /Tore ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
