Dawn,
I will elaborate a little more. Unless they have changed their file
structures from the OpenM system this is what you will have. When you log
into their environment you will have all of the tables and program files and
they may look the same as working within the MV environment. But from the
operating system side looking at the file system you have one file that is
humongous with a few log files outside of it. This one file, in our case
it's MUMPS.DAT, is where all of those tables are and where you have logged
into. It makes it convenient to back up, just back up the one file. However,
the problem comes if you have a broken table (UV file). Let's say in UV you
have a customer file, a client file, a vendor file, a parts file, and a wip
file. If your customer file becomes corrupted in U2 a quick fix would be to
rename the file from the operating system side to CUSTOMER.BAD and load the
customer file from your last backup then enter any new customers since the
backup. You're back in business. With Cache if the customer table becomes
corrupted you can't just change the name of the table from the operating
system side because it is in this black box. There may be ways from inside
that box to load that one table but I am not at that level of guru on Cache.
If one of the program files was damaged or if I didn't have the knowledge to
reload the individual tables I would have to wait and rely on Intersystems
to fix the problem. In any case there is a possibility I would have to
rename the black box and reload the whole thing from backup. Then I would
have to re-enter all of the Clients, customers, vendors, parts, and wip's
since the last backup. Then close out any work-in-progress (wips) that had
been completed. Only then could I let the users back on the system.
Jerry
----- Original Message -----
From: "Dawn Wolthuis" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 17, 2007 11:15 AM
Subject: Spam:Re: Spam:Re: [U2] RE: [U2C] U2 / Cache
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
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
