|
View previous topic :: View next topic
|
| Author |
Message |
sainathm
New User
Joined: 09 Feb 2009
Posts: 7
Location: bangalore
|
|
|
|
We have many CICS regions like TDS1A001, TDS2A003, etc (All these are AOR) TDS1A003 (FOR).
I have a VSAM KSDS file which I want to convert it into CICS table.
1. will data be consistent in all the other regions, if the file or the path is updated from FOR?
2. will the data reflect immediately?
3. How can we restore the data if the data gets corrupted, because of some abends or any issues?
Please guide me.
Thanks |
|
| Back to top |
|
 |
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
In as much as a CMT can be updated, it can defeat the purpose of having a CMT as it should be kept as "Read Only" as the entire file is loaded into extended virtual storage at CICS startup. If you have a VSAM KSDS that requires updating, then use LSRPOOL's together with optimal Data and Index CISZ's.
This is just my opinion and not a mandate, but you should consult with your CICS Sysprog beforehand.
Also, your System Programmer will be pleased if you always use the KEYLENGTH keyword in a given FILE API.
If a file is defined as a REMOTE KSDS to the LOCAL region, the KEYLENGTH is not Function Shipped. If the Keylength is not supplied in the FCT (The Remote Region), then an INVREQ condition is raised.
However, when you explicitly used the KEYLENGTH in the API, the Sysprog doesn't have to go looking for the KEYLENGTH.
Although an undocumented method to define the Keylength value in the FCT is to use a value of 255 (the max VSAM keylength). The actual keylength will then be resolved.
Keep in mind that since CICS/TS 3.2 (with a PTF) and all subsequent version/releases, local VSAM access is Threadsafe, but not remote.
HTH.... |
|
| Back to top |
|
|
|
|
