In a message dated 12/5/2007 3:16:56 P.M. SA Western Standard Time,  
[EMAIL PROTECTED] writes:

RS,

a) A CA split is still costly, but having extra data buffers  normally 
helps though (BUFND=); a CI split is almost nothing  now.

b) Empty CIs are not read by VSAM. Almost empty CIs cost the same  for 
random read as for full CIs. For sequential read almost empty CIs does  
cost extra. You can always reorg to pack the data better.

VSAM can  be made much more efficient by appropriate buffering, e.g. System 
Managed  Buffering is pretty good. VSAM splits are a fact of life, and it 
is an  Access Method that is 30+ years old. It could be worse, we could 
still be  stuck with ISAM!! (yes, I did work with  it).

Regards.

Mike

------------------------------------------------------------------------------
------------------------------------
Mike  Poil
Java z/OS Level 3 Service
IBM United Kingdom Limited, Hursley Park,  Winchester SO21 2JN
Internal: 246824  External: +44 (0)1962 816824  
Java debugging:  http://www.ibm.com/developerworks/java/jdk/diagnosis/
------------------------------------------------------------------------------
------------------------------------



"R.S."  <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion  List <IBM-MAIN@BAMA.UA.EDU>
05/12/2007 18:00
Please respond  to
IBM Mainframe Discussion List  <IBM-MAIN@BAMA.UA.EDU>


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re:  KSDS CA split, no CI split






Gene Hudders  wrote:
[...]
> I sure would hate to take too many CA splits in an  on-line environment
> especially if the CA split requires another extent  for either the 
data > and/or index component.

That's why I wrote  "not so bad". <g>
Indeed CA split is painful (CI also, but the pain  is CI/CA times less). 
However the pain is no longer because after the  split data is no longer 
in physical sequence. That (maybe) was painful in  times of SLEDs with 
long seek time.
What is painful, it's:
a) poor  performance *at the split time* - you insert single LR (logical 
record)  and VSAM moves cylinder of data.
b) free space distribution. After the  splits you could end up with 50% 
free space. Overhead because of reading  almost empty CIs.

Did I miss something ?

Regards
--  
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul.  Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m.  st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr  rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu  na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w 
caoci opacony)  wynosi 118.064.140 z. W zwizku z realizacj 
warunkowego podwyszenia  kapitau zakadowego, na podstawie uchwa XVI WZ 
z dnia 21.05.2003 r.,  kapita zakadowy BRE Banku SA moe ulec 
podwyszeniu do kwoty 118.760.528  z. Akcje w podwyszonym kapitale 
zakadowym bd w caoci  opacone.

----------------------------------------------------------------------
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







Unless  stated otherwise above:
IBM United Kingdom Limited - Registered in England  and Wales with number 
741598. 
Registered office: PO Box 41, North  Harbour, Portsmouth, Hampshire PO6  3AU






----------------------------------------------------------------------
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


Hi RS:
 
(SS=sequence set and IS=index set)
 
Extra buffers to improve a CA split requires the data set to be  defined in 
NSR under CICS which is not necessarily the best option.   Painful is longer 
response times for all transactions trying to access the file  during the CA 
split, NSR is not supported under Transaction Isolation, a NSR  file locks the 
TCB under which it runs until the split is complete (therefore,  you want to 
make sure you define the CO TCB (on a multi-processor) in these  cases where 
you 
use NSR), the formatting of the new CA, the movement of  individual CIs to new 
CA, the clearing of the moved CIs from the original CA,  the updating of the 
indices (SS and IS) which may result in a CI split when the  new high key is 
added to the IS index and there is insufficient space to  accommodate it, and 
if this is not enough of a penalty, you could wind up not  having any space to 
allocate the new CA which results in having to access and  update the catalog 
and VTOC (the price is similar to that of opening the  file) with the exposure 
that there is a volume switch which may result in a no  space condition 
exposure if insufficient space to allocate a primary or if SMS  controlled a 
secondary and finally the same applies to the index component when  adding the 
new 
index records (SS and possibly IS if split).  I am sure we  are not talking 
milliseconds even with the new disk technology.  
 
The net is you don't want CA splits on-line.  That is probably not  possible 
all the time but the idea is to minimize the occurance.
 
Regards,
Gene



**************************************Check out AOL's list of 2007's hottest 
products.
(http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001)

----------------------------------------------------------------------
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

Reply via email to