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
