Messages

1816

Report Indexing / Re: afpdmp on sun solaris

« on: March 29, 2011, 05:38:14 AM »

afpdmp isn't a utility that's bundled with CMOD - it's generally bundled with InfoPrint Manager.  You'll likely have to download the AFP file to your PC and use afpdmp.exe locally.

    ftp://ftp.boulder.ibm.com/printers/tools/afpdmp/

-JD.

1817

Other / Re: Chaning Date that is set as Segmet Date

« on: March 19, 2011, 08:14:42 AM »

The short answer is: not without reloading the data.

The segment date is critical to the operation of CMOD - it tells CMOD which tables to search, and when documents (or loads, or tables) are set to expire.  There's no supported way to do this.  Even the unsupported ways to make this change will probably impact search performance negatively.

-JD.

1818

MP Server / Re: TSM question

« on: March 16, 2011, 06:44:17 AM »

I personally haven't gone from such a backleveled system to such a new version in one step, but you *might* be able to do a backup-and-restore of the TSM database straight from 5.1 to 5.5.

If that doesn't work, upgrade the old server to TSM 5.3, then do the backup & restore.

Let us know how it goes, and good luck!

-JD.

1819

z/OS Server / Re: new load with a date for an index table that is already closed

« on: March 09, 2011, 08:06:17 AM »

I agree that your solution is more than feasible -- it uses existing features and functionality in DB2 to achieve what CMOD can't take advantage of automatically.

Unfortunately, your changed will likely create an unsupported configuration -- so you'll want to closely examine your management's tolerance for risk.

-JD.

1820

Report Indexing / Re: Indexing- Trigger change

« on: March 08, 2011, 07:48:15 AM »

Nope, once data has already been loaded, and the index values captured, changes to the Indexing Parameters will only affect NEW documents.

You may want to create new Applications for each revision (or turn old commands into 'comments') so that the old indexing information is preserved.  (Believe me, it's useful!)

-JD.

1821

z/OS Server / Re: new load with a date for an index table that is already closed

« on: March 07, 2011, 06:29:43 AM »

Hi Egon...

Really, the best answer to this question will require more research.  Do your users frequently search for historical documents?  Which fields do they use to find these documents?  Is it just one or two fields, or is it a variety of fields?  What's your total monthly volume of documents (old and new) and how many docs are in the archive already?

While CMOD is designed more for chronological loads, there are a few things you can do (from inside the admin client, which are supported) to minimize the impact of your situation.

Expanding the number of rows per database table is the first.  This sounds counter-intuitive, but if combined with the right indexes, it can improve performance by reducing table joins disk I/O on indexes.

-JD.

1822

z/OS Server / Re: new load with a date for an index table that is already closed

« on: March 05, 2011, 08:44:49 AM »

One minor correction to Alessandro's explanation:

Segment 5 will contain a 'minimum' date of 2007, and a 'maximum' date of 2011.

For the purpose of Alessandro's example, a query for data from 2009 will query two segments:  Segment 3 and Segment 5.

In fact for ANY query between 2007 and 2011, Segment 5 will ALWAYS be queried, even though it doesn't contain any information for 2008, 2009, and 2010.

This is a performance problem, especially as you get MANY segments like this, and an end user performs certain types of wildcard searches.

I always advise customers to load data in chronological order.  And *IF* there needs to be a historical load, create a duplicate Application Group for 'Historical' data only, then bind them together at the Folder level in CMOD.

Hope this helps.

-JD.

1823

iSeries / Re: NFS for Archive Storage

« on: March 05, 2011, 08:36:58 AM »

Totally agree with Alessandro about NFS -- I *do* know places that use it, but they have decades of experience, and an entirely dedicated network strictly for NFS shares.  The problems that can be caused by even a brief NFS outage are difficult to repair cleanly, and in CMOD, could go unnoticed for weeks, months, or even years.

-JD.

1824

OD/WEK & JAVA API / Re: How to upload a document using ODWEK?

« on: February 25, 2011, 06:15:50 AM »

If you're going to move forward with this, I have a few recommendations.

1)  Data validation.  LOTS OF IT.  CMOD is an archive, and data that is improperly indexed (typos, blank fields, etc.) is lost forever.
2)  Aggregate data (many files, one generic index file) and load with arsload.  There are many technical advantages to this approach.
3)  Don't move data to some write-once media for a few days.  Corrections are bound to happen.
4)  Try to prevent duplicates.  Nothing is more confusing than two different files with identical index criteria.  (Add a date-time field defaulted to load time!)

I'm sure there are others, but these are the ones off the top of my head.  Good luck!

-JD.

1825

MP Server / Re: LDAP & arsusec

« on: February 25, 2011, 06:11:21 AM »

LDAP is probably implemented with the user exit, hence the mutually-exclusivity...

1826

MP Server / Re: arsdoc update

« on: February 18, 2011, 01:19:30 AM »

I agree with Alessandro's first point -- sounds like a lack of permissions or an Application Group configuration issue.

1827

MP Server / Re: Specify obj server using arsload?

« on: February 18, 2011, 01:17:38 AM »

I'm fairly certain this only works when you have both the library and object server on one machine.  When you specify the hostname (-h) from a remote machine, it logs into the library server, and as far as I know, there isn't a way to specify an object server remotely.

But really, you achieve this 'distributed loading' via your use multiple Object Servers...  I think if you want to scale up your load performance, it might be time to add another Object server.

-JD.

1828

MP Server / Re: 'arsdoc query -f' does not follow folder display rules

« on: February 18, 2011, 01:09:21 AM »

This might be working as designed.  When I've used the -f option (admittedly, with arsdoc get) I was trying to extract documents from a particular folder, but I wanted all of the non-displayed fields, so I could load that extracted data into a new AG on a separate machine.

It might be a bug, but it could just as easily be an enhancement request. 

-JD.

1829

MP Server / Re: OD client question

« on: February 15, 2011, 01:57:57 PM »

I suspect when the client quits (cleanly) that the data is removed.

The queue you're talking about seems to be entirely outside the control of CMOD -- it might be a bug in your fax software.

1830

MP Server / Re: OD client question

« on: February 15, 2011, 04:35:04 AM »

The client stores retrieved documents locally on a temporary basis.  If the CMOD client (and not the end user) is mixing up documents and sending the wrong docs, then you need to file a PMR right away.

You didn't mention a version number, but if you're backleveled at all, I'd recommend moving to a more recent version of the client first, since that's what IBM is going to tell you to do anyway.

-JD.