Ron,
Yes, you are right.
However when talking about VSAM and CICS we think about some
transactional system. It should be... transactional, which also mean it
should survive sudden power (or data center) outage. Survive - mean all
comitted transactions are still present, all uncommitted transactions
are rolled back. Last but not least: data is *consistent*.
The same apply to system operational datasets like ICF, RACF db, JES2
spool, etc.
While I can live without my new password changed just before disaster I
expect and demand the RACF db is not corrupted. The same for JES spool.
I don't want cold start.
And still, remote copy like PPRC or XRC (but *not* PPRC-XD) is like
image of the system at given point in time (rolling until stopped or
disaster occured).
--
Radoslaw Skorupka
Lodz, Poland
W dniu 12.10.2021 o 08:52, Ron Hawkins pisze:
Radoslaw,
Isn't this also the case for VSAM when you lose your OS with the files open?
I may be out of date or have a lapse in memory, but I recall a file journaling
option that allowed CICS to roll forward/back updates to a file with LSR
buffered writes.
It could be just another senior moment.
Ron
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Radoslaw Skorupka
Sent: Friday, 8 October 2021 4:36 AM
To: [email protected]
Subject: Re: [IBM-MAIN] CICS VSAM LSR pools and IBM DASD PPRC type mirroring.
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
