Thanks Massimo, but we are committed to moving forward with IIDR. On Thu, Apr 6, 2017 at 10:14 AM, Massimo Biancucci <[email protected]> wrote:
> Cameron, > > if of interest, there're other products that do the same (same product > replicating VSAM, DB2, DLI and so on). > > Regards. > Massimo > > 2017-04-06 15:11 GMT+02:00 Cameron Conacher <[email protected]>: > > > Hello everyone, > > We are looking to leverage Classic Data Capture for VSAM (IIDR for VSAM) > to > > replicate our VSAM file changes to a distributed tier for caching > servicing > > data. > > > > My first question is if anyone has gone down this path already, and if so > > were there any surprises along the way? > > > > My understanding so far, from the materials I have read, is that we will > > turn on CF Logstream logging for the specified files. Then any real time > > updates made to the files in our CICS environments will trigger capture > > agents running in the CDC Address Space. > > We also need to install/configure CICS VR to capture the same Logstream > > events for any Batch JOB updates to the files. > > > > Is it possible for the VSAM files to become out of sync with the > replicated > > data? > > I would expect that from a CICS perspective, once the update is committed > > to the VSAM file, the log images are marked as committed, and these would > > then pass through replication. > > I can't see how CICS work could push things out of sync, but I want to > ask. > > > > When looking at things from the Batch side of the equation, well a Batch > > JOB can ABEND. > > Then, normally, we would restore the VSAM file environment (correct > > whatever the issue was) and re-run the Batch JOB. > > I read something about DWWBACK, the CICS VR Batch Backout Program. > > Should I be introducing DWWBACK wherever/whenever we restore our VSAM > files > > and re-run a Batch JOB? > > > > Last question for now, and I really do understand this is much like > asking > > how long is a piece of string. > > When we turn on log replication for the VSAM files, should we be > expecting > > to see a small bump in CPU and wall clock times? I would expect that > since > > we do more stuff, it should take more time and resources. Any real world > > experience here? Say five percent increase in MIPS and ten percent more > > wall clock elapsed times? Any examples? > > > > I have been chatting with our IBM folks, and I have been reading > materials. > > There is just so much information out there, it is overwhelming. > > > > Thanks in advance for any information > > > > .......Cameron > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
