Re: Linux CDL pack and RVA free space collection.
That's exactly what MVS does. But the problem being referenced was the need to have sufficient free space on the volume to allow those "secondary extents" to be allocated. If you have datasets that get extended frequently in this way, you need to keep your volumes at a fairly low utilization so the abends are avoided. Or, you need to run disk defragmentation programs during the off shifts to consolidate multiple extents, which can cause problems with batch jobs needing to access the data, etc. Mark Post -Original Message- From: Don Mulvey [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: Re: Linux CDL pack and RVA free space collection. -snip- >Typically, MVS volumes may be run at 50% full because >of the need to expand without abending a process. Dont know anything about mvs. But a format_1 dscb has room for describing multiple extents. Can't mvs automatically grow the dataset till these extent descriptors are used up before abending the process?
Re: Linux CDL pack and RVA free space collection.
Hi Jim, >It uses a Log Structured Array to map virtual tracks >to the back end raid array hardware. This is analogous >to a paging in MVS. As in MVS, a track is not >allocated on the hardware until it is written to. This is kinda how evms builds a sparse LV. The logical volume is divided up into chunks (like a snapshot). If a write is made to a chunk that has no backing storage an exception causes the chunk to be mapped before the i/o continues. This lets you create volumes much larger than the actual physical storage. The maps are saved for persistance. Originally conceived of as a means of testing very large volumes on very modest disks. On-demand storage :) >The technology is based on several assumptions true >for an MVS environment 1) The VTOC extent maps may say >the data set has been allocated with so much space, >but in reality, only a small park of it is used, and >2) free space really takes up space on a volume, and >3) there are a lot of repeated characters (mostly >blanks) on MVS volumes. >Typically, MVS volumes may be run at 50% full because >of the need to expand without abending a process. Dont know anything about mvs. But a format_1 dscb has room for describing multiple extents. Can't mvs automatically grow the dataset till these extent descriptors are used up before abending the process? >In addition, they added space compression, to get the >repeated characters compressed out. >The net effect is that the REAL hardware space >occupied for a volume can be zero (0) to a real full >volume. In MVS, the volumes get up to 66% compression >of the data and the packs are only 50% full. Neat. >Storage Tech took this one step further. Since they >are do not have to have all the space on a volume >reserved on the hardware, they only back the virtual >space with a fracture of the real hardware space. For >example, on one of my RVA's I have 512 3390-3 volumes >defined for a virtual capacity of 1.4 Terabytes. >However, the real dasd on the RVA is only 219 GB! So >the assumption is that there will be 6.3 >"overalloction" of the pack due to compressible data >and unused free space. Gotcha. >Actually, quite brilliant when you think about it. >Remember, this is late 1980's technology when disk >drives were still expensive and RAID technology was >new. I don't anyone uses this approach now because the >disk drives are so cheap. Vendors are using RAID10 now >- mirrored raid5, so there is actually twice has much >disc hardware that is needed for recovery purposes. Yep ... and linear concatenations of raid10 or feeding raid10 devices into an lvm volume ... to help when it comes time to resize the volume. >If you look at an MVS VTOC, the extent map may show >that the pack is full and for conventional dasd and >most vendors implementations, the space is reserved, >though it may not be actually used. Sure ... that is exactly how I viewed a cdl partition ... %100 allocated/reserved ... but I think the amount actually used would have to be determined by asking the file system. >This then brings up question of garbage collection. >There is an interface between MVS allocation and the >RVA called IXFP in the IBM RVA that communicates >allocations and free up of space between MVS and the >RVA. There is also dynamic dasd space reclamation >(DDSR) that runs periodically, interrogates the VTOC, >and frees any free tracks based on the VTOC. This is >the exposure that we are talking about. Depending upon >what IXFP interrogates in the VTOC, there is a data >loss exposure. I have seen no reports that anyone has >tested this, just recommendations that you keep your >Linux DASD seperate from your other OS. Sounds like DDSR finds dataset extents and then determines which tracks in the extent are used or not. In the evms case, the sparse volume knows which chunks have had write operations and it knows for certain which chunks are free or not. I guess IXFP must be doing something similiar by talking to mvs allocation/free rtns. -Don
Re: Linux CDL pack and RVA free space collection.
Don wrote: > First off ... could somebody tell me what an RVA is Well, if you have an RVA or if you are curious, read on. If you don't have an RVA or don't care, never mind ;-) It is the Storage Tech Iceberg Technology developed in the late 1980' specially for MVS environments. After the RAMAC III, IBM had a remarketing agreement with Storage Tech to rebrand the device as an IBM 9393 Ramac Virtual Array and was IBM's main dasd offering for mainframes for several years. When shark was announced, the agreement was discontinued. Its a common piece of hardware in may zSeries shops. Today, it is cheap to acquire, so many people still use it. It uses a Log Structured Array to map virtual tracks to the back end raid array hardware. This is analogous to a paging in MVS. As in MVS, a track is not allocated on the hardware until it is written to. The technology is based on several assumptions true for an MVS environment 1) The VTOC extent maps may say the data set has been allocated with so much space, but in reality, only a small park of it is used, and 2) free space really takes up space on a volume, and 3) there are a lot of repeated characters (mostly blanks) on MVS volumes. Typically, MVS volumes may be run at 50% full because of the need to expand without abending a process. In addition, they added space compression, to get the repeated characters compressed out. The net effect is that the REAL hardware space occupied for a volume can be zero (0) to a real full volume. In MVS, the volumes get up to 66% compression of the data and the packs are only 50% full. Storage Tech took this one step further. Since they are do not have to have all the space on a volume reserved on the hardware, they only back the virtual space with a fracture of the real hardware space. For example, on one of my RVA's I have 512 3390-3 volumes defined for a virtual capacity of 1.4 Terabytes. However, the real dasd on the RVA is only 219 GB! So the assumption is that there will be 6.3 "overalloction" of the pack due to compressible data and unused free space. Actually, quite brilliant when you think about it. Remember, this is late 1980's technology when disk drives were still expensive and RAID technology was new. I don't anyone uses this approach now because the disk drives are so cheap. Vendors are using RAID10 now - mirrored raid5, so there is actually twice has much disc hardware that is needed for recovery purposes. If you look at an MVS VTOC, the extent map may show that the pack is full and for conventional dasd and most vendors implementations, the space is reserved, though it may not be actually used. This then brings up question of garbage collection. There is an interface between MVS allocation and the RVA called IXFP in the IBM RVA that communicates allocations and free up of space between MVS and the RVA. There is also dynamic dasd space reclamation (DDSR) that runs periodically, interrogates the VTOC, and frees any free tracks based on the VTOC. This is the exposure that we are talking about. Depending upon what IXFP interrogates in the VTOC, there is a data loss exposure. I have seen no reports that anyone has tested this, just recommendations that you keep your Linux DASD seperate from your other OS. >Somebody has to ask ... are you sure you typed in cdl rather than ldl? Simple to check - if you vary an LDL volume on to MVS, you get an "I/O error" because you do not have a VTOC and it does not come online. If you vary a CDL volume on to MVS, the volume will vary online. Since I could read the VTOC under MVS, it was obviously a CDL volume. To add insult to injury, if you try to allocate an MVS data set to the CDL volume inadvertently, some levels of MVS abend the task and mess up the VTOC so the pack cannot be varied back online. >Doesn't make any sense. If you reformat a volume your >gunna reblock >and >refresh: ipl records, vol label record and the vtoc >itself. A format >doesnt create any type 1 dscbs. If there is a bug >that resulted in an >ldl >volume ... even if you specified cdl ... then this >would make sense. I >am >assuming that RVA (whatever it is) looks for any/all >type 5 dscbs if >the >vtoc track is available. If it thinks the vtoc track >is missing (ldl >volume) then my guess is that it would declare no >datasets and %100 >free. Yes, there is a bug! Since when do bugs make sense? I'm trying to track its extent and what releases of MVS and Linux that might have problems. However, I thought it fair to warn the other RVA users of the potential exposure. = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Linux CDL pack and RVA free space collection.
RVA=Ramac Virtual Array. RVA is (was) a disk subsystem engineered by StorageTek and sold by IBM roughly from 1996->2000. It uses a unique log structured file layout to present 1024 3380 or 3390 images to the hosts, while potentially not actually having enough backend disk storage to hold 1024 3390-3's worth of data. Thus the 'Virtual' name. I say 'potentially', because one feature of the RVA is that data is hardware compressed on the channel interfaces as the data is transferred into the box. If the data is compressible enough, you could easily store 1024 volumes worth of data. At a very high level, you can think of it as being similar to virtual memory in an operating system. On a 31-bit OS, you can have hundreds of address spaces that all think they have access to 2GB of memory, while in reality the hardware itself may not even have 2GB of physical memory to work with. One of the challenges of this type of architecture is communicating to the hardware when a track on a volume is not 'really' being used by the OS or an application. Because the backend disk pool is shared among all of the 1024 volumes at a track granularity, a track of residual data that once belonged to a now deleted file is just taking up space on the backend disk pool. Thus, there needs to be some way for the OS to notify the hardware that a track is really freespace and not valid data. To cut to the chase, the issue is this: there is a process that RVA users can run that will read the MVS VTOC for every online volume and for every single track not covered by a DSCB representing valid data, a command will be issued to the subsystem to return those tracks to the pool of freespace on the backend disk. Those tracks are GONE, and the data ain't coming back. If a volume is a CDL volume, or a VM volume with an OS VTOC, and there is not a dummy dataset entry in the VTOC that covers the entire area of the volume that really contains Linux or VM data, there is a great risk. If the process called Interval DDSR (which runs in an address space on MVS controlled by the user) runs against that volume, you could lose your Linux of VM data. The structure of the control statements for Interval DDSR is such that it is very easy to code them to run against every online volume by default. This is why I recommended that any VM or Linux volumes that might ever be brought online to MVS be specifically excluded from Interval DDSR processing, because no good can come from it. There is a similar process that can run against a minidisk on VM, but that is a command-only process. If a user issues the command against a Linux minidisk, they must specifically direct the process to a minidisk. Everything I have said is applicable to the IBM RVA, the STK "Iceberg" 9200, SVA(Shared Virtual Array) 9393, SVA 9500, SVA V960, SVA V2X, SVA V2X2 and SVA V2XF. It is my understanding that the CDL volume format is actually a product of the IBM provided DASD drivers. The individual partitions and their corresponding cylinder ranges are represented by Format 1 DSCB's in the VTOC. There should be no danger to your Linux partitions under normal circumstances, but I think it would be a great idea for the partitioning code that builds the CDL VTOC to cover the areas not taken by partitions with a dummy dataset. With a CDL volume online to MVS, you do run the risk that the datasets could be accidentally deleted from the CDL volume from the MVS side. This would not delete the partitions themselves, but the next time Interval DDSR ran the data would disappear because they would be seen as freespace. Scott Ledbetter StorageTek -Original Message- From: Don Mulvey [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 7:12 AM To: [EMAIL PROTECTED] Subject: Re: Linux CDL pack and RVA free space collection. >Well, I'm not sure if I'm coming or going on this! You and me both :) >I just formatted a volume CDL on another RVA with >SLES8 SP2 and it shows 0% USED and 50,083 tracks FREE! First off ... could somebody tell me what an RVA is? If you just formatted a cdl disk then it should only have 2 dscbs in the vtoc; a type 4 vtoc descriptor and a type 5 freespace descriptor. So the info seems fine. >The other volume I formatted was with SLES8 SP3 and it >showed 100% USED and 0 tracks FREE! Somebody has to ask ... are you sure you typed in cdl rather than ldl? Can you confirm that it is indeed cdl and there isn't a bug that produced an ldl volume? >So the MVS guy wasn't wrong after all! He was looking >at a volume I had formatted CDL with SLES8 SP2. >So this seems to be release dependent and there IS AN >EXPOSURE if you have a lower release that SLES8 SP3. I >don't know what would happen with RedHat. I'll try >that after I get an RHEL3 system running. Doesn't make any sense. If you reformat a volume your gunna rebloc
Re: Linux CDL pack and RVA free space collection.
>Well, I'm not sure if I'm coming or going on this! You and me both :) >I just formatted a volume CDL on another RVA with >SLES8 SP2 and it shows 0% USED and 50,083 tracks FREE! First off ... could somebody tell me what an RVA is? If you just formatted a cdl disk then it should only have 2 dscbs in the vtoc; a type 4 vtoc descriptor and a type 5 freespace descriptor. So the info seems fine. >The other volume I formatted was with SLES8 SP3 and it >showed 100% USED and 0 tracks FREE! Somebody has to ask ... are you sure you typed in cdl rather than ldl? Can you confirm that it is indeed cdl and there isn't a bug that produced an ldl volume? >So the MVS guy wasn't wrong after all! He was looking >at a volume I had formatted CDL with SLES8 SP2. >So this seems to be release dependent and there IS AN >EXPOSURE if you have a lower release that SLES8 SP3. I >don't know what would happen with RedHat. I'll try >that after I get an RHEL3 system running. Doesn't make any sense. If you reformat a volume your gunna reblock and refresh: ipl records, vol label record and the vtoc itself. A format doesnt create any type 1 dscbs. If there is a bug that resulted in an ldl volume ... even if you specified cdl ... then this would make sense. I am assuming that RVA (whatever it is) looks for any/all type 5 dscbs if the vtoc track is available. If it thinks the vtoc track is missing (ldl volume) then my guess is that it would declare no datasets and %100 free. >Bottom line still seems to be - don't run DDSR on your >CDL formatted volumes! -Don
Re: Linux CDL pack and RVA free space collection.
On Thu, 2003-11-20 at 23:39, Jim Sibley wrote: > So this seems to be release dependent and there IS AN > EXPOSURE if you have a lower release that SLES8 SP3. I > don't know what would happen with RedHat. I'll try > that after I get an RHEL3 system running. And if this is the case, the difference would be the release that you used to format the disk... I would not expect the Linux dasd driver of an upgraded SLES 8 SP3 to go out and fix the layout of your existing disks. > Bottom line still seems to be - don't run DDSR on your > CDL formatted volumes! And this is assuming the DDSR tooling looks at the same numbers that you look at and stays out when the number says 100%. On VM we don't have the equivalent of a VTOC and I recall that the RVA tool would use the CP directory to find any tracks that were not mapped by a mini disk definition. Very interesting if you have some areas not covered by dummy mini disk extents. A bit on topic: While there is no Linux version of such a tool available, I think Dougie measured that a similar effect can be achieved by filling the disk with some temporary dummy file that can be compressed very good (nulls or blanks). The same should work for SFS pools where a lot of file activity takes place. Rob
Re: Linux CDL pack and RVA free space collection.
Well, I'm not sure if I'm coming or going on this! I just formatted a volume CDL on another RVA with SLES8 SP2 and it shows 0% USED and 50,083 tracks FREE! The other volume I formatted was with SLES8 SP3 and it showed 100% USED and 0 tracks FREE! So the MVS guy wasn't wrong after all! He was looking at a volume I had formatted CDL with SLES8 SP2. So this seems to be release dependent and there IS AN EXPOSURE if you have a lower release that SLES8 SP3. I don't know what would happen with RedHat. I'll try that after I get an RHEL3 system running. Bottom line still seems to be - don't run DDSR on your CDL formatted volumes! = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Linux CDL pack and RVA free space collection.
I thought I had checked that. At any rate, it is a good idea to exclude these volumes, since there would be no reason to run DDSR from the MVS side on a CDL volume. Scott L. -Original Message- From: Jim Sibley [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 12:14 PM To: [EMAIL PROTECTED] Subject: Re: Linux CDL pack and RVA free space collection. Sorry, I think I got some misleading information from my MVS guy. The CDL VTOC does show 100% FULL. I logged onto MVS and looked at the VTOC. It showed: tracks 30,085 %used 100 trks/cyls 15 VTOC 1 track 25% used Free DSCBs 9 Freespace size 0 Largest 0 Free 0 So I would assume that IXFP would behave correctly. However, operationally, I don't think I'd like to expose my RVA CDL volumes to DDSR so I am having the MVS guy exclude the Linux volumes when online to MVS. = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Linux CDL pack and RVA free space collection.
> Sorry, I think I got some misleading information from > my MVS guy. The CDL VTOC does show 100% FULL. Oh! Okay ... that is more of what one would expect. > So I would assume that IXFP would behave correctly. > However, operationally, I don't think I'd like to > expose my RVA CDL volumes to DDSR so I am having the > MVS guy exclude the Linux volumes when online to MVS. Would be nice if someone would report back what does happen. >From what you're now reporting, it looks like the CDL code is good from the MVS perspective. We also need to confirm that RVA is doing the right thing about interpreting the allocation. -- R;
Re: Linux CDL pack and RVA free space collection.
Sorry, I think I got some misleading information from my MVS guy. The CDL VTOC does show 100% FULL. I logged onto MVS and looked at the VTOC. It showed: tracks 30,085 %used 100 trks/cyls 15 VTOC 1 track 25% used Free DSCBs 9 Freespace size 0 Largest 0 Free 0 So I would assume that IXFP would behave correctly. However, operationally, I don't think I'd like to expose my RVA CDL volumes to DDSR so I am having the MVS guy exclude the Linux volumes when online to MVS. = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Linux CDL pack and RVA free space collection.
Thanks, Scott. That is as I suspected. With MVS periodic DDSR, the VTOC is interrogated and space on the RVA is freed based on the VTOC map. So, its absolutely essential that you do not run DDSR on these packs (VM or Linux CDL). Would that the developers had used a VTOC that showed the pack 100% full and we would have no problem. = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Linux CDL pack and RVA free space collection.
Jim, You are correct in being concerned about this. On an RVA or STK Iceberg or STK SVA (all are the same architecture), the hardware has no knowledge of the logical data structures such as VTOCs, filesystems, directories, etc. It manages everything at a track level. When a dataset is 'deleted' from an MVS volume, normally the only actual change at the hardware level is an update to the track(s) containing the corresponding VTOC DSCBs, and possibly a track in the VVDS and perhaps the user catalog if it resides on the same volume. In order to notify the RVA of the deleted status of the tracks associated with a dataset, the MVS system normally will have an "under the covers" software subsystem running called IXFP (SVAA for STK boxes). The IXFP/SVAA software installs itself at IPL time, and if activated, will send notification to the RVA that all the tracks associated with a deleted dataset are eligible to be reclaimed. The RVA then marks these tracks as deleted and reclaimable inside the RVA. This entire process is called Dynamic DDSR. Here is where things get dangerous. There is also an optional process that a user can run via an address space that can be started to do some management and reporting for the RVA. This process is called Interval DDSR. What happens is that on a periodic basis controlled by a parmlib member, a task in the address space will wake up and 'sniff' every online DASD device known as an RVA or SVA device. The process will look at the VTOC on the volume, and will mark as free EVERY TRACK NOT ACCOUNTED FOR IN THE MVS VTOC. So, if your CDL volume looks like it is an empty volume, Interval DDSR will free every track on the volume not occupied by the VTOC, VVDS, VTOC index. >From the Linux side, this would mean your data is history. There is a 'device exclusion list' that can be specified that will prevent IXFP/SVAA from touching a device. Unfortunately, this will also prevent the device from being eligible for SnapShot processing. The better alternative is to update the parmlib members that control the DDSR processes to exclude the volumes from DDSR processing, without making them ineligible for SnapShot. The Parmlib member is SIBDSRxx, the parameters/commands that control this are called RELEASE INTERVALDATA and RELEASE DYNAMICDATA. By the way, if you have VM volumes formatted with an OS VTOC that shows itself as empty, you have the same exposure. Keep them offline to MVS, or exclude them from DDSR processing. The IBM IXFP/RVA manuals are here: http://www-1.ibm.com/servers/eserver/zseries/zos/bkserv/zswpdf/ixfp21.html We now return you to your regularly scheduled programming. Scott Ledbetter StorageTek -Original Message- From: Jim Sibley [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Linux CDL pack and RVA free space collection. I just noticed that when you vary a CDL pack with a VTOC online to MVS, it shows a 1 track VTOC, no data sets allocated and 100% free. (It seems to me it should show 100% allocated with a dummy data set). How does RVA free space collection affect this? If you mixed MVS and Linux CDL on the same RVA and the Linux volumes happen to be online, how would the RVA free space software handle the situation? There would be a mismatch between the RVA LSA tables and what appears to be the MVS VTOC. What would happen during space collection? Would the space be returned to the RVA freepool? Normally this is not a problem for us because we keep the Linux on separate DASD subsystems from MVS. However, I do have an operational requirement when I need to put some Linux with the MVS volumes. Does this create any other problems for Linux on the RVA? = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Linux CDL pack and RVA free space collection.
Rich wrote: "Doesn't the RVA do on the fly compression. A freshly formatted disk should compress down to almost nothing." Its not a compression issue - that is automatic. However, when a data set is deleted under MVS, a message is sent to the RVA via the software IXFP which gives the free space back. Then IXFP, every once in a while, does a free space collection. The question is, "Does the IXFP/MVS interface during space collection recognize that the VTOC shows an empty pack, therefore releasing the allocated backend space?" = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Linux CDL pack and RVA free space collection.
Doesn't the RVA do on the fly compression. A freshly formatted disk should compress down to almost nothing. On Wed, 2003-11-19 at 15:04, Jim Sibley wrote: > I just noticed that when you vary a CDL pack with a > VTOC online to MVS, it shows a 1 track VTOC, no data > sets allocated and 100% free. (It seems to me it > should show 100% allocated with a dummy data set). > > How does RVA free space collection affect this? > > If you mixed MVS and Linux CDL on the same RVA and the > Linux volumes happen to be online, how would the RVA > free space software handle the situation? There would > be a mismatch between the RVA LSA tables and what > appears to be the MVS VTOC. What would happen during > space collection? Would the space be returned to the > RVA freepool? > > Normally this is not a problem for us because we keep > the Linux on separate DASD subsystems from MVS. > However, I do have an operational requirement when I > need to put some Linux with the MVS volumes. Does this > create any other problems for Linux on the RVA? > > > = > Jim Sibley > Implementor of Linux on zSeries in the beautiful Silicon Valley > > "Computer are useless.They can only give answers." Pablo Picasso > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree -- Rich Smrcina Sr. Systems Engineer Sytek Services - A Division of DSG Milwaukee, WI rsmrcina at wi.rr.com rsmrcina at dsgroup.com Catch the WAVV! Stay for requirements and the free-for-all. Update your zSeries skills in 4 days for a very reasonable price. WAVV 2004 in Chattanooga, TN April 30-May 4, 2004 For details see http://www.wavv.org
Linux CDL pack and RVA free space collection.
I just noticed that when you vary a CDL pack with a VTOC online to MVS, it shows a 1 track VTOC, no data sets allocated and 100% free. (It seems to me it should show 100% allocated with a dummy data set). How does RVA free space collection affect this? If you mixed MVS and Linux CDL on the same RVA and the Linux volumes happen to be online, how would the RVA free space software handle the situation? There would be a mismatch between the RVA LSA tables and what appears to be the MVS VTOC. What would happen during space collection? Would the space be returned to the RVA freepool? Normally this is not a problem for us because we keep the Linux on separate DASD subsystems from MVS. However, I do have an operational requirement when I need to put some Linux with the MVS volumes. Does this create any other problems for Linux on the RVA? = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
