W dniu 23.09.2021 o 22:21, Ward, Mike S pisze:
Hello, all. I don't know if any of you are doing disk replication to a DR site,
but we are, and we are trying to resolve a specific problem with CICS and VSAM
file.
CICS, in the case of LSR pools hold the data in the buffers until a buffer
shortage\wait type of condition occurs. When that happens CICS flushes the
buffers and updates the high used RBA's of the files. In the case of a DR test.
We use the data as is. We copy the current replicating data to other DASD so
that we can perform the test by bringing up the system and testing it. Well the
only way we can think of making sure we get all the VSAM data is by closing the
files at the production site which is not feasible. Is anyone else doing this
kind of mirroring, and are there things you are doing that fixe the VSAM
buffering problem? The only thing I can think of doing is adjusting the LSR
buffer pools so that waits occur every so many minutes, I'm staying away from
share option 4,4 on the VSAM files which are a real performance hit. Any takers
are welcome. Also as an aside the implication here is that in the case of a
real disaster there is data missing from the VSAM files, or am I wrong and full
of it? Any help, opinions, whatever are welcome.
General rule: PPRC and other methods is for "wise" applications. That
mean the application/system must survive sudden blackout with no harm to
data consistency. Otherwise remote copy is fuzzy.
Yes, both asynchronous and synchronous remote copy are for disaster
recovery. What does it mean? Fire, bomb, flood, power outage, whatever
else. In any case the applications on the remote site is more or less
like someone switched off power in the server during... of course, we
don't know when and we cannot demand prerequisite actions. It is sudden,
unexpected. The only difference between power outage and DR is the
application is restarted on another machine.
Conclusion: your system elements have to be "wise" or DR aware. This is
called transactional system. Not because it processes business
transactions, but it processes transactions as Logical Unit of Works.
Yes, you can loose not finished transaction, but this is all-or-nothing.
Transaction is committed or not. Whole one.
How does it relate to CICS and LSR? Similarly to DB2 and bufferpools.
Bufferpools are good, but committed transaction has to be written on
DASD, in the transaction log.
BTW: SHR(4,4) is good in z/VSE, not in z/OS.
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
