I think you should beware of this exposure to RVA space when Linux CDL can
be accessed from MVS. Below is a converstation that I had with Scott
Lederer at Storage Tech on the Marist forum. If the VTOC showed that then
volume was 100% full, there would be no problem, but with it showing 100%
free, MVS could let the space assigned to the Linux CDL volume be freed.
�This message is not flagged. [ Flag Message - Mark as Unread ]
Date:
Wed, 19 Nov 2003 14:48:40 -0700
From:
"Ledbetter, Scott E"
<[EMAIL PROTECTED]>��(Embedded image
moved to file: pic04107.gif)Add to Address BookAdd
to Address Book
Subject:
Re: Linux CDL pack and RVA free space collection.
To:
[EMAIL PROTECTED]
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
Regards, Jim
Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs
t/l 543-4021, 408-463-4021, [EMAIL PROTECTED]
*** Grace Happens ***
----- Forwarded by Jim Sibley/San Jose/IBM on 11/20/2003 10:33 AM -----
Jim Sibley
To: [EMAIL PROTECTED]
11/19/2003 12:56 cc:
PM From: Jim Sibley/San Jose/[EMAIL
PROTECTED]
Subject: Linux CDL packs on RVA
I just noticed that when you vary a CDL pack with a VTOC online, it shows
no data sets allocated and 100% free.
How does RVA free space collection affect this. I supponse could mix MVS
and Linux CDL on the same DASD subsystem and have RVA free space collection
running. There would be a mismatch between the RVA tables and the VTOC.
What would happen?
Regards, Jim
Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs
t/l 543-4021, 408-463-4021, [EMAIL PROTECTED]
*** Grace Happens ***<<attachment: pic04107.gif>>
