ADSM-L

[no subject]

2003-05-05 17:00:13
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 5 May 2003 14:59:35 -0600
        As with the others, we are using a 3rd party document management system 
to capture and catalog the metadata and the documents themselves. In our case 
we ~used~ to use Saros and have since moved to Documentum. 

        In our case, we started out using HSM for all the individual documents, 
but no longer use it. We found that when we started to have filesystems with 
millions of HSM stubs in them, the process of reconciling them was very 
burdensome. When it worked, it worked like a charm, but when it broke, it meant 
days of work to reconcile the state of the objects, during which time the 
application had difficulties retrieving documents and HSM could not push any 
more documents using HSM.

        Working with IBM support at that time (this was back about 5 years ago 
at TSM version 2), they indicated that HSM was really not meant to handle that 
volume of files and suggested we abandon using it. We did. About that time disk 
prices started dropping and we found that it wasn't that much more expensive to 
buy new disks than to buy HSM support for TSM. Disks were less headache.

        To this day, we still use physical media (tapes, disks, CDs, etc) even 
though HSM may now be able to handle our volume of data, because "once bitten, 
twice shy", and disk space is cheaper than ever.

        Shifting focus to the other issue you brought up, the short lifespan of 
magnetic media. At our site, that issue has been brought up frequently as we 
have some retentions that are "eternal" and obviously, tape is not. In our 
case, about every 3 - 4 years, we seem to upgrade the a piece of the TSM 
infrastructure, and at that time have the opportunity to "refresh" the data 
onto new tapes. At our site, where we use 3590 tape drives, this has been the 
progression:

Initial installation:   3590B drives and low density media.
First refresh:  Upgrade the drives to 3590E, which let us condense the data 
onto about 1/2 as many tapes.
Second Refresh: Release of extended length (K) carts once again let us condense 
the data onto about 1/2 as many tapes.

        We suspect that within the lifespan of the latest set of tapes, we will 
have the opportunity to once again refresh the data.

        
Ben


-----Original Message-----
From: Cowperthwaite, Eric [mailto:eric.cowperthwaite AT EDS DOT COM]
Sent: Monday, May 05, 2003 2:21 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: 


Today we use microfilm. We are going to be converting that to IBM's Content
Manager OnDemand product. All documents will be scanned and loaded into
Content Manager. It will be kept in online disk systems for 18 months and
then archived to tape. Content Manager uses Tivoli Space Manager to perform
the HSM functionality. We have had an image management system for years that
managed online images and microfilm images. It has gone through many
hardware and software iterations, this is simply another of those. I expect
over the years there will be more iterations. Since the imaging system
houses documents that are a core part of our business and we have SLA's
surrounding those documents, access to them, how long to keep them, etc. we
just deal with the changes in technology over time. That is the norm for
industries that deal with documents that have to be maintained for legal
reasons.

Eric W. Cowperthwaite
EDS Operations Solutions
California Medicaid (Medi-Cal)
eric.cowperthwaite AT eds DOT com


-----Original Message-----
From: Hosie, John W [mailto:john.hosie AT QWEST DOT COM]
Sent: Monday, May 05, 2003 1:02 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject:

Solutions I have seen vary widely. Scanning of paper for easy retrieval is
done in many environments, but I have worked with IBM ISV's in the past to
help them implement the IBM Visual Info product family. This ties scanning
software with a database. It has been used at many government agencies, and
is frequently also used in medical records, insurance processing, and
banking. In short, it is used wherever there is a large volume of paper.
I've seen literally miles of paper storage converted to disk images kept on
a system with less than a 200 sq ft footprint. These are often backed up
with TSM, but as others have said, it is not a friendly product to this
environment as the metadata usually searched on is not readily available for
searching with TSM. Instead, the massive libraries of paper images tend to
be converted to devices like WORM jukeboxes, where data can be saved in its
original form, remain unmolested for prolonged periods of time, and be
easily retrieved - though it may be at a significantly slower speed than the
typical disk environment of today.

-----Original Message-----
From: M DeVault [mailto:tracylists AT YAHOO DOT COM]
Sent: Monday, May 05, 2003 11:38 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject:


I had someone come to me today quizzing me about
potential solutions for long term document storage.
Long term defined as up to 30 years.

Currently these paper documents are stored in bins in
a document storage facility that manages them.  There
are *thousands* of bins, each with maybe 2000-4000
pieces of paper.  The guy that came to me was
wondering about the feasibility of scanning these
documents to store electronically.  I said something
like "not in my database you won't".

Anyway, what I'm wondering is what do other companies
do with data such as this?  I can't imagine that it is
feasible to store this stuff online (especially since
some of it is 30 year old paper).  There are legal
requirements regarding the storage of this stuff, and
I don't have a clue what it is.  Even if we could
realistically scan and store online, you have to take
into account what type of file formats and media you
use, and will it be readable 30 years from now.

Would be interested to lean what your thoughts are.
Thanks.



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

<Prev in Thread] Current Thread [Next in Thread>
  • [no subject], Ben Bullock <=