Our application runs on Windows server using AcuGT version 9.1.2.1, with Windows clients.  We are using Vision files, and now have some customers requesting the ability to do real-time hot backups (real-time server replication of data).

Since Vision files do not support VSS, we are considering two options:

1) using SQL database instead of Vision files - this is a fair amount of work, and requires new knowledge for our developers and support team, as we do not use SQL today for any applications.  Our testing has also shown a performance hit with SQL, which makes sense but could become an issue in large customer sites, which of course are the ones most interested in a hot-backup solution.  We do file updates automatically as part of our software updates today, adding SQL tables makes this more complex, especially when adding VSS replication.

2) creating our own "replication", by creating transaction files for each record update in critical files, which would be processed by a Cobol program to update copies of the files on a second server.  This would allow us to handle file changes automatically during updates, and would require much less change on the core system.

Has anyone faced a similar challenge in the past and have any comments to share?

Thanks

Tony

Hi Tony

Since nobody told anything, I share my considerations on the topic.

First of all: if you stay in Vision File System, probably you will never have a real replication of data. You can try to replicate it, but if you miss anything, you could be in problem if anything goes wrong with your customer and you have to rollback data.

I know that Microfocus has an Acu4GL product that allow you to write on SQL server instead of Vision without change any line of your code. In this way, you can move your database from Vision to SQL without changing your code.

There are few drowbacks on this:

- Acu4GL is slower than Vision, so you have to check if the new performance are acceptable in your environment

- Acu4GL is mostly too expencieve. I can't tell how much it will cost to you, but in my experience it was too expencieve to use it in production

- I had few problems with some kind of data that can't be translate on Sql Server (date that contains low-value or high-value, comp numbers, ...)

The solution we took is to centralize the Vision file access to a single cobol program. That program updates the Vision file and writes all changes in a delta file.

Finally, there is another program (.NET) that reads the delta file and writes all changes in a SQL server.

Our need is to let user read data from their own tools (es: Excel), and this solution works well.

I'm not sure it can be used as replication data, since it doesn't manage low/high values, invalid date, ..