Re: CICS VSAM LSR pools and IBM DASD PPRC type mirroring.
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 On Behalf Of Radoslaw Skorupka Sent: Friday, 8 October 2021 4:36 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS VSAM LSR pools and IBM DASD PPRC type mirroring.
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 On Behalf Of Radoslaw Skorupka Sent: Friday, 8 October 2021 4:36 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS VSAM LSR pools and IBM DASD PPRC type mirroring.
It is my understanding of CICS with VSAM LSR pools, that the buffer is "written" to DASD at task completion or at a EXEC CICS SYNCPOINT. as far as HURBA, in VSE we used TCLOSE, and it looks like on ZOS the VERIFY MACRO does almost the same thing: https://www.ibm.com/docs/en/zos/2.1.0?topic=examples-verify-synchronize-end-data VERIFY RPL=address,ACTION=REFRESH Note this warning about it use: After verifying a data set, positioning must be established with a POINT macro for sequential processing or with a GET macro with RPL OPTCD=DIR. so for KSDS file, you will need to save current positioning for the VSAM Placeholder PLH, and after the VERIFY MACRO, issues a POINT RPL=address. in CICS when you do a EXEC STARTBR, CICS acquires a VSWA control block for your task, the first x4c bytes of the VSWA is the VSAM RPL used by CICS to make VSAM requests. this field in the VSWA, hold the address of your tasks PlaceHolder: VSWAPLHP I think if you do it the way below, you don't need to worry about positioning, or or creating a VSAM RPL: EXEC CICS STARTBR L R1,VSWA-address VERIFY RPL=address,ACTION=REFRESH EXEC CICS ENDBR -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS VSAM LSR pools and IBM DASD PPRC type mirroring.
I was maintaining an IMS DB/DC and on occasion we would run a mid day update. The online application would not see the update until the next day. On Thu, Sep 23, 2021 at 3:21 PM Ward, Mike S wrote: > > 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. > > == > This email, and any files transmitted with it, is confidential and intended > solely for the use of the individual or entity to which it is addressed. If > you have received this email in error, please notify the system manager. This > message contains confidential information and is intended only for the > individual named. If you are not the named addressee, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this message by mistake and delete > this e-mail from your system. If you are not the intended recipient, you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CICS VSAM LSR pools and IBM DASD PPRC type mirroring.
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. == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
