Re: massive document storage in the IFS - how to handle Mimix

My former employer uses an app to create PDFs from SPLFs. With the number
of concurrent jobs and the raw number of conversions that would occur
during a typical workday, MIMIX could not keep up. Even though the WAN
link ran at full Gb speed.

The actual issue was all of the object creation/updates that would occur
during the PDF creation process would bog MIMIX down. I think it was
trying to lock the object once it was created but the conversion process
was not yet done with it.

In their case, a workable solution was to simply not replicate during the
day. They separated the IFS folder (with about 1000 subdirectories) into
it's own MIMIX replication group and enabled that group at around 11PM then
disabled it around 5AM. That was plenty of time for MIMIX to catch up.

So the files were replicated daily. Not instant but for their use that was
good enough. And didn't require any additional software or system
reconfiguration.


On Thu, May 16, 2013 at 1:31 PM, Richard Schoen <richard@xxxxxxxxxxxxxxx>wrote:

Joel,

Not sure if you've talked to anyone yet on my team ?

Have you considered storing the documents on a SAN rather than IFS ?

If you want to schedule a discussion, let us know.

I've cced Bill Whalen on this as well.

If you need to keep the docs in the IFS, we could help with a mirroring
process if you can't get it done with Mimix.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT


------------------------------

message: 4
date: Thu, 16 May 2013 16:30:49 +0000
from: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
subject: massive document storage in the IFS - how to handle Mimix

We are storing a large number of documents in the IFS. There are 500,000+
docs stored each month. At the end of every month, a new directory is
created on the IFS and new docs are stored in the new dir.

For example, docs stored today are stored in directory 201305 until the
end of May. Then we will create 201306 and June docs will go there.

We are using RJS' Webdocs product, although the same issues would exist
with any document storage system.

There is a searchable database (the index files) on the iseries to locate
a doc, and the corresponding actual doc image on the IFS.


We purge docs after their retention period has lapsed - from both the
index files AND the actual doc from the IFS.


Mimix cannot keep up with the large amount of documents. So it was turned
off for this part of the IFS.

We would like to backup only the CURRENT directory with Mimix, which is
201305 today. All NEW docs go there and all revisions to OLD docs reside
in the current directory 201305 also.

The only changes to the OLD directories occur when documents are purged.

In this case, the LIVE system is OK, but the backup system will not purge
the old docs that were purged on the LIVE system.

Any solutions to this dilemma? Some possible solutions:


1) Run the expired document purge on both the LIVE system and the
backup (Mimix) system? This solution may have inherent issues because the
BACKUP system index file is being updated by Mimix for users adding new
docs AND the purge pgm.


2) Mimix the index files and the current IFS directory 201305, which
will produce orphan docs on the backup system. Periodically read thru the
IFS and delete any orphan docs.


3) Other solutions to keep the LIVE and BACKUP system in sync?

Thanks!



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.