Messages

1696

MP Server / Re: Recomended Setting for Max Number of Rows per ApplicationGroup Table

« on: August 07, 2012, 05:50:18 AM »

Runstats is an online operation, and doesn't require downtime -- so simply run it during a period of low activity.  If you cannot perform a 'runstats' without suffering from performance issues while serving users, you need a hardware upgrade.

-JD.

1697

MP Server / Re: Index table questions.

« on: August 03, 2012, 01:01:24 PM »

1)  You don't need it.  Use arstblsp.
2)  Yes.
3)  You don't.  You close the current table and open a new one.

It sounds like you might want to explore table partitioning -- a feature that wasn't available back when CMOD was written, but is a built-in feature of DB2 now.

1698

MP Server / Re: problem reorganizing one of the system table arscab

« on: July 26, 2012, 09:11:30 PM »

It's a bug - DB2 needs a patch.

http://www-01.ibm.com/support/docview.wss?uid=swg1IC72083

-JD.

1699

iSeries / Re: Retrieve a CMOD document and email found document

« on: July 26, 2012, 09:06:36 PM »

I was using this thread to document activity and display background for proceeding questions. Am I wrong, but are there missing entries in this thread?

I'm not aware of any edits or deletes to this thread, and I didn't notice anything strange.

1700

MP Server / Re: Cache retrieval after migrating to different instance

« on: July 23, 2012, 07:01:56 AM »

Hi Gabriela.

It's been a long time since I've migrated a Windows machine but here are some things to keep in mind regarding cache filesystems:

The FIRST cache filesystem contains the 'retr' directory, which CMOD uses to do all document retrievals.
The files inside the retr directory contain pointers (full pathname) to the location of the file you want to retrieve.
If you change the name (or drive letter) of ANY cache filesystem, you need to re-write the entire retr directory with updated info.

I have a tool to do this on UNIX platforms, but I'm not aware of one for Windows.  Contact IBM, they may have one.

1701

Other / Re: Pixtrans error

« on: July 19, 2012, 04:03:34 AM »

Sounds like you're creating TIFFs that are outside the TIFF specification, or there's a bug in the TIFF library that the client uses.

There are open source utilities for manipulating TIFFs -- LibTIFF is one of them.  You could use these open source utilities to either verify your TIFFs are compliant, or optionally re-write them into a compatible format.

You can LibTIFF at:  http://www.remotesensing.org/libtiff/
(LibTIFF.org, which appears high on Google's search results, is not current, and has not been for around 5 years due to a domain-name-ownership dispute.)

-JD.

1702

z/OS Server / Re: CMOD 8.5.0.5 client bug in Recent Folders ?

« on: July 18, 2012, 03:55:57 AM »

Larry - please don't put my name on the subject line of an append.

I've removed your name from the topic (and replies) in this thread.  Now you won't spend the rest of your life with this thread being the top hit in Google for your name... 

1703

MP Server / Re: CMOD scaling question.

« on: July 18, 2012, 03:52:14 AM »

CMOD would have information on the identity of the object servers from the server configuration in ars.cfg.  I think this is information is configured at the Storage Set level.  (ie, a file delivered to the wrong object server would still get loaded and end up on the correct object server).

-JD.

1704

General / Re: IBM Records Manager

« on: July 18, 2012, 03:47:16 AM »

I was under the impression that IRM was being phased out, and Filenet Records Manager was the new solution.  With the Enhanced Retention Management and CFS support, you can connect CMOD to a Filenet system, and manage retention inside Filenet, rather than inside CMOD or with IRM.

I haven't done an install like that -- so this is largely speculation.  Can anyone confirm?

-JD.

1705

MP Server / Re: Deleting a Report When there are 2 with the same Index Criteria

« on: July 15, 2012, 05:16:49 AM »

You can use the object ID (ie, 1234FAAZ - from your partial LoadID) as part of the SQL identifying your object in the arsdoc command -- like "report_date = 12345 and cust_num = 987654321 and doc_name = '1234FAAZ' "

-JD.

1706

Other / Re: Transformation from AFP/MTA --> PDF

« on: July 12, 2012, 04:54:51 PM »

Storing AFP is more efficient than storing PDFs.  You may want to store in AFP, and convert on the fly to PDF.  I'm not sure if you can do Metacode to AFP for storing in CMOD, and then convert to PDF at retrieval time -- but that would likely be optimal.

1707

Windows Client / Re: Error adding Application to Application Group

« on: July 12, 2012, 04:50:24 PM »

It would be helpful to know the error message, or how what you're experiencing is different from what you're expecting.

1708

MP Server / Re: migration DR550 to new hardware

« on: July 07, 2012, 06:13:29 AM »

thx JD.

So the fact that i am moving from a official IBM product (DR550) to a non-DR550 environment (seen from a hardware point) should be no problem?

Or was DR550 just a marketing name? (my opinion)

Pretty much.  The DR550 was simply a box with what was (at the time) some newly added features...  AIX (locked down), TSM (with 'Archive Retention Protection' enabled), and the DS4300 (with a feature to prevent deletion of storage by admins).  You can build your own similar system by using these (now common) features in widely-available software.

Good luck!

1709

MP Server / Re: migration DR550 to new hardware

« on: July 04, 2012, 05:07:22 AM »

You should be able to get all of the functionality of SSAM (System Storage Archive Manager aka TSM) by restoring the database backup into a newer version of TSM.

The only thing I suspect is different is the firmware tweaks on the DS4300 that prevent removal of data -- your new storage technology might have an equivalent feature though.

Let us know how it goes!

-JD.

1710

MP Server / Reclaiming Cache Filesystems...

« on: June 20, 2012, 06:37:40 AM »

Hi everyone...

I have a customer with a large number of cache filesystems.  After completing an audit, we've discovered that we can eliminate about half of the data from the cache because it's very rarely accessed.

They tried to use arsmaint to clear out the cache filesystem using 'arsmaint -c', but of course, CMOD wants to keep as much data as possible in the cache to improve retrieval performance, so it's NOT deleting what we want deleted.  The -n 0 and -x 0 parameters don't seem to change this behavior when used with the -g option.

I'm wondering if anyone has any clever ideas for forcing data out of the cache filesystems, so that we can reclaim storage space.  I've got an idea for a script to perform this, but I just want to make sure I'm not over-thinking the solution...