Hi,

The updates that are made to one of the VSAM datasets using CICS application doesn't show the updates when I browse it in TSO(Still the file is allocated to CICS). But when I copy that dataset to an other VSAM file in TSO, the updates are seen. Does anyone knows why is it that way ?

Cheers,
Som.

May be a buffer issue. Although updates always get logged and the logs flushed to disk, they may not get written to the actual dataset until the buffer gets flushed, which may be some time later. There are a lot of factors (what kind of buffer pools are used, whether VSAM is in its own address space, what the shareoptions are for the file.

Thank you for your reply.
It is a ESDS dataset defined with (2,3) share options.
I am not sure how to find out what buffer pools are used and whether it is using its own address space or not. I have just pasted here the allocation attributes for this dataset.

Average LRECL ===> 600 Owner ===> (NULL)
Maximum LRECL ===> 1795 Creation Date ===> 2004.134
Total records ===> 287 Expiration ===> 1999.999
Retrieved ==> 479 Update ===> 2005.118 02.58.39
NSPND NERAS RUS Storage class ===> S1
UNORD SPEED SHR(2,3) Management ===> USR1
Data class ===> (NULL)
Data space usage -TRACKS- KILOBYTES - CA's - - CI's - percent
Allocated space 750 37500 50 3750
High used space 15 150 1 15 0.4
CI Size ===> 10240 Allocation ===> CYLINDER
CIs per CA ===> 75 Primary ===> 50
Block size ===> 10240 Secondary ===> 20
Block/Track ===> 5 Volume ===> CDAP19
Tracks/CA ===> 15 Volume count ===> 1
Buffer space ===> 20480 Extents ===> 1

ESDSs are basically sequential files done over into VSAM. Although you can update in place using explicit RBAs, it is more usual to just append records to the end. What constitutes 'the end' depends on the SHAREOPTIONs. Your (2,3) basically means that you can have one writer and multiple readers. Unless you change this to (4,3) the readers will not see the new records until the file is closed by the writer, which updates the high used RBA in the catalog. But DON'T change it to (4,3), as the way this is implemented disables all buffering and forces a real I/O every time the dataset is read or written. This is a recipe for really crap performance, and not what we like to see in an online system.