Hi Jerry -- I started responding and decided I wasn't certain about some points so I passed your question along. I will get back to you on this when I get a response. What I do know is that the file structures look the same to any application software, but different to the OS.
I can also pass along that I talked to several people and it definitely seems to be true that there are even fewer hours spent in sys admin each month with the approach they have, as there is no file resizing and the like to be done. I asked many questions of both the vendor and their customers and did not hear about the apps hitting a wall, so I'll see if I can find out about that. Thanks. --dawn On 4/17/07, Jerry <[EMAIL PROTECTED]> wrote:
Dawn, One thing I don't think you mentioned is the file structure. Tell me if I'm wrong. The file structure is not like U2 at all. Unlike U2, and all other PICK environments, which have separate files for each table, Cache has one file that contains all of you tables. The one big problem with this file arrangement is that if you get a broken table your whole database is broken. You can either scrap the whole thing for a backup, which means all of your tables are old or you can attempt to fix the broken table which may or may not work. The file that contains all of your tables is not dynamically resized either. You have to keep a close eye on how much room you are taking up in this file (MUMPS.DAT). Because, when you run out of room for data you have to allocate more room to increase the size of your file, otherwise you hit a wall and your apps stop working. Because of this file structure you also have a problem with maximum file size due to operating system constraints. We have an OpenM system here which is the forerunner of Cache and that is the experience I have had with it. Once we ran out of space in the file and everything stopped working. We had to call and have the allocated space increased just to get in and cleanup logs and statistics tables that were growing. I have to constantly keep an eye on the file space to make sure we don't hit the limit and remove older statistics when it looks like we are running short. I have batch processes that prune the log files for anything over two weeks old. One time we hit, what I think, was a bad spot on the disk within the allocated space. This broke one of the tables. Luckily for us the table that got broken was one that wasn't used often and when Intersystems (or it may have been Ontario Systems, our VAR) dialed in to fix the file they were able to link to a backup we had to recover the data that got damaged after they fixed the broken table. The only other alternative would have been to bring back a backup which would mean we would have lost statistics for the time period between. Jerry
------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
