Re: z/VM - Lightweight specific purpose file system
Emulation would be a non-starter for a production environment. I would describe this system as a single pass code segment translation system with conditional block invalidation. We have been using VM for 20 of our 27 years in business. A development environment without it has never been considered an option. Many companies (ours included) consider running a few dozen virtual Windows® images on a rack-mounted machine good business. We see no reason why z/System should not support from 250 images on the low end to several thousand on mid and high end systems. On 3/25/08 5:45 PM, "Stephen Frazier" <[EMAIL PROTECTED]> wrote: > Are you attempting to write a windows emulator that runs under VM? > > Looking at your companies web site it looks like you mostly sell products that > run under z/OS. > > If you can do this there will be a lot of interest. > > Gary M. Dennis wrote: >> Months ago. The development team was so focused on instruction result >> fidelity, machine state, and segment translation bypass issues that I/O >> subsystem did not receive the necessary attention. At least the tough part >> is done. >> >> Gary Dennis >> Mantissa --. .- .-. -.-- Gary M. Dennis Mantissa Corporation 2 Perimeter Park South Birmingham, Alabama 35243-3274 p: 205.968-3942 m: 205.218-3937 f: 205.968.3932 [EMAIL PROTECTED] http://www.mantissa.com http://www.idovos.com
Re: Question about virtual tape in a zVM environment
I just realized you mentioned the target category specified on the mount command was VOLSPECIFIC. Check out PMH 84921,004,000 as this is a known problem being worked. Check with your CE on a timeframe when the fix will be available. Best Regards, Les Geer IBM z/VM and Linux Development >You are referring to the z/VM530 documentation, aren't you ? > >With or without target parameter in the MOUNT cmd, the targetcat is not >changed under z/VM440 when asking for a scratch in P2P. Did the test with >z/VM530, no change. > >This hardware situation is a major regression. >We could not live if the problem was similar with MVS. We mount thousands >VTS tapes a day. > > >>> I suppose you would be aware of our peer-to-peer problem. >>> >>> When we got a 2nd 3494 in 2004, we decided to make them talk each other >>> as P2P mode. This situation revealed a major problem related to the tar= >get >>> category. In basic mode, asking to mount a scratch through vmtape, rmsma= >str >>> changed the category from scratch to volspecific. No more true in P2P (f= >or >>> us). >>> We have upgraded our 3494, we have opened PMR, we have asked the IBM >>> hardware their advice with no result. We even asked the dfsms doc to be >>> changed related the p2p part to make it clearer. >>> >>> We had to developp something to change the categories according to what >>> has been mounted during the day. I would really like to know if someone = >is >>> in the same situation >>> >> >> I was under the impression with more recent PtP microcode levels the >> restriction on a mount that a target category could not be specified >> was removed. >> >> >> Best Regards, >> Les Geer >> IBM z/VM and Linux Development >>
Re: Question about virtual tape in a zVM environment
Jr, Unfortunately, I have no weight to make the hardware change his position on this. I suppose I could use 'RMS supports PtP as a single node VTS' as a new argument to reopen an issue. But I think I found people more stubborn than me. Alain Le 25/03/08 23:08, « Imler, Steven J » <[EMAIL PROTECTED]> a écrit : > Hi Alain, > > I thought your finally got this ironed out and the problem was resolved? > > As Les states, that restriction was removed and this should not be a > problem. We have several customers who run P2P configurations and do > not have this problem. VM:Tape was changed (back) to use the TARGETCAT > VOLSPECIFIC option on MOUNT SCRATCH requests at least 2 GenLevels ago > (probably 5 or 6 years ago). > > JR (Steven) Imler > CA > Senior Software Engineer > Tel: +1 703 708 3479 > Fax: +1 703 708 3267 > [EMAIL PROTECTED] > > >> -Original Message- >> From: The IBM z/VM Operating System >> [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) >> Sent: Tuesday, March 25, 2008 03:03 PM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Re: Question about virtual tape in a zVM environment >> >>> I suppose you would be aware of our peer-to-peer problem. >>> >>> When we got a 2nd 3494 in 2004, we decided to make them talk >> each other >>> as P2P mode. This situation revealed a major problem >> related to the target >>> category. In basic mode, asking to mount a scratch through >> vmtape, rmsmastr >>> changed the category from scratch to volspecific. No more >> true in P2P (for us). >>> We have upgraded our 3494, we have opened PMR, we have asked the IBM >>> hardware their advice with no result. We even asked the >> dfsms doc to be >>> changed related the p2p part to make it clearer. >>> >>> We had to developp something to change the categories >> according to what >>> has been mounted during the day. I would really like to know >> if someone is >>> in the same situation >>> >> >> I was under the impression with more recent PtP microcode levels the >> restriction on a mount that a target category could not be specified >> was removed. >> >> >> Best Regards, >> Les Geer >> IBM z/VM and Linux Development >> >> >
Re: z/VM - Lightweight specific purpose file system
Are you attempting to write a windows emulator that runs under VM? Looking at your companies web site it looks like you mostly sell products that run under z/OS. If you can do this there will be a lot of interest. Gary M. Dennis wrote: Months ago. The development team was so focused on instruction result fidelity, machine state, and segment translation bypass issues that I/O subsystem did not receive the necessary attention. At least the tough part is done. Gary Dennis Mantissa -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: z/VM - Lightweight specific purpose file system
Months ago. The development team was so focused on instruction result fidelity, machine state, and segment translation bypass issues that I/O subsystem did not receive the necessary attention. At least the tough part is done. Gary Dennis Mantissa On 3/25/08 4:17 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Ummm, I may have missed something, but since when can you run Windows on > an IBM mainframe? > > Peter > > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Gary M. Dennis > Sent: March 25, 2008 17:14 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: z/VM - Lightweight specific purpose file system > > The callable services benchmarks we conducted with BFS ran between 8 and > 10 > times longer than the test set running with the CMS file system. > > Assuming a cluster of 125 Windows(r) 2K z/VM guests and using I/O counts > generated by Win 2K on native Intel hardware the results of > extrapolating > the I/O overhead spooked us a bit. In effect, all our instruction > pipeline > optimization and translated instruction segment reuse optimization would > be > negated by the I/O overhead. > > We have a callable file system for z/OS that can handle an array of 128 > pools each containing up to 255 volumes each. That system would be a > bear to > convert owing to the OS-specific interface code but it appears from your > comments that converting may have to be seriously considered to achieve > the > desired results. > > Thank you. > > > Gary Dennis > Mantissa > > On 3/25/08 9:55 AM, "Alan Altmark" <[EMAIL PROTECTED]> wrote: > >> On Tuesday, 03/25/2008 at 04:26 EDT, "Gary M. Dennis" >> <[EMAIL PROTECTED]> wrote: >> >>> Is anyone aware of a VM open source file system port with some of the >>> characteristics listed below. Such a system might enable us to add > the >>> functionality needed to support these guests without starting at > zero. >> >> It isn't Open Source, but CMS has a POSIX file system (Byte File > System, >> BFS) that is managed by the SFS server, allocating space only as used. > I >> don't know that I would classify it as "lightweight", though from the > CMS >> user's point of view, it is, since the I/O takes place in the SFS > server, >> but it takes APPC/VM (IUCV on steriods) calls to make it happen. You > can >> talk to it in assembler using the BPX1 callable services. It > could >> provide you a "jump start" while you develop your own file system. >> >> And just in case you haven't discovered it already, there's no > "pluggable" >> file system interface in CMS. You will need to write your file system >> from the bottom up. The only help CMS will provide to you is in the > form >> of HNDIO,HNDSVC, NUCEXT, and NUCXLOAD. >> >> 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. >
Re: Question about virtual tape in a zVM environment
Hi Alain, I thought your finally got this ironed out and the problem was resolved? As Les states, that restriction was removed and this should not be a problem. We have several customers who run P2P configurations and do not have this problem. VM:Tape was changed (back) to use the TARGETCAT VOLSPECIFIC option on MOUNT SCRATCH requests at least 2 GenLevels ago (probably 5 or 6 years ago). JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) > Sent: Tuesday, March 25, 2008 03:03 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Question about virtual tape in a zVM environment > > >I suppose you would be aware of our peer-to-peer problem. > > > >When we got a 2nd 3494 in 2004, we decided to make them talk > each other > >as P2P mode. This situation revealed a major problem > related to the target > >category. In basic mode, asking to mount a scratch through > vmtape, rmsmastr > >changed the category from scratch to volspecific. No more > true in P2P (for us). > >We have upgraded our 3494, we have opened PMR, we have asked the IBM > >hardware their advice with no result. We even asked the > dfsms doc to be > >changed related the p2p part to make it clearer. > > > >We had to developp something to change the categories > according to what > >has been mounted during the day. I would really like to know > if someone is > >in the same situation > > > > I was under the impression with more recent PtP microcode levels the > restriction on a mount that a target category could not be specified > was removed. > > > Best Regards, > Les Geer > IBM z/VM and Linux Development > >
Re: z/VM - Lightweight specific purpose file system
Ummm, I may have missed something, but since when can you run Windows on an IBM mainframe? Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gary M. Dennis Sent: March 25, 2008 17:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM - Lightweight specific purpose file system The callable services benchmarks we conducted with BFS ran between 8 and 10 times longer than the test set running with the CMS file system. Assuming a cluster of 125 Windows(r) 2K z/VM guests and using I/O counts generated by Win 2K on native Intel hardware the results of extrapolating the I/O overhead spooked us a bit. In effect, all our instruction pipeline optimization and translated instruction segment reuse optimization would be negated by the I/O overhead. We have a callable file system for z/OS that can handle an array of 128 pools each containing up to 255 volumes each. That system would be a bear to convert owing to the OS-specific interface code but it appears from your comments that converting may have to be seriously considered to achieve the desired results. Thank you. Gary Dennis Mantissa On 3/25/08 9:55 AM, "Alan Altmark" <[EMAIL PROTECTED]> wrote: > On Tuesday, 03/25/2008 at 04:26 EDT, "Gary M. Dennis" > <[EMAIL PROTECTED]> wrote: > >> Is anyone aware of a VM open source file system port with some of the >> characteristics listed below. Such a system might enable us to add the >> functionality needed to support these guests without starting at zero. > > It isn't Open Source, but CMS has a POSIX file system (Byte File System, > BFS) that is managed by the SFS server, allocating space only as used. I > don't know that I would classify it as "lightweight", though from the CMS > user's point of view, it is, since the I/O takes place in the SFS server, > but it takes APPC/VM (IUCV on steriods) calls to make it happen. You can > talk to it in assembler using the BPX1 callable services. It could > provide you a "jump start" while you develop your own file system. > > And just in case you haven't discovered it already, there's no "pluggable" > file system interface in CMS. You will need to write your file system > from the bottom up. The only help CMS will provide to you is in the form > of HNDIO,HNDSVC, NUCEXT, and NUCXLOAD. > > 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.
Re: z/VM - Lightweight specific purpose file system
The callable services benchmarks we conducted with BFS ran between 8 and 10 times longer than the test set running with the CMS file system. Assuming a cluster of 125 Windows® 2K z/VM guests and using I/O counts generated by Win 2K on native Intel hardware the results of extrapolating the I/O overhead spooked us a bit. In effect, all our instruction pipeline optimization and translated instruction segment reuse optimization would be negated by the I/O overhead. We have a callable file system for z/OS that can handle an array of 128 pools each containing up to 255 volumes each. That system would be a bear to convert owing to the OS-specific interface code but it appears from your comments that converting may have to be seriously considered to achieve the desired results. Thank you. Gary Dennis Mantissa On 3/25/08 9:55 AM, "Alan Altmark" <[EMAIL PROTECTED]> wrote: > On Tuesday, 03/25/2008 at 04:26 EDT, "Gary M. Dennis" > <[EMAIL PROTECTED]> wrote: > >> Is anyone aware of a VM open source file system port with some of the >> characteristics listed below. Such a system might enable us to add the >> functionality needed to support these guests without starting at zero. > > It isn't Open Source, but CMS has a POSIX file system (Byte File System, > BFS) that is managed by the SFS server, allocating space only as used. I > don't know that I would classify it as "lightweight", though from the CMS > user's point of view, it is, since the I/O takes place in the SFS server, > but it takes APPC/VM (IUCV on steriods) calls to make it happen. You can > talk to it in assembler using the BPX1 callable services. It could > provide you a "jump start" while you develop your own file system. > > And just in case you haven't discovered it already, there's no "pluggable" > file system interface in CMS. You will need to write your file system > from the bottom up. The only help CMS will provide to you is in the form > of HNDIO,HNDSVC, NUCEXT, and NUCXLOAD. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: Question about virtual tape in a zVM environment
It might help if you included the error message. :) Gentry, Stephen wrote: Rob do you know what might be causing the errors below? -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Question about virtual tape in a zVM environment
Les, You are referring to the z/VM530 documentation, aren't you ? With or without target parameter in the MOUNT cmd, the targetcat is not changed under z/VM440 when asking for a scratch in P2P. Did the test with z/VM530, no change. This hardware situation is a major regression. We could not live if the problem was similar with MVS. We mount thousands VTS tapes a day. Alain Benveniste Le 25/03/08 20:03, « Les Geer (607-429-3580) » <[EMAIL PROTECTED]> a écrit : >> I suppose you would be aware of our peer-to-peer problem. >> >> When we got a 2nd 3494 in 2004, we decided to make them talk each other >> as P2P mode. This situation revealed a major problem related to the target >> category. In basic mode, asking to mount a scratch through vmtape, rmsmastr >> changed the category from scratch to volspecific. No more true in P2P (for >> us). >> We have upgraded our 3494, we have opened PMR, we have asked the IBM >> hardware their advice with no result. We even asked the dfsms doc to be >> changed related the p2p part to make it clearer. >> >> We had to developp something to change the categories according to what >> has been mounted during the day. I would really like to know if someone is >> in the same situation >> > > I was under the impression with more recent PtP microcode levels the > restriction on a mount that a target category could not be specified > was removed. > > > Best Regards, > Les Geer > IBM z/VM and Linux Development >
Re: Question about virtual tape in a zVM environment
>I suppose you would be aware of our peer-to-peer problem. > >When we got a 2nd 3494 in 2004, we decided to make them talk each other >as P2P mode. This situation revealed a major problem related to the target >category. In basic mode, asking to mount a scratch through vmtape, rmsmastr >changed the category from scratch to volspecific. No more true in P2P (for us). >We have upgraded our 3494, we have opened PMR, we have asked the IBM >hardware their advice with no result. We even asked the dfsms doc to be >changed related the p2p part to make it clearer. > >We had to developp something to change the categories according to what >has been mounted during the day. I would really like to know if someone is >in the same situation > I was under the impression with more recent PtP microcode levels the restriction on a mount that a target category could not be specified was removed. Best Regards, Les Geer IBM z/VM and Linux Development
Re: Question about virtual tape in a zVM environment
Rob do you know what might be causing the errors below?
Re: Question about virtual tape in a zVM environment
I suppose you would be aware of our peer-to-peer problem. When we got a 2nd 3494 in 2004, we decided to make them talk each other a s P2P mode. This situation revealed a major problem related to the target category. In basic mode, asking to mount a scratch through vmtape, rmsmastr changed the category from scratch to volspecific. No more true in P2P (for us). W e have upgraded our 3494, we have opened PMR, we have asked the IBM hardwar e their advice with no result. We even asked the dfsms doc to be changed related the p2p part to make it clearer. We had to developp something to change the categories according to what h as been mounted during the day. I would really like to know if someone is in the same situation Alain Benveniste
Re: Question about virtual tape in a zVM environment
>I'm sure the people planning for the new hardware have considered it. >I was just concerned that in their plan they had no native physical tape >for VM. Ann, You should check. Our storage people brought in a remote VTS to replace tapes that were being physically moved offsite. They were completely unaware that a production VM system didn't just send tapes offsite, it had a DR process that required those tapes to be sent to another data center for recovery. If they had bothered to ask the VM group during design, instead of when they were ready to implement, they would have known this. Don't assume that your hardware planning people know anything about your DR process. You should have no trouble with your other concern, passing maintenance tapes between systems. The VTS will happily mount one system's tapes on other system. You can control that with the foreign tape exit in VM:Tape. You also need to decide whether you will divide up the virtual tape drives among your systems statically, or use a drive sharing product such as MIA or VM:Tape's STAM feature. VTS's have lots of addresses, so you may have enough to give each system its own. For those who are wondering, our VTS is in, but the physical tapes continue to go offsite until we can move the production users to another system that has a remote vaulting DR process. Dennis O'Brien "No government deprives its citizens of rights without asserting that its actions are "reasonable" and "necessary" for high-sounding reasons such as "public safety." A right that can be regulated is no right at all, only a temporary privilege dependent upon the good will of the very government officials that such right is designed to constrain. -- Herbert W. Titus and William J. Olson, attorneys for GOA
Re: Adding Spool Volumes
Well, I tend to disagree about your statement that it will not be the same the next time. We have a tendency to keep the dump disks clean by processing dumps in a timely manner. Do not forget that the type of change I am considering is a planned outage/IPL for the purpose of rearranging things. It is not a random outage. In that event, There will be no dumps in spool when the system is shutdown. In fact, I could even SET DUMP OFF just before the shutdown and process any dumps (a very rare occurrence thanks to the incredible stability of the modern VM) that exist before he IPL. And where does it say that spool will spill over into dump space? It is quite the opposite. If dump fills, then dump space will be allocated from ordinary spool space. From CP Planning and Administration: "Dump tells CP to reserve the spool space on the specified volume exclusively for dumps." The word "exclusively" does not mean "exclusive except when it is not." In other words, it is not an inclusive "exclusively." Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier > Sent: Monday, March 24, 2008 3:43 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Adding Spool Volumes > > OK, the fact that one time there were no files on or partly > on the disk in slot 16 when you IPLed with out it does not > mean that there will not be the next time. As you have the > disks at 16 and 17 marked for dump storage nothing else > should be on them. If you are willing to lose all the dumps > on the spool you can probably get away with changing their > slots. If the regular spool space gets full and there is free > space on the dump reserved space then VM will use that space. > Also if you run out of dump reserved space and VM needs to > allocate more space for a dump it will use any spool space. > > It sounds like you try to keep lots of extra spool space on > your system. That is good if you can afford it. If you can > keep your dumps and ordinary spool files separate that is helpful. > > Schuh, Richard wrote: > > The existing spool, not including dump space, volumes would > remain in > > place on their current volumes. I do not think that, if > there were no > > existing dumps, that relocating those two disks to different slots > > would be a problem. The system did not even whimper when it came up > > minus the first of the dump disks a short while ago. It happily > > allocated both dump files on the remaining disk. The > operators did not > > notice any messages, much less have to respond to any, when > the system > > was IPLed minus the disk. I noticed that it was missing the > next day > > when I entered a Q ALLOC SPOOL command. It has since been > IPLed with > > the disk present, and there was nothing out of the ordinary > during the > > system start up. > > > > Regards, > > Richard Schuh > > -- > Stephen Frazier > Information Technology Unit > Oklahoma Department of Corrections > 3400 Martin Luther King > Oklahoma City, Ok, 73111-4298 > Tel.: (405) 425-2549 > Fax: (405) 425-2554 > Pager: (405) 690-1828 > email: stevef%doc.state.ok.us >
Re: z/VM - Lightweight specific purpose file system
Another possibility would be to exploit the infrastructure that the RSK provides.. DJ Alan Altmark wrote: On Tuesday, 03/25/2008 at 04:26 EDT, "Gary M. Dennis" <[EMAIL PROTECTED]> wrote: Is anyone aware of a VM open source file system port with some of the characteristics listed below. Such a system might enable us to add the functionality needed to support these guests without starting at zero. It isn't Open Source, but CMS has a POSIX file system (Byte File System, BFS) that is managed by the SFS server, allocating space only as used. I don't know that I would classify it as "lightweight", though from the CMS user's point of view, it is, since the I/O takes place in the SFS server, but it takes APPC/VM (IUCV on steriods) calls to make it happen. You can talk to it in assembler using the BPX1 callable services. It could provide you a "jump start" while you develop your own file system. And just in case you haven't discovered it already, there's no "pluggable" file system interface in CMS. You will need to write your file system from the bottom up. The only help CMS will provide to you is in the form of HNDIO,HNDSVC, NUCEXT, and NUCXLOAD. Alan Altmark z/VM Development IBM Endicott
Re: z/VM - Lightweight specific purpose file system
On Tuesday, 03/25/2008 at 04:26 EDT, "Gary M. Dennis" <[EMAIL PROTECTED]> wrote: > Is anyone aware of a VM open source file system port with some of the > characteristics listed below. Such a system might enable us to add the > functionality needed to support these guests without starting at zero. It isn't Open Source, but CMS has a POSIX file system (Byte File System, BFS) that is managed by the SFS server, allocating space only as used. I don't know that I would classify it as "lightweight", though from the CMS user's point of view, it is, since the I/O takes place in the SFS server, but it takes APPC/VM (IUCV on steriods) calls to make it happen. You can talk to it in assembler using the BPX1 callable services. It could provide you a "jump start" while you develop your own file system. And just in case you haven't discovered it already, there's no "pluggable" file system interface in CMS. You will need to write your file system from the bottom up. The only help CMS will provide to you is in the form of HNDIO,HNDSVC, NUCEXT, and NUCXLOAD. Alan Altmark z/VM Development IBM Endicott
Re: Question about virtual tape in a zVM environment
I'm sure the people planning for the new hardware have considered it. I was just concerned that in their plan they had no native physical tape for VM. Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, March 24, 2008 6:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Question about virtual tape in a zVM environment Have you considered how you will get data from the local VTS to the remote VTS? Smith, Ann (ISD, IT) wrote: > Thanks. I was hoping to VMTAPE mount the maintenance tapes to the > other VM systems as FOREIGN tapes. > And yes, there will be a VTS at the remote DR site. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
z/VM - Lightweight specific purpose file system
We need a lightweight file system to support z/VM i86 guest operating systems. A high speed garbage can of sorts. Is anyone aware of a VM open source file system port with some of the characteristics listed below. Such a system might enable us to add the functionality needed to support these guests without starting at zero. 1. Large file allocation capability; potentially multi-terabyte. A file in this instance represents a drive in the PC world (the boot disk for instance; C: drive). The system needs to support a few thousand very large files rather than millions of small files. 2. Allocation and access for variable interval sizes (A multiple of 512 up to 4096) 3. Sparse allocation. For example, an allocation of 250 GB would create the required structure for 250 GB but not actually allocate the storage intervals until required. 4. Support for very large shared storage pools Thanks Gary Dennis Mantissa
