>>> On 7/29/2010 at 7:53 PM, in message <[email protected]>, "Joel C.
>>> Ewing"
<[email protected]> wrote:
> On 07/29/2010 06:26 PM, Thompson, Steve wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[email protected]] On
>> Behalf Of Frank Swarbrick
>> Sent: Thursday, July 29, 2010 5:53 PM
>> To: [email protected]
>> Subject: ALTER of open VSAM cluster
>>
>> It appears we can ALTER FREESPACE while a file is open to CICS (or
>> anywhere else, I assume). Is this an OK thing to do, so the next time
>> the file is reloaded it will use the new freespace values?
>> <SNIP>
>>
>> The ALTER modifies the definition info in the Catalog (as I recall). So
>> the effect is rather immediate. What this will do is allow you to LOAD
>> with x y for freespace, and then when running change to m n for
>> freespace.
>>
>> So, let us say that you LOAD a KSDS with FREESPACE(0 0) that has 50 CYLs
>> of data. Once the load is complete you ALTER it to FREESPACE(25 25). You
>> know that the majority of the adds to the file will start in the last 2
>> cylinders of data (as loaded) and go from there. So the CA/CI splits
>> will start at that point.
>>
>> Regards,
>> Steve Thompson
> ...
> Steve,
> If you are implying that changing FREESPACE of a loaded file will affect
> future adds at the high end of the key range, this is not true.
> Changing FREESPACE has no effect on a VSAM file already containing
> records. FREESPACE is only used when the file is in a reset or initial
> empty state with no records and an initial file load is done. I am also
> certain that if you could ALTER the VSAM catalog entry while the file is
> still OPEN for that initial load process, that the running program doing
> the load is at that point only using in-memory control blocks for the
> VSAM file with values that were derived at OPEN time, and only future
> OPENS would see any change.
>
> After that intial load, adding a record than doesn't fit in an existing
> CI results in a CI split with about half the CI records going to a new
> CI, and if there are no free CI's in that CA, a CA-split is first done
> to put about half of that CA's CI's in a new CA. The FREESPACE is
> totally ignored in that process. Even if all the future adds have
> ascending key values, the add logic is the same.
>
> Unless you define the VSAM file with REUSE and have an application that
> resets the file to empty and reloads all records at some later time
> without deleting and redefining the dataset, changing FREESPACE after
> initial load would have no effect.
>
> CI splits are relatively cheap, so using CI FREESPACE to minimize
> CI-splits after initial load has minimal benefit and in cases where a
> large percent of records must be read may actually reduce performance by
> requiring reading of more CIs to get the same data. CA-splits are
> relatively expensive, so there may be special cases where CA-FREESPACE
> can improve update response consistency after an initial load. But even
> with FREESPACE(0,0), if updates are clustered by key, performance will
> improve after the initial CI and CA splits from earlier updates
> introduce free space at the precise points in the file undergoing
> repeated changes.
Here are the details on the file in question. I just did a CLO ENA in CICS to
get update VSAM stats:
ATTRIBUTES
KEYLEN-----------------9 AVGLRECL-------------250
BUFSPACE-----------15872 CISIZE--------------7168
RKP--------------------0 MAXLRECL------------1900
EXCPEXIT----------(NULL) CI/CA----------------105
SHROPTNS(2,3) SPEED UNIQUE NOERASE INDEXED
NOWRITECHK NOIMBED NOREPLICAT
UNORDERED REUSE NONSPANNED
STATISTICS
REC-TOTAL---------791636 SPLITS-CI-----------8135
EXCPS------------1125532
REC-DELETED------------0 SPLITS-CA------------228
EXTENTS----------------1
REC-INSERTED-----------9 FREESPACE-%CI----------0 SYSTEM-TIMESTAMP:
REC-UPDATED-------659805 FREESPACE-%CA----------0
X'C65CE0AD26274284'
REC-RETRIEVED----2903925 FREESPC--------146055168
The file is REUSE and is reloaded at the beginning of every business day. (So
as of the above stats it's been open about 24 hours.) The end of each record
is a "transaction" table that contains up to 20 transactions per day. In other
words, as the customer has new transactions the length of the record is
extended to allow for this new record and then the record is rewritten.
Updates are random (not clustered).
When we were on VSE I think we had FREESPACE(50 50), but it somehow got
overlooked on our migration to z/OS. Our senior mainframe application
architect (not me!) is recommending, I believe he said (10 3). THough I may be
misremembering.
Anyway, since the CICS region is up 24/7, and the file is closed only once a
day (to be reloaded), we wanted to do the ALTER fREESPACE with the file open.
So you've answered that question, among others! :-) Thanks.
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
The information contained in this electronic communication and any document
attached hereto or transmitted herewith is confidential and intended for the
exclusive use of the individual or entity named above. If the reader of this
message is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
examination, use, dissemination, distribution or copying of this communication
or any part thereof is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this communication. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
